Life of Integration Pattern
For all these years of working in Integration domain, one thing that has been conspicuous is the constant factor of change. It doesn’t matter how promising a technology is in terms of ease of implementation, support for business agility, promoting better maintenance or may be user friendliness, we will invariably see that things get changed. I remember in one client (Investment Bank) we did implement an integration solution brainstorming in the meeting rooms, burning calories, staying back late in office, with impeccable architectural standards, earning accolades from various quarters, only to find that three years down the line the entire solution was migrated to another product. This makes me wonder about the lifecycle of the solution. Few days back I wrote a paper where I tried to simulate and find out if we can ever predict the change in advance to help the managers, architects make a better decision. The following two paragraphs is my POV (A consulting term which means Point of View) excerpts from that paper.
Technology lifecycle often follows growth pattern similar to product lifecycle i.e. a S shaped curve. If specific integration technologies are considered from past (for example CORBA, RPC etc) in most cases lifecycle seems to follow the S shaped curve. If you are interested you can do a little google search when you can easily find out how CORBA was deemed to be the most promising middleware option, sometime back. These days I hear that the people who were writing CORBA specifications are now busy with WSDL specification. I hope I was able to convey my point that change is always constant in the Integration Domain
Integration has various technology options for example RPC, Com D-Com, CORBA (in the past) along with many architecture patterns like Hub and Spoke, SOA etc. Just because I mentioned all these terms together it doesn’t mean that they are all related together or used in the solution. Also these days on the horizon we have virtualization and Integration-as-a-Service. For each architectural pattern there are specific products (commercial or open source) associated and marketed by different product companies. The relationship is often many to many. Thus today, if you are little bit familiar about various tools you will know how all products ( Tibco, WebSphere, WebMethods etc) support Service Oriented Architecture (SOA). Again the same software (perhaps TIBCO) will offer integration options/ patterns like sync- async, publish- subscribe etc. That’s why I mentioned the relationship is many to many.
A firm trying to leverage on an integration style (for example let’s say focus is SOA over Web services framework) will have to buy or get an off the shelf software ( like Tibco or Websphere) which will provide frameworks, tools, features to implement the Integration solution using this Integration Style. Thus an integration style will be combination of architecture style and associated product offerings. There is a tight coupling between architecture styles a product supports. For example SAP PI didn’t allow modeling processes the way its done by a BPM product. So BPM modeling was not allowed when Integration solution was being designed in SAP PI). Later I found a separate stack (ARIS) was integrated on top of SAP PI to fill in this gap. (Not sure what happened to this initiative after Software AG bought the parent company of ARIS, i won’t be able to comment on it much and also I know Gartner/ Forrester consultants must be on it ).
Anyways this doesn’t mean that firms first decide on an architectural style or an Integration pattern and then try to look for software. In most cases the reasons are business driven and product will be sold to the firm through cumulative, continuous and untiring efforts of many stakeholders( sales person from product vendors, architects with their own affinity towards certain technology, consultants, contractors and the list will go on and on) . If a firm has been an IBM shop historically, while trying to implement Integration solutions they may consider Websphere, as their product of choice. And since implemented solutions will leverage on the architectural pattern that Websphere offers, the solution design will be restricted by that product offering. Architectural styles supported by Web sphere will normally be promoted by the architects in the firm for all practical purposes. (Of course these days every product supports every other feature. If you are in doubt, please call the sales representatives of the product you know least and soon you will realise how his product will support what you need)
Reference Mode
If we have to think of a reference mode of lifecycle behavior of Integration Style we have to study the reference mode of its constituent variables namely
Architectural pattern (e.g. SOA),
Product/software (e.g. Mule) offerings for Integration options (e.g. Soap, HTTP) (Remember we defined that Integration Style is the combination of Architecture Style and Product offerings).
The reference mode of each of these variables will be somewhat be similar to a Technology Product Lifecycle. Thus product lifecycle and technology lifecycle has similar reference mode of behavior except for the fact that architectural pattern often outlives a product. For example SOA is an architectural style and there are many products (Example WebSphere, BizTalk, Mule etc) in the market which provides framework for SOA. Some products are start up technology products and some are products supported by big firms. Start up products may have a small lifespan. Often some products, if supported by big firms like SAP or Microsoft, will have extended lifecycle supported by multiple releases and various product enhancements. But if we look at Architectural principles they have remained constant or have been fairly consistent over a long period of time. Hence it can be said the Product lifecycle is smaller than architecture lifecycle. I have provided a diagram below for the people who are visually inclined
The blue curve is the architectural style and the green and orange curves are hypothetical product lifecycle curve. The reference mode behavior is not drawn to scale.
Thus the Integration Style will also have a reference mode of behavior as follows:
Now that I have introduced the concept for lifecycle, It won’t be fair unless I mention the significances of this lifecyle for the IT Professionals. But I would save it for the next blog.
Comments
Maloy...Should we say designing a solution with reliable architecture will have more life than choosing a product and going by what it offers.. irespective of the architecture it follows?
Posted by: Manoj Oommen | November 11, 2010 5:59 AM
Hi Manoj,
Consultants ( like me) are always trained to say "It depends". :)
When budgets are sanctioned by business for a project there are so many forces in action its not sure which direction the actual decision will go. If product has already been chosen, timelines are in place: the project manager will be focussed on getting things done rather than deliberating on best practices, Technology Specialists will work to keep on the existing product work.
While choosing a product itself the Enterprise Architects should decide which product should be suitable for the firm. Again products are strictly not chosen beacuse it supports all best practices. Sometimes a product will be chosen for pure economic reason. For example one product firm which has come up with a new product concept will give away the product almost free to the firms to lock them in . This new product may not have much feature at all. But just for economic reasons solutions will be developed in that product.
So your question doesn't have any simple answer. At the end of the day IT supports business and in business its all about bottomline.
Posted by: Maloy Halder
|
November 12, 2010 8:18 PM