Serge Thorn – Page 2

Implementing SOA through TOGAF 9.1: the Center Of Excellence

October 1, 2012 by Serge Thorn

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.

Implementing SOA through TOGAF 9.1: the Center Of Excellence

October 1, 2012 by Serge Thorn

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?

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

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:

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

They will provide different types of support:

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:

The CoE will provide the “litmus test” of a good service.

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.

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.

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

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.

Here is a detailed principle example:

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

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

June 29, 2013March 1, 2012 by Serge Thorn

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:

Categories Archimate, Business Strategy, business transformation, Enterprise Architecture, IT Business Alignment, Metamodel, Open Group, togaf, Value proposition

When Was Your Last Enterprise Architecture Maturity Assessment?

January 30, 2012January 29, 2012 by Serge Thorn

Every company should plan regular architecture capability maturity assessments using a model. These should provide a framework that represents the key components of a productive enterprise architecture process. A model provides an evolutionary way to improve the overall process that starts out in an ad hoc state, transforms into an immature process, and then finally becomes a well defined, disciplined, managed and mature process. The goal is to enhance the overall odds for success of the enterprise architecture by identifying weak areas and providing a defined path towards improvement. As the architecture matures, it should increase the benefits it offers the organisation.

Architecture maturity assessments help to determine how companies can maximise competitive advantage, identify ways of cutting costs, improve quality of services and reduce time to market. These assessments are undertaken as part of the Enterprise Architecture management.

There are some methodologies for assessment of the comprehensive Enterprise Architecture maturity. Examples of these are the US Department of Commerce ACMM, the Open Group architecture maturity model, and a BSC-based Architecture Score Card presented by IFEAD. For application or technology portfolios, portfolio evaluation models can be used.

As a part of project development, assessments (in reality compliance) of architecture solutions are made against the business objectives and requirements (desired process and service structures and business models) and the constraints derived from the Enterprise Architecture context (these may be standards, principles, policies or other restrictions for solution development). Assessment and compliance of technologies are also a central part of Enterprise Architecture development projects. Finally, the development of Enterprise Architectures undergoes the scrutiny of the software development quality assurance method in use. Many IT providers have adopted a comprehensive software quality assurance approach like CMMI, or ISO/IEC 15504 (known as SPICE).

Using the Architecture Capability Maturity Model from TOGAF® 9.1 is a great way of evaluating the way companies have implemented the framework, to identify the gaps between the business vision and the business capabilities. Unfortunately no sufficient assessment instruments or tools have been developed for TOGAF based assessments.

Instruments or tools should contain maturity and documentation assessment questionnaires and a method on how to conduct such an assessment.

In the following example you may observe four different phases on how to run an assessment.

The Phase 1 would include several steps:

Planning & preparation workshop with the stakeholders. Stakeholders should represent both Business and IT
Interviews with stakeholders based on a questionnaire related to all process areas (elements in TOGAF) or domains that have characteristics important to the development and deployment of Enterprise Architecture. Each process area could be divided into a number of practices, which are statements that describe the process area for each level of maturity, on a scale of 0 to 5. Each practice would have a set of practice indicators, evidence that the requirements for a process area to be at a given level have been met. A set of questions that will be asked in the interviews establishes whether or not the practice indicators exist and thus the level of maturity for the practice. If all the practices for a given level within a Process Area are present, then that level will be achieved. Ideally, directly relevant documentary evidence will be provided to demonstrate that the practice Indicator exists. As this is not always practical, sometimes for this exercise, only verbal evidence from subject matter experts will be considered.
Production of a report
Calculation of a maturity score. For the representation, we use the term maturity level or organisational maturity as described below

Sources

o CMMI for Development (Version 1.2, 2006)
o Appraisal Requirements for CMMI (ARC) (Version 1.2, 2006)
o The US Department of Commerce Enterprise Architecture Capability Maturity Model (2007)
o TOGAF® 9.1
o NASCIO Enterprise Architecture Maturity Model (Version 1.3, 2003)

