The practice of business architecture

Nine views of the business architect role and its core concepts

Copyright 2017 Graham Berrisford. One of about 300 articles at Last updated 11/11/2020 12:55


At the time of writing, the Wikipedia page on business architecture is a partial, narrow and shallow, and marked as subjective.

And some videos on business architecture by management consultants are pretentious and/or mind numbing.


The aim here is not to promote any particular approach to business architecture – it is only to report and collate what is said in job advertisements and industry standards.

However, something approaching a consensus emerges from the research.

This article updates some research done in 2008 for the British Computer Society’s professional certificates in enterprise and solution architecture.

It is a companion to this newer slide show on business architecture its terms and concepts, and how they relate to each other.

And this older article on the science of business architecture.


Preface: positioning BA within EA.. 1

The BA role as employers and recruiters see it 1

BA in the Skills Framework for the Information Age (SFIA) 1

BA in Business System Planning. 1

BA in BOST (relating BA to IT) 1

BA in BizBOK.. 1

BA in TOGAF 8 and 9. 1

How do business architects differ from business analysts?. 1

Conclusions and remarks. 1

More on the business architect role. 1


Preface: positioning BA within EA

Four millennia have passed since the dawn of civilization and the first business systems were devised.

A mere four decades have passed since Enterprise and Business Architecture approaches emerged.


Business architects look, across the breadth of an organisation, to improve, integrate and innovate business processes.

Most approaches start with some strategic analysis of core business processes and the data they need.

In 2006, the popular book "EA as Strategy" urged enterprises to define their business operating model in terms of core business processes and information.


Modern business roles and processes rely on IT to store and transmit business data.

So EA can’t ignore IT; however, it remains focused on supporting and enabling business roles and processes.


Mainstream EA first addresses business processes and information, and only then what they need by way of applications and computing infrastructure.

Since the PRISM report of 1986, architecture has been divided into the four domains in the columns of the table below.

The top row of the table positions EA as a high-level cross organizational and strategic view of business systems.







Infrastructure technology



Business roles & processes,

standardization, integration

and road maps

Business data

standardization, integration

and road maps

Business application portfolio

standardization, integration

and road maps

Platform technology portfolio

standardization, integration

and road maps



Outline design of a solution’s

required processes

Outline design of a solution’s

data architecture

Outline design of a solution’s

application(s) architecture

Outline design of a solution’s

IT production environment



Detailed design of

processes & use cases

Detailed design of

data stores and flows

Detailed design of

software architecture

Detailed design of

IT production environment


Every enterprise has to work out for itself how its roles cover the cells of the table.

But clearly, the focus of a business architect is in the top-left quadrant.

Business architects and directors

Business architects support business directors.

·       are concerned with the services provided by a business.

·       must engage with what directors declare by way of goals/strategies/plans that change the market or services of a business.

·       may stimulate or contribute to innovations in services, and strategic business planning of the kind done by directors.


However, the business architect role is distinct from that of a director.

As described in the job advertisements, industry standards and frameworks below, the role is more about business system planning.                                                                                                                                          

Business architects

·       analyse current business operations, then design and plan changes to them, with a business case for doing so.

·       must understand where roles and processes can be supported and enabled by applications, and opportunities that IT can bring.

·       are involved in stakeholder management, risk management and must have good communication skills.

Some business architecture ingredients

Enterprise and business architects are concerned with the services provided by a business.

And with how those services are delivered by processes that refer to and advance the state of the business.


The services are behaviors that deliver results of value to actors with a stake in the business.

E.g. Take out a loan. Complete a tax return. Direct an airplane take off. Conduct a research project.

The role of a business architect can include the identification of service improvements and innovations.


The processes are sequences of activities that a business must perform to complete and provide services.
The role of a business architect can include process improvements and innovations.


The state of a business is represented in information found in the data structures of messages and memories.

The role of a business architect can include improvements and innovations in data capture and use.


You don’t have to model every business activity that could possibly be documented.

You model what you need to understand, then choose what to communicate to others - simplifying as need be.

What can be modelled?

