Implementing SOA through TOGAF 9.1: the Center Of Excellence

Service-oriented architecture (SOA) has at times been challenged but is now on the verge of mainstream acceptance. It now shows maturity, success and even signs of popularity. Service Oriented Architecture (SOA) is an enterprise scale architecture for linking resources as needed. These resources are represented as business-aligned services which can participate and be composed in a set of choreographed processes to fulfil business needs.

The primary structuring element for SOA applications is a service as distinct from subsystems, systems, or components. A service is an autonomous and discoverable software resource which has a well defined service description.

SOA is based on a fundamental architectural model that defines an interaction model between three primary parties, the service provider, who publishes a service description and provides the implementation for the service, a service consumer, who can either use the uniform resource identifier (URI) for the service description directly or can find the service description in a service registry and bind and invoke the service. The service broker is the third party who provides and maintains the service registry in addition to providing mediation services between providers and consumers.

In 2012, the use of SOA for pivotal emerging technologies, especially for mobile applications and cloud computing, suggests that the future prospect for SOA is favourable. SOA and cloud will begin to fade as differentiating terms because it will just be “the way we do things”. We’re now at the point where everything we deploy is done in a service-oriented way, and cloud is being simply accepted as the delivery platform for applications and services. Also many enterprise architects are wondering if the mobile business model will drive SOA technologies in a new direction.  Meanwhile, a close look at mobile application integration today tells us that pressing mobile trends will prompt IT and business leaders to ensure mobile-friendly infrastructure.

To be successful in implementing a SOA initiative, it is highly recommended that a company create a Center of Excellence and the Open Group clearly explains how this can be achieved through the use of TOGAF 9.1. This article is based on the specification and specifically the section (in italics) 22.7.1.3 Partitions and Centers of Excellence with some additional thoughts on sections 22.7.1.1 Principle of Service-Orientation and 22.7.1.2 Governance and Support Strategy.

I have looked at the various attributes and provided further explanations or referred to previous experiences based on existing CoEs or sometimes called Integration Competency Centers.
The figure below illustrates below a SOA Center of Excellence as part of the Enterprise Architecture team with domain and solution architects as well as developers, QAs and business architects and analysts coming from a delivery organization.

This center of excellence support methodologies, standards, governance processes and manage a service registry. The main goal of this core group is to establish best practices at design time to maximize reusability of services.
Below is then what is written in the TOGAF 9.1 specification.


A successful CoE will have several key attributes:

• A clear definition of the CoE's mission: why it exists, its scope of responsibility, and what the organization and the architecture practice should expect from the CoE.

Any SOA Center of Excellence must have a purpose. What do we want to achieve? What are the problems we need to solve?

It may sound obvious, but having a blueprint for SOA is critical. It's very easy for companies, especially large enterprises with disparate operations, to buy new technologies or integrate applications without regard to how they fit into the overall plan. The challenge in building a SOA is to keep people, including IT and business-side staff focused on the Enterprise Architecture goals.

In order to realize the vision of SOA the following topics should be addressed:

· What to build: A Reference Architecture
· How to build: Service-Oriented Modeling Method
· Whether to build: Assessments, roadmaps, and Maturity evaluations
· Guidance on Building: Architectural and Design patterns
· Oversight: Governance
· How to build: Standards and Tools

The Center of Excellence would first have a vision which could be something like:

“ABCCompany will effectively utilize SOA in order to achieve organizational flexibility and improve responsiveness to our customers”.

Then a mission statement should be communicated across the organization. Below a few examples of mission statements:

“To enable dynamic linkage among application capabilities in a manner that facilitates business effectiveness, maintainability, customer satisfaction, rapid deployment, reuse, performance and successful implementation.”
“The mission of the COE for SOA at ABCCompany is to promote, adopt, support the development and usage of ABCCompany standards, best practices, technologies and knowledge in the field of SOA and have a key role in the business transformation of ABCCompany. The COE will collaborate with the business to create an agile organization, which in turn will facilitate ABCCompany to accelerate the creation of new products and services for the markets, better serve its customers, and better collaborate with partners and vendors.”