We then deliver a report which includes the maturity of each process area or element. (There are more elements in this example than those in the chapter 51 of the TOGAF® Version 9.1).

The use of radar may also be a nice way to present the results. (Example below)

Presentation of the report to the stakeholders with strengths, weaknesses, gap analysis, recommendations
Next steps

The Phase 2 would include several steps:

Based on results from the Phase 1, a consensus workshop would produce a roadmap and action plan with recommendations to attain the next (required) level of maturity.
The workshop would provide a tool to produce an objective view of the report provided in Phase 1. This would give stakeholders and the senior management team a detailed view of how well Enterprise Architecture is deployed in the organisation, it provides a full understanding of the business drivers and organisation issues and a clear view of where the stakeholders want the organisation to be. The outputs of this phase are priorities, and an action plan that is agreed, and understood by the key stakeholders in the organisation. There could also be a target radar diagram as shown below (Example).

The updated report may then look like this (extract of an example):

The Phase 3 would be the management of Enterprise Architecture as described in the report and Phase 4 similar to Phase 1.

To conduct an evaluation of an organization’s current practices against an architecture capability maturity assessment model, allows to determine the level at which the organization currently stands. It will indicate the organisation’s maturity in the area of enterprise architecture and highlight the practices on which the organisation needs to focus in order to see the greatest improvement and the highest return on investment. The recommendation is that assessments should be carried out annually.

When Was Your Last Enterprise Architecture Maturity Assessment?

January 30, 2012January 29, 2012 by Serge Thorn

Instruments or tools should contain maturity and documentation assessment questionnaires and a method on how to conduct such an assessment.

In the following example you may observe four different phases on how to run an assessment.

The Phase 1 would include several steps:

Planning & preparation workshop with the stakeholders. Stakeholders should represent both Business and IT
Interviews with stakeholders based on a questionnaire related to all process areas (elements in TOGAF) or domains that have characteristics important to the development and deployment of Enterprise Architecture. Each process area could be divided into a number of practices, which are statements that describe the process area for each level of maturity, on a scale of 0 to 5. Each practice would have a set of practice indicators, evidence that the requirements for a process area to be at a given level have been met. A set of questions that will be asked in the interviews establishes whether or not the practice indicators exist and thus the level of maturity for the practice. If all the practices for a given level within a Process Area are present, then that level will be achieved. Ideally, directly relevant documentary evidence will be provided to demonstrate that the practice Indicator exists. As this is not always practical, sometimes for this exercise, only verbal evidence from subject matter experts will be considered.
Production of a report
Calculation of a maturity score. For the representation, we use the term maturity level or organisational maturity as described below

Sources

We then deliver a report which includes the maturity of each process area or element. (There are more elements in this example than those in the chapter 51 of the TOGAF® Version 9.1).

The use of radar may also be a nice way to present the results. (Example below)

Presentation of the report to the stakeholders with strengths, weaknesses, gap analysis, recommendations
Next steps

The Phase 2 would include several steps:

Based on results from the Phase 1, a consensus workshop would produce a roadmap and action plan with recommendations to attain the next (required) level of maturity.
The workshop would provide a tool to produce an objective view of the report provided in Phase 1. This would give stakeholders and the senior management team a detailed view of how well Enterprise Architecture is deployed in the organisation, it provides a full understanding of the business drivers and organisation issues and a clear view of where the stakeholders want the organisation to be. The outputs of this phase are priorities, and an action plan that is agreed, and understood by the key stakeholders in the organisation. There could also be a target radar diagram as shown below (Example).

The updated report may then look like this (extract of an example):

The Phase 3 would be the management of Enterprise Architecture as described in the report and Phase 4 similar to Phase 1.

What does developing an IT Strategy mean?

October 28, 2011 by Serge Thorn

I have observed many situations where a c-level person was supposed to document an IT Strategy in a short period of time in order to prepare the following year’s annual budget. Very often lacking much supporting documented business information the result is a weak strategy, sometimes ignored by the user’s community, the key stakeholders.

