Todd Biske: Outside the Box

Archive for October, 2006

Scott Mark posted some comments on his blog about ESBs versus Smart Routers. This is one of my favorite subjects, and I posted some extensive comments on Scott’s blog. I wanted to go a bit further on the subject, so I decided to post my own entry on the subject.

First off, full disclosure. My personal preference is toward appliances. That being said, I don’t consider myself an ESB basher, either. If there’s one takeaway from this that you get, it should be that the selection of a product for intermediary capabilities is going to be different for every organization, based upon their culture and who does what. I spoke with a colleague at a conference last June who had both an appliance and software-based broker, each performing distinct functions, largely due to organizational responsibilities. While both products could have provided all of the capabilities on their own, there were two different operational teams responsible for subsets of the capabilities.

Let’s start with the capabilities. This is the most important step, because as soon as you throw ESB’s into the mix, the list of capabilities can become volatile. The area of concern that I believe is the right set of capabilities are those than belong “in the middle.” The core principle guiding what belongs “in the middle” are things that developers shouldn’t be concerned about. Developers should be concerned about business logic. Developers should not have to code in security (in the Authentication/Authorization sense), routing, monitoring, caching. These are things that should be externalized. J2EE and .NET try to do this, but they still make the policies part of the developers domain, either by bundling into an archive file or by using annotations in source code. In a Web Services world, these capabilities can be completely externalized from the execution container. My list of capabilities include:

• Routing
• Load Balancing
• Failover
• Monitoring and Metrics
• Caching
• Alerting
• Traffic Optimization
• Transport Mapping
• Standards Mediation (e.g. WS-Security 1.0 to WS-Security 1.1)
• Credential Mapping / Mediation
• Authorization
• Authentication
• Encryption
• Digital Signing
• Firewall
• Auditing
• Content-Based behavior, including version management
• Transformation (not Translation)

Note that one area commonly associated with ESBs these days is missing from my list: Orchestration. I don’t view orchestration as an “in the middle” capability. Orchestration does represent an externalization of process, just as we are externalizing these capabilities, however, an orchestration engine is an endpoint. It initiates new requests in response to events or incoming service requests. Adapter-based integration ala EAI is also not on my list. Many cases fall into the category of translation, not transformation. There is business logic associated with translating between an incoming request, and one or more requests that need to be directed at the system being “adapted.” The grey areas that are tougher to draw a line include queueing via MOM and basic transformation capabilities.

Now, if we take this list, you’ll see that it can be covered by products from three major areas: Networking and Security (normally appliances), Software Infrastructure (ESBs, Application Servers, EAI/BPM), and to a lesser extent, Systems Management (most management systems employ an agent based architecture. Most Web Services Management providers include gateways and agents that perform these). My own tracking and discussion with various vendors that deal in this space yields a diagram like this:

As you can see, these three areas overlap. There’s a convergence of capabilities in the middle, but not complete overlap. Also, note that this is more about the target space of the product versus the form factor. There are some surprises on the diagram. SOA Software’s Network Director (formerly BlueTitan) and perhaps IBM’s WebSphere XD are much more like network devices than software infrastructure, even though they are software based.

So how do you choose one of these providers? First off, I believe all of the products that control the capabilities I listed should be policy-driven, utilizing distributed enforcement points with centralized management. The notion of policy-driven is extremely important, because we need to externalize policy management from policy enforcement. Why? If you look at those capabilities, who sets the policies associated with them? It likely should be multiple groups. Information Security may handle authorization and authentication policies, Compliance may handle auditing, Operations will handle routing, and the development team may specify transformations in support of versioning. Right now, the management tools are all tightly coupled to the enforcement points. Therefore, if you choose an ESB for all capabilities, your Information Security team may need to use Eclipse to set policies, and they may have visibility into other policy domains. This could be a recipe for disaster. You need to match the tools to the groups that will be using them. Software infrastructure tools will likely be targeted at developers. Network and Security tools will likely be targeted toward network and security operations, and may be in an appliance form factor. Systems Management will also be operations focused, but may have a stronger focus on monitoring and a weaker focus on active enforcement. It may involve the management of agents. Think about who in your organization will be using these tools and whether it fits their way of working. When evaluating products, see how far they’ve gone in externalizing policy. Can a policy be reused across multiple services via reference? Can policies be defined independent of a service pipeline? Is there clear separation of the policy domains? Do you have to be a developer to configure policies?

