The business architect role

Eight views and six core concepts

Copyright 2017 Graham Berrisford. One of about 300 papers at Last updated 16/03/2019 16:10


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.


This is a survey of what business architecture means.

It distils from what is said in several job advertisements and several industry standards.

It is not the aim to present any source mentioned as the whole truth.

However, something approaching a consensus emerges from the research.


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 trouble is, other roles share something of the same aims, knowledge and skills. 

How to differentiate the role from business planner, management consultant, enterprise architect, business analyst etc.?

To differentiate the business architect we need describe their interests and their role more specifically.


Some take ways:

           The difference between business planning and business architecture

           Six core business architecture concepts that appear in many sources.

           How recruiters see the role differently from industry standards.


Preface: BA in the domains and levels of enterprise architecture. 2

BA in a real job. 3

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

BA in BOST, relating BA to IT. 5

BA in BizBOK.. 6

BA in TOGAF 8 and 9. 8

BA role: how does architect differ from analyst?. 12

BA role: how do recruiters see it?. 13

Conclusions and remarks. 15

Footnotes. 15


Preface: BA in the domains and levels of enterprise architecture

Business directors must respond to business drivers by declaring strategic directions and top-level goals/objectives.

Business planning addresses changes that have been envisioned to one or more of an enterprises’

·        Constitution: mergers, acquisitions and divestments, opening/closing outlets

·        Market: industry domain/sector/segment, customers and suppliers

·        Products: products and services, sales and service channels, prices

·        Relationships: partners, in-sourcing and out-sourcing of operations

·        Resources: people, wages, machines, locations/buildings and other physical asset types.

It may involve predicting demand, sacking or appointing CxOs and restructuring the organisation's management.


Business architects may stimulate or contribute to business planning of that kind.

But their primary concern is business system planning.

They look to optimise, standardise, integrate and innovate in the structures and behaviors of regular business operations.

Partly to enhance current operations, and partly to support goals/strategies/plans that directors declare.


Much if not most of the human activity in a business is not architected.

That is fine; business architecture is not (and should not) be about what humans do better un-architected. 

It is about the processes that are (and should be) systematised and digitised.


In the 1960s, regular business processes were often analysed and designed by people in an Operational Research department.

In the 1970s, IT departments were created to support and enable business processes that create and use business data.

Then, as Information Age began, many Operational Research departments were absorbed into IT departments.


Enterprise Architecture (EA) emerged in the 1980s.

It grew out of IBM’s "business system planning", James Martin’s “information engineering” and other approaches.

All these approaches urged enterprises to take a strategic and cross-organizational view of business processes and data.


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

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

And it positions business architecture in the top-left quadrant.







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.

Business architecture approaches started out decades ago as process and information-oriented rather than technology-oriented (as footnote 2 shows).

More recently, in 2006, "EA as Strategy" urged enterprises to define their business operating model in terms of core business processes and information.


Having said that, business architects are expected to look for opportunities to take advantage of technologies.

And since much if not most business information is digitised, business architects cannot ignore IT.

Business architects must understand where business processes can be supported and enabled by application use cases.

BA in a real job

A later section in this paper describes the business architect role in general as seen in 2018 by a major recruitment agency.

To get us started, here is one particular role definition advertised by a different agency.


“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.”


Note: This architecture function 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.

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.

It 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.


Note: The whole field is 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 use business model, as in business model canvas, for a 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 an intangible "service" – such as advice, be it oral or documented.

BA in BOST, relating BA to IT

A business is, in reality, a complex network of actors and activities.

Architects and managers impose one or more hierarchical structures on that network to help them understand and/or manage it.

Here are four hierarchies employed in business architecture definition.


·        Motivations: goal/objective hierarchy - as in a strategy map, or a balanced score card.

·        Behaviors: process hierarchies – dividing longer processes or value streams into shorter processes.

·        Physical active structure: organization hierarchy – dividing people and resources for management purposes.

·        Logical active structure: function hierarchy – dividing larger/wider functions into smaller/narrower functions.


Many EA approaches use a business function hierarchy to impose a logical structure over an organization’s behavior or capabilities.

In BOST, the business operations architecture is based on a function hierarchy that 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].”


