01 October, 2012

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.
clip_image002
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.

01 March, 2012

Building an Enterprise Architecture value proposition using TOGAF® 9.1. and ArchiMate 2.0

When introducing Enterprise Architecture as a program or initiative, it is regularly done from an IT perspective rarely considering what the costs will be and if there will be any return on investment. This presents a particular challenge to Enterprise Architecture.

Generally speaking, IT departments have all sorts of criteria to justify projects and measure their performance. They use measurements and metrics, KPIs. Going to the solution level, they commonly use indicators such as percentage uptime for systems from the System Management team, error rates for applications from the Development Support team, or number of calls resolved on the first call from the Service Desk, etc. These KPIs usually are defined at an early stage and very often delivered in dashboards from various support applications.

On the other hand it is much more difficult to define and implement quantifiable measure for Enterprise Architecture. Many activities introduced with appropriate governance will enhance the quality of the delivered products and services, but it still will be a challenge to attribute results to the quality of Enterprise Architecture efforts.

This being said, Enterprise Architects should be able to define and justify the benefits of their activities to their stakeholders, and to help executives understand how Enterprise Architecture will contribute to the primary value-adding objectives and processes, before starting the voyage. The more it is described and understood, the more the Enterprise Architecture team will gain support from the management. There are plenty of contributions that Enterprise Architecture brings and they will have to be documented and presented at an early stage.

There won’t be just one single answer to demonstrate the value of an Enterprise Architecture but there seems to be a common pattern when considering feedbacks from various companies I have worked with.
Without Enterprise Architecture you can probably NOT fully achieve:
  • IT alignment with the business goals
As an example among others, the problem with most IT plans is that they do not indicate what the business value is, and what strategic or tactical business benefit the organization is planning to achieve. The simple matter is that any IT plan needs also to have a business metric, not only an IT metric of delivery. Another aspect is the ability to create and share a common vision of the future shared by the business and IT communities.
  • Integration
With the rapid pace of change in business environment, the need to transform organizations into agile enterprises that can respond quickly to change has never been greater. Methodologies and computer technologies are needed to enable rapid business and system change. The solution also lies in Enterprise Integration (both business and technology integration).

For business integration we use Enterprise Architecture methodologies and frameworks to integrate functions, processes, data, locations, people, events and business plans throughout an organization. Specifically the unification and integration of business processes and data across the enterprise, and potential linkage with external partners become more and more important.

To also have technology integration, we may use enterprise portals, enterprise application integration (EAI/ESB), Web services, service-oriented architecture (SOA), business process management (BPM) and try to lower the number of interfaces.
  • Change management
In recent years the scope of Enterprise Architecture has expanded beyond the IT domain and Enterprise Architects are increasingly taking on broader roles relating to organizational strategy and change management. Frameworks such as TOGAF 9.1 include processes and tools for managing both the business/people and the technology sides of an organization. Enterprise Architecture supports the creation of changes related to the various architectures domains, evaluating the impact on the enterprise, taking into account risk management, the financial aspects ( cost / benefit analysis), and most importantly ensure the alignment with business goals and objectives. Enterprise Architecture value is essentially tied to its ability to help companies to deal with complexity and changes.
  • Reduced time to market and increased IT responsiveness
Enterprise Architecture should reduce systems development, applications generation and modernization timeframes for legacy systems. It should also decrease resource requirements. All of this can be accomplished by re-using standards, or existing components such as the architecture and solution building blocks in TOGAF 9.1. Delivery time and design/development costs can also be decreased by the reuse of reference models. All that information should be managed in an Enterprise Architecture Repository.
  • Better access to information across applications and improved interoperability
Data and information architectures manage the organization assets of information, optimally and efficiently. This supports the quality, accuracy and timely availability of data for executive and strategic business decision-making, across applications.
  • Readily available descriptive representations and documentation of the enterprise
Architecture is also a set of descriptive representations (i.e. "models") that are relevant for describing an Enterprise such that it can be produced to management's requirements and maintained over the period of its useful life. Using an Architecture Repository, developing a variety of artefacts and modelling some of the key elements of the enterprise; will contribute to build this documentation.
  • Reduce IT costs by consolidating, standardizing, rationalizing and integrating corporate information systems
Cost avoidance can be achieved by identifying overlapping functional scope of two or more proposed projects in an organization, or the potential cost savings of IT support by standardizing on one solution.
Consolidation can happen at various levels for the architectures: for shared enterprise services, applications and information, for technologies and even data centers.

This could involve consolidating the number of database servers, application or web servers and storage devices, consolidating redundant security platforms, or adopting virtualization, grid computing and related consolidation initiatives. Consolidation may be a by-product of another technology transformation, or it may be the driver of these transformations.

Whatever motivates the change, the key is to be in alignment, once again, with the overall business strategy. Enterprise architects understand where the business is going, so they can pick the appropriate consolidation strategy. Rationalization, standardization, and consolidation process helps organizations understand their current Enterprise Maturity level and move forward on the appropriate roadmap.
  • More spending on Innovation
