The term service-oriented architecture (SOA) is one of the hottest buzzwords in IT today. Indeed, it is difficult to pick up any IT-related magazine and not discover three, four or more articles on this topic. However, while a good number of senior executives are clamoring for SOAs, I find that there is a great deal of misinformation on this topic and even less knowledge on what it truly takes to implement an SOA environment.
SOA refers to the use of loosely coupled (meaning that they should be independent, sharable and technology-agnostic) services that are built to provide reusable business processes that enable communication between systems and the creation of entire applications within an organization. These services will typically pass data between each other as they perform some predefined common process. The process could be basic data movement, much more intricate data transformations, data cleansing or the use of multiple services to create a multistep, complex process.
The goal of an SOA environment is to make these services readily available so that they can be accessed without knowledge of their underlying technology platform implementation or programming language. In addition, the SOA environment should monitor the use and performance measurements of these individual services within the environment. In other words, a good SOA environment has standardized, sharable, common services that are well understood and highly efficient.
Many factors are driving the adoption and implementation of SOAs in organizations. Chief among these factors is that the current IT application architectures are far too rigid, inflexible and inefficient. In fact, a survey by the Business Performance Management Institute found that 36 percent of companies' IT departments state that they have "significant difficulties" (27 percent) or "can't keep up at all" (nine percent) with business demand. In addition, only 11 percent of executives say they're able to keep up with business demand to change their technological processes.1
SOA promises to give companies a portfolio of services (think common processes) that can be mixed and matched without difficulty to create automated business processes with the hope of reducing application development time and costs. This is the promise that has been sold to many companies. Let's look at what the reality has been.
Your company's key executives have bought into the suggested value of having an SOA environment, but what are the actual tasks that companies typically take in building this environment? In my experience, these companies are building messaging buses utilizing technologies such as TIBCO and webMethods, along with a host of standards such as OASIS, XML, CORBA, DCOM and many others.
How successful are these messaging bus implementations? Most organizations I have seen are not building standardized processes with their messaging buses but rather are using them to mimic point-to-point interfaces. This approach is successful in slowing down already overburdened point-to-point interfaces; however, it completely undermines the entire goal of SOA, which is to simplify overly complex IT environments.
For example, I recently visited an executive of one of our clients. In between our various meetings of the day, we stopped by an internal event that they were holding called a "solutions showcase." In this showcase, they had set up a vendor floor-like area where many of their large IT project teams could discuss their efforts. One of the booths featured the messaging bus that they were currently implementing. The executive and I approached the booth (neither one of us had name tags so we were incognito), which was being staffed by the large consulting vendor that was building the bus. The featured attraction at this booth was a mock messaging bus that was constructed using thousands of LEGOs. Yes, those same LEGOs that you and I played with as children. The LEGO set was supposed to move the LEGO blocks between the different LEGO buckets. (I guess this was supposed to be what a messaging bus does!) As soon as he turned on the demo, the little LEGO pieces that were supposed to be gently moved between the buckets started flying all over the vendor floor, to the dismay of the 10 or so people watching this catastrophe.
At this point, they immediately stopped the demo and I must confess that a little devil sitting on my shoulder made me offer aloud the comment, "That is the most realistic demo I have ever seen!" After the audience laughter settled down, I began to ask the vendor a couple of very simple questions on their SOA architecture, including how they will monitor their environment and track the efficiency of their messages. The vendor looked me in the eye and said that the key to their project was their "data meta repository." That is not a misprint. Data meta! That same little devil on my shoulder then coerced me into asking, "Could you please tell me more about your data meta repository?" With this level of intelligence, it is not surprising that the project has not delivered on its promises.
Please do not misinterpret this article to be anti-SOA. An SOA environment can provide tremendous value to an organization; however, proper metadata management that has already been implemented is an absolute necessity to make the SOA environment a reality. In my next column, I will show how metadata management enables an SOA environment and share the necessary steps that an organization must take in order to even begin an SOA initiative.
- Christopher Koch. "The Truth About SOA." CIO Magazine, 15 June 2006.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access