But note the terminology torture in these business architecture reference models:

·        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.

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


The approach used to create ProAct is generalised in the Business Transformation Framework (BOST) endorsed by CISCO and Informatica.

BOST is a relatively simple, traditional, EA framework that adds a “business view” over the top of the domains 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 describe the function, information and application views using hierarchical structures.

They map elements in one view to elements in other views (e.g. map applications to business functions).


BOST follows the common practice of treating one function hierarchy as the primary structure for enterprise architecture purposes.

It is possible to draw several function hierarchies, e.g. where different business managers have different goals, have different value propositions.

The resulting set of trees is called a "function forest".


Note: there is some terminology torture here.

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 of BizBOK’s glossary definitions are abstract or vague to the point of not being definitive.

And note some more terminology torture.

·        BizBOK’s capability map - corresponds to a function hierarchy in other sources.

·        BixBOK’s function - is more generally called a process.

·        BizBOK’s end-to-end value delivery - is the flow of business processes from suppliers to customers.

·        BizBOK’s information - is data created and used by activities in business processes.


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 on hierarchies 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).


TOGAF defines an enterprise "on a page" as a high-level business function hierarchy that is independent of the organization structure and process flows.

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

And map each key function to the organization units needed to realise that function (in a matrix).


This description of business capability modelling  reads very like a description of functional decomposition.

It is good in many ways, but misleading on a few points made in the footnote on hierarchical structures below.

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 positions that work under the heading of enterprise architecture, to be completed at the highest possible enterprise/strategic level.

It is a management framework for the meta system in which business and IT architects work.


Today, TOGAF’s objectives are those of EA in general - to ensure (taking a cross-organizational view) that business processes and roles help a business meet its goals.

It is not prescriptive; you are expected to tailor it.

It so general and abstract that much EA and BA practice can (if you wish) be presented as a tailoring of it.

The question is rather what is not TOGAF, and I suggest two things.

·        Documenting architecture in a repository for its own sake.

·        Doing IT architecture work without reference to business architecture.


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



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 and Roles

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.


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.”

For example, value stream diagrams might be used to represent the highest level processes.

In this paper, the concepts are more important than the diagram notations.


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."


Structured analysis

This completes a function hierarchy views and maps it to the organisation and to processes:

·        drawing a functional decomposition diagram (cf. business capability map)

·        mapping functions to organization units (divisions in the management structure).

·        mapping functions to processes

·        either mapping lower-level functions to stages/steps of higher-level processes (cf. value streams)

·        or mapping lower-level process steps to higher-level functions.

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.

BA role: how does architect differ from analyst?

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 analysis and design 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.


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.

BA role: how do recruiters see it?

The term “business architect” sounds like senior business director/strategist.

But when a director wants a baseline or target business architecture to be analysed or designed, they usually hire somebody to do it.

And you may be surprised that employers in the public and private sectors see the business architect role as computer/software/technology-focused.

According to 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.”

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.”

Conclusions and remarks

This paper 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.


Other sources

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 paper)

·        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

Footnote 2: theoretical underpinnings

EA is business system planning, but there are misunderstandings of what a business system is.

To call every problem, situation or business “a system” is unhelpful.

It is important to distinguish:

·        a social network in which people communicate

·        a social system in which people realise role and rules.


An enterprise is one social network that realises many social and technological systems.

Architects may find some systems overlap, duplicate or even conflict with each other.

Architects apply some change control to large-scale, generational, system change.


People often liken enterprise or business architecture to building architecture, airplane engineering or city planning.

Such analogies can mislead people.

Enterprise and business architects are concerned with business activity systems - rather than concrete structures.

"Building" a business system is very different from building any kind of concrete structure.

An education in business process engineering is very different from an education in building architecture.

The similarities are far outweighed by the differences.

The concepts that appear and reappear in business architecture are abstract ones like goals, roles, processes and information.

The theoretical basis for architecting activity systems is not building architecture.

It is general system theory and classical cybernetics - along with a dash of “design thinking” and social systems thinking.

If those things interest you, then do book a place on the next System Theory for Architects Tutorial in London.

Footnote 3: EA not = ITA

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

EA meta models have been around for fifty years.

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

It set the pattern for other EA meta models in the 1980s and 90s.