A weak IT strategy can be costly and wasteful, especially for resource-constrained organizations that operate with minimal budget, tools, knowledge and people. It also implies that organizations cannot respond to changing business requirements rapidly enough. The absence of strategic anticipation causes organizations to be inefficiently reactive, forcing them to work in a constant state of catch-up.

An IT Strategy should answer the following questions:

Are we doing the right things with technology to address the organization’s most important business priorities and continuously deliver value to the clients?
Are we making the right technology investments?
Do we measure what is the real value to the organization derived from that technology?
Is our current Information Technology agile enough; flexible to continuously support a successful organization?
Is our Information Technology environment properly managed, maintained, secured, able to support the clients, and is it cost effective?
Can our strategy support current and future business needs?

Quite often the first thing we should consider when writing such a document is the targeted audience and its content. Different people with varying roles and responsibilities may read an IT Strategy within a company, so the document may need to serve several different purposes. It is not easy to pitch a strategy to different levels in the hierarchy within an organization, and at the appropriate level of detail. Sometimes it is too detailed and does not always match the stakeholder’s needs.

An IT Strategy is an iterative process to align IT capabilities with the business strategy and requirements:

It is a documented and approved process (part of the organization’s governance framework)
It is iterative (it needs to be frequently be revisited). Traditionally, IT strategies are updated and communicated on an annual basis, usually to meet budget cycles. This should be considered the minimum review period. If an emerging technology surfaces that has the potential to enhance the business, it should be investigated and communicated to the business as soon as possible. A one-year cycle may be too late.
It is a strong alignment of business and IT capabilities rather than designing IT solutions to support business requirements
- Assuming that both business and IT capabilities drive each other
- Assuming that business drives IT and not the other way around
The IT Strategy sets future direction for IT function in the organization
- Ensuring that the IT budget is spent on value creation activities for the business
- Creating shareholder value
- Helping to maximize the return on IT investments
The IT Strategy may include sub-elements such as:
- Infrastructure strategy
- Application strategy
- Integration strategy
- Service strategy
- Sourcing strategy
- Innovation strategy

This pyramid diagram can be used to illustrate the IT strategy and vision, and how the technology and business strategies are totally aligned. At the top of the pyramid is the enterprise overarching vision. Aligned below that is how IT supports the vision by becoming a premier IT organization in creating competitive advantage for the clients. The IT vision is in turn supported by three pillars: integration, improvement, and innovation.

To deliver this , the business strategy should clearly be articulated and documented taking into account some IT aspects. There are different ways of gathering these business inputs.
The first approach is a very classical one where you develop a questionnaire in business terms which asks each business unit to identify their future requirements for infrastructure growth, taking into account capacity and availability requirements. This extracts the data you need for business driven strategy.

This questionnaire may include some of the following examples of questions:

1. What are your top 5 business “pain” points? These are things that you wish you had a solution for
2. What are your top 5 business objectives? These can be short term or long term, can be driven by revenue, cost, time, time to market, competitive advantage, risk or various other reasons
3. How do you plan to achieve these objectives?
4. What will we gain by leveraging IT Capabilities across the business?
5. What is in the way of achieving your business imperatives?
6. Can IT help achieve your business imperatives?
7. How much do you spend on IT capabilities?
8. What is your technology ROI?
9. Does your company have a plan for technology?
10. Does your business plan include a technology plan?
11. Where is IT being used across your business unit?

The second approach would be the use of Enterprise Archite

What does developing an IT Strategy mean?

October 28, 2011 by Serge Thorn

An IT Strategy should answer the following questions:

Are we doing the right things with technology to address the organization’s most important business priorities and continuously deliver value to the clients?
Are we making the right technology investments?
Do we measure what is the real value to the organization derived from that technology?
Is our current Information Technology agile enough; flexible to continuously support a successful organization?
Is our Information Technology environment properly managed, maintained, secured, able to support the clients, and is it cost effective?
Can our strategy support current and future business needs?

An IT Strategy is an iterative process to align IT capabilities with the business strategy and requirements:

