In the most pure and simple service oriented scenario, a single consumer interacts directly with a single service provider.

For more complex situations, intermediaries are used to provide additional capabilities:

• Security
• Transactions
• Routing
• Data Mapping
• Interface Mapping
• Reliability
• Protocol Translation
• And etc…

What exactly is an intermediary?

An intermediary is a piece of hardware or software that bridges the gap between a service provider and service consumer to provide one or more value-added capabilities (see bulleted list above). There are three primary options for intermediaries (and a host of variations on these three themes):

• Service Intermediary - Another service acts as the intermediary, providing required enterprise capabilities
• Centralized Bus - Service calls are brokered through a common, centralized focal point
• De-centralized Framework - Enterprise capabilities (security, mapping, etc.) are pushed out to the endpoints

Comparing the three options

As with so many things, there is no clear-cut winner across these three strategies, it all depends upon what you are trying to accomplish.

Option 1: Service Intermediary 

Advantages: Extremely lightweight solution.

Disadvantages: Not as robust or flexible as other approaches and requires more testing to verify proper configuration.

Option 2: Centralized Bus

Advantages: Offers lots of “out-of-the-box” capabilities that are pre-configured and available for use.  Provides a single point of control and service access management.

Disadvantages: May be over-kill in many situations, offering far more functionality and options that are needed.

Option 3: De-centralized Framework

Advantages: Provides the greatest flexibility and configurability for managing endpoints and enforcing policies.

Disadvantages: Requires a more disciplined governance process to ensure that each service is managed properly.

Working with intermediaries

Services do not generally need intermediary support except to provide value-added capabilities such as security, transactions, routing, data/interface mapping, guaranteed delivery, protocol translation, etc.  It is important that organizations carefully evaluate their requirements and select architectural strategies that meet their needs.  There are a variety of valid topologies that could be employed, depending upon your requirements, including services as intermediaries, deployment of a centralized bus (either physical or logical), and the utilization of a decentralized, policy-driven framework (“liberate the endpoints”).

Well, I have officially had my 15 minutes of fame.  Back in June, I was invited to participate in a SOA Power Panel for SYS-CON in New York.  I’ve participated in a number of expert panels over the years, but this one was unique.  The discussion took place in the Reuter’s TV studio in Times Square.  The room had a professional camera crew, a sound stage, CNN-style set, and the windows behind the panel overlook Times Square (you can actually see some of the digital billboards in the background).  It was a fantastic experience and we had a really great discussion around the current state of Service Orientation and the future holds for enterprises both large and small with respect to technology innovation and successful SOA adoption.

You can find the videocast here: SOA Power Panel - Live from Times Square. There is a brief commercial and then it takes you right into the panel discussion.

I had a ton of fun participating in it and hopefully you’ll find value in viewing it.

Immediately after the conference last month, I got caught up in vacation and then working with a couple of new clients.  I’m back in the saddle now, and wanted to share some of my experiences.

The SOAWorld conference was very well attended, including the co-located events: Virtualization World and Data Services World.  I was a bit suprised to see that so many of the presenters were vendors rather than customers or practioners.  If this had been my first SOA conference, this would be a red flag for me that SOA is still just a lot of hype.  As it was, I just found it rather odd and a little more of an empty experience than I have come to expect.  Otherwise, the conference was great and it was quite encouraging to see so much energy around things like SOA and Virtualization in spite of the state of the economy.  This gives me great confidence and reinforces a belief that I have held for some time now, which is that SOA and Virtualization make good economic sense.

My portions of the conference went fairly well.  On Monday, June 23rd, I delivered: “A Composable Service is a Good Service”.  The room was packed and that presentation was extremely well received.  The audience was very engaging, shared some of their own war stories and asked for insight on particular service design dilemas that they have been dealing with.  On Tuesday, SYS-CON staff contacted me and asked if I would be willing to step in for a speaker that would not be able to attend.  I accepted, and delivered: “A Little SOA Goes a Long Way” (my SOAWorld presentation from last November).  I also had the pleasure to participate in two expert panels, one of which was held in the Reuters studio in Time Square.  When one or more of those videos become available, I’ll be sure to provide a link.