This slide show on business architecture illustrates how architects model business systems.

This table shows how an architect may approach the description of a business, or of a required business change.


A simple approach

A simple illustration

1)     What are the goals of the business?

Attract more customers to the hotel

2)     What services will the business offer/provide to achieve those goals?

Valet parking of a car

3)     What processes must be performed to deliver those services?

Park and retrieve a customer’s car

4)     What roles are needed to perform the activities in the processes? (And how many actors in each role?)

Valet (3)

5)     What organisation structure is needed to manage the actors?

Front desk management

6)     What are the locations where the processes are performed?

Hotel entrance and car parks


You can find corresponding concepts in many standards and sources on business architecture.

E.g. The SFIA standard’s definition of the business architect role refers to goals, functions, services, processes, information, roles and organisation.

Which of the concepts above appear in definitions of the business architect role in job adverts, industry standards and frameworks?

Read on to find out. Beware there is terminology torture out there.

The BA role as employers and recruiters see it

Both public and private sector role definitions below refer to goals, processes, information, and organisation.

Note that some employers see the business architect role as related to computing/software/technology.

The BA role in an insurance company

“As part of a dedicated Business Architecture team you will be working at a macro level,

to design business models to shape change initiatives in support of the strategic business goals.


·       Develop business models to support strategic goals of the business

·       Apply structure design methodology when capturing requirements from the business

·       Identify structural issues within the business and use innovative design models to maximise efficiencies

·       Work closely with IT to align technical capability to business needs

Key Skills:

·       Experience in a business architecture role within the insurance industry

·       Extensive experience developing business strategy

·       TOM design exposure

This is an excellent opportunity to join a leading process-focused architecture function within the insurance market.”


The business architect in this advertisement defines business processes and connects them to IT.

To “develop the business strategy” surely means to elaborate and realise the “strategic business goals” by optimising and changing business processes.

To connect those processes to IT, architects must define the information created and used at each stage or step.

This business architect is expected to use analysis techniques: business requirements capture, structured analysis and design methods and models.

The BA role in the Canadian government

The generic job description below is quoted from the Canadian government web site in 2018.


“Business Architect

Experience Levels: Junior: < 5 years of experience; Intermediate: 5- < 10 years of experience; Senior: 10+ years of experience, or 5+ years of experience with a recognized professional certification.

Responsibilities could include but are not limited to:

Develop policies and rules that allow an organization to carry out its mandate and functional responsibilities,

and that govern the organization's actual and planned capabilities in terms of computers, data, information, human resources, communication facilities, software and management responsibilities.

Develop the specifications for where, how and why the various organizational components fit together as they do, and how they support the organization's mandate.

Specialties could include but are not limited to BPWin, Oracle CASE, Rational Rose and RUP.”

The BA role according to a recruitment agency

The generic job description below is quoted from the CW jobs web site in 2018.


“Business architect job description

Typically business architects report to the programme director and work alongside the firm's most senior business process executives and stakeholders.

They may report to the IT department, or to the business.


Business process management (BPM) projects need an effective IT architecture.

Working hand-in-hand with the change manager, the business architect takes the lead in developing that architecture.

The business architect fleshes out the business model and describes the need for business technology across the organization and the role that process plays.


Business architects have deep pockets of business knowledge but also see the big picture.

Necessary talents encompass process discipline skills in methodologies such as Lean and Six Sigma.

They’re a hybrid beast and so need a rare combination of business domain knowledge, process experience, transformation talents and methodology skills.

On top of that, you need a winning personality to bring disparate parties together.

The best business architects have got their hands dirty designing and building technology platforms and can intellectually strip a system down to the hardware and software nuts and bolts.

Additionally, they know all about large-scale, cross-functional processes and systems: supply chain management, enterprise resource planning (ERP), finance, or customer resource management (CRM) are meat and drink to them.

Many business architects end up in financial services where the business environment of compliance and regulation is complex and fast-changing.

But other sectors working on a similarly large and complex scale (utilities and transportation outfits, energy trading exchanges, telecoms and retailers) are advertising business architects jobs on CWJobs right now.”