The Center of Excellence would also define a structure and the various interactions with
· the enterprise architecture team
· the project management office
· the business process/planning & strategy group
· the product management group
· etc.

And create a steering committee or board (which could be associated to an architecture board).

They will provide different types of support:

· Architecture decision support
     o Maintain standards, templates and policies surrounding Integration and SOA
     o Participate in Integration and SOA design decisions
· Operational support
     o Responsible for building and maintaining SOA Infrastructure
     o Purchasing registries and products to grow infrastructure
· Development support
     o Development of administrative packages and services
     o Develop enterprise services based on strategic direction

• Clear goals for the CoE including measurements and Key Performance Indicators (KPIs). It is important to ensure that the measures and KPIs of the CoE do not drive inappropriate selection of SOA as the architecture style.

Measurements and metrics will have to be identified. The common ones could be:

· Service revenue
· Service vitality
· Ratio between services used and those created
· Mean Time To Service Development or Service change
· Service availability
· Service reuse
· Quality assurance
· Etc.

• The CoE will provide the "litmus test" of a good service.

Clearly comprehensive testing activities must be described by the Center of Excellence. In addition to a set of defined processes related to Web Service Definition Language (WSDL) testing, functional unit testing, regression testing, security testing, interoperability testing, vulnerability testing and load, performance testing, an analysis tool suite may be used to tailor the unique testing and validation needs of Service Oriented Architectures.

This helps test the message layer functionality of their services by automating their testing and supports numerous transport protocols including: (here a few examples) HTTP 1.0, HTTP/1.1, JMS, MQ, RMI, SMTP, .NET WCF HTTP, .NET WCF TCP, Electronic Data Interchange, ESBs, etc.
Only by adopting a comprehensive testing stance, enterprises can ensure that their SOA is robust, scalable, interoperable, and secure.

• The CoE will disseminate the skills, experience, and capabilities of the SOA center to the rest of the architecture practice.

The Center of Excellence will promote best practices, methodologies, knowledge, and pragmatic leading-edge solutions in the area of SOA to the project teams.

• Identify how members of the CoE, and other architecture practitioners, will be rewarded for success.

This may sounds like a good idea but I have never seen this as an applied practice.

• Recognition that, at the start, it is unlikely the organization will have the necessary skills to create a fully functional CoE. The necessary skills and experience must be carefully identified, and where they are not present, acquired. A fundamental skill for leading practitioners within the CoE is the ability to mentor other practitioners transferring knowledge, skills, and experience.

Competency and skills building is needed for any initiative. SOA is not just about integrating technologies and applications but it is a culture change within the enterprise which requires IT to move from being a technology provider to a business enabler. There may be a wide range of skills required such as:

· Enterprise Architecture
· Value of SOA
· Governance model for SOA
· Business Process Management and SOA
· Design of SOA solutions
· Modeling
· Technologies and standards
· Security
· Business communication
· Etc.

It has to be said that lack of SOA skills is the number one inhibitor to SOA adoption.

• Close-out plan for when the CoE has fulfilled its purpose.

Here again, I am not sure that I have observed any Center of Excellence being closed...
The Center of Excellence will then also define a Reference Architecture for the organization.

A Reference Architecture is an abstract realization of an architectural model showing how an architectural solution can be built while omitting any reference to specific concrete technologies. Reference Architecture is like an abstract machine. It is built to realize some function and it, in turn, relies on a set of underlying components and capabilities that must be present for it to perform. The capabilities are normally captured into layers which in their own right require an architectural definition. However, the specific choice of the components representing the capabilities is made after various business and feasibility analysis are performed. A Reference Architecture can be used to guide the realization of implementations where specific properties are desired of the concrete system.

The purpose of the Reference Architecture is reflected in the set of requirements that the Reference Architecture must satisfy. We can structure these requirements into a set of goals, a set of critical success factors associated with these goals and a set of requirements that are connected to the critical success factors that ensure their satisfaction.

