Business Architecture is Part of Enterprise Architecture

A common misperception being hyped in EA circles concerns the notion that business architecture is something different from enterprise architecture. This is a blatant attempt to classify EA as something only applicable to IT when, in fact, EA is applicable to the ENTERPRISE that covers numerous viewpoints for stakeholders, including business, information, technology and solution […]

The post Business Architecture is Part of Enterprise Architecture appeared first on Philip Allega.

Business Architecture is Part of Enterprise Architecture

A common misperception being hyped in EA circles concerns the notion that business architecture is something different from enterprise architecture. This is a blatant attempt to classify EA as something only applicable to IT when, in fact, EA is applicable to the ENTERPRISE that covers numerous viewpoints for stakeholders, including business, information, technology and solution […]

Accelerating Business and IT Transformation

In our work with more than 200 organizations, we’ve found two groups of customers: Those who previously tried to create an Enterprise Architecture (EA) function but failed, and those who knew they needed a successful EA function to transform t…

Are you a Business Architect or a Business Analyst?

Enterprise Architecture domains include Business Architecture which is the first architecture domain within TOGAF 9. An Enterprise Architecture program that includes this domain, maps critical business processes to their application, information, and infrastructure components to provide a comprehensive view of the business and IT landscape that enables informed decision-making.

Business Architects are supposed to manage Business Architecture, but who are they, what are their skills? How are they different to a Business Analyst or even a Project Manager?

Business Analysts are on the way to becoming Business Architects. Sometimes called IT Business Analysts, they are not strictly business or IT specialists. They write business cases (with very few technical terms), identify business requirements and often are part of a Development Team.

Based on many job descriptions and my observation below, is a grid of standard skills and responsibilities related to the function of a Business Analyst. In the second column, are the responsibilities also applicable to a Business Architect and in the last column comments on how TOGAF 9 recommend the activities to be addressed.

Expected skills and activities Business Analyst Business Architect Comments related to TOGAF 9
Is an intermediary between IT and the business users, follows the implementation strategy with respect to getting stakeholder buy-in and support. x x Both roles require to be positioned between IT and business.
In particular business processes of a line of business. x The Business Architect considers the organization’s strategy and less focused in a specific line of business.
Acts as catalyst to implement strategic and tactical change for the business. x x The Business Architect will focus more on strategic changes.
Works with end-user groups to assist with aligning IT to the department’s business goals. Conduct feasibility studies to define the purpose, functions, and overall structure of business processes x x The Business Architect in TOGAF 9 will use Business Scenario techniques.
May be involved in Business Process Management (BPM). x x
Performs analysis and documents business processes leading to process change and/or system implementation. x x The Business Architect will model and process the business processes.
Operating as a more-or-less independent group that is focused on delivering BPM services x The Business Architect will be working at a strategic level and will be less focused on the delivery of BPM services.
Does not have an IT background, but had, instead, a background in quality control. x The Business Architect must have a perfect knowledge of the business.
Translates user requirements into software requirements that IT can then use to develop software x A Business Architect would not develop and review design specifications for software application. This would be the role of the Application Architect during Phase C.
Analyze and resolve software errors in a timely and accurate fashion x A Business Architect is not in charge of managing incidents linked to applications. IT operations may escalate this to the Development Team, or the vendor. Once a first level of diagnostic done, it will be transferred to one of the architects depending on the domain (technology, application).
Helps to develop and maintain software to support the business processes. Assist in developing system/application architecture. x The Business Architect does not contribute to software development. This is done by the Solution Architect.
Leads and validates enterprise system designs across multiple business applications. x The Business Architect does not lead Application Architecture. This will be done by the Application Architect and potentially the Solution Architect.
Creates and executes test plans to ensure that the functional and business requirements are met by the proposed solution x The Business Architect does not contribute to test plans. This is done probably by the Solution Architect.
Documents and defines processes, eliminating activities that don’t add value and straightening out the flow of the activities. x x In the TOGAF 9 Phase B we would do this by documenting the baseline and target architecture and do a gap analysis, identifying the various business architecture building blocks to be eliminated.
Determining how business policies are implemented in business rules. x x Business rules have to be identified and implemented when business processes documented in both baseline and target architecture. Can be done at both strategic and tactical level.
Analyses customer needs and the processes customers go through to interact with an organization are key skills that any business process practitioner needs to be effective. x x Business scenarios would be used to identify business requirements.
Creates, manages and maintains an optimum business architecture that includes informational, organizational, process, performance and systems architecture. x The Business Analyst focus more on projects delivery. The Business Architect is mostly focused on the delivery of the Business Architecture.
Defines, socializes and implements Business Architecture. Reviews roadmap projects for impact and compliance. x Business Architecture roadmaps will be delivered from the gap analysis.
Identifies and facilitates cross divisional continuous business improvement initiatives. x The Business Architect works at a strategic level and focus mostly on Strategic Architecture.
Member of the Architecture Board, composed of representative process owners who approve any cross organizational business process changes. x Business Architects should be part of the Architecture Board.
Identifies and maintains an up to date picture of opportunities and risks. x x Risks have to be identified during both the Architecture vision phase and the development of the solution.
Experienced in business/process architecture including broad skills in the area of strategy mapping, business analysis skills, conceptual data and process modeling/design, EA frameworks. x The Business Architect must have these skills. The Business Analyst may focus on process modeling only.
Strong work experience in Project and Change management. x x Both roles require these skills.
Proven track record for working effectively with technical and business functions. x The Business Architect must work with other domain’s architects.

