You can Find the Part 1 of this series Here
Evolution of Software Engineering Paradigms: (Contd…)
The standards such as COM, CORBA enabled the interoperability aspects between systems. However, until the standards such as XML, WSDL, SOAP came about the “true” interoperability was not achieved. We started seeing lots of Web Services bases solutions come about, and for the first time, we saw true interoperability between systems. Once the standards became more mature and active participation from vendors like IBM, Oracle, BEA just to name a few, a new (well, not so new) paradigm took shape in the form of SOA.
SOA – What it is and What it is not?
SOA, is the latest version of software engineering principles that we all have been trying to achieve so far. Cutting through all the flab, and hype around SOA, at heart you will find that SOA is an architectural concept that re-emphasizes the basic design principles like
- Programming to interfaces,not to the implementation.
- Favoring composition
- Loose coupling
The way these are achieved are by creating services not just components and letting the services interact with each other to form a part of business process or a bigger service.
There are certain characteristics that are key to an effective SOA implementation.
- Standard interfaces. All the services will have a properly defined and self explained interfaces. This is achieved primarily through well designed, documented WSDLs.
- Each service will perform one activity/function completely.
- The services will exchange information in standard, well defined manner.
- There will be a standard based inventory of existing services so that re-use can be encouraged.
On the topic of what is not SOA, there are a lot of points that need to be considered.
- SOA is not a Magic bullet!
- It will not solve all your problems.
- Having a bunch of web services is not SOA.
- Having an ESB is not SOA.
Let me get on with the article, by summarizing what SOA is by saying:
SOA is an architectural concept that puts the focus firmly on basic things like Standard interfaces, loose coupling, proper analysis etc, with an emphasis on standards based exchange of information and ability to easily identify existing services that encourages re-use.
SOA Services - Lego Blocks
The most common analogy for SOA is that of Lego blocks.
- All Lego blocks have a specific interface that is standard.
- Each block is complete in itself.
- You can compose different structures with the same blocks.
In our toy box, we have blocks of different sizes, shapes, and color. We can build a castle with the Lego blocks and then we can quickly dismantle a castle and build a row house! With the same blocks!! You get the picture don’t you?
SOA is all about building the blocks (read services) in such a way, that you can put them to use in many different purposes and situations. (I am not going to debate on the finer aspects of the analogy, I simply use it to drive home the point of re-use and agility)
Why should I consider SOA
In other words, what does SOA bring on to the table ?
- Reuse – You can build services that can be used over and over again there by saving your business all important “cash”
- Agility – You can initiate change, respond to change in much faster manner than before. The time to market can be significantly reduced, once you have a mature set of discoverable, re-usable services.
- Efficiency – You can streamline your processes and have a much more efficient business.
- Business & IT alignment – chance to align IT with business, in an much closely, there by leverage each other to achieve the common goals.
- Rationalize existing infrastructure – by having a standard enterprise level architecture, there is a chance to rationalize infrastructure and thereby reducing the opex.
Before we go on to the next topic, please read the disclaimer: My intention is not to scare you away from SOA, on the contrary it is to make you aware that there are lots of challenges and show you how best we can derive value out the investments made.
What does it take to Implement SOA
A hell of a lot! It’s not an easy road, with simple options and choices. SOA is not for all. It takes a certain level of maturity for a business to go the SOA way.
I am not only talking about the cost aspects, but at an organization level, lots of changes need to happen starting from mind sets, attitudes, way IT and Business interact etc. From cost point of view You are looking at significant investment in terms of technology and effort to achieve a truly rewarding SOA implementation.
Having gotten the bad news out of the way, lets see how we can go about addressing all the challenges and come up with winning strategy for SOA realization.
To begin with, the most important thing is, to have intimate knowledge of your business, various process your business will have, and a sense of how you want to react to change. It does help to conduct a proper analysis of the existing processes, and map them to the existing capabilities. A detailed end to end mapping, starting from a business process, breaking them down to smaller processes, and the components that make up the processes, the platforms that support the components, the infrastructure that supports the platforms etc. Also a detailed analysis of the data involved in all the processes also needs to be done.
I know, it’s a tough one. Particularly for the massive organizations it will take years to complete such a comprehensive study, and by the time we complete study, I am sure what we studied would have become obsolete. For small and medium businesses it might still be achievable, but a time consuming process nevertheless. We also have the risk of not showing any return on investment (ROI) for an extended period of time.
Alternatively, if we went head first into implementing SOA, and building “re-usable” services we will run the risk of creating silos instead of truly Service oriented Architecture. We will still not be able to demonstrate ROI since we have no clue how many of our services will be re-used and there by how much money did we save ? By how much, did we reduce the time to market?
So the answer to the question of “How to implement SOA in the most effective way?” lies somewhere in between the above two approaches. And only after a study of your business, the complexity and the expectations, will we be able to arrive at an effective strategy for SOA realization.
However, Based on previous experiences, There are some key questions that must be asked while trying to identify the strategy to implement SOA.
I shall try to group them into relevant heading. Some questions might repeat, but will have relevance to the heading.
Measure of SOA Success:
- How will the success be measured ?
- Do we have a base line of the following metric
- Cost – to take an idea to realization/product
- Time – to take an idea to realization
- At what intervals the metric be collected to measure progress/success ?
- How fast would you want to see the benefits?
- Have we done enough to set the expectations right ?
- Do we have the time/money to do a complete analysis of business process ?
- How frequently the processes change ?
- What are the key milestones and check points for securing funding ?
- What is the ROI expected, and when would we expect to meet the ROI ?
- What sort of an organization are we talking about ?
- What is the existing delivery model/model of engagement between IT and Business ?
- Is IT and Business working closely ?
- What is the level of interaction between Business users and IT ?
Eagerness to confirm to Architectural Standards:
- How long is the business ready to wait to see results under SOA?
- Under what circumstances, business will support a Non SOA based solution to achieve its objectives ?
(To Be continued)