BA in the Skills Framework for the Information Age (SFIA)

SFIA is an international standard for role definitions used by employers that includes enterprise and solution architect roles.

E.g. SFIA’s definition of the business architect role refers to goals, functions, services, processes, information, roles and organisation.


SFI treats business architecture as a subset of enterprise architecture.

It says that enterprise and business architecture roles involve:

·       interpretation of business goals and drivers;

·       translation of business strategy and objectives into an "operating model" (see note below)

·       assessment of current capabilities [cf. functions] and identification of required changes to them;

·       description of inter-relationships between business system elements:

o   services (resulting from business activities)

o   processes (sequencing business activities)

o   data, information (created and used by business activities)

o   technologies (supporting and enabling business activities)

o   people (playing roles in business activities)

o   organizations (managing people employed in business roles)

o   the external environment (notably customers, suppliers, partners, competitors and other stakeholders)

·       formation of constraints, standards and guiding principles necessary to define, assure and govern the required business change.


Some terminology torture

A business strategy usually features business goals/objectives, declared in response to business drivers.

Sometimes it means plan for activities to achieve those goals, perhaps along with some directives (principles or policies).


A business operating model in "EA as Strategy" (2006) is an abstract graphical representation of core business processes and information.

Others use the term to mean a more detailed description of business actors and activities, structures and behaviors.


A business model is sometimes used as a synonym of operating model.

Others mean a business model canvas, or similar diagram or conceptual tool, indicating

·       how a business makes money by way of revenue and profit

·       what “value proposition(s)” the offers customers by way of services

·       the core business processes and resources

·       entities the business has relationships with.


Here, service-orientation means encapsulating a system behind an interface composed of the services the system is required to provide.

The output of a business service may be a tangible "product" or something more intangible – such as advice, be it oral or documented.

BA in Business System Planning

EA and BA are much older than today’s TOGAF and BizBOK and have always been about Process and Data before Technology.

Perhaps the first was that of IBM’s Business System Planning, created by Duane Walker in the 1970s.

I am told that IBM's GE20-0527-2 (1978) Information Systems Planning Guide publication was the first definitive guide to business systems planning.

It was source for John Zachman in the 1980s, and set the pattern for other EA meta models in the 1980s and 90s.


Another source (lost to me) reported that the Business System Planning meta model featured these 7 entities and 8 relationships.

·       Problems <are solved by > Processes <are enabled and supported by> Applications

·       Business entities <are represented by> Data entities <are maintained in> Data stores

·       Organisations <perform > Processes <create and use> Data entities

·       Organisations <use> Applications <access> Data stores


Notice the focus on Processes and Data used in the Business, rather than IT.

BA in BOST (relating BA to IT)

An EA/BA framework typically catalogs entities of importance to a business under hierarchical structures.

The Business Transformation Framework (BOST), endorsed by CISCO and Informatica, is generalized from a reference model for a retail business called ProAct.

BOST is a simple, traditional, EA framework.

It adds a “business view” over the top of the business, application and technology domains/layers of enterprise architecture.




Business architecture

Business view

Enterprise market, products, relationships and resources

Operations view

Business functions/capabilities, information subjects and flows

IT architecture

Systems view

Application components and information exchanges

Technology view

Technology components and devices


BOST users build a hierarchical structure to describe each view.

Then map elements in one view to elements in the other views; e.g. map applications to business functions.


The function hierarchy in BOST

You will surely be familiar with a hierarchical organisation or management structure.

Many EA approaches use a business function hierarchy to impose a purely logical structure over an organization’s business activities.

BOST says this provides “a structured definition of all essential operations capabilities.”

Functions are independent of:

·       organization [the management structure];

·       where work is performed [locations] or

·       who [roles] performs it; and

·       how the work is performed [process flow sequences].”


For more on what it means to create and use a function hierarchy, and map hierarchies to each other, read The science of business architecture.


More terminology torture

Note the terminology torture in these three business architecture reference models:

·       In ProAct for a retailer - the function hierarchy, from the top down, features capability area, service function and basic service function.