Presentation deck downloads: “A Composable Service is a Good Service” (PDF)  and “A Little SOA Goes a Long Way” (PDF)

One final comment about the conference is that there was quite a bit of buzz about virtualization as well as “cloud computing”.  I’ve paid a little bit of attention to the virtualization movement, but thus far I have completly ignored cloud computing.  None of my clients are talking about it, and it may all be vaporware (let the cloud-related puns ensue), but it has sparked my curiosity all the same.

Up until now, there has been such a rush to roll out initial SOA services and supporting infrastructure, that little attention has been given to what good service design truly entails.  This is a natural evolution that must occur with any technology or methodology.  Throughout this summer, I plan on releasing several posts regarding proper service design.

Initially, I would like to focus on the subject of ‘composability’.  Composable services have several important qualities:

• composable services stictly adhere to their service interface, Service Level Agreements(SLAs), and supporting metadata
• service operations always leave enterprise data in a valid business state
• service operations can be called indepently, in parallel, or as a part of a larger service orchestration
• service operations can be called within or without a transaction context

When you boil it down to the essentials, composable services clearly define what they do and they do exactly what they have defined.  Consumers of composable services are then at liberty to determine how they want to use that service’s operations, rather than the service having certain built-in assumptions regarding how the service will be used or what the larger business context ought to be.

To learn more about the merits and details of composable services, I recommend the following resources:

• “Composable Services” (MSDN Library)
• “Service Composability” (SOAprinciples.com)
• “A Composable Service is a Good Service” (Presentation at SOAWorld 2008 next week)

There’s another, less tangible benefit of composable services — they are lower stress.  The frustration and stress associated with consuming a service that later fails due to some unknown buisiness logic violation is supremely frustrating.  Consuming services that are not composable is stressful, because they cannot be depended upon to work in whatever context you choose.  Likewise, publishing non-composable services for consumption is stressful because the service provider is constantly in fear that someone will ‘misuse’ a service.  This is no way to run an enterprise or encourage the adoption of service orientation. 

I’ll explore all of these topics next week in my presentation at SOAWorld on composable services.  I’ll post the completed presentation as well as perspectives from the audience next week.  Have a great weekend and I’ll see you in New York!

Primitive man and woman were forced to adapt to their environment to survive. Animal hides for clothes, crude weapons and tools made out of stone or bone, and roots or berries for food (perhaps sabertooth steak or terradactyl ribs if company is coming over). Eventually, some nearby tribe discovers fire, but reports of fire-related injuries and property destruction lead our cave dwellers to avoid this new magic. These primitive humans are doing fine with their current capabilities and they are able to meet their basic needs without dabbling with such things. Over time the nearby tribe’s use of fire expands and one very enterprising woman invents pit fired pottery. The more primitive people have heard and seen the potential of this new breakthrough and are interested in using it. Alas, the obstacles to adopting this innovation are not trivial. They must learn how to create fire, handle fire cautiously, locate and stockpile flint and tender, develop fireproof tools, create fire pits, learn to craft with clay and finally develop a process to fire the clay pots successfully. Lack of education, skills, infrastructure, resources, and processes hinder their ability to progress. Perhaps the greatest barrier for these primitive people is fear of the unknown and risk of failure. Thousands of years later, we are faced with the same technology adoption challenges — education, skills, infrastructure, resources, processes, and fear.

Modernizing legacy information systems is not unlike the modernization efforts that have occurred for thousands of years. In fact, legacy or heritage systems are often referred to as ‘dinosaurs’. Correspondingly, the same types of obstacles must be overcome:

