If trends such as Cloud, Web2:0 and Virtualisation don’t shake up the role that IT plays within organisations then SOA certainly will.
So what does the CEO/CIO need to know and care about SOA?
- Its almost certainly an ongoing and iterative process so the old culture of a fixed time/cost project needs to transition to iterative improvements to business agility (and they need to be funded and measured).
- The businesses intellectual property needs to be defined (process maps) and the resulting business logic should be decoupled from any legacy departmental or application constraints. The future business success of SOA depends on being able to change the business logic quickly and not being held up waiting for IT to catch up.
- The gathering of process maps must not boil the ocean and should be business benefit led. The end result should see a single definition of business logic encapsulated within Business Services even if multiple applications are needed to deliver the service.
- There is no need to care about different applications, languages, legacy standards or how they used to connect to each other in some proprietary way. Its too hard to rip them out and replace them so going forward as you define business services the game-plan is to create a adapters that make all components of a service (legacy or otherwise) communicate in a consistent way.
- As services are shared throughout the business and indeed with other businesses a fresh approach to security is needed: the old school of secure the boundary is not going to work anymore. Identity management and trustworthy applications are needed along with a service level and legal framework that is joined up.
- Monitoring of Business Service Levels will be critical as will the need to span departmental and organisational boundaries.
A word on TOGAF:
SOA is not yet formally absorbed into TOGAF (but its certainly coming). In a nutshell (and in my view) the Business Architecture phase of the Architectural Definition Method (ADM) needs to define what the Business Services are and position them so that they can change in an agile manner. The remaining 3 Architectural phases should in time simply consume commodities (Software as a Service, Data as a Service and Infrastructure as a Service).