·       In PCF for a commercial business - the function hierarchy is called a process hierarchy.

·       In BIAN for a bank- the function hierarchy is called a service landscape.


BOST uses function and capability interchangeably.

It uses service where TOGAF says component or building block.

And by system it means business application (a very narrow use of the term system.).

BA in BizBOK

BiZBOK is a relatively young collection of guidance on business architecture. Its founders say:

“Business architecture serves as a bridge between strategy and execution.

        Framing and communicating impacts of strategic business objectives

        Aligning strategies and plans across business units

        Realizing business model aspirations

        Enabling strategic business transformation”


Other stated uses of business architecture include:

        “Framing business requirements

        Scoping IT investments

        Defining target state IT architectures

        Integrating companies during a merger or acquisition.”


Biz BOK defines business architecture thus.

 “Business architecture represents holistic, multidimensional business views of capabilities, end-to-end value delivery, information, and organizational structure as well as the relationships among these business views and strategies, products, policies, initiatives, and stakeholders.”


Some more terminology torture.

At the time of writing, some of BizBOK’s glossary definitions are abstract or vague to the point of not being definitive.

Note that a “capability map” corresponds in appearance and use to a function hierarchy in some other sources.

What BizBOK calls “function” may be called by others a process.

The term “end-to-end value delivery” suggests the flow of business processes from suppliers to customers.

The term “information” refers to the meanings created and found - by activities in business processes - in data structures.


This table maps BizBOK’s terms and concepts to those in SFIA (before this section) and TOGAF (after this section).


In BizBOK terms

In SFIA terms

In TOGAF terms

holistic, multi-dimensional business views of


cross-organizational, multi-dimensional views of

capabilities (see notes below)

current and required capabilities

business functions (see notes on hierarchies below)

end-to-end value delivery


business scenarios and processes,


data, information

business data/information

organization structure

people and organizations 

organization decomposition

relationships among these business views and


mappings of the above views to each other and to


business strategy, goals and drivers

business strategy, drivers, goals and objectives



business services


constraints, standards and principles

business principles and policies


the required business change

business vision, requests for architecture work


the external environment

stakeholders and their concerns.


BizBOK defines an enterprise “on a page" as a high-level business capability map that is independent of the organization structure and process flows.

It suggests you layer heat maps on that map to show areas of concern or change.

You can map each key capability to the organization units needed to realise that capability (in a capability/organization matrix).


That is exactly how TOGAF describes the use of functional decomposition.

And this description of business capability modelling also reads very like a description of functional decomposition.

It is good in many ways, but misleading on a few points.

Read The science of business architecture for more detailed analysis.

BA in TOGAF 8 and 9

TOGAF started as an IT Architecture framework c1995, without reference to EA and BA history.

TOGAF versions 1 to 7 were about rationalising platform/infrastructure technologies.

TOGAF version 8 was radically revised in 2002 with a focus on transforming business systems to meet business goals/objectives.

It is a management framework for the architecture projects on which both business and IT architects work.

The aim is to ensure (taking a cross-organizational view) that business processes and roles help a business meet its goals.


TOGAF assumes architects define a target business architecture and plan how to get there.

It recommends some business architecture effort before embarking on any change initiative.

It says that on starting an “architecture project”...

"... little or no Business Architecture work may have been done to date.

In such cases, there will be a need for the architecture team to research, verify, and gain buy-in

to the key business objectives [goals] and processes that the architecture is to support.

This may be done as a free-standing exercise, either preceding architecture development, or as part of Phase A."


TOGAF version 9.2 described business architecture as capturing architectural models of:

“business operations [processes], factors that motivate the enterprise [drivers],

how the enterprise is organizationally structured, and what functional capabilities the enterprise has.”

This table lists maps this definition to some core business architecture entities, and to other terminologies.


TOGAF 9.2’s definition of business architecture

Some core entities

In SFIA’s definition

In BizBOK’s definition

“Business operations

Processes and Roles


end-to-end value delivery

“factors that motivate the enterprise”

Drivers and Goals

business strategy, goals and drivers


“how the enterprise is organizationally structured”