My observations are:

Business Analysts are much closer to IT. They often are assigned to a specific Line of Business, which is close to the Development Team, and are implicated in software development. They may be part of the Development Team or the Project Management Office. The Business Architect reports to managers or senior managers who may be business or IT but are independent of any project. They have a global view on most business and will be responsible for modeling the business as a whole, then working top down to “architect” encompassing end to end business processes. Their role is more horizontal and is considered a neutral voice and because of that will make more critical decisions than a Business Analyst.

Business Analysts document requirements as defined by users during workshops. A Business Architect documents and may contribute to define a business strategy using requirements provided by the users if that strategy is not finalized. The Business Architect must have the ability to think in both a strategic and tactical manner whereas a Business Analyst is normally tactical.

The Business Analyst operates within the confines of a predetermined application and technology architecture. A Business Architect is a part of the decision making process to define the IT architecture (Data, Application and Technology). He will have a strong influence directing information technology to meet business needs, and assist in identifying business inefficiencies and opportunities.

Business Architect must be cognizant of enterprise strategies whereas a Business Analyst is normally concerned with specific projects independent of enterprise strategy.

Are you a Business Architect or a Business Analyst?

Enterprise Architecture domains include Business Architecture which is the first architecture domain within TOGAF 9. An Enterprise Architecture program that includes this domain, maps critical business processes to their application, information, and infrastructure components to provide a comprehensive view of the business and IT landscape that enables informed decision-making.

Business Architects are supposed to manage Business Architecture, but who are they, what are their skills? How are they different to a Business Analyst or even a Project Manager?

Business Analysts are on the way to becoming Business Architects. Sometimes called IT Business Analysts, they are not strictly business or IT specialists. They write business cases (with very few technical terms), identify business requirements and often are part of a Development Team.

Based on many job descriptions and my observation below, is a grid of standard skills and responsibilities related to the function of a Business Analyst. In the second column, are the responsibilities also applicable to a Business Architect and in the last column comments on how TOGAF 9 recommend the activities to be addressed.

Expected skills and activities Business Analyst Business Architect Comments related to TOGAF 9
Is an intermediary between IT and the business users, follows the implementation strategy with respect to getting stakeholder buy-in and support. x x Both roles require to be positioned between IT and business.
In particular business processes of a line of business. x The Business Architect considers the organization’s strategy and less focused in a specific line of business.
Acts as catalyst to implement strategic and tactical change for the business. x x The Business Architect will focus more on strategic changes.
Works with end-user groups to assist with aligning IT to the department’s business goals. Conduct feasibility studies to define the purpose, functions, and overall structure of business processes x x The Business Architect in TOGAF 9 will use Business Scenario techniques.
May be involved in Business Process Management (BPM). x x
Performs analysis and documents business processes leading to process change and/or system implementation. x x The Business Architect will model and process the business processes.
Operating as a more-or-less independent group that is focused on delivering BPM services x The Business Architect will be working at a strategic level and will be less focused on the delivery of BPM services.
Does not have an IT background, but had, instead, a background in quality control. x The Business Architect must have a perfect knowledge of the business.
Translates user requirements into software requirements that IT can then use to develop software x A Business Architect would not develop and review design specifications for software application. This would be the role of the Application Architect during Phase C.
Analyze and resolve software errors in a timely and accurate fashion x A Business Architect is not in charge of managing incidents linked to applications. IT operations may escalate this to the Development Team, or the vendor. Once a first level of diagnostic done, it will be transferred to one of the architects depending on the domain (technology, application).
Helps to develop and maintain software to support the business processes. Assist in developing system/application architecture. x The Business Architect does not contribute to software development. This is done by the Solution Architect.
Leads and validates enterprise system designs across multiple business applications. x The Business Architect does not lead Application Architecture. This will be done by the Application Architect and potentially the Solution Architect.
Creates and executes test plans to ensure that the functional and business requirements are met by the proposed solution x The Business Architect does not contribute to test plans. This is done probably by the Solution Architect.
Documents and defines processes, eliminating activities that don’t add value and straightening out the flow of the activities. x x In the TOGAF 9 Phase B we would do this by documenting the baseline and target architecture and do a gap analysis, identifying the various business architecture building blocks to be eliminated.
Determining how business policies are implemented in business rules. x x Business rules have to be identified and implemented when business processes documented in both baseline and target architecture. Can be done at both strategic and tactical level.
Analyses customer needs and the processes customers go through to interact with an organization are key skills that any business process practitioner needs to be effective. x x Business scenarios would be used to identify business requirements.
Creates, manages and maintains an optimum business architecture that includes informational, organizational, process, performance and systems architecture. x The Business Analyst focus more on projects delivery. The Business Architect is mostly focused on the delivery of the Business Architecture.
Defines, socializes and implements Business Architecture. Reviews roadmap projects for impact and compliance. x Business Architecture roadmaps will be delivered from the gap analysis.
Identifies and facilitates cross divisional continuous business improvement initiatives. x The Business Architect works at a strategic level and focus mostly on Strategic Architecture.
Member of the Architecture Board, composed of representative process owners who approve any cross organizational business process changes. x Business Architects should be part of the Architecture Board.
Identifies and maintains an up to date picture of opportunities and risks. x x Risks have to be identified during both the Architecture vision phase and the development of the solution.
Experienced in business/process architecture including broad skills in the area of strategy mapping, business analysis skills, conceptual data and process modeling/design, EA frameworks. x The Business Architect must have these skills. The Business Analyst may focus on process modeling only.
Strong work experience in Project and Change management. x x Both roles require these skills.
Proven track record for working effectively with technical and business functions. x The Business Architect must work with other domain’s architects.

