Cognition 2.0

SOA, the latest buzzword and technology paradigm, has evolved and matured since it was first proposed and implemented in 1999. With a fairly mature set of standards supporting its design and implementation, service-orientation is still new to Enterprise Architecture frameworks and methodologies, such as TOGAF and Zachman. In this blog, I will summarize my experience with SOA and TOGAF, in particular with respect to business transformation and governance.

SOA, like architecture in general, is more a philosophy or an art form than a science. SOA allows for different interpretations of what a service is and how it will be implemented and used within an organization and outside of it, too. I have witnessed and been part of many attempts at establishing a successful SOA practice in several industries and contexts, and there are no two alike. However, there is a pattern to SOA from the perspective of its chances of survival and its perception as a successful initiative:

• SOA needs to address business agility and business process integration.
• SOA needs to be governable, i.e. it must adapt and streamline current governance processes in the organization.
• SOA can play a role in any or all of the TOGAF domains, i.e. business, information, application, and techcnology.
• SOA is stakeholder-centric, all the way from IT to the business owner.
• SOA is technology-agnostic, but information-centric.
• SOA must follow standards and extend best-practices.
• SOA is best implemented using MPP (see Model-Process-Policy pattern).

Based on the above recommendations, it is now time to view SOA as a process. Without a process to direct the effort, SOA can easily become a free for all and end up in the creation of more complexity than initially aticipated. SOA should simplify the systems and business processes it is relying on, as it provides a super-interface that consolidates and abstracts many more granular interfaces and business processes. As such, SOA becomes a process, as well as a solution. The process can be described as follows:

• An architecture evaluation process that identifies the relevant quality attributes and scenarios to be analyzed.
• An enterprise architecture development method that takes all four TOGAF domains into consideration, especially as far as information processing, transformation and enrichment are concerned.
• A solution development process that defines and designs the specific components of the SOA implementation.
• An agile development methodology or discipline for developing and delivering the components.

The feedback loops going from the delivery process back to the solution design, enterprise architecture and evaluation processes constitute the change management model that ensures changes are accommodated and assimilated by the organization and the SOA program itself. Changes need to be assessed and executed in accordance to prevailing change management and governance processes or culture in the organization. It is important to note that as one progresses from the architecture evaluation to the delivery of specific components, we are generating a tree structure, where specific architectural attributes or scenarios are at the root and then branch off into several enterprise domains. Each building block in each of the domains may subsequently be realized in many components of the solution, and each component be delivered in multiple code components or deliverables. Each quality attribute in the architecture then fans out into a potentially large number of deployable components, hence the importance of having proper governance processes that ensure the traceability of code back to quality attributes.