A Reference Architecture for SOA describes how to build systems according to the principles of SOA. These principles direct IT professionals to design, implement, and deploy information systems from components (i.e. services) that implement discrete business functions. These services can be distributed across geographic and organizational boundaries, can be independently scaled and can be reconfigured into new business processes as needed. This flexibility provides a range of benefits for both IT and business organizations.

Using the pattern approach the SOA Reference Architecture is a means for generating other more specific reference architectures, or even concrete architectures depending on the nature of the patterns. Or to put it another way, it is a machine for generating other machines.

The Open Group Standard for SOA Reference Architecture (SOA RA) is a good way of considering how to build systems.

The center of Excellence needs also to define the SOA life cycle management which consists of various activities such as governing, modelling, assembling, deploying and controlling/monitoring.
Simply put, without management and control, there is no SOA only an “Experience”. The SOA infrastructure must be managed in accordance with the goals and policies of the organization, which include hardware and software IT resource utilization, performance standards as well as goals for service level objectives (SLOs) for the services provided to IT users as well as business goals and policies for businesses that run and use IT. To be truly agile, enactment of all these different types of policies requires automated control that allows goals to be met with only the prescribed level of human interaction.

For every layer of the SOA infrastructure a corresponding Manage and Control component needs to exist / be in place. Moreover, the “manage and control” components must be integrated in a way that they can provide an end-to-end view of the entire SOA infrastructure.

These manage and control functions provide the run-time management and control of the entire enterprise IT execution environment. This includes all of the enterprise’s business processes and information services, including those associated with the IT organization’s own business processes.

The “Principle of Service orientation” must exist as defined in 22.7.1.1 Principle of Service-Orientation, but lower levels of principles, rules, and guidelines are required.

Needs and capabilities are not mechanisms in the SOA Reference Architecture. They are the guiding principles for building and using a particular SOA. Nonetheless, the usefulness of a particular SOA depends on how well the needs and capabilities are defined, understood, and satisfied.

Architecture principles define the underlying general rules and guidelines for the use and deployment of all IT resources and assets across the enterprise. They reflect a level of consensus among the various elements of the enterprise, and form the basis for making future IT decisions.

Guiding principles define the ground rules for development, maintenance, and usage of the SOA. Specific principles for architecture design or service definition, are derived from these guiding principles, focusing on specific themes. These principles are the characteristics that provide the intrinsic behaviour for the style of design.

SOA principles should be clearly related back to the business objectives and key architecture drivers. They will be constructed on the same mode as TOGAF 9.1 principles with the use of statement, rationale and implications. Below examples of the types of services which may be created:

· Put the computing near the data
· Services are technology neutral
· Services are consumable
· Services are autonomous
· Services share a formal contract
· Services are loosely coupled
· Services abstract underlying logic
· Services are reusable
· Services are composable
· Services are stateless
· Services are discoverable
· Location Transparency
· Etc.

Here is a detailed principle example:

· Service invocation
     o All service invocations between application silos will be exposed through the Enterprise Service Bus (ESB)
     o The only exception to this principle will be when the service meets all the following criteria:
          § It will be used only within the same application silo
          § There is no potential right now or in the near future for re-use of this service
          § The service has already been right-sized
          § The Review Team has approved the exception

As previously indicated, the Center of Excellence would also have to provide guidelines on SOA processes and related technologies. This may include:

· Service analysis (Enterprise Architecture, BPM, OO, requirements and models, UDDI Model)
· Service design (SOAD, specification, Discovery Process, Taxonomy)
· Service provisioning (SPML, contracts, SLA)
· Service implementation development (BPEL, SOAIF)
· Service assembly and integration (JBI, ESB)
· Service testing
· Service deployment (the software on the network)
· Service discovery (UDDI, WSIL, registry)
· Service publishing (SLA, security, certificates, classification, location, UDDI, etc.)
· Service consumption (WSDL, BPEL)
· Service execution (WSDM)
· Service versioning (UDDI, WSDL)
· Service Management and monitoring
· Service operation
· Programming, granularity and abstraction
· Etc.