In short, I think if you nail down the capabilities, eliminating the grey area in integration and transformation, and have a clear idea of who in the organization will use the system, the product space should be much easier to navigate, for now. This convergence will continue, as smaller vendors get gobbled up and registry/repository becomes a more integrated part of the solution as a policy repository. It will begin to converge with the Configuration Management database space as I’ve previously discussed. Network devices continue to converge with MPLS and the addition of VoIP capabilities. If you have an intermediary today, continue to watch the space every 6 months to a year to see what’s happening and know when it might make sense to converge.

Greetings from the Shared Insights EA Conference. I just finished attending a case study given by Eric Carsten of Ford Motor Company. It was an excellent presentation in two ways. First, the concerns he outlined that their EA organization was trying to address certainly hit home with my own experiences within a large enterprise: technology consolidation and everything that goes along with it. He had a great item when he showed five business goals, and how those same goals could be applied to the technology domain. This was great, however don’t misinterpret this as business/IT alignment. For example (hypothetical, Eric didn’t say this), a goal of Ford could be consolidation. Applied to the business, this would be a reduction in the number of models being sold. Applied to IT, this would be a reduction in the number of technology vendors being used. While both will contribute to lowering costs, it would be difficult to directly show how a reduction in the technology platforms leads to a reduction in the models being produced.

This leads to the second thing that I found interesting. Ford’s EA organization, at least what I inferred from this one presentation, is very technology focused. It is involved with governing project technology decisions. That is, it is focused on the “how” to do things, rather than the “what.” This poses a problem if SOA is expected to be driven from the EA organization. If the EA organization is too focused on the how, it will help out in selecting service technologies but it won’t help on what services to build. I think this is a natural evolution for an EA group, however, it’s a big, big challenge. Technology selection is inherently part of EA, akin to cleaning your own house. Choosing what solutions to build on that technology is a business decision. This means that the EA organization must be involved closely with the business in order to pull it off. If they aren’t, what organization will drive the SOA effort? Perhaps that’s an indication that the organization isn’t ready for it yet. Once the EA organization has been invited to the portfolio planning/IT governance table, their chances of success will likely increase. I think I’ll ask this question now of the panel discussion that I’m sitting in…

Robin Mulkers had this post :Transformation in a SOA recently. He provided three options for providing transformation services:

1. A central message or transaction broker ESB platform is using connectors to access the various back-end systems and mediates between the service consumers and the service providers. The service consumers don’t see the mediation, they see a semantically coherent service offered by the mediation platform. It’s an EAI like architecture.

2. Externalize the transformation as a service, that’s the solution described by Zapthink in their paper. In this scenario, it is up to the service provider or the service consumer to detect an unsupported message format and know which transformation service to use to transform that unsupported format into something understandable.

3. It’s up to the service provider to implement the transformation as part of the service.

The options were a bit confusing, in that what the first one was really saying was the use of a centralized broker that was the responsibility of some centralized team, and not the service provider. If a centralized team handled this, that team “would have to be aware of all the legacy messages and schemas used throughout the enterprise,” as stated by Robin. He continues on to emphasize that the service provider is responsible for exposing various interfaces to the service functionality, using whatever infrastructure might be appropriate.

Let’s think about this for a second, however. This is where problems can arise. Often times, a group will choose technology based upon familiarity. In this scenario, the team providing the service is likely composed of developers. What’s the tool they can directly use? Their code. If an organization has some form of intelligent intermediary (XML appliance, Web Service Intermediary, ESB, etc.), the developer may not have access to the management console to properly leverage the transformation capabilities of the device. Note that this problem goes beyond the developer, however. What are some of the other core capabilities of an intermediary? Security. For a number of reasons, many organizations want to centralize the management of security policies within the organization. I’m sure they don’t have access to either code or the intermediary console. What about routing policies? That’s probably under the domain of an infrastructure operations group. What about audit logs? The compliance group may want to control these.