• Education — There is a mindset shift that must take place to understand the service oriented way of thinking. At first glance, services are just fancy objects. The reality is that service orientation requires a much broader, end-to-end view of the enterprise, complete with process-centric alignment, layered architecture, contracted interfaces, standards-based connectivity, and full life cycle governance. I have blogged about the alignment of service orientation and the unique qualities of SOA before. Also, David Ing has some interesting thoughts on service orientation.
• Skills — A well documented skills gap exists around service orientation. Joe McKendrick sites it as one of the two things killing SOA in 2008 and the guys over at ZapThink have been alerting the industry to the dangerous SOA skills gap for quite some time. Why is this? Service orientation skills cannot be acquired by attending a conference or reading a book (although I do have a book that I HIGHLY recommend). Academic learning as well as hands-on mentoring is required. Moreover, there are nuances to effective service orientation, service design, process alignment, and enterprise governance that require time and experience to develop. There are new technologies, design patterns, techniques, and methodologies that must be introduced and ultimately absorbed. This will require instructor-led training, research, hands-on mentoring, and practical experience to develop proficiency in these areas.
• Infrastructure — Contrary to popular belief, a service oriented infrastructure cannot be achieved by purchasing an Enterprise Service Bus (ESB) from a vendor and adding water. There are, in fact, a variety of infrastructure elements (service registry/repository, governance suite, business process engine, policy manager, policy enforcer, and etc.). There is a great little SOA infrastructure white paper that a consortium of vendors put together a while back. Additionally, be sure to avoid the trap of assuming that you need to have your SOA infrastructure fully mature on day one. Eric Newcomer has a great post from a couple years back regarding an incremental adoption of SOA infrastructure.
• Resources – There are several ways to slice the resource issue. For effective adoption of SOA, you will need a pool of human resources (with appropriate education and skills), technical resources (infrastructure, knowledge management and collaboration tools, as well as design and development tools), and you will need expert resources (developed in-house, or brought in from an outside source initially).
• Processes — All the education, skills, infrastructure, and resources in the world won’t amount to a hill of Java beans without effective processes for governing the adoption of service orientation. You will need processes for service selection, service design, quality assurance and testing, policy enforcement, and runtime service management. Effective governance can make or break your adoption of SOA. I have blogged on the importance of service oriented governance numerous times.
• Fear – People fear change. Service orientation appears threatening to many people at first due to the changes required in adopting it. New patterns of thinking are required around how to solve customer problems. Skills must be adapted, other skills developed from scratch. New infrastructure and resource pools must be created and processes must be adapted and new processes created. These changes can be intimidating. A considerable degree of people change management must be accepted as a part of a successful transition toward service orientation.

Service orientation adoption is challenging in its own right. It becomes increasingly challenging when you factor in the dinosaurs that must be modernized as a part of the adoption process. Immediately, questions begin to arise:

• What systems and/or business processes should be modernized?
• Should we migrate, expose, or leverage our existing legacy assets?
• Should adoption occur within a particular line of business or across the whole of the enterprise?
• How will modernization impact existing teams and project roles?

These questions and many more must be explored as part of the adoption of service orientation. I explored several of these topics in a recent public webinar - Enterprise Modernization and SOA Concepts (pdf).

Another resource you might consider is a new course that Web Age has been offering since April of this year. It is a two-day workshop that explores the modernization of legacy applications, SOA concepts, modernization challenges and risks, and various strategies for modernizing legacy systems. It is aimed at team leads, architects, managers, and legacy application support personnel. For more details, check out the course details - WA1657 Application Modernization and SOA Concepts.

Adopting service orientation and “moving out of the Stone Age” is not a simple task. It requires intentional allocation of time, energy, and resources. It cannot and should not be approached in an ad-hoc fashion. Technology adoption has always been challenging, just like when ancient man and woman adopted fire. When it comes to service orientation, be sure that you work through the necessary steps of adopting education, skills, infrastructure, resources, processes, and addressing the fear factor. Otherwise, you just might get burned.