Other activities may be considered by the Center of Excellence such as providing a collaboration platform, asset management (service are just another type of assets), compliance with standards and best practices, use of guidelines, etc. These activities could also be supported by an Enterprise Architecture team.

As described in TOGAF 9.1, the Center of Excellence can act as the governance body for SOA implementation, work with the Enterprise Architecture team, overseeing what goes into a new architecture that the organization is creating and ensuring that the architecture will meet the current and future needs of the organization.

The Center of Excellence provides expanded opportunities for organizations to leverage and re-use service oriented infrastructure and knowledgebase to facilitate the implementation of cost-effective and timely SOA based solutions.

Release Management should be utilized in a SOA environment

Release Management is one of the Service Support ITIL processes that allows planning and overseeing the successful rollout of software and related hardware. Deploying Release Management will encourage IT Management to designin and implement efficient procedures for the distribution and installation of changes to IT systems, and will ensure that hardware and software being changed is traceable, secure and that only correct, authorized and tested versions are installed. IT Operations groups that are implementing ITIL Release Management in a SOA context should collaborate with Application Development leaders to extend those processes for new kinds of distributed applications and services.

IT Service Management and SOA Governance concepts

Application Development teams building SOA solutions either internally or externally or mixing both approaches must consider the ITIL Release Management process to rollout any software and hardware components.

ITIL is a set of Best Practice recommendations for IT Service Management. ITIL consists of a series of publications giving guidance on the provision of Quality IT Services, and on the Processes and facilities needed to support them. These services which are used by the user/customer can take the form of applications that they use (e.g. email services, components of HR systems, ERP and financial systems) or other services which are utilized, such as internet access, printing services, etc.

A SOA Service is defined as a unit of work to be performed on behalf of some computing entity, such as a human user or another program. SOA defines how two computing entities, such as programs, interact in such a way as to enable one entity to perform a unit of work on behalf of another entity.

The SOA Service is much more granular that an IT Service and the latest can be the aggregation of several SOA Services. For these reasons, more and more IT Service Management and SOA will relate to each other and be part of an SOA Governance framework which should really be considered as part of a broader IT Governance strategy.

SOA is introducing many independent and self-contained moving parts, components that are typically widely reused across the enterprise and are a vital part of mission-critical business processes; it becomes critical to properly manage the life cycle. SOA governance usually includes:

• Lifecycle management. This involves the definition, the implementation and the enforcement of policies and processes across the entire SOA lifecycle.


• Policy management. This process is used for a successful web services deployment ensuring that services, XML messages and transactions comply with local and global security and operational policies. This woulde include access-control list management, identity management authentication and authorization policies.


• Contract management. This activity consits of managing the relationships between service consumers and providers. Policies, capabilities and Service Level Agreements (SLA) are negotiated. Service Level Management is an ITIL Service Delivery process can be used.


• SOA metadata management. More and more data services are created based on various information sources, metadata centric visibility tying data services to their associated information sources participating in Data Integration techniques is critical. SOA Metadata management can be based on SOA Metadata repository and SOA Registry.

Activities within Release Management must also cover SOA solutions but have additional constraints

Release Management helps to communicate and manage expectations of the Customer during the planning and rollout of new Releases. It also allows agreeing the exact content and rollout plan for the Release, through liaison with the Change Management process. New software or hardware releases are then implemented into the operational environment using the controlling processes of Configuration Management and Change Management. Also, a Release should be under Change and Configuration Management and may consist of any combination of hardware, software, firmware and document Configuration Items.

Release Management activities in the development, control, test and live environments include:

