"We didn't start the fire ... it was always burning since the world's been turning ..." [Billy Joel 1989]. Is SOA the "Same Old Architecture?" or is it "Simply Over Ambitious?" Let's apply SOA's arsenal:: XML, BPM, Services, SOAP, Web Services - to the real world and find out. Let's put out some fires.

« SOA in difficult times | Main | Composite Applications continues to make inroads »

Are you in a hurry to implement SOA?

My experience with some of the enterprise clients in SOA space has been rather surprising. I find lots of these enterprises rushing to create a SOA roadmap and deploy a pilot SOA program. My trouble is not that they want to do it fast and want to have quick win but having it done at the cost of 'insufficient' understanding of what they want and why they want is my worry.

Unfortunately SOA is not a topic that is as straight forward and clear as all of us would like it to be. On top of that, when I see enterprises rushing on the SOA initiative, I see that as an early indicator for the disaster in making. What I had been doing in such cases and I also recommend the same to other SOA champions across the globe (who share the problem and potentially the view-point) are summarized below:

  • It is utmost essential to ask and understand why a particular SOA initiative is being launched. And answers should not be in terms of 'deliverables' but in terms of 'results'. At times I found that the actual problem statement shared by the client can not be solved by SOA and there was no clarity why SOA is being considered. So beware of such mismatch of problems that client might be expecting SOA to solve.
  • Next important thing to pay attention to is the scope. Is prime scope of SOA initiative limited to 'Integration/Broker' technology betterment or does it include any other enterprise domain? If its only limited to integration, then one need to ask and understand what 'results'/'differences' will this SOA initiative bring so that validity of the strategy can be established.
  • If you are creating a roadmap or deployment plan for SOA, don't even think about it if there is no strategy in place. There is really no meaning of a roadmap if you have not defined a strategy that sets the direction of the entire roadmap. Defining roadmap is not such a complex thing but a roadmap that is going to drive all of SOA investments, programs and changes in the organizations, it better be based on strategic considerations.
  • It is very common to see SOA programs to be heavily focused on integration platforms. Nothing wrong with it. However when considering a transformation view of the SOA program, there is a great opportunity to consider 'technology portfolio rationalization'. SOA must help enterprises simplify the enterprise landscape and hence such opportunities should be leveraged to reduce unwanted technology stack in the organization.
  • I always believed and still stand by the view that there is nothing called 'SOA' solution or SOA portfolio. When there is SOA in the organization, it is nothing separate than existing elements of the enterprise eco-system including business applications, integration etc. SOA doesn't exist in isolation and has no life of its own. So it is extremely important to understand about the enterprise programs/initiatives that the concerned SOA program is tied to directly or indirectly in terms of outcomes. And if there is none, I will be little worried about the business case of the SOA program (and the money that is being put into it).
  • As I mentioned in some of my previous blogs, BPM is likely to have more power to transform the organization than the SOA. In that light, when considering SOA, ensure that BPM is absolutely in the scope of the matter and is not left out as something to be looked into at a later point in time. That 'later' point in time never comes and even if it comes, it is never the same in the organization making it extremely difficult to get value out of SOA without it.
  • We all need to understand that behind all good looking SOA roadmap, most likely there is going to be a huge task of legacy modernization/migration if SOA has to be a real thing in the organization. Given that, organization (and more importantly the SOA strategy consultants) need to clearly understand the landscape that will be impacted by SOA changes, nature of the change, readiness of the organization for these changes and finally the cost factors of these changes in the SOA roadmap. These are the important factors that make the SOA roadmap more real and credible.

In most of the cases that I have dealt with, I have been able to successfully add value to client's thinking process and quality of their decision making as far as SOA is concerned. So that's reason I believe this input will help larger SOA consulting community as well as organizations that are for ever in hurry to jump onto SOA, what ever that supposed to be.

TrackBack

TrackBack URL for this entry:
http://www.infosysblogs.com/soa-mt/mt-tb.fcgi/92

Comments

Thanks for sharing your experience.

Agree that one needs to understand why SOA? and what result ?
- So you are saying roadmaps alone don't help, agree
- Nor does focus on integration or technology stack alone does, agree
- So naturally the focus comes back on what exists

But that's the problem customers have, they know their existing IT systems and also know that they need more out of them. They know what they want, clear on their end. But the problem is on the IT end, not being able to support or respond to business needs, which, by all means is changing constantly. Therefore a good approach should defenitely have a roadmap, (Business, IT, Technology) which is subject to changes and re-alignment, and deliver results of business value in short turnarounds or iterations.

Influencing clients thinking on SOA may not always work, he doesn't need to. Because there's always some legacy modernization he can manage himself in-house if required. That doesn't help if you're an IT solutions provider. I think it's more important to apply SOA from IT & Technology p.o.v in a manner that is predictable, measurable and flexible to changes, and focus on iterative delivery of valuable business results. Business, IT & Tech roadmaps are just as important as they're subject to changes, nothing survives more than a few months. So re-align, factor and apply, all in short iterations.

Satish, first of thanks for caring put share your perspective. I should have responded long ago but I think I just forgot to post my reply, my apologies.

I don't think I meant that oragnizations shouldn't have roadmap for SOA. They must but having a roadmap without clear strategy (which is basically the game plan) against well define business goals that SOA is going to attempt to achieve is just an execution plan that has no 'real' objectives.

SOA problem (or the solution) is independent of the configuration of the service provider/inhouse IT organization. The way SOA has to be applied and SOA initiative has to take place should not have a variance because of sourcing strategy. Service orientation is clearly has different imperatives (from design perspective) what it means for IT capabilities vs. what it means for business design while both may share the same principles. So for IT it means that it not only has to support the service orientation of business (through means of IT capabilities) but also bring service orientation of IT assets/capabilities also. Very often organizations are not able to clearly differentiate between these two and hence mix up the SOA program directives.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.