- Data Services - Services that carry data
- Business Services - Services that meet a business need
- ITIL Services - Services which meet Help Desk and Operations centric services
- Business Process Services - Services which emulate business processes and they use standards like BPEL and BPMN
- Web Services - Information is exchanged over the HTTP protocol in XML or as attachments which are in SOAP container
- Java Services - Java enabled services
- RESTful Services - Information is exchanged over the HTTP protocol in XML but the information is not in a SOAP container.
- Orchesterated Services - Services which are made of services
- etc., etc
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:
- Define a Service Data Dictionary - This will reduce the confusions when talking about services.
- See if the EA strategies identify any systems which need to be consolidated or broken-up.
- If so then use SOA in system(s) migration
- If all new systems are built in a SOA fashion then address SOA governance
- Address SOA governance by designing and implementing processes and groups which deal with SOA governance.
- All new SOA services should be projectized
- All new SOA services should have a Mission and Vision statement
- and on, on