Serge Thorn – Page 3

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.

How Strategic Planning relates to Enterprise Architecture?

June 29, 2011 by Serge Thorn

TOGAF often refers to Strategic Planning without specifying the details of what it consists of. This document explains why there is a perfect fit between the two.

Strategic Planning means different things to different people. The one constant is its reference to Business Planning which usually occurs annually in most companies. One of the activities of this exercise is the consideration of the portfolio of projects for the following financial year, also referred to as Project Portfolio Management (PPM). This activity may also be triggered when a company modifies its strategy or the priority of its current developments.

Drivers for Strategic Planning may be

· New products or services

· A need for greater Business flexibility and agility

· Merger & Acquisition

· Company’s reorganization

· Consolidation of manufacturing plants, lines of business, partners, information systems

· Cost reduction

· Risk mitigation

· Business Process Management initiatives

· Business Process Outsourcing

· Facilities outsourcing or in sourcing

· Off shoring

Strategic Planning as a process may include activities such as:

1. The definition of the mission and objectives of the enterprise

Most companies have a mission statement depicting the business vision, the purpose and value of the company and the visionary goals to address future opportunities. With that business vision, the board of the company defines the strategic (e.g. reputation, market share) and financial objectives (e.g. earnings growth, sales targets).

2. Environmental analysis

The environmental analysis may include the following activities:

· Internal analysis of the enterprise

· Analysis of the enterprise’s industry

· A PEST Analysis (Political, Economic, Social, and Technological factors). It is very important that an organization considers its environment before beginning the marketing process. In fact, environmental analysis should be continuous and feed all aspects of planning, identify the strengths and weaknesses, the opportunities and threats (SWOT).

3. Strategy definition

Based on the previous activities, the enterprise matches strengths to opportunities and addressing its weaknesses and external threats and elaborate a strategic plan. This plan may then be refined at different levels in the enterprise. Below is a diagram explaining the various levels of plans.