It is a documented and approved process (part of the organization’s governance framework)
It is iterative (it needs to be frequently be revisited). Traditionally, IT strategies are updated and communicated on an annual basis, usually to meet budget cycles. This should be considered the minimum review period. If an emerging technology surfaces that has the potential to enhance the business, it should be investigated and communicated to the business as soon as possible. A one-year cycle may be too late.
It is a strong alignment of business and IT capabilities rather than designing IT solutions to support business requirements
- Assuming that both business and IT capabilities drive each other
- Assuming that business drives IT and not the other way around
The IT Strategy sets future direction for IT function in the organization
- Ensuring that the IT budget is spent on value creation activities for the business
- Creating shareholder value
- Helping to maximize the return on IT investments
The IT Strategy may include sub-elements such as:
- Infrastructure strategy
- Application strategy
- Integration strategy
- Service strategy
- Sourcing strategy
- Innovation strategy

This questionnaire may include some of the following examples of questions:

The second approach would be the use of Enterprise Architecture that I will explain later on.

With this input you may now start to consider the structure of your document. It may look similar to this example below: An executive summary

An introduction
- The purpose
- The background
- The Business drivers
- The Organizational drivers
- The IT drivers
The Business and IT aspects
- The Business Goals and Objectives
- The IT approaches and principles
The IT components
- Business application systems
- IT infrastructure
- Security and IT Service continuity
Structure, organization and management
- IT Governance
- Skills, knowledge and education
- IT Financial management
- KPIS, measurement and metrics, balance scorecards
Technologies opportunities
Key issues

And this is where Enterprise Architecture may have to play an important and even crucial role. Some companies I have encountered have an Enterprise Architecture team, and in parallel, somebody called an IT Strategist. Frequently the connection is non-existing or quite weak. Other organizations may also have a Strategic Planning unit, again without any connection with the Enterprise Architecture team.

An Enterprise Architecture must play the important role of assessing; existing IT assets, architecture standards and the desired business strategy to create a unified enterprise-wide environment – where the core hardware and software systems are standardised and integrated across the entire organisation’s business processes, to greatly enhance competitive advantage and innovation. The IT Strategy details the technologies, application and the data foundation needed to deliver the goals of the corporate strategy, while Enterprise Architecture is the bridge between strategy and execution; providing the organising logic to ensure the integration and standardisation of key processes that drive greater agility, higher profitability, faster time to market, lower IT costs, improved access to shared customer data and lower risk of mission-critical systems failures.

As a real example, TOGAF 9 is perfect way to produce that IT Strategy document during the Phase F: Migration Planning.

Below you will find the relationship between some phases of the ADM and the structure of the above document. It needs to be said that we should probably use a Strategic architecture level to deliver a first version of the document, which then could be reviewed with Segment or Capability architectures.

Content		Examples	Enterprise Architecture and TOGAF
An executive summary
An introduction (This document must be business oriented)
Content		Examples	Enterprise Architecture and TOGAF
	The purpose	Key elements of the scope, audience, time horizon	The Preliminary phase is about defining ‘‘where, what, why, who, and how” Enterprise Architecture will be done and will provide all information. It also creates the conditions and context for an Architecture Capability
	The background	Business problems, constraints (financial, resources, IT, legal, etc.)	This is covered by the Phase A: Architecture Vision. An Architecture Vision sets stage for each iteration of ADM cycle. -Provides high-level, aspirational view of target the sponsor uses to describe how business goals are met and stakeholder concerns are addressed -Provides an executive summary version of full Architecture -Drives consensus on desired outcome The Business Scenarios is used to discover and document business requirements, identify constraints, etc.
	The Business drivers	Market conditions, competition, consumer trends, new customers, products sales, costs savings, incremental services revenues, drivers related to the IT function	In the Phase A: Architecture Vision, we: Identify business goals and strategic drivers -Ensure that descriptions used are current -Clarify any areas of ambiguity Define constraints -Enterprise-wide constraints -Architecture project-specific constraints
	The Organizational drivers	Profitability, financial performance, change in strategic objectives, end of the product development life cycle, mergers and acquisitions, staffs, risks
	The IT drivers	New or obsolete technologies, updates	Considering that IT is part of the Business, these drivers should also be considered in that phase