• Release policy and planning. The Release Policy document covers Release numbering, frequency, the level in the IT infrastructure that will be controlled by definable Releases. The SOA policy defines configurable rules and conditions that affect services during design time and at runtime. The SOA policy is used to validate services at design-time, well before they're released to consumers, and is used to enforce specific standards and behaviors at runtime. The Release Policy has to include instructions such that deployed SOA solutions have to comply with the SOA Policy. Release Planning would also have to include applications running on SOA infrastructure.
  


• Release design, build and configuration. The Release design of a SOA application differs from a classical application as several web services can be aggregated for a composite application from in-house developments or from third party components. License, support a and Service level Agrements will have to be defined at the web service level and Application Development groups will have to negotiate at the component level with the different vendors. The Release Build will require additional efforts because of the highest granularity of software components and also because an impact analysis is required to identify what other applications could be affected. Configuration will require detailed procedures for installation from all web services providers.
  


• Release acceptance. This activity is responsible for testing a Release, and its implementation and Back-out Plans, to ensure they meet the agreed Business and IT Operations Requirements. Additional consideration has to be given to existing applications already using some component of the release. An impact analysis will conduct to a non-regression testing for other applications already using some components. A controlled test environment must be configured to replicate the current live version also taking into account external web services. Vendors should be able to contribute to the release and provide as well a test environenment.
  


• Rollout planning. First of all it is almost impossible to agree a rollout plan without consulting the customers; indeed they are an integral part of the planning. So to meet this goal companies will need to work closely with the customers to prepare a release or rollout plan that not only meets IT needs but also takes into account customer availability and their business deliverables. Once the plan is agreed, the IT department will need to provide constant feedback to the customers during the processing of the Release or rollout. Ideally the customers should be able to view the plan on-line any time and should receive regular reports from the plan team leader. SOA applications do not really impact this activity as customers are often not aware of the underlying architecture.
  


• Extensive testing to predefined acceptance criteria. Testing of a Build or Release to ensure that the parts including the web services work correctly together. SOA will require additional non-regression testing because of the potential share of components between old and new applications. Tests may have to include vendors’ components when used and will require dedicated tests vendors environments even if the web service is hosted somewhere else.
  


• Signoff of the Release for implementation.
  


• Communication, preparation and training.
  


• Distribution and installation. This will cover the installation of new or upgraded hardware and the distribution and installation of software. The ITIL Definitive Software Library (DSL) which is the storage of controlled software in both centralized and distributed systems will also contain the SOA hardware and software components. External components will have to be documented in a SOA registry-repository as they will be hosted externally.

SOA Repository and Registry

The ability to register, discover, and manage Web services is an essential requirement for any SOA implementation. This need may not be fully appreciated in the early stages of an SOA rollout when dealing with a small number of services but becomes almost mandatory when there is a need to support a large number of Web services. When the number of services deployed grows to dozens or hundreds, centralized facilities for access and control of service metadata and artifacts becomes critical. A service registry provides these capabilities and becomes a key infrastructural component. First generation service registries were based on the UDDI standard but new products have recently emerged from various vendors inspired by the standard.

SOA Repositories and registries should integrate with CMDBs (Figure 1).

Figure 1 Registry and Repository linked to a CMDB

Product choices and strategies

• Systinet is a mature solution but requires further integration in the HP IT Service Management suite. The roadmap for HP’s IT Service Management soultions identified Peregrine ServiceCenter has the evolution for the HP OpenView Service Desk. However as HP also acquired Mercury, the future of the HP CMDB will target Appilog (Now Mercury Application Mapping). In January 2006 Mercury extended its offering with Systinet which provides the foundation for SOA Governance and lifecycle management. Mercury ITG for the time being manages Change and Release Management, Peregrine ServiceCenter manages Change Management, and Systinet 2 manages SOA Changes. The Governance Interoperability framework (GIF) developed by multiple SOA vendors does not seem to cover the integration with a federated CMDB[i].
  
• IBM proposes its Websphere Service Registry and Repository V6 which integrates with the Tivoli CCMDB. This solution will communicate with Tivoli CCMDB which manages Changes and Configuration. The Tivoli CCMDB also integrates with IBM Tivoli Release Process Manager and Tivoli Configuration Manager which are other Release Management modules. The end to end solution will have to be validated.
  