For those of you out there championing the cause of service orientation, the title of this post may catch you off guard. Likewise, casual observers of the service orientation movement might assume that developing services for reuse is the norm. Believe it or not, my title is not ironic, sensationalized, or tongue-and-cheek. I honestly believe that given the way most enterprises have established SOA, only a fool would build reusable services. Why might you ask? Simple. Rational self-interest.

What does rational decision-making have to do with adopting service orientation and developing services for reuse by others? I’m glad you asked. The simple fact is that the creation of services as reusable rather than one-off solutions is not free. Experts peg the expense of creating reusable solutions anywhere from base cost +30% to base cost +200%. It is significantly more expensive to build for reuse. On the flip side, it is considerable less expensive to reuse an existing service. Experts peg the expense of reusing a solution rather than creating one from scratch to be anywhere from base cost - 80% to base cost - 20%. In short, developing reusable services is very expensive, but once you have reused a service multiple times, a return on your initial investment will emerge. I blogged about this several months ago (SOA ROI, deconstructed) and provided a link to a whitepaper that explores this subject in more detail.

From an enterprise perspective this all seems very logical and the additional investment is easily offset by the value of the reuse over the long term. The problem is that in the short term, rational self-interest will drive individuals to never develop reusable services.

Consider the following scenario:

Bill is a project leader and is creating a service oriented product portal. He realizes that several of the services he needs could be designed in a fashion to foster reuse. As a good citizen of the enterprise, he directs the team to design these services in a more flexible and enterprise-centric fashion. Additional effort is spent during design and potential enterprise customers are interviewed regarding their potential needs. The added cost puts a strain on his budget but is certainly the best answer for the enterprise overall.

Sharon is another project leader in the same division as Bill. She is creating a product reporting application. She discovers that several of her requirements can be met by simply reusing the services created by Bill’s team. Other services that she needs are then developed as unique, one-off services to contain costs. Sharon uses a fraction of her budget to produce this solution, freeing up resources to meet other goals for the year.

At the end of the year, both Bill and Sharon will be judged based upon what they were able to accomplish with their respective budgets. In the absence of some acknowledgment of Bill’s contribution to the pool of available services or similar affirmation of Bill’s decision, then he is in hot water. Sharon looks like a hero and Bill comes off as a fool. Knowing this, Bill will be less likely to develop reusable services in the future (unless he can directly benefit in a very short timeframe).

Adopting service orientation and encouraging reuse is great, but what will compel divisions and individual project teams to actually play ball? In the absence of some sort of incentive structure, charge-back mechanism for using services, or similar recognition for contributions to the greater good, no one will develop reusable services. Rational self-interest will drive each group and each team to develop services that only help themselves and which will, in effect, re-create the same silos that we are trying to supplant.

All of this points to a very real gap that exists within many enterprises that are adopting or at least exploring SOA – lack of business buy-in. Someone within the business needs to recognize the true cost of SOA and put in place some sort of incentive structure to encourage teams to contribute to the greater good of the enterprise. SOA is not a short-term, quick-win approach. It requires strategic planning and long-term investment windows.

So what if you have no business buy-in? Are you sunk? No. You may not be able to get traction around reuse, but you can go for ease of integration, the benefits of standardization vs proprietary solutions, lower maintenance costs due to the loose-coupling that SOA offers, the configurable nature of services and process, and other benefits that do not depend upon long-term reuse time windows.

Adopting service orientation requires a considerable amount of strategic planning and up-front design work. There are a variety of business drivers around SOA and reuse is certainly a popular one. Is it foolish to develop reusable services? It is if you attempt to do so within an organization that is not viewing things strategically or is unaware of the long-term impacts of service orientation. In the absence of business buy-in and strategic incentives, only a fool would build reusable services.

I’ve been on the road a lot lately, working with various clients, writing courseware, writing articles, and basically doing everything EXCEPT for blogging.

Here’s some of what I’ve been up to:

• Article: SOA Governance: Start Small and Build Incrementally (published March 6th by SYS-CON)
  