So, now the situation is that I have at least four different policy domains, each managed by different areas of the organization, all capable of being enforced by specialized infrastructure. Do I let these groups use the tools they have access to, all of which may take far longer in getting policy changes out into the enterprise (e.g. a development cycle for transformations coded in the service implementation) limiting the agility of the organization? If I want to leverage the specialized infrastructure, I’m in a bind as the console probably provides access to the entire policy pipeline for a service, putting my environment at risk.

What we need is an externalized policy manager, complete with role-specific access to particular policy domains. So who’s the vendor that’s going to come up with this? Unfortunately, policy managers are tightly coupled to policy enforcement points, because there are very few standard policy languages that could allow a third party manager. Security is the most likely policy domain, but even in the broader web access management space, how many policy managers can control heterogeneous enforcement points? It’s more likely that the policy managers require proprietary policy enforcement agents on those enforcement points. So, how about this vendors? Who’s going to step up to the plate and drive this solution home?

While I can’t think of any practical applications right now, this is just cool. Anyone want to go watch The Abyss?

A favorite topic of mine, SOA for IT, has come back up with a blog from Robin Mulkers at ITtoolbox. He attended the Burton Group’s Catalyst conference in Barcelona and heard Anne Thomas Manes talk about her Infrastructure Services Model.

Robin states:

Instead of Account management and order processing, think of services like authentication, auditing, integration, content management, etc. etc.

Security is a great example. If you’re a large enterprise, there’s a good chance that you’ve adopted some Identity and Web Access Management infrastructure from Oracle, CA-Netegrity, IBM or the like. Typical usage involves installing some agent in a reverse proxy or application server (policy enforcement point or PEP) which intercepts requests, obtains security tokens and contextual information about the request, and then communicates with a server (policy decision point or PDP) to get a yes/no answer on whether the request can be processed. Today, this communication between the PEP and the PDP is all proprietary. Vendors license toolkits to other providers, such as XML appliance and Web Service Management products, to allow them to talk to the PDP. In this scenario, the PDP is providing the security services. Why does this need to be proprietary? Is there really any competitive difference between the players in this space? Probably not. If there were standard interfaces for communicating with an authorization service, one PDP could easily be exchanged for a new PDP.

One challenge in the infrastructure space, however, is understanding the difference between implied capabilities and services. Take routing, for example. In a typical HTTP request, routing is implied. The actual service request is to GET/POST/PUT/DELETE a resource. It’s not to route a message, other than through the specification of a URI. It’s likely that the URI used can represent one of many web/application servers, the exact one determined by a routing service provided by the networking infrastructure or clustering technology. In this case, routing is an implied capability, not an explicit service. The security example is an implied capability from the point of view of the service consumer, however, the communication between a PEP and a PDP is an explicit service request.

In applying SOA to IT, it’s important to identify when a capability should be implied and when it should be explicitly exposed. In some cases it may one or the other, in other cases it will be both. The most important services in SOA for IT, in my opinion, are the management services. In both the security and the routing example, the decision made are based upon policies configured in the infrastructure through some management console or management API/scripting capability. Wouldn’t it be great if all of the capabilities in the management console were available as standards based services? Automation would be far easier. This is a daunting challenge, however, as there are no vertical standards for this. We have horizontal standards like JMX and WS-DistributedManagement, but there are few standards for the actual things being managed. Having a Web Service for deploying applications is good, but odds are that the services for JBoss, WebLogic, and WebSphere will have significant semantic differences.