If I have it right, the Business System Planning meta model features 7 entities and 8 relationships

·        Processes <solve > Problems

·        Processes <are performed by > Organisations

·        Processes <create and use> Data entities

·        Process <are enabled and supported by> Applications

·        Data entities <represent> Business entities

·        Data entities <are maintained in> Data stores

·        Applications <access> Data stores

·        Organisation <use> Applications

Notice the focus on Process and Data rather than Technology.

Footnote 4: on composition hierarchies

Composition of smaller things into larger things is a primary abstraction technique.

It is used in most EA reference models and frameworks (one exception being the Zachman Framework).


Business architects use hierarchical structures to define some views of a business.

E.g. TOGAF distinguishes organization, function and process hierarchies (admittedly, TOGAF explains this badly.)


BizBOKkers claim business capability maps to be an innovation.

Yet function hierarchies look exactly the same and have been used for the same purposes for decades.

There seems to have been a failure of collective memory, a mass forgetting of:

·        the general principles for how to build hierarchical structures

·        the difference between strict and redundant hierarchies, and

·        the implications of correspondences and clashes between hierarchies.


Corresponding and clashing hierarchies

When the same hierarchy is imposed over different actors, activities or data elements, the structures are said to correspond (the nodes are in 1-to-1 correspondence).

When different hierarchies are imposed over the same or related actors, activities or data elements, the structures are said to clash.


The science of corresponding and clashing hierarchies can be traced back through Michal A Jackson (1975) to earlier sources.

In applications architecture, any two data structures read and written by an application must either correspond or clash.

When they correspond, the structures can be merged into one program structure.

When they clash (Jackson showed) the program is better divided into application components that each process a different data structure.


Business architecture also features corresponding and clashing hierarchies.


Multiple hierarchies

Business directors usually impose a hierarchical management or reporting line structure over the employees of a business – an organization decomposition.

Architects often impose other, more logical, hierarchies on the actors, activities and resources of a business.

Here are four common hierarchical structures.


Motivations: goal/objective hierarchy - as in a strategy map, or a balanced score card.

Behaviors: process hierarchies – dividing longer processes or value streams into shorter processes.

Physical active structure: organization hierarchy – dividing people and resources for management purposes.

Logical active structure: function hierarchy – dividing larger/wider functions or capabilities smaller/narrower functions or capabilities.


Corresponding structures

Managers may base the organization structure on a function hierarchy.

In such a “functional organization”, every organization unit realises a function in the function hierarchy.


Architects may align a function hierarchy with a goal/objective hierarchy.

Suppose managers define a top-down business goal/objective hierarchy.

Architects can build a function hierarchy from the bottom up, by successively clustering bottom and lower level activities/functions under higher level nodes.

Provided the clustering criterion is a business goal/objective, then this second structure will necessarily correspond to the goal/objective hierarchy.


Although the concepts of capability and function differ, they are naturally organised under hierarchies that correspond to each other.

Why? Because to realise each unique function, you need a unique capability.

The two hierarchies will clash only if you insist on using different cohesion criteria to cluster lower level nodes under a higher level node.


Wherever two hierarchies correspond, you may merge and maintain them in one structure, though this is a hostage to fortune.


Clashing structures

Given two structures are currently in correspondence, one may change without the other.

E.g. an organization’s management structure may be restructured by location, customer type, product type or resource type.

This may be done without significantly changing what the business does, as shown in a function hierarchy.

And that is the major reason for basing business architecture documentation on the latter rather than the former.


Moreover, business architects may impose different, logic hierarchies over the network of business actors and activities

One enterprise architect drew 9 different function hierarchies to match the interests of 9 different business directors.


Duplication or reuse of elements in different legs of a hierarchy?

Process, function and capability hierarchies abstract from the bottom up by composition or aggregation.

You may find some common or shared elements at the bottom, which may be reused by delegation.


If you decompose a business capability or function hierarchy far enough, you will reach some capabilities or functions that are shared or generic.

But if you follow the convention to decompose to only a 3rd or 4th level, you are unlikely to find those common elements.


(By contrast, class hierarchies abstract from the bottom up by generalization.

You will find common or shared elements at the top, which may be reused by inheritance.)