Organization units and Actors

people and organizations 

organization structure

“what functional capabilities the enterprise has”

Business functions

current and required capabilities



TOGAF 8 and 9 mostly presumed architects already know architecture definition techniques and artifacts

However, it outlined the ones listed below.

Business architecture approach in TOGAF 8 and 9

TOGAF provided a process and products for business architecture, as listed in this table.


Business architecture process in TOGAF 8.1

Business architecture artifacts in TOGAF 9.1

1.     Document the organization structure, relating locations to organization units.

Organization Decomposition diagram

Business Interaction matrix/diagram

2.     Document business goals and objectives for each organization unit.

Driver/Goal/Objective catalog

3.     Define business functions... successive decomposition... into sub-functions.

Functional Decomposition diagram

4.     Define business services each unit provides to its customers, internal and external.

Goal/Objective/Service diagram

Business Service/Function catalog

5.     Define business processes, including measures and deliverables.

Process Catalog, Flow diagrams

6.     Define business roles, including skills requirements.

Role catalog

7.     Define business data [information] model.

Conceptual Data diagram

8.     Relate business functions to organization units in the form of a matrix

Function/Organization matrix


Note: Business architecture is not limited to supply chain businesses that process and produce concrete products.

TOGAF defines business functions in terms of the services they are required to provide.

The entry conditions to a service include any trigger or input; the exit conditions include any output or product produced.

It then defines the processes and roles needed to deliver a service.

And defines information created and used in business processes in a business/conceptual data model/diagram.

Business architecture techniques - in TOGAF 8 and 9

TOGAF 8 and 9 assumed knowledge of the following techniques for modelling business activities, both in a structure and in sequences.


Structured analysis

This completes a function hierarchy and maps its nodes to organisation units and to processes.

Read The science of business architecture for a general description of structured analysis.

The following specific techniques appear in TOGAF.


Functional decomposition (cf. business capability mapping)

Functional decomposition diagram [shows] on a page the capabilities of an organization.

By examining the capabilities of an organization, it is possible to quickly develop models of what the organization does

without being dragged into debate on how the organization does it.

... layer heat-maps on top of this diagram to show scope and decisions.

E.g. the capabilities to be implemented in different phases of a change program.”


Business scenario analysis (cf. value stream analysis)

This is used to discover and document business requirements.

It involves defining a process to meet a goal, along with the roles of human and computer actors.

The template for describing a scenario starts thus:

·       “Problem description: purpose [goal] of the scenario.

·       Detailed objectives.

·       Environment and process models: process description, process steps mapped to environment and to people, information flow.

·       Actors and their roles and responsibilities: human actors and roles, computer actors and roles, requirements.”


Note: architects usually document roles rather than individual actors (an exception being named organization units).


Like functional decomposition, scenario definition starts at the highest cross-organization level.

 “[Business scenarios] may be used iteratively, at different levels of detail in the hierarchical decomposition of the Business Architecture."

... any other [comparable] method may be used.”

Value steam diagrams might be used to represent the highest level scenarios or processes.


Business process modelling

This involves.

·       Identifying business services provided, or required.

·       Defining processes (sequences of stages/steps/activities) to deliver the services

·       Mapping activities in processes to logical functions and roles.

·       Identifying information created and used by activities.


"Process Flow diagrams... may utilize swim lane techniques to represent ownership and realization of process steps."


Business architecture products - in BizBOK and TOGAF 9.2

TOGAF 9.1 authors treated business architecture techniques and artifacts as presumed knowledge.

TOGAF 9.2 was extended to include business architecture terms and artifacts from BizBOK.

Thus TOGAF acquired two business architecture vocabularies and more optional artifacts than anybody wants to use


Some business architecture definition activities

TOGAF artifacts in v9.1

BizBOK-style artifacts added in v9.2

Document the organization structure

Organization Decomposition diagram

Business Interaction matrix diagram

Organization map

Document business goals and objectives

Driver/goal/objective catalog


Define business services that meet the goals

Goal/Objective/Service diagram

Present a top-level view of activities needed to deliver services and goals