To build that strategy, an Enterprise Strategy Model may be used to represent the Enterprise situation accurately and realistically for both past and future views. This can be based on Business Motivation Modeling (BMM) which allows developing, communicating and managing a Strategic Plan. Another possibility is the use of Business Model Canvas which allows the company to develop and sketch out new or existing business models. (Refer to the work from Alexander Osterwalder http://alexosterwalder.com/).

The model’s analyses should consider important strategic variables such as customers demand expectations, pricing and elasticity, competitor behavior, emissions regulations, future input, and labor costs.

These variables are then mapped to the main important business processes (capacity, business capabilities, constraints), and economic performance to determine the best decision for each scenario. The strategic model can be based on business processes such as customer, operation or background processes. Scenarios can then are segmented and analyzed by customer, product portfolio, network redesign, long term recruiting and capacity, mergers and acquisitions to describe Segment Business Plans.

4. Strategy Implementation

The selected strategy is implemented by means of programs, projects, budgets, processes and procedures. The way in which the strategy is implemented can have a significant impact on whether it will be successful, and this is where Enterprise Architecture may have a significant role to play. Often, the people formulating the strategy are different from those implementing it. The way the strategy is communicated is a key element of the success and should be clearly explained to the different layers of management including the Enterprise Architecture team.

To support that strategy, different levels or architecture can be considered such as strategic, segment or capability architectures.

Figure 20-1: Summary Classification Model for Architecture Landscapes

This diagram below illustrates different examples of new business capabilities linked to a Strategic Architecture.

It also illustrates how Strategic Architecture supports the enterprise’s vision and the strategic plan communicated to an Enterprise Architecture team.

Going to the next level allows better detail the various deliverables and the associated new business capabilities. The segment architecture maps perfectly to the Segment Business Plan.

5. Evaluation and monitoring

The implementation of the strategy must be monitored and adjustments made as required.

Evaluation and monitoring consists of the following steps:

1. Definition of KPIs, measurement and metrics

2. Definition of target values for these KPIs

3. Perform measurements

4. Compare measured results to the pre-defined standard

5. Make necessary changes

Strategic Planning and Enterprise Architecture should ensure that information systems do not operate in a vacuum. At its core, TOGAF 9 uses/supports a strong set of guidelines that were promoted in the previous version, and have surrounded them with guidance on how to adopt and apply TOGAF to the enterprise for Strategic Planning initiatives. The ADM diagram below clearly indicates the integration between the two processes.

The company’s mission and vision must be communicated to the Enterprise Architecture team which then maps Business Capabilities to the different Business Plans levels.

Many Enterprise Architecture projects are focused at low levels but should be aligned with Strategic Corporate Planning. Enterprise Architecture is a critical discipline, one Strategic Planning mechanism to structure an enterprise. TOGAF 9 is without doubt an effective framework for working with stakeholders through Strategic Planning and architecture work, especially for organizations who are actively transforming themselves.

How Strategic Planning relates to Enterprise Architecture?

June 29, 2011 by Serge Thorn

TOGAF often refers to Strategic Planning without specifying the details of what it consists of. This document explains why there is a perfect fit between the two.

Drivers for Strategic Planning may be

· New products or services

· A need for greater Business flexibility and agility

· Merger & Acquisition

· Company’s reorganization

· Consolidation of manufacturing plants, lines of business, partners, information systems

· Cost reduction

· Risk mitigation

· Business Process Management initiatives

· Business Process Outsourcing

· Facilities outsourcing or in sourcing

· Off shoring

Strategic Planning as a process may include activities such as:

1. The definition of the mission and objectives of the enterprise

2. Environmental analysis

The environmental analysis may include the following activities:

· Internal analysis of the enterprise

· Analysis of the enterprise’s industry

3. Strategy definition

4. Strategy Implementation

To support that strategy, different levels or architecture can be considered such as strategic, segment or capability architectures.

Figure 20-1: Summary Classification Model for Architecture Landscapes

This diagram below illustrates different examples of new business capabilities linked to a Strategic Architecture.

It also illustrates how Strategic Architecture supports the enterprise’s vision and the strategic plan communicated to an Enterprise Architecture team.

Going to the next level allows better detail the various deliverables and the associated new business capabilities. The segment architecture maps perfectly to the Segment Business Plan.

5. Evaluation and monitoring

The implementation of the strategy must be monitored and adjustments made as required.

Evaluation and monitoring consists of the following steps:

1. Definition of KPIs, measurement and metrics

2. Definition of target values for these KPIs

3. Perform measurements

4. Compare measured results to the pre-defined standard

5. Make necessary changes

The company’s mission and vision must be communicated to the Enterprise Architecture team which then maps Business Capabilities to the different Business Plans levels.

Managing Requirements from a Business Analyst or an Enterprise Architect perspective using BABOK 2.0 and/or TOGAF 9

May 16, 2011May 16, 2011 by Serge Thorn

Many Business Analysts are using the IIBA’s BABOK 2.0 (Business Analyst Body of Knowledge ) which contains information about a Requirements Management process, from identifying organizational situations that give cause to a project, through to starting the requirements gathering process, to delivering a solution to the business or a client. TOGAF 9 from an Enterprise Architecture viewpoint also provides some techniques to gather requirements to equally deliver business solutions. This paper illustrates the two processes, defines the mapping between the two approaches and identifies gaps in each.

BABOK 2.0 Knowledge Area (KA) 4 covers Requirements Management and Communication which “describes the activities and considerations for managing and expressing Requirements to a broad and diverse audience” (The other KAs: Plan Requirements, Management Process, and Requirement Analysis will not be included here).

The tasks from this KA “are performed to identify business needs (the why of the project; whereas requirements are the how), the state the scope of their business solutions, ensure that all stakeholders have a shared understanding of the nature of these solutions and that those stakeholders with approval authority are in agreement as to the requirements that the business solution shall meets.”

It manages a baseline, tracks different versions of Requirements documents, and trace requirements from origin to implementation.

This area includes five steps described below.

1. Manage Solution Scope and Requirements

In this step, we “obtain and maintain consensus among stakeholders regarding the overall solution scope and the requirements that will be implemented”. Requirements may be baseline following an approval and a signoff. That means that all future changes are recorded and tracked, and the current state may be compared to the baselined state. Subsequent changes to the requirements must follow a Change Management process and will require additional approval. As changes are approved, a Requirements Management Plan may require that the baselined version of the requirements be maintained in addition to the changed Requirement. Additional information is often maintained such as a description of the change, the person who made the change, and the reason for the change. As requirements are refined or changed as the result of new information, changes will be tracked as well.

A signoff formalises an acceptance by all stakeholders that the content and presentation of documented requirements is accurate and complete. This can be done in a face to face meeting.

2. Manage Requirements Traceability

Traceability consists of understanding the relationship between Business Objectives, the requirements, the stakeholders, other deliverables and components to support the business analysis among other activities. It also allows documenting “the lineage of each requirement, its backward and forward traceability, and its relationship to other requirements”. The reasons for creating relationships are “Impact Analysis”, and “Requirements coverage and allocation”. A coverage matrix may be used to manage tracing.

3. Maintain Requirements for re-use

Requirements re-use is another important aspect in the process and there is a need to manage knowledge of requirements following their implementation, identify the requirements that are candidates for long-term usage by the organisation. “These may include requirements that an organisation must meet on an ongoing basis, as well requirements that are implemented part of a solution” (e.g. regulatory, contractual obligations, quality standards, service level requirements, etc.). Each will have to be clearly named, defined, and available to all analysts.

4. Prepare Requirements Package

This step consists in selecting and structuring a set of requirements “in an appropriate fashion to ensure that the requirements are effectively communicated to, understood and usable” by the various stakeholders. This Requirements Package could have different forms such as a documentation (can be managed in a Requirements Repository), presentations, templates, etc.

5. Communicate Requirements

This step relates to the communication of requirements to the various stakeholders for a common understanding. It may happen that new requirements have to be considered.

The BABOK bundles Requirements Communication together with Requirements Management.

Requirements Analysis is another KA which describes “how we progressively elaborate the solution definition in order to enable the project team to design and build a solution that will meet the needs of the business and stakeholders. In order to do that, we have to analyze the stated requirements of our stakeholders to ensure that they are correct, assess the current state of the business to identify and recommend improvements, and ultimately verify and validate the results”. BABOK 2.0 Requirements Analysis being not really covered within TOGAF 9, there are no comparisons done at this stage.

Within TOGAF 9, the objective of the Requirements Management activity is to define a process whereby all kinds of requirements, including most notably business drivers, concerns, and new functionality and change requests for Enterprise Architecture are identified, stored, and fed into and out of the relevant Architecture Development Method (ADM) phases. As such it forms part of the activities and steps carried out in each of the ADM Phases. Architecture requirements are subject to constant change, and requirements management happens throughout the entire Enterprise Architecture implementation lifecycle.

It is important to note that the Requirement Management circle denotes, not a static set of requirements, but a dynamic process.

As indicated by the Requirements Management circle at the centre of the ADM graphic, the ADM is continuously driven by the Requirements Management process.

Enterprise Architecture has specific techniques to gather requirements. TOGAF as a framework uses a method based on what we call a “Business Scenario” which is used heavily in the initial phases A & B of the ADM to define the relevant business requirements and build consensus with business management and other stakeholders.

A Business Scenario ensures that there is a complete description of business problem in business and architectural terms. Individual requirements are viewed in relation to one another in the context of the overall problem; the architecture is based on complete set of requirements that add up to a whole problem description; the business value of solving the problem is clear and the relevance of potential solutions is clear.

Below is a mapping between the two approaches.

BABOK 2.0 sets up a framework for the requirements development and management, which seems to appear as a standard used by many organizations around the world. Between TOGAF 9 and BABOK 2.0, there is almost 1:1 correspondence but there may be more details and activities in the first one. TOGAF is a methodology whereas the BABOK is methodology agnostic, so it can be tricky to translate between the two but nothing prevent an Enterprise Architecture team to use this analogous technique.

If an organization follows the TOGAF methodology and Business Analysts use BABOK, the later will provide a lot of useful information, as a reference; BABOK won’t give you direction for an Enterprise Architecture.

Sources: Chapter 4 IIBA’s BABOK 2.0, TOGAF 9

Managing Requirements from a Business Analyst or an Enterprise Architect perspective using BABOK 2.0 and/or TOGAF 9

May 16, 2011May 16, 2011 by Serge Thorn

It manages a baseline, tracks different versions of Requirements documents, and trace requirements from origin to implementation.

This area includes five steps described below.

1. Manage Solution Scope and Requirements

A signoff formalises an acceptance by all stakeholders that the content and presentation of documented requirements is accurate and complete. This can be done in a face to face meeting.

2. Manage Requirements Traceability

3. Maintain Requirements for re-use

4. Prepare Requirements Package

5. Communicate Requirements

This step relates to the communication of requirements to the various stakeholders for a common understanding. It may happen that new requirements have to be considered.

The BABOK bundles Requirements Communication together with Requirements Management.

It is important to note that the Requirement Management circle denotes, not a static set of requirements, but a dynamic process.

As indicated by the Requirements Management circle at the centre of the ADM graphic, the ADM is continuously driven by the Requirements Management process.

Below is a mapping between the two approaches.

Sources: Chapter 4 IIBA’s BABOK 2.0, TOGAF 9

Creation of a strategy for the consumption and management of Cloud Services in the TOGAF Preliminary Phase

March 19, 2011March 19, 2011 by Serge Thorn

In a previous article I described the need to define a strategy as an additional step in the TOGAF 9 Preliminary Phase. This article describes in more details what could be the content of such a document, what are the governance activities related to the Consumption and Management of Cloud Services.

Before deciding to switch over to Cloud Computing, companies should first fully understand the concepts and implications of an internal IT investment or buying this as a service. There are different approaches which may have to be considered from an enterprise level when Cloud computing is considered: Public Cloud vs Private Clouds vs Hybrid Clouds. Despite the fact that many people already know what the differences are, below some summary of the various models

· A public Cloud is one in which the consumer of Cloud services and the provider of cloud services exist in separate enterprises. The ownership of the assets used to deliver cloud services remains with the provider

· A private Cloud is one in which both the consumer of Cloud services and the provider of those services exist within the same enterprise. The ownership of the Cloud assets resides within the same enterprise providing and consuming cloud services. It is really a description of a highly virtualized, on-premise data center that is behaving as if it were that of a public cloud provider

· A hybrid Cloud combines multiple elements of public and private cloud, including any combination of providers and consumers

Once the major Business stakeholders understand the concepts, some initial decisions may have to be documented and included in that document. The same may also apply to the various Cloud Computing categorisations such as diagrammed below:

The categories the enterprise may be interested in related to existing problems can already be included as a section in that document.

Quality Management

There is need of a system for evaluating performance, whether in the delivery of Cloud services or the quality of products provided to consumers, or customers. This may include:

· A test planning and a test asset management from Business requirements to defects

· A Project governance and release decisions based on some standards such as Prince 2/PMI and ITIL

· A Data quality control (all data uploaded to a Cloud computing service provider must ensure it fits the requirements of the provider). This should be detailed and provided by the provider

· Detailed and documented Business Processes as defined in ISO 9001:

o Systematically defining the activities necessary to obtain a desired result

o Establishing clear responsibility and accountability for managing key activities

o Analyzing and measuring of the capability of key activities

o Identifying the interfaces of key activities within and between the functions of the organization

o Focusing on the factors such as resources, methods, and materials that will improve key activities of the organization

o Evaluating risks, consequences and impacts of activities on customers, suppliers and other interested parties

Security Management

This would address and document specific topics such as:

· Eliminating the need to constantly reconfigure static security infrastructure for a dynamic computing environment

· Define how services are able to securely connect and reliably communicate with internal IT services and other public services

· Penetration security checks

· How a Security Management/System Management/Network Management teams monitor that security and the availability

Semantic Management

The amount of unstructured electronic information in enterprise environments is growing rapidly. Business people have to collaboratively realise the reconciliation of their heterogeneous metadata and consequently the application of the derived business semantic patterns to establish alignment between the underlying data structures. The way this will be handled may also be included.

IT Service Management (ITIL)

IT Service Management or IT Operations teams will have to address many new challenges due to the Cloud. This will need to be addressed for some specific processes such as:

· Incident Management

o The Cloud provider must ensure that all outages or exceptions to normal operations are resolved as quickly as possible while capturing all of the details for the actions that were taken and are communicated to the customer.

· Change Management

o Strict change management practices must be adhered to and all changes implemented during approved maintenance windows must be tracked, monitored, and validated.

· Configuration Management (Service Asset and…)

o Companies who have a CMDB must provide this to the Cloud providers with detailed descriptions of the relationships between configuration items (CI)

o CI relationships empowers change and incident managers need to determine that a modification to one service may impact several other related services and the components of those services

o This provides more visibility into the Cloud environment, allowing consumers and providers to make more informed decisions not only when preparing for a change but also when diagnosing incidents and problems

· Problem Management

o The Cloud provider needs to identify the root cause analysis in case or problems

· Service Level Management

o Service Level Agreements (or Underpinning contracts) must be transparent and accessible to the end users. The business representatives should be negotiating these agreements. They will need to effectively negotiate commercial, technical, and legal terms. It will be important to establish these concrete, measurable Service Level Agreements (SLAs) without these and an effective means for verifying compliance, the damage from poor service levels will only be exacerbated

· Vendors Management

o Relationship between a vendor and their customers changes

o Contractual arrangements

· Capacity Management and Availability Management

o Reporting on performance

Other activities must be documented such as:

Monitoring

· Monitoring will be a very important activity and should be described in the Strategy document. The assets and infrastructure that make up the Cloud service is not within the enterprise. They are owned by the Cloud providers, which will most likely have a focus on maximizing their revenue, not necessarily optimizing the performance and availability of the enterprise’s services. Establishing sound monitoring practices for the cloud services from the outset will bring significant benefits in the long term. Outsourcing delivery of service does not necessarily imply that we can outsource the monitoring of that service. Besides, today very few cloud providers are offering any form of service level monitoring to their customers. Quite often, they are providing the Cloud service but not proving that they are providing that service.

· The resource usage and consumption must be monitored and managed in order to support strategic decision making

· Whenever possible, the Cloud providers should furnish the relevant tools for management and reporting and take away the onerous tasks of patch management, version upgrades, high availability, disaster recovery and the like. This obviously will impact IT Service Continuity for the enterprise.

· Service Measurement, Service Reporting and Service Improvement processes must be considered.

Consumption and costs

· Service usage (when and how) to determine the intrinsic value that the service is providing to the Business, and IT can also use this information to compute the Return On Investment for their Cloud computing initiatives and related services. This would be related to the process IT Financial Management.

Risk Management

The TOGAF 9 risk management method should be considered to address the various risks associated such as:

· Ownership, Cost, Scope, Provider relationship, Complexity, Contractual, Client acceptance, etc

· Other risks should also be considered such as : Usability, Security (obviously…) and Interoperability

Asset Management and License Management

When various cloud approaches are considered (services on-premise via the Cloud), hardware and software license management to be defined to ensure companies can meet their governance and contractual requirements

Transactions

Ensuring the safety of confidential data is a mission critical aspect of the business. Cloud computing gives them concerns over the lack of control that they will have over company data, and does not enable them to monitor the processes used to organize the information.

Being able to manage the transactions in the Cloud is vital and Business transaction safety should be considered (recording, tracking, alerts, electronic signatures, etc…).

There may be other aspects which should be integrated in this Strategy document that may vary according to the level of maturity of the enterprise or existing best practices in use.

When considering Cloud computing, the Preliminary phase will include in the definition of the Architecture Governance Framework most of the touch points with other processes as described above. At completion, touch-points and impacts should be clearly understood and agreed by all relevant stakeholders.

Creation of a strategy for the consumption and management of Cloud Services in the TOGAF Preliminary Phase

March 19, 2011March 19, 2011 by Serge Thorn

· A hybrid Cloud combines multiple elements of public and private cloud, including any combination of providers and consumers

The categories the enterprise may be interested in related to existing problems can already be included as a section in that document.

Quality Management

There is need of a system for evaluating performance, whether in the delivery of Cloud services or the quality of products provided to consumers, or customers. This may include:

· A test planning and a test asset management from Business requirements to defects

· A Project governance and release decisions based on some standards such as Prince 2/PMI and ITIL

· A Data quality control (all data uploaded to a Cloud computing service provider must ensure it fits the requirements of the provider). This should be detailed and provided by the provider

· Detailed and documented Business Processes as defined in ISO 9001:

o Systematically defining the activities necessary to obtain a desired result

o Establishing clear responsibility and accountability for managing key activities

o Analyzing and measuring of the capability of key activities

o Identifying the interfaces of key activities within and between the functions of the organization

o Focusing on the factors such as resources, methods, and materials that will improve key activities of the organization

o Evaluating risks, consequences and impacts of activities on customers, suppliers and other interested parties

Security Management

This would address and document specific topics such as:

· Eliminating the need to constantly reconfigure static security infrastructure for a dynamic computing environment

· Define how services are able to securely connect and reliably communicate with internal IT services and other public services

· Penetration security checks

· How a Security Management/System Management/Network Management teams monitor that security and the availability

Semantic Management

IT Service Management (ITIL)

IT Service Management or IT Operations teams will have to address many new challenges due to the Cloud. This will need to be addressed for some specific processes such as:

· Incident Management

o The Cloud provider must ensure that all outages or exceptions to normal operations are resolved as quickly as possible while capturing all of the details for the actions that were taken and are communicated to the customer.

· Change Management

o Strict change management practices must be adhered to and all changes implemented during approved maintenance windows must be tracked, monitored, and validated.

· Configuration Management (Service Asset and…)

o Companies who have a CMDB must provide this to the Cloud providers with detailed descriptions of the relationships between configuration items (CI)

o CI relationships empowers change and incident managers need to determine that a modification to one service may impact several other related services and the components of those services

o This provides more visibility into the Cloud environment, allowing consumers and providers to make more informed decisions not only when preparing for a change but also when diagnosing incidents and problems

· Problem Management

o The Cloud provider needs to identify the root cause analysis in case or problems

· Service Level Management

o Service Level Agreements (or Underpinning contracts) must be transparent and accessible to the end users. The business representatives should be negotiating these agreements. They will need to effectively negotiate commercial, technical, and legal terms. It will be important to establish these concrete, measurable Service Level Agreements (SLAs) without these and an effective means for verifying compliance, the damage from poor service levels will only be exacerbated

· Vendors Management

o Relationship between a vendor and their customers changes

o Contractual arrangements

· Capacity Management and Availability Management

o Reporting on performance

Other activities must be documented such as:

Monitoring

· The resource usage and consumption must be monitored and managed in order to support strategic decision making

· Service Measurement, Service Reporting and Service Improvement processes must be considered.

Consumption and costs

Risk Management

The TOGAF 9 risk management method should be considered to address the various risks associated such as:

· Ownership, Cost, Scope, Provider relationship, Complexity, Contractual, Client acceptance, etc

· Other risks should also be considered such as : Usability, Security (obviously…) and Interoperability

Asset Management and License Management

Transactions

Being able to manage the transactions in the Cloud is vital and Business transaction safety should be considered (recording, tracking, alerts, electronic signatures, etc…).

There may be other aspects which should be integrated in this Strategy document that may vary according to the level of maturity of the enterprise or existing best practices in use.

Speaking at 2 conferences in February

January 20, 2011 by Serge Thorn

I will be delivering a speech at the next Open Group Conference in San Diego on the subject of Architecting the Cloud, February 9, 2011.

Taking place at 9:45am, “Cloud Computing requires Enterprise Architecture and TOGAF™ 9 Can Show the Way “

Abstract: Most companies doing Enterprise Architecture are wondering how to approach Cloud Computing and how does it fits in TOGAF 9. This presentation is a suggested approach which has been used by some companies.

Key takeaways:

When does it make sense to use Cloud Computing in a company which does Enterprise Architecture
What suggested additional activities may be included in the TOGAF 9 ADM

For further information on the event, please visit:

http://www.opengroup.org/sandiego2011/

I’m also excited to be on the program at the upcoming Enterprise Architecture Management Forum in Frankfurt, Germany, February 22-23, 2011.

I will be presenting at the conference on the subject of EA Governance. This event is one of the leading conferences for Information Technology in Germany, with speakers and participants representing companies such as Volkswagen, Deutsche Bank, Deutsche Post, Heidelberger Druck and others.

Taking place at 2:30pm on February 22, “Enterprise Architecture Governance – Why? A need for transparency and better control” addresses:

Governance and why we need it
The importance of processes, roles, responsibilities, and skills
Definition of the components and related activities
Case Study for a successful Enterprise Architecture governance using TOGAF

The conference also features several additional topics high on the importance list of technology professionals:

Business IT Alignment
Innovation Management
EA and Cloud Computing
EA Governance
Agility
Project Portfolio Management
Best Practices, Tools and Anti Patterns

For further information on the event, please visit: http://www.iir.de/eam.

Speaking at 2 conferences in February

January 20, 2011 by Serge Thorn

I will be delivering a speech at the next Open Group Conference in San Diego on the subject of Architecting the Cloud, February 9, 2011.

Taking place at 9:45am, “Cloud Computing requires Enterprise Architecture and TOGAF™ 9 Can Show the Way “

Key takeaways:

When does it make sense to use Cloud Computing in a company which does Enterprise Architecture
What suggested additional activities may be included in the TOGAF 9 ADM

For further information on the event, please visit:

http://www.opengroup.org/sandiego2011/

I’m also excited to be on the program at the upcoming Enterprise Architecture Management Forum in Frankfurt, Germany, February 22-23, 2011.

Taking place at 2:30pm on February 22, “Enterprise Architecture Governance – Why? A need for transparency and better control” addresses:

Governance and why we need it
The importance of processes, roles, responsibilities, and skills
Definition of the components and related activities
Case Study for a successful Enterprise Architecture governance using TOGAF

The conference also features several additional topics high on the importance list of technology professionals:

Business IT Alignment
Innovation Management
EA and Cloud Computing
EA Governance
Agility
Project Portfolio Management
Best Practices, Tools and Anti Patterns

For further information on the event, please visit: http://www.iir.de/eam.

Cloud Computing requires Enterprise Architecture and TOGAF 9 can show the way

November 9, 2010 by Serge Thorn

Enterprise Architecture is necessary regardless of changes to underlying technologies. If managed properly, Enterprise Architecture will iterate and adjust to the winds of change. Client/server, SOA, RFID, Cloud, and other technology developments should be considered as styles, but Enterprise Architecture is at the heart of change. Cloud computing should have little impact on Enterprise Architecture.

It is the role of the Enterprise Architecture team to:

· Investigate if any style is simply hype or whether it holds real business value

· Understand the benefits and risks of a specific style

· Communicate these to Business and IT

· Develop an adequate governance framework

· Align the “style” with business requirements

· Give guidance for sustainable innovation

If Cloud computing does not take Enterprise Architecture into consideration, it will result in “spaghetti clouds” (aligned with “spaghetti architectures”).

Cloud computing is often characterised by: virtualised computing resources, seemingly limitless capacity and scalability, dynamic provisioning, multi-tenancy, self-service and pay-for-use pricing. Enterprise Architecture can help to make the shift to cloud computing smooth.

For organisations focusing more on Technology Architecture, Cloud computing could be a “big hit”. But for businesses that want to successful adopt cloud computing in a way that aligns to their business strategy, Enterprise Architecture is imperative (refer to above diagram).

Cloud computing may be a fit when the core of internal Enterprise Architecture is mature. This means:

· As recommended in TOGAF. well defined and layered:

o Business Architecture

o Application Architecture

o Data Architecture

o Technology Architecture

· Well defined interoperability (ADM Guidelines and Techniques)

· Low level of security agreed (during the Architecture Vision)

· Web as a target

· Costs issues

· New products and services

Cloud computing may not be a fit when the core of internal Enterprise Architecture is immature. This means:

· Business, Application and Data architectures are tightly coupled

· Low level of interoperability defined

· High level of security required

· When applications have IPAs (Information Provider Applications) with only proprietary interfaces

· When solutions are legacy

Where there is could be a good fit, a TOGAF iteration should then be “Cloud Architecture aware”. The Enterprise Architecture team drives the programme and works collaboratively with both the business and the IT department.

In the Preliminary Phase we should consider the addition of a step related to the creation of a strategy for the consumption and management of cloud services (public/private clouds, semantic management, security, transactions). The governance framework also needs to include the processes, roles and responsibilities related to cloud services and operations. At this stage, we need to identify who in the business owns the cloud from both a user and service provider management perspective. New principles may be created referring to the Cloud when the organisation has a fairly mature Enterprise Architecture (maturity model) in order to fully take advantage of the Cloud.

During Phase A, you may use a Business Scenario where you would identify in a workshop what are the business problems, business Requirements and identify a potential business solution. Stakeholders in this workshop may come from Business and IT Operations, Procurement, PMO, Data Center, Development, COO/CIO/CTO. Interoperability will be an important element of the phase. The Enterprise Architecture team will collaborate with the business to understand and scope the needs; align them with the Strategic Enterprise Architecture (bringing to bear the existing technological capabilities that can satisfy those needs thereby promoting sharing, reusing or building new ones if needed). Given the relatively low barrier to entry, in the scenarios where the Business is not sure of the viability of their proposal, they could go straight to the Cloud instead of “experimenting” before solidifying their requirements. The result of this is that the business may embark on a path of no return. To avoid this, make sure that the Business Scenario is complete, only refer to business solutions without referring to any architecture style (as this will be discussed during Phase E) and signed off.

Start the architecture considering Phase B, C and D.

At that stage, it is be recommended that you consider a Cloud Reference Model. This is a description of the appropriate Cloud industry standards, the dimensions of the Cloud problem space, and the decisions and choices that apply to a Cloud computing for an organisation. A Cloud reference model, reference architecture and reference implementation approach is an accepted approach for planning and implementing Cloud computing. Different Cloud Reference Models can be considered such as those published by

· The Open Cloud Consortium

· The Cloud Security Alliance

· The Cloud Computing Reference Model (CC-RM) and Reference Architecture framework from AgilePath

· The Accenture Cloud Reference Model for Application Architecture with its 7-layers. Like the OSI Model for networks, this Cloud Model is layered to separate concerns and abstract details

There is also an on-going initiative by the Open Group to deliver a Cloud Reference Model.

The Security activities from TOGAF will have to be applied to all phases taking into account the company’s Security strategy. The TRM should be extended with cloud services.

In phase C: Data Architecture, Data integration, in particular may be an issue for cloud computing as it pushes information back into siloes, that IT may not have direct access to. It is also recommended to determine Data and privacy classification and to prioritise the risk criteria of what goes in the cloud and what stays on-premise.

During phase E and F there is a need to understand the Cloud resources which may exist or not. A new step will also be dedicated to identify candidates’ services in the Cloud.

Instead of now having to provide standardized ROI or cost-benefit analysis justifying the products that need to be bought or charge-backs that need to be agreed upon upfront for shared assets, the Business can provide operational expenditure outlines and may go out to the Cloud to source their requirements. No surprises with CapEx, decreased new product introduction training line item expenditures (many products are “standards “which means, lots of documentation and books available, e-learning, etc.), different charge-back agreements between Finance and Business Units (the organisation may have accesses to the service independently from his internal structure), in short, no need to conform to existing enterprise-wide Reference Architectures to meet individual project needs. In relation to this, the recent Open Group white paper “Building Return on Investment from Cloud Computing” is a valuable source of information.

During Phase G, activities may also include the relocation of:

· Business processes (Process-as-a-Service)

· Applications (Application-as-a-Service)

· Data (Information-as-a-Service and Database-as-a-Service)

· Technical services (Storage-as-a-Service and Infrastructure-as-a-Service).

· Security and operations implementation will have to be taken into consideration during the relocation. Security can also be considered as Security-as-a-Service.

The following diagram summarises the additional activities or concerns which should be considered in the ADM:

Below is a diagram which maps the various Cloud services to the TOGAF Metamodel.

The development and deployment teams would now be sourcing from and conforming to the Cloud API and services, without the Enterprise Architecture team becoming policeman, enforcing the reference architectures or corporate standards at various checkpoints (compliance and dispensation activities will remain for internal new systems). With overarching cross-project oversight not relevant anymore, each project would tend to work in its own Cloud development sandbox, party engendered by the partitioning paradigm of the Cloud itself.

Barring some exceptions, traditionally the Enterprise Architecture team has not been relevant to the Operation side of the organisation, but with the Cloud, even that seems to be disappearing. The Cloud providers will furnish the relevant tools for management and reporting and take away the onerous tasks of patch management, version upgrades, high availability, disaster recovery and the like.

New technologies styles are exciting, but using technology styles just for the sake of technology does not bring a real value. Technology use should be driven not by its “coolness factor”, but rather by business requirements and an underlying Enterprise Architecture such as TOGAF. Moving some applications to the Cloud can make some infrastructures go away, but badly designed solutions won’t be improved by relocating to the Cloud.

Cloud Computing requires Enterprise Architecture and TOGAF 9 can show the way

November 9, 2010 by Serge Thorn

It is the role of the Enterprise Architecture team to:

· Investigate if any style is simply hype or whether it holds real business value

· Understand the benefits and risks of a specific style

· Communicate these to Business and IT

· Develop an adequate governance framework

· Align the “style” with business requirements

· Give guidance for sustainable innovation

If Cloud computing does not take Enterprise Architecture into consideration, it will result in “spaghetti clouds” (aligned with “spaghetti architectures”).

Cloud computing may be a fit when the core of internal Enterprise Architecture is mature. This means:

· As recommended in TOGAF. well defined and layered:

o Business Architecture

o Application Architecture

o Data Architecture

o Technology Architecture

· Well defined interoperability (ADM Guidelines and Techniques)

· Low level of security agreed (during the Architecture Vision)

· Web as a target

· Costs issues

· New products and services

Cloud computing may not be a fit when the core of internal Enterprise Architecture is immature. This means:

· Business, Application and Data architectures are tightly coupled

· Low level of interoperability defined

· High level of security required

· When applications have IPAs (Information Provider Applications) with only proprietary interfaces

· When solutions are legacy

Start the architecture considering Phase B, C and D.

· The Open Cloud Consortium

· The Cloud Security Alliance

· The Cloud Computing Reference Model (CC-RM) and Reference Architecture framework from AgilePath

· The Accenture Cloud Reference Model for Application Architecture with its 7-layers. Like the OSI Model for networks, this Cloud Model is layered to separate concerns and abstract details

There is also an on-going initiative by the Open Group to deliver a Cloud Reference Model.

The Security activities from TOGAF will have to be applied to all phases taking into account the company’s Security strategy. The TRM should be extended with cloud services.

During phase E and F there is a need to understand the Cloud resources which may exist or not. A new step will also be dedicated to identify candidates’ services in the Cloud.

During Phase G, activities may also include the relocation of:

· Business processes (Process-as-a-Service)

· Applications (Application-as-a-Service)

· Data (Information-as-a-Service and Database-as-a-Service)

· Technical services (Storage-as-a-Service and Infrastructure-as-a-Service).

· Security and operations implementation will have to be taken into consideration during the relocation. Security can also be considered as Security-as-a-Service.

The following diagram summarises the additional activities or concerns which should be considered in the ADM:

Below is a diagram which maps the various Cloud services to the TOGAF Metamodel.

What is Enterprise Analysis: does it differ from Enterprise Architecture?

April 29, 2010 by Serge Thorn

Enterprise Analysis is a knowledge area which describes the Business analysis activities that take place for an enterprise to identify business opportunities, build a Business Architecture, determine the optimum project investment path for that enterprise and finally, implement new business and technical solutions. The question you may ask: Does this really differs from Enterprise Architecture, and if so, how?

At first sight, business opportunities are not always considered as being part of an Enterprise Architecture initiative, more as an activity which should be considered as an input. But let’s look at this in more detail.

Let’s look at this in more detail by way of mapping activities between BABOK v2* and the TOGAF 9 Framework*. The BABOK is the collection of knowledge within the profession of business analysis and reflects generally accepted practices. It describes business analysis areas of knowledge, their associated activities and tasks and the skills necessary to be effective in the execution:

BABOK v2 Knowledge Area Activity in Enterprise Analysis	Definition	Enterprise Architecture (e.g TOGAF 9)	Differences, observations
Requirements Elicitation	This describes the interview and research process-how to best extract needs from stakeholders (and even how to recognize needs they don’t know they have).Elements such as metrics (tracking the amount of time spent eliciting requirements) and elicitation techniques (prototyping and brainstorming are just a couple) among the topics covered	Phase A: Architecture Vision is the initial phase of an architecture development cycle. It includes information about scope, the key steps, methods, information requirements and obtaining approval for the architecture development cycle to proceed	Business scenarios are a useful technique to articulate an Architecture Vision. A Business Scenario describes, a business process, an application or set of applications enabled by the proposed solution , the business and technology environment, the people and computing components (called “actors”) who execute it, the desired outcome of proper execution To build such a Business Scenario, workshops with business users (stakeholders) would be organized
Business Requirements Analysis	This describes how to write/state requirements that will meet business needs. Key objectives include methods for prioritizing and organizing requirements, as well as the most beneficial techniques for requirements presentation (including state diagrams, prototyping, data flow diagrams, and process modeling, and more). Business Requirements for future project investments are identified and documented. They are defined at a high level, and include goals, objectives, and needs are identified	Business Requirements are collected from business people during the Architecture Vision’s phase using the technique called Business Scenario (as mentioned above). That document identifies what will be the business solutions in generic terms	The Enterprise Architects will define the Architecture Vision phase based on the goals, and objectives of the enterprise gathered from the business. There are two steps: 1. Business people will have defined the goals and the objectives of the enterprise independently from the Enterprise Architecture team 2. The Enterprise Architecture team which include business people gather the requirements based on the previous activity
Enterprise Analysis	Begins after a Business executive team develops strategic plans and goals This outlines the crucial (and sometimes political) process of keeping everyone in the loop and on the same page regarding project’s direction and progress. This activity delves into such details as the requirements review and approval processes (including record-keeping).	Most of these activities are taken into account in doing Enterprise Architecture or done directly by the Business executive team before starting an new Enterprise Architecture project
	Strategic plan development		Done outside of the Enterprise Architecture process by business people but is a key source of information
	Strategic goal development		This is done outside of the Enterprise Architecture initiative by business people but is a key source of information
	Business Architecture development		Done during Phase B:Business Architecture, looking at the baseline and target architecture, delivering a gap analysis, a plan and a roadmap
	Feasibility Studies		Done during Phase A: Architecture Vision (with a Business Scenario)
	Business Case Development		Done during Phase A: Architecture Vision (with a Business Scenario)
	New Project Proposal		This is done in two steps: during the Phase A where we identify a Business solution and during Phase F: Migration Planning
	Selecting and Prioritizing New Projects		This is done in two steps: during the Phase A where we identify a Business solution and during Phase F: Migration Planning
	Business Opportunities		This is done during the Phase A: Architecture Vision and the Phase E: Opportunities and Solutions
	Launching New Projects		This is done during Phase F: Migration Planning
	Managing Projects for Value		This is done during Phase F: Migration Planning
	Tracking Project Benefits		Once the project is in production, it is no longer part of the Enterprise Initiative
Solution Assessment and Validation	Details how to choose the best solutions for specific business needs (as well as assessing how well the chosen solution worked after its implementation).This should also cover risks, dependencies, and limitations that must be identified before proposing any solution	Solutions are identified during Phase E.: Opportunities and Solutions. This phase is directly concerned with implementation, identifying major work packages to be undertaken and creating a migration strategy. Risk management, dependencies are taken into consideration.
Business Analysis Planning and Monitoring	Explains how to decide what you need to do to complete an “analyst effort” (in other words, how to plan a project). This helps intelligently decide which stakeholders, tools, tasks and techniques we will need to get the job done	Covered mostly in the Architecture Vision phase, then in the Business Architecture Phase	Stakeholder management techniques are used within TOGAF, tools and techniques are identified in the Business Architecture phase (modeling, reference models, viewpoints)
Requirements Management and Communication	Describes how to identify business needs (the why of the project; whereas requirements are the how) and state the scope of their solutions. This is a crucial piece of the analyst’s work. SMART criteria of measurement, SWOT analysis and other measurement factors that make identifying this root cause data objective and tangible are used	Business Requirements are collected with the business people during the Architecture Vision’s phase using the technique called Business Scenario (as mentioned above).	SMART techniques are equally used. Communication plans are defined.

This diagram below is a draft map BABOK® and TOGAF 9; more work is required!

Observations

There are obviously overlaps between Enterprise Analysis and Enterprise Architecture, but activities are not always done in the same sequence.

Enterprise Analysis is more a business initiative than an Enterprise Architecture which includes both business and IT people
Enterprise Analysis provides the context in which an Enterprise Architecture should be conducted
Enterprise Analysis is about defining the strategic goals and the strategic planning taking into account the environment and market trends, identify business issues, focus on remaining competitive, profitable, efficient. Enterprise Architecture is reusing all this information.
Enterprise Analysis is only covering the initial activities of Enterprise Architecture but does not address other Enterprise Architecture activities such as: – Application Architecture, Data Architecture, Technology Architecture (and Solution Architecture).
Enterprise Analysis does not include all aspects related to governance such as the IT Governance and the Enterprise Architecture Governance Framework. Touch points with other frameworks are not addressed.
Enterprise Analysis may not completely address the need of working with other parts of the enterprise such as IT, PMO, development teams, IT partners.
Enterprise Architecture suggest a Preliminary phase which is about defining ‘‘where, what, why, who, and how” Enterprise Architecture will be done, establishing the business context, customizing the framework, defining the architecture principles, establishing the Architecture Governance structure.

Enterprise Analysis complements Enterprise Architecture but also overlaps in some areas. Organization looking into Enterprise Architecture and specifically TOGAF 9 may consider adopting a Business Analysis framework such as BABOK and integrate them in the Preliminary Phase. If both approaches exist in a company, this would be a great opportunity for optimizing the alignment between Business and IT, and to run an Enterprise Architecture program from a complete business perspective.

About Business Analysis Body of Knowledge® (BABOK®)

The Business Analysis Body of Knowledge® (BABOK®) is the collection of knowledge within the profession of Business Analysis and reflects current generally accepted practices. As with other professions, the body of knowledge is defined and enhanced by the Business Analysis professionals who apply it in their daily work role. The BABOK® Guide describes Business Analysis areas of knowledge, their associated activities and the tasks and skills necessary to be effective in their execution. The BABOK® Guide is a reference for professional knowledge for Business Analysis and provides the basis for the Certified Business Analysis Professional™ (CBAP®) Certification.

BABOK® Guide 2.0 represents the development of a common framework to understand and define the practice of business analysis.

http://www.theiiba.org/am/