• Presentation: SOA Adoption Planning (1-hour seminar I delivered in February)
• Presentation: Delivered a virtual presentation for the Dallas SOA Users Group. I had a client engagement in Calgary, so we tried out a virtual delivery and it was quite successful.
  
• Book: Service Oriented Architecture: A Field Guide for Executives (August 2008, Wiley Press)
• Courses: Updates to various courses plus new courses coming soon for Project Managers, Mainframe and Legacy Personnel, and some Best Practices content. For more information, check out Web Age’s SOA curriculum.
• Web-based SOA Training: I’ve been working on a new offering at Web Age in which some of our content is made available as recorded, flash-based audio/visual presentations that can be hosted internally within an organization’s intranet. More details to follow.

I’m going to try and be more diligent about blogging in April. I especially hope to share insights and perspectives that I glean from the IBM SOA IMPACT conference in Vegas. I’ll be attending that conference in early April and conducting a Birds of a Feather session on governance.

A rose by any other name would still smell sweet, just as a strategic corporate initiative is no more or less successful due to its use of certain en-vogue terms such as Enterprise Architecture (EA), Business Process Management (BPM), and Service Oriented Architecture (SOA). I was struck by the realities of the semantic terminology game that we play while attending the Open Group’s 17th Annual Enterprise Architecture Practitioners Conference in San Francisco last week.

There was a general consensus at the conference that there are common themes running throughout enterprises that have various labels attached. Those themes include the following:

• Business and IT need tighter alignment
• Visibility between business and IT should be increased
• Governance is needed at various levels of the organization to reduce risk and protect ROI
• Business processes and technology solutions should be more flexible and better able to adapt to changing demands
• Business processes and technology solutions should be designed intentionally and with sufficient rigor

The labels attached to these trends vary from enterprise to enterprise. Some drive toward one or more of these goals under the EA umbrella, others under the BPM label, and still others are talking about SOA. Some organizations use two or even all three labels. Regardless of the attached label, it is a strategic initiative at the business unit or enterprise level that aims to improve business predictability and squeeze more value out of technology investments. This become readily apparent as the SOA Governance panel (other panelists included Michael Nassar of IBM, Stephen Bennett of BEA, and Mats Gejnevall of Capgemini) that I participated in last Tuesday was quickly challenged by the audience to delineate between governing SOA and governing EA. The line between these disciplines is quickly blurring within many enterprises.

So what’s the take-away for us? We need to look past the labels that are applied and take a more business-focused and goal-oriented approach to education, mentoring, and ultimately solution development. We need to probe more intently with our clients to discover their strategic direction, business drivers, and objectives for one-year, two-year, and five-year timeframes. We may have the perfect service offering for them, but because it is labeled as SOA, BPM, or EA, it may not jive. I have several examples of this:

• Back in November, I wrote about Synovus, a mid-sized bank in the southeastern US, that spoke at SOAWorld in San Francisco. They were a non-traditional case study in that they did not set out to adopt SOA. They just knew that they had various business problems that needed to be solved. They set out to solve those problems and in the process created a SOA. If someone had approached them a year or two ago with an offer to enable their enterprise through SOA, they would have dismissed it because they were not doing ‘SOA’, at least not in name.
• Last year, a US Department of Defense (DOD) agency participated in one of my SOA governance workshops. Several of the students made the observation that although we had originally set out to talk about SOA governance, the vast majority of the concepts, principals and best practices that we discussed were applicable to EA. The mentoring engagement quickly broadened in scope and we began speaking in terms of governing the enterprise and aligning with business strategy. The principals, methodologies, and best practices all flowed very nicely into this broader scope. The ‘SOA’ label that we had begun with was immaterial to the objective — better governance of enterprise assets and business processes.
• Throughout last year Web Age Solutions worked with various clients that wanted to service orient their enterprise assets and orchestrate those assets as a part of executable business processes. Some of them called that SOA, others called that BPM. Some wanted us to describe SOA in the context of BPM and others wanted us to introduce BPM in the context of SOA. At the end of the day, the solution was the same. It was the same standards, same tools, and the training was about 90% the same. The difference was found in the labels attached and the emphasis upon certain key concepts.