Value chain diagram

Business model canvas or diagram

Sequence activities in processes that deliver products/services of value

Business scenarios or process flows

Value stream map or diagram

Define the abilities or functions needed to complete activities

And organise them in a hierarchical structure


Functional decomposition diagram.


Business capability map

Map business abilities or functions to the strategy or services

Business Service/Function catalog

Strategy/Capability matrix

Map activities in processes to functions, roles or capabilities

Business scenarios or process flows

Value stream map or diagram

Map business abilities or functions to organization units

Function/Organization matrix

Capability/Organization matrix


EA meta models have been around since the 1980s (see footnotes).

The TOGAF meta model was first built by adding two dimensions to more traditional EA meta models.

·       There are logical and physical versions of each "active structure” component in each architecture domain/layer.

·       Each logical component is defined by the services (specified as service contracts) it is required to offer.


This table classifies TOGAF’s core meta model entities.


Required behaviors

Logical active structures

Physical active structures


Business Services

Business Processes

Business Functions


Organization Units


Information Systems

Application/IS Services

Logical Application Components

Physical Application Components


Platform/Technology Services

Logical Technology Components

Physical Technology Components


The TOGAF meta model is elaborate, and therefore somewhat impractical as an EA repository structure.

But it does help to teach people two of TOGAF's general principles:

·       Define required behaviors (notably service contracts) before structures

·       Define logical structures before physical structures.


TOGAF 9.2 and its meta model were further elaborated by including parallel versions of business architecture concepts.

Business capability maps and function hierarchies not only look the same, they have the same purposes and uses.

The business scenario guidance obscures what had formerly been the central idea of a process (cf. value stream) in which human and computer actors play roles to meet a goal.

TOGAF has always promoted service-oriented definition of business systems, whereas BizBOK-oriented extensions refer to products (the outputs of services).

Oddly, the artifacts chapter mentions only BizBOK-oriented artifacts under phase A, though it is supposed to draft artifacts in every domain (in architecture definition v0.1).


The following sections answer two outstanding questions.

The answers don’t correspond to each other as well as you would like.

How do business architects differ from business analysts?

First, here is an attempt to reduce some terminology torture.

On the recursive nature of system and process definition.

·       Systems can be related in a wider system.

·       Processes can be joined in a longer process (or value stream).

The wider/longer the system/process, the more abstract (less detailed) the description of it that one person can be held responsible for


On the analysis and design of business systems.

·       Analysis is the investigation and description of a situation or system.

·       Business analysis is the investigation and description of business systems (goals, roles and processes). 

·       Design is the description/specification of a new solution or system.

·       Business design is the description/specification of a new business solution or system.


Given the definitions above, some sources differentiate business analyst and architect roles along these lines.

·       Business analysts do business analysis and design work at lower levels of abstraction, on discrete solutions/systems.

·       Business architects do business analysis and design work at higher levels of abstraction, and across an organization.


Digital Business Analyst in 2019

“Four of our finest BAs shared their experience across business areas.

·       Solid analysis is the bedrock (good business case analysis, requirements, stakeholder engagement, ability to influence) .

·       The digital bit is a combination of new skills on top...

·       The ability to understand and engage with agile and fast delivery.

·       Plus some knowledge of (fast moving) emerging technologies or “knowing someone who knows”.

·       The ability to very quickly to translate needs into what is possible is a very powerful combination.

What is different today – from the systems analyst of yore – is the pace of change and user experience.

Customers have choice, they want fast response and a good user experience.

But don’t forget those bedrock skills.

Also, few organisations are greenfield sites, so the legacy/technical debt needs to be on the right path as well.

Which requires a team effort.


A Digital Business Architect in 2019

EA frameworks like TOGAF propose architects work at the highest levels of abstraction, and across an organization.

They must begin by understanding the strategic context, and recording business drivers, goals and objectives.

To do this, architects must understand and use the terms that business directors/planners use.


One contributor to discussion on the internet says this of the business architect role.

“It requires a deep understanding of budgeting, resourcing, management, marketing and strategy.

