Who Needs the SOA Competency Center in this world?

I can almost call it a trend as I see it happening again and again, case after the case. As soon as enterprises get active on SOA, apart from SOA technology platform and business service pilot concerns enterprises get their ideas bubbling around ‘SOA competency center’. It is an invariable expectation of having some sort of competency center that will give the enterprises whatever they want from SOA. Let me spend few paragraphs here to bring certain perspective to those who might be seriously attached to the competency center for SOA and might be seeking some direction.

To start with, first of all, I don’t believe that there is really something called SOA CoE or SOA Competency Center that can work in real-world. Well, hold on; I have not completed yet. J..if you understand SOA, you will realize that SOA is like a school of thought, it is like a religion or better yet, it is some sort of a methodology for IT solutioning. It is not a new domain in the enterprise architecture like applications, systems, integration etc. Point I’m trying to say it that if enterprises adopt the SOA, the architecture stack in terms of domains (applications, infrastructure, integration, data-stores etc) doesn’t change. What really will happen on the ground through SOA adoption is a metamorphosis of the existing EA stack domains to incorporate new methods and principles in what each of the domains does. Now, this is important to appreciate it because a typical competency center really is a powerful idea to create some sort of shared services structure in the IT organization to deliver a EA domain specific services. Now if SOA is not going to create a new domain in the EA reference stack, then what is this SOA competency center going to do? SOA will influence and result into some new way of doing things for all existing domains in the EA stack. For example, who application designing and solutioning is happening will see some change to adopt SOA. Similar how integration and data stored play a role, some changes will, happen there to adopt SOA. So in simple terms, all EA domains will be ‘SOA-fied’ (few much more while other less and some may not be for now) to collectively make the enterprise SOA enabled.

So here is how I think whole matter can be approached in more pragmatic manner with getting obsessed with the idea of competency center for SOA. To start with, I could like to differentiate a CoE from competency center or service delivery center as I would like to address it more appropriately. A center of excellence as name suggest is more focused on bringing excellence to few aspects of the domain for which CoE is being built. In general, it will be founded around establishment, management and governance of the core methods, standards and blueprints that are required for any specific domain/discipline to bring excellence. At the same time, service delivery center will be more focused around end-to-end services delivery using a shared services model. So with that definition, surely in the existing model of IT service delivery, SOA competency center or SOA service delivery center doesn’t make as much sense. But let me say this also. As strategic long term picture how I would envisage enterprises moving to, a Business Solution Delivery Center is more promising idea that is built on principles of SOA and has integrated competencies of business and IT. Which means, sometime in future, enterprises will have a common entity in the organization that drives the end-to-end business solution by integrating elemental shared services like applications, process integration, infrastructure, business etc. But for now, I’m leaving it as futuristic idea since most of the enterprises are years away from it. To make the approach easier, let us look at three stages where enterprises might have to think of SOA competency center:

1. Very early days of SOA adoption – this is when enterprise has just thought or heard of SOA and it is trying to find ground and explore the direction with it. Now at this stage all that is needed is to get better understanding of what SOA is all about, its relevance to what it promises to change in the organization and various technological options that it has to explore. At this stage, enterprises should create a focused team that is tasked with this exploration task that might involve collaboration with product vendor, external SOA consultant and other industry SOA forums. This team is largely part time allocated on to the SOA initiative, however might have one or two fulltime allocations to provide rigor and ownership.
2. Enterprise-wide SOA program being run for SOA adoption – this is when enterprise has done some due diligence around SOA strategy and is now ready to go on with the organizational change necessary to bring the enterprise at large to SOA-ready state. At this stage, different IT competency centers like CRM competency centers, SAP competency centers, BI competency centers etc . will need to be prepared to deliver their bits for making SOA work according to overall SOA reference model. On top of that, organizations need additional support to establish common directions and strategies for SOA and subsequently govern what each of the competency centers are doing. At this stage, there are two levels of effort required. At one level, enterprises need to continuously establish SOA capabilities. At another level, it needs to engage other competency centers to adopt and deliver the SOA results with overall governance. For this to achieve, all individual IT competency centers will have their small centers of excellence for SOA specific to their responsibilities of SOA delivery. At the same time, Enterprise Architecture group will have additional roles and competencies of SOA in order to drive the enterprise level SOA. So in this case, there is no separate SOA competency center is established. Instead, it is like a SOA adoption task force consisting of EA group, business groups and IT competency center representative that need to come into existence. It is more of a transient program structure as opposed to a fulltime independent service delivery center.
3. End-state of the enterprise with SOA – this is when all that was supposed to happen, has actually happened and enterprise is now running in SOA-enabled state. To large extent, focus and structure is not much different than previous case but there will not be any transient structure in this case. Since SOA is reasonably in the DNA of the enterprise, there will be very little governance structure needed while most of the responsibilities of SOA delivery will be taken care by IT competency centers for their respective role in overall SOA delivery.

With this, my take is that setting up a proper SOA program structure for first two stages is more important than actually setting up a dedicated service delivery center for SOA. However:

• It is essential to focus on the excellence part of the SOA delivery in terms of adherence of SOA standards, metrics of SOA success etc. through appropriate governance structure. It should be housed in the EA group.
• SOA brings in responsibility of designing the business solutions effectively using services methodology for which business analysts should be taking the ownership.
• A capable SOA infrastructure in the enterprise includes strong service orchestration, composition and delivery platform. This is typically housed in the Integration / ESB domain of the EA. I see this as a significant part of the SOA game plan. And hence to large extent, what I would liked to see in the SOA competency center should be taken up by the existing Integration Competency Center. That way, an Integration Competency Center that has been upgraded to provide all necessary SOA infrastructure for service orchestration, composition and delivery will be what I would see as a the SOA competency center. It will work very closely with the previous two core structures to deliver full SOA compliance Business- IT solutions.

To me it made perfect sense to approach in this manner. But again, I will be glad to hear the alternative perspectives.

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.

SOA on its way out? Lets get ready for future

http://blogs.zdnet.com/service-oriented/?p=1168&tag=nl.e539 (Debate Rages over SOA's cloudy future - by Joe McKendrick)

I stumbled upon this article while reading some articles. As I read it, I heard a 'click' sound in my brain :-). My previous post of SOA's future, I speculated about fading of SOA's strongly hypothetical personality and come of age of BPM driven IT solutions.

As far as SOA is concerns, Joe makes precisely the same point of having more real forms of technical reforms like web-architecture, cloud computing etc. successful today while SOA as a whole still struggling to get into action for most of the businesses. As Joe says 'SOA is too hard to understand and does not lend itself to people just doing it'. I completely believe in it. I have heard lot of experts and practioners on SOA in last 4-5 years. By and large my opinion is that 70% of those drag the topic ultilately to web-services or similar technical topics. Rest of the 30% who tend to remain pure in terms of SOA as a concept also fail to bring realistic and implementation-level view-point on how IT can be transformed using SOA. So in nut-shell, SOA is loosing the differentiation it tried to create all these years but good thing is that because of this hype, some good technical innovation will happen that hopefully prove to be next-generation foundation when BPM takes over from SOA..We are alreadying seeing vendoring lowering their SOA pitch and slowly getting to BPM pitch in big manner...:-)