• Flashline which joined in august 2006 the BEA Aqualogic product family is a new offering but BEA until now distributed Systinet. Flashline is now the BEA Aqualogic Enterprise Repository, has out of the box connectors source code management systems but does not have yet integration with ITSM suites.
  
• Webmethods acquired Infravio but seems more focused on new clients acquisition with an integration with Fabric. Its governance edition integrates with System Management suites such as IBM Tivoli, BMC Patrol, CA Unicenter but custom development would be required.
  
• Amberpoint is a Web services management product which completes a repository-registry. Amberpoint integrates into any IT environment and specifically system management suites, but does not consider yet ITSM (although it does deliver a module related to SLM).
  
  

Release Management is a pre-requisite to properly manage the service lifecycle

IT infrastructure and operations/engineering professionnals using IT Service Management and starting SOA programs should evaluate the maturity of their Release Management process or consider its implementation. The acquisition of a SOA Governance platform must take into consideration existing IT Service Management suites in order to have as a target an end to end view of the SOA components deployment. Without any integration, operations staffs will not be able to quickly track the end to end life cycle and carry out root cause analyse in an efficient way in case of problems.

• Review the process activities and ensure they take into consideration components based on SOA infrastructures. Release policy and planning will be adapted to SOA solutions implementations taking into consideration the use of potential external and distributed web services. Design and build of a Release will have to integrate more granular components which can be hosted externally and sold by vendors. Service Level Agreements will have to be defined not only at the IT Service level but also at the Web service level. Testing will have to cover non-regression for shared application components and situations were componets are hosted externally.
  
• Evaluate cautiously SOA Governance platfoms. SOA Management platforms, metadata repositories and registries should take into account not only Release and Change Management, but also Service Level Management from Service Management suites. Identify the vendor’s strategy in terms of either partnership with ITSM vendors, or internal roadmaps such as IBM and HP.
  
• Understand the level of integration required between products. A complete integration would be ideal but the existing solutions are not yet there. Some vendors have started to understand the need for integration between a SOA Registry and repository and a CMDB in a federated way, the repository-registry being considered as a specialized database in this federation. Some others are only provinding APIs to system management solutions.
  
• Ensure that Underpinning Contracts are covering Release Management for third party components. Companies building applications either composite or integrating in BPM activities third party web services should define in a SLA with the vendors how new external components versions should be managed in the Release Management process. Vendors should not be allowed to upgrade customers web services without any authorization if hosted externally. The contract should specify that any new component modification will be part of the customer’s IT Operations Releases covering testings.

What It means...

Convergence between the SOA registry, repository and the CMDB

The registry and repository of SOA has allowed convergence of the development time asset repository with the run-time service registry. We must now proceed into the management repository. As we frequently see another repository associated with that space called the Configuration Management Database, or CMDB. A convergence across this space is required in order to be able to correctly track the end to end life cycle of Web services as well as to maintain an up to date software and hardware information. Part of the metadata associated with a service needs to be the machines where it is deployed. The chances are that information may already be in the CMDB.


Non ITSM shops will integrate SOA Governance Platforms with adhoc deployment solutions

Companies which have not considered ITIL as an IT Operations framework can deploy a SOA Repository and Registry without fully considering the Release Management process. They will be able to manage the service lifecycle and if they have a software deployment product, they will use it for deployment. Reconciliaton between the various products will have to kept manually or integration development will be required. However IT Operations group haven’t yet endorsed IT Service Management and starting to embrace ITIL will gain substential benefits in terms of customer’s quality of service. Release Management among other processes such as Change and Service Level Management will definitly improve the quality of SOA solutions.

[i] Ten leading SOA vendors have partnered with Systinet for the GIF, including Above All Software, Actional, AmberPoint, Composite Software, DataPower, HP, Layer 7 Technologies, MetaMatrix, Reactivity, and Service Integrity.