Enterprise Architecture should serve as a driver of innovation. Innovation is highly important when developing a target Enterprise Architecture, and realizing the organization’s strategic goals and objectives. For example, it may help to connect the dots between business requirements and the new approaches SOA and cloud services can deliver.
  • Enabling strategic business goals via better operational excellence
Building Enterprise Architecture defines the structure and operation of an organization. The intent of enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives. It must be designed to support an organization’s specific business strategies.

Jeanne W. Ross, Peter Weill, David C. Robertson in “Enterprise Architecture as Strategy: Creating a Foundation for Business” wrote “Companies with more-mature architectures reported greater success in achieving strategic goals” (p. 89). This included better operational excellence, more customer intimacy, and greater product leadership (p. 100).
  • Customer intimacy
Enterprises which are customer focused and aim to provide solutions for their customers should design its business model, IT systems and operational activities to support this strategy at the process level. This involves the selection of one or few high-value customer niches, followed by an obsessive effort at getting to know these customers in detail.
  • Greater product leadership
This approach enabled by Enterprise Architecture is dedicated to providing the best possible products from the perspective of the features and benefits offered to the customer. It is the basic philosophy about products that push performance boundaries. Products or services delivered by the business will be refined by leveraging IT to do the end customer’s job better. This will be accomplished by the delivery of new business capabilities (e.g. on-line websites, BI, etc.).
  • Comply with regulatory requirements
Enterprise Architecture helps companies to know and represent their processes and systems and how they correlate; fundamental for risk management and managing the regulation requirements, such as those derived from Sarbanes-Oxley, COSO, HIPAA, etc.

This list could be continued as there are many other reasons why Enterprise Architecture brings benefits to organizations. Once your benefits have been documented you could also consider some value management techniques. TOGAF 9.1 refers in the Architecture Vision phase to a target value proposition for a specific project. Here we would apply the value proposition concept to the Enterprise Architecture initiative as a whole.

Value Management uses a combination of concepts and methods to create sustainable value for both organizations and their stakeholders. Some tools and techniques are specific to Value Management and others are generic tools that many organizations and individuals use. There exist many Value Management techniques such as Cost-benefits Analysis, SWOT Analysis, Value Analysis, Pareto Analysis, Objectives Hierarchy, Function Analysis System Technique (FAST), and more…

The one I suggest to illustrate is close to the Objectives Hierarchy technique, which is a diagrammatic process for identifying objectives in a hierarchical manner and often used in conjunction with business functions. Close, because I will use a combination of the TOGAF 9.1 metamodel with the ArchiMate 2.0 Business Layer, Application Layer and Motivation Extensions Metamodels, consider core entities such as value, business goals, objectives, business processes and functions, business and application services, application functions and components. This approach being inspired by the presentation by Michael van den Dungen and Arjan Visser at the Open Group Conference in Amsterdam 2010 and I’m here adding some Archimate 2.0 concepts.

Firstly the entities from the TOGAF 9.1 metamodel:





Then I will consider the entities from ArchiMate 2.0. Some may be identical to TOGAF 9.1. In the Business Layer, one key concept will obviously be the Value. In this case I will consider the Product (“A coherent collection of services, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers.” Source Archimate 2.0 Specification), as the Enterprise Architecture program. In addition to that; I would refer to Business Services, Functions, and Processes.



In the Motivation Extension Metamodel, the Goals. The Objective entity in TOGAF 9.1 can also be represented using the concept of “goal”.


And in the Application Layer Metamodel, Application Services, Functions, and Components.





It is important to mention that when we deliver a value proposition, we must demonstrate to the business where the benefits will be with concrete examples. For example: the business see Operational Excellence and Customer Intimacy as key drivers, soon you will realize that BPM suites or CRM could support the business goals. These are the reasons why we consider the Application Layer Metamodel.

We could then use a combination of the ArchiMate 2.0 viewpoints such as: Stakeholder Viewpoint, Goal Realization Viewpoint, Motivation Viewpoint, or some other viewpoints to demonstrate the Value of Enterprise Architecture for a specific business transformation program (or any other strategic initiative).

To be mentioned that the concept of Benefit does not exist in any of the meta-models.

I have added the concept as an extension to ArchiMate in the following diagram which is the mapping of the value to a program related to the” improvement of customers’ relationships”. I also have limited intentionally the number of concepts or entities, such as Processes, Application Services or Measures.





Using these ArchiMate 2.0 modelling techniques can demonstrate to your stakeholders the Value Proposition for a business program, supported by an Enterprise Architecture initiative.

As a real example, if the expected key business benefit is Operational Excellence through process controls, which would a goal, you could present such a high level diagram to explain why Application Components like a BPM Suite could help (Detecting fraud and errors, embedding preventive controls, continuously auditing and monitoring Processes, and more).

There is definitely not a single way of demonstrating the value of Enterprise Architecture and you probably will have to adapt the process and the way you will present that value to all companies you will be working with. Enterprise Architecture contributes without a doubt to the success of an organization, and brings numerous benefits, but very often it needs to be able to demonstrate that value. Using some techniques as described previously will help to justify such an initiative.

The next steps will be the development of measures, metrics and KPIs to continuously monitor that value proposition.