7 years, 11 months ago

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.

7 years, 11 months ago

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.

8 years, 1 month ago

Using Cobit 5 Part 3 – The Policy Hierarchy

Many companies do not do governance well. A primary reason for this is a focus on governance “process” at the expense of policies. And, where policies are established, it is common to observe a surfeit of bad, inconsistent policies that are overlapping and generally ignored. As a result much governance is carried out by opinion; and governance decisions are not easily repeatable.

The Cobit 5 framework provides reference models for process and goals but, other than providing very general guidance, stops short of any detail at all relating to principles and policy. However in fairness Cobit 5 does recommend “a (hierarchical) structure into which all policies should fit and clearly make the link to the underlying principles”.

So what does a policy hierarchy look like? Does each organization need to invent its own unique structure and content?  Actually we need more than just a policy hierarchy, we need a model that helps us establish a consistent approach to policy search and description. And whilst every organization will have unique needs, much of the hierarchy and policy content will be reusable. What will usually be highly customized are the contexts and their relationships with policy assertions.
 
In the diagram:
policy type – classifies the policy. It can be hierarchic.
policy subject – identifies the focus of the policy the class of object being governed.
policy – a strategy or directive defined independently from how it is carried out
policy assertion  – is an atomic policy requirement, expressed as a statement that must be true or false
policy context  – an entity that limits the reach of a Policy.
policy effect – an intended and/or an actual outcome of a Business Policy. This can be the Principle(s), Goal(s) or Outcome(s), which of course map neatly to Cobit 5.
Let’s look at an example:

Meta Class Example
Policy TypeArchitecture        
Policy SubjectApplication Architecture
PolicyInterfacing
Policy AssertionAll new Application Interfaces must be loose coupled.
Policy ContextGlobal applicability
Policy EffectPrinciple: Interoperable; IT Goal: Agility

Now to put this more broadly into the Cobit 5 context, here’s a fragment of a policy hierarchy, mapped to Policy Subect and Cobit 5 IT Goals.

The policy hierarchy shown above is not rocket science. However it facilitates consistency and communication to all the various stakeholders. You could at a stretch manage policies in a spreadsheet, but in practice it would be advisable to use something like Sharepoint or an equivalent, that allows you to manage the life cycle, status and so on. In a further elaborations of this little series of blog posts I will explore policy relationships with guidance and standards, policy assertion and context development plus the broader policy management model.

Reference: 
Using Cobit 5 – Part 1: Principles
Using Cobit 5 – Part 2: Policy Nomenclature

Next Step: Talk to David about how to apply effective, policy based governance.  

8 years, 1 month ago

Using Cobit 5 – Part 2: Policy Nomenclature

As discussed in Part 1, for me the primary value in Cobit 5 is the formalization of policy as a concept that has a life cycle and management process. In CBDI-SAE we have focused very strongly on defining the policy hierarchy and instances as the mechanism by which consistency is delivered and governed. Consequently over the years I have been critical of Cobit 4.1 because it was essentially promoting process based governance – if you are executing this process, with some nodding in the direction of general outcomes, then everything’s OK.

So I am very pleased to see policy introduced in a more coherent manner in Cobit 5. The 4.1 definition of policy was: “Generally, a document that records a high-level principle or course of action that has been decided upon. A policy’s intended purpose is to influence and guide both present and future decision making to be in line with the philosophy, objectives and strategic plans established by the enterprise’s management teams.”

In Cobit 5 the definition changes to: “Overall intention and direction as formally expressed by management.” This is better, but still not quite there. Contrast it with the CBDI-SAE definition: “A strategy or directive defined independently from how it is carried out.” I could ask what does management mean? If it was really necessary to include, then a reference to Governance Board, Design Authority or equivalent might have been helpful.

However, minor irritations aside, what Cobit 5 does is lay down a clear requirement for policy “to be part of an overall governance and management framework providing a (hierarchical) structure into which all policies should fit and clearly make the link to the underlying principles”. Further Cobit 5 separates Policy from Principle – a very important step. Also very sensibly Cobit 5 does not attempt to define policy instances, nor indeed the hierarchy and this allows specialists (such as ourselves) to map and or align our pre-existing hierarchy to the Cobit framework. I will return to and expand upon the hierarchy in the next part of this series. But first I want to consider policy nomenclature and structure in a little more depth.