Executives learn this on a journey through the ranks taking a decade or more and/or via a very comprehensive MBA qualification.

The business architect role is to: “transform the business model into an operating model and align it with the strategic model.”

·       Strategic models speak to the positioning of the firm that represent the drivers for the business models.”

·       "Business models are how the business generates revenues."

·       Operating models are the infrastructure for enabling the business model.”


Some sources appear to suggest business directors/strategists employ MBA-trained business architects.

See Conclusions and Remarks below for references to MBA sources.

Conclusions and remarks

This article exposes the terminology torture found in several business architecture sources, and aligns some of them

It is not the aim to present any source mentioned as the whole truth, or an unqualified success.

However, something approaching a consensus emerges from the sources.

Text analysis suggests business architects address six core concepts, here called goal, service, process, role, information and function.

Business architects define these abstract concepts, relate them, and map them to concrete actors working in organization units.


Generally, enterprise architecture views a business as a system in which actors perform activities to meet aims.

Business architects look to improve business processes by optimization, standardization, integration or innovation.

They analyse current business systems; they design and plan changes to them; with a business case for doing so.

This involves some stakeholder management, risk management and the exercise of communication skills.

The term “architect” implies they do all these things at a more cross-organizational and strategic level than “business analysts”.


What about the more human aspects of organization change?

What might be called socio-cultural changes?

And changes to roles, salaries, benefits packages, office facilities, management reporting structures, etc?

Certainly business architects must be aware of these and consider them.

Sometimes however, there is a parallel “business change" team who works with HR, business managers and others.

See “working hand-in-hand with the change manager” in the recruitment agency’s job description above.

More on the business architect role

This article is a companion to this newer slide show on business architecture its terms and concepts, and how they relate to each other.

And this older article on the science of business architecture.


Below are some more sources you might be interested to research.

This Forces article points out that MBA schools still teach business ideas that are decades old.


Michal Porter’s “Competitive forces”1980 and 1985

Harvard Business School’s Porter wrote on why some industries are more profitable and competitive than others.

His big three ideas are the five forces model, generic strategies and value chain.

The value chain diagram is an abstract conceptual tool, comparable with what people now call a business model canvas diagram.

This 2018 article reviews the five forces model from a modern perspective.

Others have pointed out the need to understand the impacts of globalisation, deregulation and digitisation on the model.


Hammer and Champey’s “Reengineering the Corporation” 1993

MIT professor Hammer spoke eloquently about starting with a clean sheet of paper, and radically changing processes to reduce costs or deliver better services.

Business process reengineering has reportedly failed more often than succeeded, and is no longer fad du jour.

Currently, more incremental business process improvement is favoured.


Clayton Christensen’s “The Innovator's Dilemma” 1997

Another Harvard Business School professor, Christensen’s notion of disruption remains a popular buzzword.

This Computer Weekly article in 2000 doubted his ideas can save big companies from being disrupted.


Did Henry Ford start by drawing a business model canvas diagram?

Would a dose of business process reengineering enable high street retailers to compete with etaillers?

Or older music businesses to compete with Spotify’s operating model?


Other sources you might look at include

·       Architecture Frameworks such as those used by IBM, CSC (Catalyst) and Cap Gemini (IAF), which informed TOGAF

·       BABOK for business analysts; watch this recording for an extension into the EA space

·       Drucker and Peters – management by goals/objectives

·       Checkland and Wilson – soft systems (outlined and discussed in this article)

·       Six Sigma and Lean, which encourage eliminating waste from and maximising the efficiency of processes.


See also Deming, W.E. (2000). Out of the Crisis. The MIT Press.

It includes Demings 14 points for management, listed here

Which include:

·       Rather than set targets – continually measure and improve.

·       Rather than tender on price alone - tender with quality measures as well

·       Rather than rely on inspectors – ask all to look out for problems

·       Rather than drive by exhortation - facilitate collaboration.

·       Educate


You can find some business architecture processes and products in Avancier Methods at

Avancier Methods align reasonably well with the terms and concepts in SFIA, BizBOK and TOGAF.

You can find discussion of other architect roles on this page