My observations are:

Business Analysts are much closer to IT. They often are assigned to a specific Line of Business, which is close to the Development Team, and are implicated in software development. They may be part of the Development Team or the Project Management Office. The Business Architect reports to managers or senior managers who may be business or IT but are independent of any project. They have a global view on most business and will be responsible for modeling the business as a whole, then working top down to “architect” encompassing end to end business processes. Their role is more horizontal and is considered a neutral voice and because of that will make more critical decisions than a Business Analyst.

Business Analysts document requirements as defined by users during workshops. A Business Architect documents and may contribute to define a business strategy using requirements provided by the users if that strategy is not finalized. The Business Architect must have the ability to think in both a strategic and tactical manner whereas a Business Analyst is normally tactical.

The Business Analyst operates within the confines of a predetermined application and technology architecture. A Business Architect is a part of the decision making process to define the IT architecture (Data, Application and Technology). He will have a strong influence directing information technology to meet business needs, and assist in identifying business inefficiencies and opportunities.

Business Architect must be cognizant of enterprise strategies whereas a Business Analyst is normally concerned with specific projects independent of enterprise strategy.

Business Software Platforms are not Strategic

I want to share an idea that occurred to me and some of my colleagues, Dave Langer in particular, that was triggered during the work in building our business system architecture to enable our S+S corporate strategy, which is that reusable Business Software Platforms are not Strategic. In fact, if anything they are the opposite of Strategic.

Note: Before you read further, I recommend glancing at the Glossary of Terms at the end of this post to brief yourself on the definitions of Business Strategy, Business Process and Software Platform.

Essentially, the idea is a simple 3-step process which starts with Business Strategy and ends with candidate logical descriptions of Business Software Platform that, interestingly, are deliberately not directly enabling Business Strategy. Here’s the process:

image

Step 1. Identify the Business Strategy

A business must identify what its Business Strategy is. With methods like Michael Porter’s “Five Forces Concept” and/or Jim Collins’ Hedgehog Analysis, a business can identify its Business Strategy.

 

One output from this activity is a set of Business Strategy Statements where each Business Strategy Statement includes Objective, Scope and Competitive Advantage elements. Here’s a link to HBS article describing this in detail.

Step 2. Identify Context Business Processes

Using Business Processes, often in the format of a Business Process Categorization model, identify Business Processes that do not directly enable Business Strategy. There are many methods out there to help do this such as Geoffrey Moore’s Core versus Context, and your common Enterprise Architecture mapping Business Process to Business Strategy activity.

In the Core versus Context method, I refer to the “Core versus Context” concept developed by Geoffrey Moore. In Moore’s book ‘Living on the Fault Line’, Moore described a method for identifying Core and Context Business Processes and Business Process Activities, “For core activities, the goal is to differentiate as much as possible on any variable that impacts customers’ purchase decisions and to assign one’s best resources to that challenge. By contrast, every other activity in the corporation is not core, it is context. And the winning approach to context tasks is not to differentiate but rather to execute them effectively and efficiently in as standardized a manner as possible.”