Cobit 5 says “Policies provide more detailed guidance on how to put principles into practice . . .” This is potentially misleading. Yes policies are practical strategies and directives that support and realize principles, but to suggest they must be detailed is incorrect. Good policies should be formed as assertions that are true or false and should not be detailed with “how” they are achieved. The best policies are those that are mandatory – providing unequivocal direction to architects and service delivery teams. The detail is best left to Guidelines – or recommendations that indicate use of patterns and practices.

This simple error in Cobit 5 is actually a fundamental flaw that I would like to see fixed. Time and time again I come across confusion over the nomenclature being used by our clients to support governance. Confusion in this area leads to poor  implementation and inconsistent governance. The terms policy, standard and guideline are very commonly used, but frequently mean very different things.

In this context, the good news is Cobit 5 has at least defined policy as the overall intention and direction. I will certainly be using this to advise my clients to standardize on this terminology. Guidelines should then be regarded as practice recommendations. These are not policies with a lower level of mandatory status. At some stage they may evolve to become policies, but not necessarily.

Standards are perhaps a little easier. The CBDI-SAE definition is “A collection of rules or practices which are relevant in Service Architecture or Engineering.” And for good measure the meta type Protocol is a subtype of Standard. Standards therefore are clearly defining the mandatory requirement to comply with specific protocols and practices in given contexts.

To summarize, Cobit 5 is a major step forward. It encourages a policy framework and nomenclature standardization on “policy” for the major directives and strategy assertions and doesn’t preclude complementary Guidelines and Standards under a common management process. In addition Cobit 5 provides the outline framework for development of a policy hierarchy and policy instances, which I will cover in some detail in the next part of this series of blogs.

References: Using Cobit 5 – Part 1 – Principles
                   Using Cobit 5 – Part 3 – The Policy Hierarchy

8 years, 11 months ago

Mission Impossible? Or how to achieve the SOA vision.

When I am asked about the state of SOA, I sometimes comment that anything involving architectural change is bound to take a little time. But my more considered response would be that whilst the impression of SOA is now widespread, true implementation of the SOA vision, for most enterprises remains a distant vision, if indeed they still remember what that was.

For me the vision was encapsulated in the report by one of our customers on their SOA progress in 2009. They reported their systems were exploding in size and complexity. They had scant standardization, and there was no single truth. If a core process broke they would change it to fit the application, rather than the other way round. This was crazily expensive to maintain. After four years of transformation they report a 20% reduction in IT staff, 1500 systems closed down, the ability to turn services on automatically for customers virtually as they place their orders and a massive reduction in complexity demonstrated by a rental price change that previously required changes to 42 systems – followed by three months of testing, now requires just one platform adjustment that automates the change process. THAT’S STRATGIC!

In contrast I read a Forrester survey[1] from last year that reported while 47.4% of respondents work in organizations where SOA projects are underway, the original reasons for SOA, reuse and cost reduction, have morphed into data integration, legacy integration, flexibility of application development, and department-level application integration. Perhaps this is why we at Everware-CBDI are observing numerous inquiries about “SOA Reboot”, which is variously explained as interest in doing SOA properly, realizing the vision and or delivering real business benefit.

For many enterprises the root cause of this lack of achievement is very straightforward – SOA requires a strategic initiative that looks longer term than most enterprises are able to do. But for most enterprises this is mission impossible, they are bound by short term goals and budgets.

The solution is not rocket science. What’s needed is a governance system that manages a progression from tactical to strategic. Many SOA efforts today are business process project focused, because simply put that’s where the business priority is today. What’s needed is a governance system that ensures project service solutions can be evolved to become enterprise services, where it makes sense. The overhead in making this leap is that a few new policies are needed that spell out better working practices. Consider some candidate policies.

  • All new components and services MUST comply with a defined minimum level of reference architecture.
  • Implications and strategy for future service reuse is a REQUIRED element of all Plan or Feasibility phase end reports.
  • All projects MUST reuse and evolve existing (loose coupled) services and components before acquiring or building new components

There’s more; to make this work needs good governance plus a product (sic) management system in place, because it will get complex. But it works.

I am writing this practice up for the Quarter 4 CBDI Journal. Make sure you are a registered subscriber so you get a copy on publication.


[1] TechTarget/Forrester Research State of SOA Survey for 2010

http://media.techtarget.com/searchSOA/downloads/TTAG-State-of-SOA-2010-execSummary-working-523%5B1%5D.pdf