Can SOA be achieved in an enterprise

For the last year or so, I have been working for the Federal Aviation Administration (FAA) as a Services Oriented Architecture (SOA) Subject Matter Expert (SME). It has been a challenge to see how various folks view SOA the panacea for IT related systems or enterprises. Each stakeholder within an organization has different definition with respect to SOA. So far I have noticed the following at the FAA, we have:

1. Data Services - Services that carry data
2. Business Services - Services that meet a business need
3. ITIL Services - Services which meet Help Desk and Operations centric services
4. Business Process Services - Services which emulate business processes and they use standards like BPEL and BPMN
   
5. Web Services - Information is exchanged over the HTTP protocol in XML or as attachments which are in SOAP container
   
6. Java Services - Java enabled services
7. RESTful Services - Information is exchanged over the HTTP protocol in XML but the information is not in a SOAP container.
8. Orchesterated Services - Services which are made of services
9. etc., etc

As you can see, Services can be confusing. To add to the confusion, we have other tools and methodologies which make SOA a zoo. We also have people who view SOA serving different purposes. In the end, they are all true since they are identifying components which can be or may be true in an enterprise. Here is my take on SOA. SOA should be viewed from a Enterprise Architecture (EA). EA identifies (if it is done right) the "As-Is" state of the IT enterprise and proposes the "To-Be" state of the IT enterprise.

EA should also have a strategy on how to achieve "To-Be" state in a timeframe. This is usually articulated in various EA artifacts like Roadmaps, line of sight documents, strategy documents and an EA repository. Other components that need to implemented to give a true EA picture is to have an enforced System Development Lifecycle (SDLC), Change Control Board (CCB), and Configuration/Change Management (CM). The other thing is that to have a working EA, all of the stakeholders must buy into it. I am a big fan of The Open Group Architecture Framework (TOGAF).

Back to SOA now, if EA recommends that SOA is one of the possible approaches to meet "To-Be" state then it needs to bought by all stakeholders in the enterprise. The following steps need to be done when an enterprise wants to use SOA to achieve its goals:

1. Define a Service Data Dictionary - This will reduce the confusions when talking about services.
2. See if the EA strategies identify any systems which need to be consolidated or broken-up.
3. If so then use SOA in system(s) migration
4. If all new systems are built in a SOA fashion then address SOA governance
   
5. Address SOA governance by designing and implementing processes and groups which deal with SOA governance.
6. All new SOA services should be projectized
7. All new SOA services should have a Mission and Vision statement
8. and on, on

In the end, will SOA ever be truly achieved in the FAA. The answer is "No"! However pursuing SOA will help FAA identify gaps in its enterprise with respect to its EA since it forces various stakeholders to communicate together and address how some of the internal processes should be achieved. This is a big key for any successful IT enterprise. Adopting SOA will not provide a successful EA without having a working SDLC and appropriate mechanisms which provide accountability.