I welcomed the new version of Business Analysis Body of Knowledge (BABOK) Guide with great pleasure. Version 3 introduces a lot of changes, improvements, and new content in comparison to the previous one. I think it will be enough to say that version 2 had 271 pages and version 3 has 514 pages; that’s a significant gain.
While there are a lot of interesting topics that originate from the release of the new BABOK Guide, in this article I will constrain myself just to the area of Strategy Analysis (formerly named Enterprise Analysis) in the context of Business Architecture Perspective. In general, the new version of BABOK positions Business Analysis professions much better than the former one among other concepts, standards, frameworks and methodologies existing currently on the market. It focuses on similarities and synergies between them in order to improve collaboration between different disciplines of IT.
Similarities between TOGAF and BABOK
When I was reading the Strategy Analysis chapter of the Guide, it struck me how much BABOK tries to be complimentary with TOGAF. I said ‘tries’ because it started with the release of version two in 2009 and looking now at the market trends in 2015, we can safely say that integration between those two standards is not ubiquitous. However, with version three of the BABOK Guide, they’re bringing it to the next level. There is a brand new concept called Business Architecture Perspective that redefines Business Analysis tasks in the context of Enterprise Architecture.
According to the BABOK Guide, the Business Architecture focuses on understanding the enterprise (which is not so obvious in huge companies); its needs in terms of problems and opportunities; and the defining of possible ways to realize the needs in terms of future and transition architectures.
The BABOK Guide defines Business Architecture as
The design, structure, and behavior of the current and future states of an enterprise to provide a common understanding of the organization. It is used to align the enterprise’s strategic objectives and tactical demands. Source BABOK v3 Glossary.
This is mostly what TOGAF 9 says, so there is no surprise to see that BABOK notices that synergy as well:
TOGAF “Provides a method for developing the enterprise architecture. Phase B of the TOGAF Architecture Development Method (ADM) is focused on the development of business architecture. Organizations following TOGAF may choose to tailor Phase B to adopt the business architecture blueprints, techniques, and references described in the BABOK Guide.” BABOKv3 Page 416
I would argue that Phase B is not the only one common area, however, it is most relevant to the Strategy Analysis knowledge area. We can find similarities between all ADM phases and BABOK knowledge areas. Work of the business architect or business analyst plays an important role during execution of them.
While the idea of a combination of BABOK and TOGAF is very exciting for me, as I consider both of them as the best standards that I have encountered in my professional career. I will not discuss the integration between TOGAF and BABOK here. Instead, I will focus on how and why Business Architect can use ArchiMate?
What is ArchiMate?
ArchiMate was developed in the Netherlands by a project team from the Telematica Instituut in cooperation with several Dutch partners from government, industry and academia during 2002-2004. In 2008, the ownership and stewardship of ArchiMate were transferred to The Open Group (TOG). In 2009 TOG published the ArchiMate as a formal technical standard. In 2012 the ArchiMate 2.0 standard was published, in 2013 it was updated and the current version 2.1 was released. [Source]
ArchiMate is an open and independent Enterprise Architecture modelling language. It was developed with regard to existing standards and methods such as UML, BPMN and TOGAF. It was aligned with these as much as possible in order to be used in conjunction with them, not to replace them.
ArchiMate language consists of Core concepts and two official Extensions. Core concepts are intended to model the architecture of systems that support the enterprise. ArchiMate has a layered and service-oriented look on architectural models. The higher layers make use of services that are provided by the lower layers. It distinguishes three layers:
- The Business layer is about business processes, services, functions and events of business units. This layer “offers products and services to external customers, which are realized in the organization by business processes performed by business actors and roles”.
- The Application layer is about software applications that “support the components in the business with application services”.
- The Technology layer deals “with the hardware and communication infrastructure to support the Application Layer. This layer offers infrastructural services needed to run applications, realized by computer and communication hardware and system software”. [Source]
The concept of three-layered architecture is compliant but not conformant with the TOGAF 9 framework as ArchiMate does not provide the means to model Data Architecture defined during ADM’s Phase C. (The words compliant and conformant are used deliberately here, see explanation in TOGAF 9 specification). Data Architecture can be modelled in UML which is complementary to the ArchiMate language.
There are two official extensions to ArchiMate: The Motivation Extension and the Implementation and Migration Extension. The Motivation Extension is meant to model the context or the reason lying behind the architecture of an enterprise and the undertaken change. It operates with concepts such as drivers, goals, requirements, constraints, and principles. The Implementation and Migration Extension is intended to model some elements of a change process: implementation programs and projects, work packages, deliverables, and plateaus. This extension provides the means to manage transition architectures and perform the Gap Analysis between them.
In the picture, you can see the example of the architecture that consists of three layers defined by the ArchiMate language: Business, Application and Technology. Each layer is divided into two groups: the externally exposed services; and the internal components which “realize” those services. Please notice that between layers there is the same type of relationship named Used-by (represented by an arrow with open head →). From the “bottom” to the “top”, each layer is providing services which are used by an upper layer in order to provide its own services.
BABOK mentions ArchiMate as one of the Business Architecture techniques and I think there is a good reason for that. According to TOGAF, Business Architecture is a part of Enterprise Architecture. Since ArchiMate is a modelling language for it, it’s safe to assume it will be useful for Business Architects as well. This is why the beginning of this article focuses so much on the common aspects between BABOK and TOGAF.
Business Architecture in perspective of BABOK
The BABOK’s Business Architecture Perspective defines a viewpoint for tasks defined in Strategy Analysis, which means it adds additional insights and adjustments for this particular scope of work.
The Strategy Analysis (formerly known as Enterprise Analysis) knowledge area includes four tasks:
- Analyze Current State: understands the business need and how it relates to the way the enterprise functions today. It sets a baseline and context for change.
- Define Future State: defines goals and objectives that will demonstrate that the business need has been satisfied and defines what parts of the enterprise need to change in order to meet those goals and objectives.
- Assess Risks: understands the uncertainties around the change, considers the effect those uncertainties may have on the ability to deliver value through a change, and recommends actions to address risks where appropriate.
- Define Change Strategy: performs a gap analysis between the current and future state, assesses options for achieving the future state and recommends the highest value approach for reaching the future state including any transition states that may be required along the way.
Normally, the scope of tasks in Strategy Analysis would consist of one application with adjacent systems (domain), or one end-to-end business process supported by a few applications (or even a part of that process), or one product, or a single project. However, because of Business Architecture Perspective, we are now looking at the entire enterprise. It is not a single project, initiative, process, or system. That perspective puts projects, processes, and information into the larger business context to provide an understanding of interactions, integration opportunities, redundancies, and inconsistencies in the whole enterprise (or a significant part of it).
ArchiMate for Business Architect
Analyze Current State
This BABOK task focuses on understanding the reasons why an enterprise needs to change some aspect of how it operates and what would be directly or indirectly affected by the change.
To better illustrate the tasks performed by Business Architect, I developed a sample case of an organization undertaking a change. To make it easier to distinguish from the rest of this paper, it will be described with the blue font.
The organization has two communication channels with its customers. The first channel is realized as a web page and is called SelfCare. It allows customers to perform two tasks 1) update their profile (a simple contact form for information like address, phone number etc.) and 2) update preferences (when the account manager can contact them, what products they are interested in and similar things). The second channel is a call center, where customers can call and request a meeting with their account manager.
There are two long-term strategies in the organization. The Horizon 2020 is a business strategy which aims are: Omni-Channel customer services and Customer-facing IT systems. This strategy covers whole organization and is driven by the CEO of the company. It influences in a positive way the Customer Satisfaction driver of the CEO. At the same time, the IT department is executing its own IT Consolidation strategy which has one primary goal: IT Complexity & Cost reduction which is decomposed into several detailed objectives. This strategy is driven by the CIO. It influences in a positive way both Customer Satisfaction and Cost optimization drivers.
This is the organizational context of the change. The change itself is rather straightforward: business stakeholders expressed the need to allow customers to schedule a meeting with an account manager through the SelfCare web page. Because of the new Omni-Channel approach, full integration and transparency with existing “over the phone” service is required as well.
The Motivation Extension of ArchiMate can be used to document the motivations or intentions of the enterprise in terms of goals, principles, (business)requirements, and constraints as well as the sources of these intentions such as stakeholders, drivers, and assessments. The BABOK Guide pays close attention to aligning the change to the strategy of organization. It is reasonable to refer to it in ArchiMate models. Unfortunately, the Motivation Extension does not have a dedicated strategy element (concept) that could be used in a model. However, in my opinion, the strategy can be modeled by internal driver element. ArchiMate’s specification defines a driver as “something that creates, motivates, and fuels the change in an organization”. I think the strategy is covered by this definition pretty well.
Each driver can be associated with goals. A goal can be composed of other goals. Such ‘sub-goals’ can be understood as BABOK’s objective. Goals are realized by requirements. This small subset of elements allows us to trace back business requirements (need) to the organization’s strategy.
This diagram, let’s call it Motivation View diagram, illustrates the organizational context and positions the new business requirements (green box) relatively to Horizon 2020 strategy. Black arrows with dashed line represent influence, and the white arrows with dashed lines represent realization. In our case the requirement: New capabilities in online SelfCare application for customers will realize the goal: Customer-facing IT systems. Each element has in parenthesis its ArchiMate type to make it easier to grasp.
The Motivation View can be used to understand and document why an enterprise needs to change. It also allows Business Architect to validate whether the requested change is aligned with high-level goals of the organization expressed by its strategies. ArchiMate can be used further to define and design on whatthe change has an impact, in other words, the architecture.
At this moment, we need to define AS-IS as the state of business architecture to understand how currently the business services work. Usually, organizations should have more or less current model of AS-IS state, however, if this is the first time you are using ArchiMate you need to model everything from scratch.
As it was described, the organization has two communication channels: web page and phone (call center) which together provide three services: profile update, preferences update and schedule a meeting. Let’s model that in ArchiMate.
There is a lot of going on this diagram, so let’s go through it. We have two Business Services: SelfCare service for customers and Schedule a meeting over the phone, both are used by Customer. The first service is composed of two services: Update personal information via a Web page and Update preferences via a Web page. Both services are exposed to the “outside world” by two distinct interfaces. The SelfCare service is a “frontend” for some applications and is accessible via a web page modelled as an Application Interface. In other words, the Application Interface provides the means for Customer to access automated Business Services. On the other hand, the Schedule a meeting over phone Business Service is realized manually by a Call center clerk (Business Role). That’s why there is a Phone Business Interface which means there is an interaction between two humans and not human – machine like in the first case.
A call center clerk answers the phone and schedules the meetings with customers. Probably she is using internally some software to schedule the meeting but we didn’t model that yet because it’s not “visible” from the Customer’s perspective. The work of the clerk is modeled as Schedule a meeting manually with the account manager Business Process which realizes the Business Service provided for Customer.
Business Objects on the diagram represent business information that is accessed during execution of the services. The last element on the diagram, represented by an oval shape, defines the value of Business Service for the Customer.
Define Future State
After finalizing the current state of Business Architecture, the future state should be designed. This involves remodeling the current state in order to fulfill new requirements, which was defined at the beginning in the Motivation View. Below is a diagram that illustrates one of the possible approaches to fulfill the business requirements. In the real world usually there are many feasible options and the Business Architect should document and consider (together with some kind of committee) all before selecting the best one.
The Future State is built upon the current state, that’s why many elements are reused in this view, however, some of them are changed or new.
The SelfCare service for customers (Business Service) has been given new functionality: Schedule a meeting via a Web page (Business Service) which is realized by Schedule a meeting with an account manager (Business Process). As you can see the new business process is using the same information,Calendar Item (Business Object, as the process performed by the call center clerk. This shall enable integration and transparency between the web and phone channels. Also, the element, Schedule a meeting in preferred time (Value), is right now associated with both Business Services to highlight that both services provide the same value for customers.
After designing the TO-BE state, it should be traced back to the reason why the organization wants to undertake the change. In ArchiMate language, therequirement element from the Motivation Extension can be realized by almost any Core element, for example by Business Service, Business Process, Application Component and others. All those elements together make the Enterprise Architecture blueprint. ArchiMate allows to create a logical link in the model betweenwhy and what described by BABOK.
Let’s see how to define that link. In our sample case, we can create the Requirements Realization View diagram which will “link” the requirement with its realization. The diagram below shows that Schedule a meeting via a Web page (Business Service) realizes the New capabilities in the online SelfCare application for customers (Requirement). Anything that is connected with that Business Service element also realizes the change because of its derived relationships.
After conducting the two tasks from the Strategy Analysis knowledge area: Analyze Current State and Define Future State the following artifacts are created:
- two versions of business architecture, representing: AS-IS and TO-BE states
- the Motivation model describing the rationale behind the change.
The next task defined by BABOK focuses on risks. While it is important work conducted by analysts, it’s not possible to utilize ArchiMate when describing risks, so it is not covered in this paper. We will skip that task and move directly to the next one.
| Terminology:BABOK Guide uses terms: current and future states, which refer to the actual value (now and in future) delivered by the solution. TOGAF respectively uses terms Baseline and Target Architectures, which define current and future architectures.
…and I use AS-IS and TO-BE terms in both cases.
|
Define Change Strategy
This task focuses on performing the Gap Analysis to collate AS-IS and TO-BE blueprints. This is done in order to identify the gaps (differences) and define the best approach for achieving the future state. Although I’m following BABOK tasks here, it’s important to notice that TOGAF in Phase B of ADM defines an almost identical objective, “Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Business Architectures”.
The gap analysis is another task where ArchiMate language prevails. Implementation and Migration Extension allow to manage different versions of architecture like AS-IS and TO-BE, as well as transitioning architectures between them.
To perform the gap analysis, we need to understand the meaning of two elements: plateau and gap. The first one describes a relatively stable state of the architecture that exists during a limited period of time. As the architecture is expressed by Core elements of ArchiMate language, the plateau element can aggregate them, which basically means that architecture at this state looks like that. In other words, plateau represents a particular version or state of the architecture in time. The second element, the gap, is linked to two plateaus (e.g., Baseline/ AS-IS and Target/TO-BE Architectures, or two subsequent Transition Architectures) and represents the differences between these plateaus. The ‘difference’ falls into one of the following categories:
- what needs to be added (created)
- what needs to be modified (impacted)
- what needs to be removed (eliminated)
in order to achieve the desired state.
The diagram below presents the outcome of the Gap Analysis of Business Architecture layer. White elements are not impacted by the change and are the same in Baseline (AS-IS) and Target (TO-BE). Orange elements are impacted by the change and they need to be modified. Green elements are new, added in the Target (TO-BE) state. At the bottom of the diagram, there are two plateaus and the gap representing differences between them. Notice that gap is associated with elements that will change in Target Architecture.
Technically all of the elements on the diagram above should be aggregate by one or both plateaus. This would make this diagram extremely cluttered and unreadable. Instead of displaying everything on one diagram we should create another view with a limited number of elements.
This diagram was created according to the view pattern presented by Gerben Wierda in his book Mastering ArchiMate Edition II. It shows how plateaus aggregate elements impacted by change.
While ArchiMate is an excellent tool to show gaps between AS-IS and TO-BE states of architecture landscape in an easy to grasp way, it’s extremely important to remember that architecture is just one dimension of Gap Analysis, one aspect of the change. There are many other aspects to consider such as organizational culture and policies, people skills, finances, etc. ArchiMate diagram cannot express information for all of those aspects. For detailed information on Gap Analysis, please refer to BABOK Guide V3 chapter 6.4.4 and TOGAF 9.1 specification chapter 27.
What’s next?
The Business Layer is the main focus area for Business Architect. The lower layers are more technical, and other roles shall be responsible for them. I’m convinced that Enterprise Architect is accountable for whole enterprise architecture blueprint (model). However, I also think that Business Architect should be responsible for documenting AS-IS and designing TO-BE models of business architecture in collaboration with Enterprise Architect.
This analysis performed by Business Architect sets the stage for the next phase of planning the transformation from the current to the future state. The next logical step would be to meet with the Enterprise Architect and inform him/her about the new change that is going to happen and ask how it can be realized by Application Layer architecture. At this moment, AS-IS and TO-BE models for Application Architecture need to be developed similarly as it was done for Business layer. Welcome to the Phase C of TOGAF’s ADM.
Summary
Usage of one enterprise architecture language capable of expressing concerns from technology layers to business needs and drivers gives tremendous benefits to the organization. It streamlines the communication and enables easy collaboration between Enterprise and Business Architects. It eliminates, at least partially, big tensions during the modelling of business and application layers, because there is a shared model that unifies different views. It also saves time as there is no need to translate from one notation (often invented by “business people” and unskilled “professionals”) or text documents into the common Enterprise Architecture blueprint managed by Enterprise Architect.
ArchiMate was deliberately aligned to be compliant with the TOGAF 9 framework. It is also very useful for people practicing (high-level) Business Analysis, according to the BABOK Guide. Because of many similar concepts between those two standards, ArchiMate language can be successfully applied in organizations which don’t utilize TOGAF 9 framework, and need relatively simple, yet structured and based on international standards, the method for managing Business Architecture.
Author: Pawel Zubkiewicz, Business Analyst
Pawel has worked in many different roles, as a developer, business and systems analyst, architect and an IT consultant, mostly for financial sector. He has extensive knowledge of Business Analysis and Enterprise Architecture. He holds TOGAF 9, OCEB, CCBA and ArchiMate 2 certificates.
As an analyst and architect he helped to improve many existing solutions and had the opportunity to design several IT systems from the ground up.
Pawel can be reached via his LinkedIn profile https://www.linkedin.com/in/pawelzubkiewicz
The article was originally published on http://zubkiewicz.com/archimate-for-business-architect/