The Business and IT aspects
	The Business Goals and Objectives	Market growth, entering new markets, addressing manufacturing capacities	In the Phase A: Architecture Vision, we: Identify business goals and strategic drivers -Ensure that descriptions used are current -Clarify any areas of ambiguity -Define constraints -Enterprise-wide constraints -Architecture project-specific constraints
	The IT approaches and principles	IT standards, development, implementation, delivery, testing, consolidation, maturity, best practices	Standards should be documented in the SIB (Standard Information Base) When we define the Architecture Governance Framework during the Preliminary Phase, we identy the various touch points with existing other frameworks in the organization IT principles should have already have been defined by the IT department
The IT components
	Business application systems	Baseline (main applications: ERP, CRM, customers facing systems). Future plans, concerns, time period, priorities)	This will be addressed by Phase C: Information Systems based on the Statement of Architecture Work, output from the Phase A
	IT infrastructure	Baseline (servers, network , middleware, technical services)	This will be addressed by Phase D: Technology Architecture based on the Statement of Architecture Work, output from the Phase A
	Security and IT Service continuity	Issues, challenges, opportunities related to security, security principles, controls	Security concerns are addressed during all phases of the ADM
Structure, organization and management
	IT Governance	Best practices, frameworks, management and monitoring, resource management, portfolio management, vendors management, IT service management, project management, etc.	IT Governance will be considered when the Architecture Governance Framework is defined. There will obviously be touch points between the ADM and some other best practices used by the organization. IT Governance is defined outside of the Enterprise Architecture programme
	Skills, knowledge and education	Skills, knowledge and education	Enterprise Architecture skills will have to be addressed by the Architecture Capability Framework. Other skills may also be identified independently of the Enterprise Architecture programme
	IT Financial management	IT budget, costs structures, measurement and metrics, targets, areas needing investments, etc.	This is addressed is outside of the Enterprise Architecture programme
	KPIS, measurement and metrics, balance scorecards	IT performance measurements on SMART objectives ((Specific, Measurable, Achievable, Realistic, & Time bound)	Every governance frameworks may have its own KPIs. Enterprise Architecture KPIs may be added to that list.
Technologies opportunities		Emerging technologies, business related benefits	This can be done in parallel of the Enterprise Architecture programme
Key issues and initiatives		Summary or link to the IT Project portfolio	This can be done in parallel of the Enterprise Architecture programme

Color legend
	Direct relationship with Enterprise Architecture
	Indirect relationship with Enterprise Architecture
	Produced somewhere else

The next step would be the review of the IT Strategy document by the main stakeholders who would accept or reject technology opportunities. This could also be used as an important source of information for the Strategic Planning exercise (please refer to another post for additional information: “How Strategic Planning relates to Enterprise Architecture? “).

Once the IT Strategy has been reviewed, amended and authorised (which should in reality already be approved, as it is the result of various ADM cycles and the output of Phase F: Migration planning), the multi-disciplinary programme team for the implementation during Phase G: Implementation Governance, will deliver the solutions to the business.

As already mentioned previously, the outline strategies will be refined and expanded with a low level of detail when addressing Segment and Capability architectures. This is the part that meets the first challenge described above, where we need different levels of detail for different stakeholders. The documents should be hierarchical, with the ability to drill down to lower levels as more detail is required.

One of the main reasons for developing an Enterprise Architecture with TOGAF 9 is to support the business by providing the fundamental technology and process structure for an IT Strategy. Enterprise Architecture is the superset that represents both Business and IT Strategy; this is reflected in Enterprise Architecture’s basic structure of strategy, business architecture and technology/information architecture. One can certainly do an IT Strategy without Enterprise Architecture, but Enterprise Architecture cannot be done without an IT Strategy; the same would apply to business strategy/business architecture.

Cloud Governance, Risk and Compliance Summit

October 13, 2011 by Serge Thorn

As more enterprises engage in public, private and hybrid cloud computing services, they face new sets of security and compliance challenges. As a result of the rapid transition and growing capabilities of the cloud, enterprises must evolve their securi…

Cloud Governance, Risk and Compliance Summit

October 13, 2011 by Serge Thorn

What is Business Technology Management and how does it relate to Enterprise Architecture?

September 30, 2011 by Serge Thorn

Business Technology Management (BTM) is not a methodology but I would say a concept, or eventually the aggregation of several guidelines and techniques. It is also described as a management science which aims to unify business and technology business strategies with the aim of extracting the full potential value of business technology solutions. In a nutshell, it allows you to unify business and technology decision making. Sounds familiar?
Pragmatically it corresponds to a group of various services intended to help businesses communities. BTM can include different methods such as IT planning, Project and Portfolio management (e.g. PMI, Prince 2), Balance Scorecards, Business support, Database services, disaster recovery, network management, security, document service, and frameworks. BTM delivers a set of guiding principles known as capabilities and defines the expected characteristics of an organization according to five levels of a maturity mode like CMMi. While these methods/methodologies have recognized strengths, they represent a piecemeal approach. There is a need to integrate these capabilities to achieve that strategic business technology alignment because most of these methods do not really focus on the goals and objectives of an enterprise. Balance Scorecard is a performance measurement methodology, Six Sigma or Lean are quality improvement methodologies mostly used in manufacturing, and so on…
BTM may sound like an evolved IT governance concept, where business and IT are in tune in an effort to support and realise the enterprise strategy. But does it really differ from an Enterprise Architecture which sometimes may also be considered as being the glue between various methods/methodologies?
Some questions may quickly arise…Is BTM just “better IT Governance” or simply a different way of naming an Enterprise Architecture? And does TOGAF® support BTM? BTM like Enterprise Architecture aligns activities which remain pure business and some pure technology, but most activities intertwine business and technology such that they become indistinguishable. It also guides and supports enterprises to these various states.
The precepts of Business Technology Management have been developed and refined by BTM experts working with such think tanks as the BTM Institute and the International Institute of Business Technologies (IIBT).

Business Technology Management addresses four critical dimensions of enterprise-wide strategy
1. Process
This first dimension refers to the institution of a set of robust, flexible and repeatable processes, broadly defined as:
General quality of Business Practice: Doing the right things
Efficiency: Doing things efficiently, quickly with little redundancy
Effectiveness: Doing things well
The TOGAF® 9 ADM is an example of such processes with its associated governance framework.
2. Organisation
Management processes are more likely to succeed when it refers to the establishment of appropriate organisational structures, establishing a structure in which every member understands the scope and responsibilities of his or her role, and decision rights. Something perfectly addressed during the Phases Preliminary and A of TOGAF®.
Organizational structures may include
· Participative bodies involving senior level business and technology participants on a part-time but routine basis (e.g. Business Technology Investment Board). TOGAF® suggests the creation of an architecture board who participate with the key business stakeholders.
· Centralized bodies requiring specialized dedicated technology staff (e.g. PMO).
· Need-based bodies involving rotational assignments dealing with particular efforts (e.g. PMO, Project Management teams).
Both last bodies would be identified during Phase F: Migration Planning and Phase G: Implementation Governance
3. Information
Valid, effective, timely provision of information is a prerequisite in effective decision making. Information must be delivered in a way that is comprehensible to non specialists as well. Data and metrics must be available. This would be addressed by the Communication Plan defined in the TOGAF® Architecture Vision’s phase taking into account the stakeholders needs, the communication mechanisms and timetable. Measurements and metrics may be included for strategic and operational objectives.
4. Technology
Effective technology can help connect the other three dimensions. The idea is that technology plays a vital role in all processes and can enable timely information sharing, improve co-ordination between members of an organisation and makes processes easier to execute. This covers automation of tasks, reporting, analytics and integration between management systems. In Enterprise Architecture, this would be covered by the interoperability requirements identified by the business and the identification of appropriate solutions in the TOGAF® Phases E and F, such as BPM suites and BI products.

Business Technology Management (BTM) Capabilities
A BTM capability is defined as a competency achieved by combining each of the above dimensions and creating repeatable management processes that are executed with the appropriate organizational structures, using an effective information architecture.
Business Technology Management defines 17 of these specific capabilities, each grouped into one of four functional areas.
Governance and Organisation: These capabilities are focused on the enterprise’s CIO and business executives concerned with enterprise wide governance of business technology. It ensures that business technology decisions are effectively identified and executed, meet the needs of the business, manages the risk and give proper consideration to regulatory, legal and industry requirements. TOGAF® addresses all of this in the Preliminary Phase and the Architecture Vision, where an enterprise architecture governance framework is created.
Managing Technology Investments : This sits with PMO and business executives who are concerned with the selection and execution of the right business technologies initiatives and fulfil their objectives. The enterprise understands its current IT capabilities, what is currently available and what it is working on for the future. This is equally addressed during the Phase F: Migration Planning.
Strategy & Planning: These capabilities ensure that the CIO and business executives make the most appropriate moves to synchronise technology and business, both reducing complexity and planning for future developments. Enterprise Architecture and TOGAF 9 undoubtedly support these capabilities; you may refer to the previous article “How Strategic Planning relates to Enterprise Architecture”.
Strategic Enterprise Architecture: This capability must be developed to support this functional area, ensure that appropriate information and documentation exists that can describe current and future business technology environment within the enterprise. As we observed, TOGAF® as an Enterprise Architecture framework includes most of the capabilities mentioned above!
The BTM Maturity Model
A maturity model describes how well an enterprise performs a particular set of activities. These capabilities are useless without a method by which to measure their effectiveness. The BTM Maturity model is aligned with the de-facto standard from CMMi and use the five levels of maturity of all the four dimensions. Here again the Architecture Capability Maturity Model from TOGAF® 9 may be used to evaluate these capacities. We would identify the area most in need for improvement.
Level 1: enterprises execute some strategic business technology management processes in ad-hoc way. These enterprises typically manage processes in a simple task-based manner.
Level 2: enterprises attempt to assemble information for major decisions, and refer to IT on decisions for technology implications.

Level 3: enterprises are ‘functional’ in BTM.

Level 4: enterprises have achieved full BTM implementation. Their capabilities ensure that there is strong alignment between business and technology decision making.

Level 5: enterprises have achieved the ‘Holy Grail’ of BTM. They are good enough to know when to change the rules to maintain strategic advantages over competitors.
To implement its business strategy, the enterprise requires particular operational capabilities as described above and clearly it appears that Business Technology Management can be supported by Enterprise Architecture. TOGAF® 9 is in reality addressing all of these 17 BTM capabilities grouped in functional areas, identified by the four dimensions and work as a management framework to clarify required enterprise business needs. Companies having implemented BTM should consider using TOGAF® 9 as the way of rightfully pursuing alignment of technology with the business and support a Business-Agile enterprise.

What is Business Technology Management and how does it relate to Enterprise Architecture?

September 30, 2011 by Serge Thorn

Are Business Process Management and Business Architecture a perfect match?

September 1, 2011 by Serge Thorn

Whenever I suggest collaboration between these two worlds, I always observe some sort of astonishment from my interlocutors. Many Enterprise Architects or Business Architects do not realise there may be synergies. Business Process Management (BPM) team have not understood what Enterprise Architecture is all about and the other way around…. There is no a single definition of Business Process Management, often it means different things to different people. To keep it very generic, BPM relates to any activities an organization does to support its process efforts.

There are many activities which can be included in such efforts:
· The use of industry Business Reference Model (or Business Process Reference Model), a reference for the operational activities of an organization, a framework facilitating a functional Lines of Business, such as

o The Federal Enterprise Architecture Business Reference Model of the US Federal Government
o The DoD Business Reference Model
o The Open Group Exploration and Mining Business Reference Model (https://www.opengroup.org/emmmv/uploads/40/22706/Getting_started_with_the_EM_Business_Model_v_01.00.pdf)
o Frameworx (eTOM) for Telco companies
o The Supply Chain Operations Reference (SCOR®) model
o The SAP R/3 Reference Model
o The Oracle Business Models : Oracle Industry Reference Model for Banking, (IRM), Oracle Retail Reference Model
o And others…

· The use of organization specific Business Reference models
· The use of Business process improvement methodologies

o Lean, a quantitative data driven methodology based on statistics, process understanding and process control
o Six Sigma, a methodology that mainly focuses on eliminating bad products or services to clients by using statistical evaluation

· Business Process Reengineering, which in reality is a facet of BPM
· The understanding of Business Change Management, the process that empowers staff to accept changes that will improve performance and productivity
· The understanding of Business Transformation, the continuous process, essential to any organization in implementing its business strategy and achieving its vision
· The use of Business Rules Management which enables organizations to manage business rules for decision automation
· The understanding of Business Process Outsourcing (BPO) services to reduce costs and increase efficiency
· The support of Business Process modeling and design, which is illustrated description of business processes, usually created with flow diagrams. The model contains the relationship between activities, processes, sub-processes and information, as well as roles, the organization and resources. This can done with many notations such as flow chart, functional flow block diagram, control flow diagram, Gantt chart, PERT diagram, IDEF, and nowadays with the standard de facto notations such as UML and BPMN
· The support of BPM tools and suites implementation. With the right, process models can be simulated, to drive workflow or BPMS systems, and can be used as the basis for an automated process monitoring system (BAM)
· The support of Business Activity Monitoring (BAM), the ability to have end-to-end visibility and control over all parts of a process or transaction that spans multiple applications and people in one or even more companies.

To combine Business Process Management and Enterprise Architecture for better business outcomes is definitely the way forward, where BPM provides the business context, understanding, and- metrics, and Enterprise Architecture provides the discipline to translate business vision and strategy into architectural changes. Both are needed for sustainable continuous improvement. When referring to Enterprise Architecture, we would mainly refer to Business Architecture. Business Architecture involves more than just the structure of business processes. It also entails the organization of departments, roles, documents, assets, and all other process-related information.

Business Architects may be defining and implementing the Business Process framework and, in parallel, influencing the strategic direction for Business Process Management and improvement methodologies (e.g. Lean, Six Sigma). The business process owners and Business Analysts are working within their guidelines at multiple levels throughout the organizations’ business process. They have roles and responsibilities to manage, monitor and control their processes.
An important tool in developing Business Architecture is a Business Reference Model. These types of models are enormously beneficial. They can be developed in the organization to build and extend the information architecture. The shared vocabulary (verbal and visual) that emerges from these efforts promotes clear and effective communication.

To illustrate the touch points between Enterprise Architecture and Business Process Management, I have illustrated in the table below the synergies between the two approaches using TOGAF® 9.

In this table, we observe that, there is a perfect match between Business Process Management and the use of an Enterprise Architecture framework such as TOGAF. BPM is often project based and the Business Architect (or Enterprise Architect) may be responsible for identifying cross-project and cross-process capabilities. It can be considered as being the backbone of an Enterprise Architecture program. We can also add to this, that Service Oriented Architecture is the core operational or transactional capability while BPM does the coordination and integration into business processes.

When using BPM tools and suites, you should also consider the following functionalities: workflow, enterprise application integration, content management and business activity monitoring. These four components are traditionally provided by vendors as separate applications which are merged through BPM into a single application with high levels of integration. The implementation of a BPM solution should theoretically eliminate the maintenance and support cost of these four applications resulting in reducing the total cost of ownership.

Business Architecture provides the governance, alignment and transformational context for BPM across business units and silos. Enterprise Architects, Business Architects, Business Analysts should work together with BPM teams, when approaching the topic of Business Process Management. BPM efforts need structures and appropriate methodologies. It needs a structure to guide efforts at different levels of abstraction (separating “the what“ (the hierarchical structure of business functions) from “the how” (how the desired results are achieved), a documented approach and structure to navigate among the business processes of the organization, i.e. a Business Architecture. They also need a methodology such as an Enterprise Architecture framework to retain and leverage what they have learned about managing and conducting BPM projects.