In the Business Process to Business Strategy Analysis method, one analyzes the Business Strategy Statements and associates Business Processes that directly relate to Business Strategy Statements. I add a little twist here and assert that Business Processes that do not directly enable Business Strategy are considered Context Business Processes.

The assumption at this point is that Business Processes that are strategic should expect change. Those that are not strategic, therefore Context Business Processes, should expect less change. In fact, according to Moore, Context Business Processes should be standardized.

Step 3. Identify Candidate Platforms

We now need to identify Business Software Platforms. There are number of methods out there to help logically group Functions by Information entities to identify candidate Software Platforms. Methods such as Affinity Analysis, Yourdon and Constantine’s Functional Cohesion, and Coplien’s Scope, Commonality, Variability Analysis. All three have a common goal when using Business Process and Data as factors to be analyzed which is to mathematically identify logical groupings of processes based on their relationship to data.

The only addition I make to these methods is to only focus on Context Business Processes in the analysis. The assumption I make is that Software Platforms, by their very nature provide reusable/shared automation of business processes and data, represent standardized processes and data. By focusing on Context Business Processes, we simply realize these as Business Software Platforms as a result of the analysis.

Core Business Processes are left to be supported/automated by the more agile Applications because Applications are not specifically designed to be shared or reused. Applications provide time-to-market agility to the business.

Summary – Nothing new just putting together known concepts

This is an interesting post for me because I haven’t introduced any new concepts to suggest this new process idea for maturing the Enterprise Architecture discipline. Instead, I pulled together known concepts from business and software engineering domain experts to form a simple 3-step process for identifying Business Software Platforms.

I’m an Enterprise Architect so I also wonder if this idea can be broadened beyond S+S to across the Microsoft’s enterprise and, potentially, for any enterprise so I thought I’d publish this idea and share it. Thoughts?

By the way, I realize that this simple process is far from easy as there are lots of prerequisites to complete it such as; Defined Business Strategies exist, an inventory of business processes, an inventory of Business Data, and a mapping from Business Process to Business Data. Sorry if I’ve presented it in a way that appears way too easy. 🙂

 

Glossary of Terms:

Term Definition Source
Competitive Business Strategy (aka Business strategy) Business Strategy refers to how a company competes in a particular business (note: overall strategy for diversified firms is referred to as corporate strategy). Competitive strategy is concerned with how a company can gain a competitive advantage through a distinctive way of competing. Competitive Business Strategy refers to the aggregated strategies of single business firm or a business unit that incorporates either cost leadership, differentiation or focus in order to achieve a sustainable competitive advantage and long-term success in its chosen arenas or industries. The essence of strategy is choosing a unique and valuable position rooted in systems of activities that are much more difficult to match. Michael Porter, Harvard Business School
Business Process A business process is a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers. It often can be visualized with a flowchart as a sequence of activities. Harvard Business School
  A business process is a series of interrelated activities that convert inputs into results (outputs); processes consume resources and require standards for repeatable performance; processes respond to control systems that direct the quality, rate, and cost of performance. APQC
Business Process Categorization A reference framework for categorizing all the business activities used by an enterprise involved in delivering products and services. This is done through the definition of each area of business activity, in the form of process components or Process Elements that can be decomposed to expose progressive detail. These process elements can then be positioned within a model to show organizational, functional and other relationships, and can be combined within process flows that trace activity paths through the business. Business Process Categorization can serve as the blueprint for standardizing and categorizing business activities (or process elements) that will help set direction. TMForum.org
Business Software Platform Standardized business software engineered for reuse. Often Business Software Platforms are responsible for mechanizing standard business processes and managing standard data.

Note: I couldn’t easily find a non-bias definition so I researched and aggregated definitions from several credible sources, then simplified to avoid too much criticism while maintaining the sources intent.

Gabriel Morgan 🙂

Categories Uncategorized

Modeling the MDM Blueprint – Part VI

In this series we have discussed developing the MDM blueprint by developing the Common Information (part II), Canonical (part III) , and Operating (part IV)  models in our work. In Part V  I introduced the Reference Architecture model into the mix to apply the technical infrastructure or patterns we plan on using. The blueprint has […]

Modeling the MDM Blueprint – Part V

In this series we have discussed developing the MDM blueprint by creating Common Information (part II), Canonical (part III), and Operating (part IV) models in our work streams. We have introduced the Operating Model into the mix to communicate how the solution will be adopted and used to realize the benefits we expect with the […]

Modeling the MDM Blueprint – Part IV

In part II and III of this series we discussed the Common Information and Canonical Models. Because MDM is a business project we need to establish of a common set of models that can be referenced independent of the technical infrastructure or patterns we plan on using. Now it is time to introduce the Operating […]