Infrastructure services aren’t going to happen overnight, but it’s time for IT Operations Managers to begin pushing the vendors for these capabilities. The time is ripe for some vendors in the management space to switch from management of Web Services ala Sonic/Actional and Amberpoint to management using Web Services. In the absence of standards, it would be great if some of the big systems management players decided to create a standards-based insulation layer and present a set of services that could be used with a variety of infrastructure products, allowing IT Operations to leverage automation and workflow infrastructure to improve their efficiency.

This topic has been wandering around my head for a while, and a recent post by Joe McKendrick of ZDNet brought it back to the forefront. Sidenote: why can’t people get Joe’s name right? David Chappell of Sonic Software called him Joel McKendrick, and every time David Linthicum quotes him in his SOA Podcast, it sounds like “Joe McItrick.” Anyway, in this entry, Joe has some quotes from John deVadoss of Microsoft. He states:

In the Q&A, deVadoss says the most important thing about SOAs is that they are a means to an end — not an end in and of themselves. “There is . . . a preponderance of what I call the top-down, big-bang mega approach, which is often guilty of trying to ‘do SOA’ as opposed to delivering business value,” deVadoss says. “The fundamental problem with the big-bang mega approaches to SOA is that they almost always end up being out-of-sync with the needs of the business.”

There’s a lot of truth in that statement, but how do organizations end up that way? One suspicion that I have is that the organization was already that way to being with. I had the opportunity to have lunch with someone two weeks ago who is a VP of Operations (business operations, not IT) at a local enterprise. We discussed how he was leveraging BPM technologies. I left the lunch thinking how great this was that the use of IT was being driven by a tech-savvy business executive. There wasn’t any discussion about top-down or bottom-up. Having a plan for where the business needed to go was part of his job, not something that needed to be justified. He knew what could be taken on and where IT fit into the picture, and was able to successfully leverage it. Take now, in contrast, an enterprise where IT is a bunch of order takers, without clear strategic planning. It’s certainly possible that the lack of strategic planning goes all the way back to the business, as well. The lack of IT alignment may just be a symptom of poor alignment throughout the organization. Organizations like that are going to struggle to accomplish anything of a strategic nature, SOA and BPM just being recent examples. While there may be some room for some incremental success, there are bigger problems that exist preventing it.

In short, while SOA is touted as some as the tool which will increase IT and business alignment, so far, it’s only the enterprises that already had great IT and business alignment that are truly leveraging it successfully. Think of it like the difference between the automobiles that we drive to work and a Formula One race car. Technology in the race car could allow us to drive ridiculously fast, but if you put the average driver in that car, they’ll crash and burn. It’s only the drivers that were already on the racing circuit that can stay on the track. For the rest of us, there is a culture change that must occur in the organization before we can get on the track.

Yes, a Momentum shift is underway! While I could be talking about my hometown Cardinals playing better baseball and beating the Padres tonight, I’m not. Instead, I’m talking about MomentumSI, my new employer. I’ve joined their team of top consultants on SOA and am looking forward to helping their clients be successful with their SOA initiatives. MomentumSI is a blog-friendly company, as evidenced by the blog of their CEO, Jeff Schneider. I look forward to having a little bit more freedom in some of the topics that I cover. I previously was part of an Enterprise Architecture team for a financial services company, which put some limits on things that could be discussed. If you’ve got questions about me, questions about Momentum, or topics you’d like to see covered, please don’t hesitate to ask.

I was reading the October 2 edition of eWeek, and on page 16 there is article by Darryl K. Taft titled, “AJAX, SOA to Merge.” The rate of acronym mergers and acquisitions is beginning to rival the rate of SOA company mergers and acquisitions. The bulk of the article is devoted to a discussion of some announcements from JackBe and TIBCO. The one that set me off was on JackBe’s Presto platform which now includes an “ASB (AJAX Service Bus).” So now I need a specific service bus to each technology I use to expose services? I thought that technology mediation was a key feature of an ESB? Of course that’s not entirely true since I seem to be hearing more and more about ESB federation. That seems like an oxymoron to me. We need to forget about all of the marketing buzzwords and focus on the capabilities (not acronyms) that are needed by the enterprise like mediation, transformation, security, etc.