It is imperative that we understand our client’s needs, perspectives, and bias with respect to trends and labels. At the end of the day, we are enabling them to solve business problems, not in order to check a box next to an acronym.

Over the last couple of months, I’ve been focusing quite a bit on helping people think about how much SOA they really need to address their business objectives. It turns out that you can, in fact, have too much of a good thing.

In November, I spoke at SOAWorld in San Francisco: “A Little SOA Goes A Long Way”. Then in December, I was interviewed by Jason Bloomberg and David Linthicum of ZapThink fame: “How Much SOA Do You Need?”. The presentation is available as a video webcast and the interview is available as an audio podcast.

“A Little SOA Goes A Long Way” (video webcast)

“How Much SOA Do You Need?” (audio podcast)

Additionally, my upcoming book (Wiley Press, Spring 2008) devotes an entire chapter to the subject of right-sizing SOA.

Have any experiences to share regarding how much SOA is just right and/or too much? Feel free to comment and discuss!

“SOA is fine, unless of course you want a system with decent performance.”
“XML is slow and all the added layers that SOA demands will cripple any marginally high-transaction system.”

I’ve heard uneducated statements like these, and many others regarding SOA, XML, and the prospect of service orienting high performance, mission-critical systems. The truth is, that these statements are ill-informed and those that make them rarely have anything beyond vague anecdotes from “some Fortune 500 company a few years ago” to back them up.

Generalizing SOA

First, we’ll start with some broad sweeping generalizations regarding SOA. These have some truth to them and do, in fact, characterize a typical utilization of SOA. In general, SOA is realized as follows:

• Multiple layers of abstraction
• Standard XML message format (typically SOAP)
• Standard Web transport (typically HTTP)
• Non-reliable (no guaranteed delivery by default)
• Oriented more toward reuse and agility rather than performance or scalability

Breaking the perception barrier

There is more than one way to skin a cat and there is more than one way to implement SOA. HTTP is simple and cheap, but not robust or performant. HTTP-based SOA’s are certainly the most common as they are simple to setup, simple to exploit, cheap, and widely available. The problem is that HTTP isn’t reliable, suffers from high latency, has limited bandwidth, and does not offer any sort of message buffering or message durability. High performance SOA solutions must take a different approach. Messaging middleware solutions such as IBM WebSphere MQ, SonicMQ, or TIBCO hold one answer. These platforms are designed with scalability and performance in mind and are increasingly supporting SOA right out of the box.

High Performance SOA

Designing a high performance SOA solution is possible. Gerardo Pardo-Castellote, PhD, recommends the following steps:

• Select a Messaging Fabric/Bus
• Select an appropriate Architecture (hub-spoke, clustered, federated, peer-to-peer)
• Identify Quality of Service requirements (reliability, latency, flow control, lifespan, history, transport priority, etc.)
• Leverage Performance Technologies (multicast, message batching, asynchronous writes, compression, etc.)
• Select and monitor appropriate Metrics (throughput, latency, scalability, etc.)

Still skeptical? Consider the following examples:

• Network Management example
• Data Sharing example
• Data Fusion example
• Emergency Response example

As with so many things, there just is no simple answer. The only absolute is that there are no absolutes. SOA is a style of enterprise architecture for which the focus tends to be more upon flexibility and reuse. However, to the extent that solution performance is a priority, the architecture can be tweaked accordingly.

For further reading on this topic, I suggest the following:

• High Performance SOA (Jason Bloomberg)
• High Performance SOA - A Contradiction in Terms? (Patrick Leonard)
• Implementing a High Performance SOA (gridwisetech.com)
• High Performance SOA with Software Pipelines (Cory Isaacson)