Business Architecture Hierarchies

“Thank you. I wish I had read this at the beginning of my EA journey. I could have saved a lot of hours.” (Enterprise architect)

"Thank you for this very well written article! I can use a lot of this in my current assignment. It saved me from a lot of confusion about processes, capabilities and functions." (Information and enterprise architect).

"Many thanks, for investing the time to explain these concepts. This is how I remember the learning journey we've been living through." (Enterprise Architect).

Other comments: “Very spot on.” “Very good article, thanks????” “Excellent article.” “Excellent article, thanks for sharing Graham.”

PART ONE: Business architecture concepts

An enterprise is a socio-technical entity that participates in and employs many activity systems. Each activity system has a pattern of behaving that is regular and repeatable enough to be modeled in terms of actors interacting in an orderly way.

You rely on countless such systems. Would you want to stand trial in a court that didn’t follow court procedures? board airplanes operated by people who didn’t follow the rules? loan money to a company that didn’t repay its loans as promised? or·play poker with people who ignore the laws of the game?

Many concepts used in modelling human activity systems are general to all activity systems. The basic concept is the atomic activity.

Atomic activity: a process that is not further decomposed. It is called an action in UML In human activity systems it is sometimes defined as a one-person, one-place one-time (OPOPOT) activity/

Other business architecture concepts group activities (be they atomic or composite) in various ways.

This article draws terms and concepts from several sources (including IAF, BIZBOK, ArchiMate and UML) into a coherent and consistent whole. The graphic below is adapted from one in TOGAF.

Diagram: A model of business architecture concepts

Required behaviors

Architects start from the aims of system sponsors and other stakeholders, which define the desired outcomes that emerge from business activity.

Aim: an outcome envisaged by an observer as desirable. It may be called a goal, objective or requirement.

Outcome (aka effect or result): a state change or output that activity causes or contributes to.

Service: a process performed for the benefit of an external actor. It is definable in a service contract that records its entry and exit conditions, including a result (output or state change) of value to the actor.

(The term value is used with various meanings. Here, the value delivered by a service to an actor might be expressed qualitatively or quantitatively, perhaps as the maximum price a customer is willing to pay, the gross benefit to the customer, or the net return to the customer.)

Process: a sequence of activities, triggered by an event, that terminates in a result (output or state change) of value to an actor. It may consume input, produce output, or change the state of a structure (a variable, a part, a resource of some kind).

Typically a service or process consumes inputs and produces outputs. ?

Input: an information or material object or product consumed by a system, supplied by some external actor(s).

Output (aka product): an information or material object or product provided by a system to some external actor(s). It changes the state of system environment.

Logical structures

Function: a group of activities that are cohesive in some way, and grouped for ease of understanding and assignment.

Capability: the ability of one or more actors or systems to perform one or more functions or activities.

Role: activities grouped for assignment to one or more actors.

Actors play roles in processes that advance the internal state of the system and produce outputs. The state is recorded in data.

Data Store: a memory holding encoded information.

Data flow: a message holding encoded information.

Data entity (aka digital twin): a representation of a thing or event of interest to a business.

Physical structures

Architects may do at least some social entity thinking. They may map logical functions, capabilities and roles to physical organization units and actors, who work in particular locations.

Actor: an individual that plays roles in the systems of interest.

The actors in the business architecture domain/layer of enterprise include anything that plays a role in a business process that creates or uses business data maintained by the enterprise. They can be machines (as in the Internet of Things), but usually they are human actors,

External actor: a sponsor or other stakeholder, and/or a player of customer, supplier, or user roles.

Organization unit: groups activities and/or actors for management.

Location: a place where business is done.

To make sense of a business, architects may catalog entity types of any kind mentioned above, and impose a hierarchy on that catalog.

Remarks

EA is terminology torture because some use the same term for a concept at every level of granularity, but others use different terms.

For example, processes are given names such as value stream, procedure, activity, action, use case, epic, user story, operation and method, and are represented in different kinds of diagram such as value stream diagrams, flowcharts, state charts and sequence diagrams.

You'll not find anything above that implies or requires data to be digitized. However, in practice, today, most business architecture is done in an IT-supported context.

At design time, architects use a variety of modeling techniques to model abstract activity systems. At run time, supervised by managers who keep thing in order, business actors instantiate abstract activity systems in real business operations that consume inputs, advance the state of the business, create business data and use it to produce outputs

EA is a never-ending battle to optimize and extend, standardize and integrate activity systems to the benefit of the business as a whole.

PART TWO: Business architecture hierarchies

To understand and manage a complex network, the common practice is to impose a hierarchy on it. A hierarchy is a one-to-many cascade that divides a whole into successively finer-grained parts, down to the level regarded as “atomic” parts or elements.

In reality, a business is a complex network of actors and activities. Systems thinker Donella Meadows wrote that the actors are the most concrete and tangible elements, the activities are harder to see, and the aims are even harder to see. Business architects make them visible by documenting hierarchies of actors, activities and aims.

This article discuses the theory behind what sources such as TOGAF, ArchiMate, BIZBOK say about using hierarchical structures to describe a business activity system. It discusses six hierarchies.

Aim hierarchy

The idea of imposing an aim hierarchy on a business can be seen in the management technique known as a “balanced score card”.

·???????Aim: a goal or objective for business activity.

·???????Aim hierarchy: a goal/objective cascade.

·???????Atomic aim: the desired result of an atomic activity.

Business directors and managers may assign aims to the whole business, or to a business unit, a business process, or a proposed business change. Architects look to identify all declared goals and objectives, and relate them to any declared mission and vision for the business. It is generally recommended that aims are defined in a way that Specific, Measurable, Actionable, Realistic and Timebound (SMART).

Service hierarchy

Services are activities external actors request a system to perform, as defined in a service contract,

·???????Service: an activity performed for a customer or client

·???????Service hierarchy: a service decomposed into shorter services.

·???????Atomic service: a bottom-level elementary service

For example, consider what your local garage offers by way of a “full service”. It is decomposable into smaller services such as replace worn tires, top up the oil, replace broken lights, test the exhaust emissions, etc.

Process hierarchy

The concept can be seen in the general practice of process decomposition, and the particular practice of value stream diagrams.

Process hierarchy

·???????Process: a sequence of activities within a system.

·???????Process decomposition: a hierarchy in which one activity in a higher process is detailed as a lower-level process.

·???????Atomic activity: a bottom-level elementary process.

Traditionally, process decomposition stops at the level of One Person One Place One Time (OPOPOT) activities, which may enabled or supported by one or more application use cases (aka services, epics or user stories).

Value stream hierarchy

The core end-to-end processes of a business are often called value streams. A value stream diagram presents a process informally, as a sequence of stages, with a list of activities in each stage.

·???????Value stream: a sequence of stages (coarse-grained activities).

·???????Value stream diagram: a hierarchy in which each stage is detailed as a list of finer-grained activities.

Value stream diagrams are a good way to represent end-to-end business processes at a high level of abstraction.

Other kinds of process diagram

A value chain diagram presents a simple overview of the activities in a company. It shows the highest-level functions, divides them between “core” and “support” functions. It usually presents the core functions in a sequence that resembles a value stream, but only in a very superficial way.

In material (rather than information) processing systems, a value stream map represents an end-to-end business process in which each successive activity step adds value to a material product. (This differs from a value stream diagram of the kind drawn above.)

Organization hierarchy

The organization structure imposed on human actors may also be called a management/reporting hierarchy.

·???????Organization unit: a managed group of actors

·???????Organization decomposition: a hierarchy of organization units.

·???????Human actor: a bottom-level elementary organization unit.

Why is it normal to impose a hierarchical management/reporting structure on the actors who perform business activities? First, because in a business with hundreds or thousands of employees, directors must limit the number of people who report to them. Also, it is natural for people who must work cohesively together in one location or functional area to be managed as a group, and be relatively distanced or decoupled from people who work in a different location or functional area.

From the top down, business directors and managers decompose and decouple large groups of human actors into smaller groups. From the bottom up, they cluster human actors, using some cohesion criteria, into a group under a manager. The cohesion criteria for grouping actors could be one or more of the following.

·???????An aim (goal or objective)

·???????A directive (principle or policy)

·???????A service or product type delivered

·???????A customer type served

·???????Knowledge or skills needed

·???????A set of data maintained,

·???????Other resources created or used

·???????A location where people work.

While the organization structure is important to enterprise and business architects, there are difficulties with using it as a basis for business architecture definition.

Commonly, organization structures are volatile. In response to changing conditions, changes in personnel, and lessons learned, business directors and managers restructure the organization, according to whichever cohesion criteria they think most effective, and other factors such as which managers they trust.

Another difficulty is that in large companies, the top-level division is often geographical, by location rather than function, which tends to work against the cross-organization brief of enterprise architects.

Given the somewhat arbitrary and volatile nature of the organization’s management structure, enterprise architects usually impose a more logical and stable hierarchy on the activities or abilities of a business.

Function hierarchy

A function hierarchy is commonly called a functional decomposition.

·???????Function: a cohesive group of activities within a system.

·???????Functional decomposition diagram: a hierarchy of functions.

·???????Atomic activity: a bottom-level elementary function.

The advice is to name a function as a gerund (word-ing), after its purpose, and not to tag “management” onto the end of the name. For example, Advertising goods. Accepting payments. Handling goods-in. Logistics. Bidding for contracts.

Purposes

Whereas a process model sequences essential activities in a business, a function hierarchy imposes merely groups them. The primary purposes of a function hierarchy are to help architects:

• Show the scope of a business, or a division thereof
• Highlight where problems and opportunities exist
• Highlight where changes are needed and/or planned
• Prioritise work to be done
• Categorize resources needed (especially data and applications)
• Facilitate impact analysis when changes are agreed.

A baseline function hierarchy defines the scope of what a business does now in a regular manner. A target hierarchy defines the scope of what ?the business could or should do.

Technique

Suppose you identify 300 atomic business functions or activities, such as buying, selling, shipping and delivering a product. In business operations, these activities are related in a network by the movement of information and materials. To simplify presentation and discussion you impose one or more hierarchies on them.

From the top down, you can separate functions that are loosely coupled, that is, performed by people in roles who exchange little or nothing by way of information and materials. Divide functions into successively narrower, finer-grained ones, until you reach the level you regard as elementary functions or atomic activities.

From the bottom up, you can successively group atomic activities two, three or four times, and so build hierarchical structure, or tree. You do this by clustering activities relate by one or more cohesion criteria, such as resources needed or goals met.

By iterating between top down analysis and bottom up synthesis, you can build a tree that is typically 3 or 4 levels deep,

Function forests

There are as many possible function hierarchies as there are different, valued, cohesion criteria. By using different criteria, you can build a forest of trees. Generally, the practice is to choose one as the primary hierarchy – the one that most business people best understand.

Having said that, different business directors, with differing interests or concerns may prefer different trees. I recall the CIO of a government agency saying they represented the different interests of 9 board members in 9 different hierarchies. They settled on one primary hierarchy for most purposes, but still, maintained the forest of trees for discussion with different directors.)

Three principles for hierarchical decomposition

The abstraction principle says a function hierarchy is decomposed to no more than 3 or 4 levels. Often, it can be shown on one page.

The strict hierarchy principle says no element is duplicated under different branches of a hierarchy. To achieve that, you must stop functional decomposition when you reach a common function, and document it separately, or else in a “common functions” leg of the hierarchy.

The consistency principle says function hierarchies and process models come together at the bottom level where atomic activities are defined.

In practice, it seems nobody has the time and resources to complete both functional and process decompositions; but still, the principle holds - every activity in a process should be locatable under a function - else the function hierarchy is incomplete.

How many atomic nodes?

Supposing the decomposition ratio in a hierarchy is 1-to-7, then two levels of decomposition lead to about 50 atomic nodes; three levels. about 350 atomic nodes and four levels, could be 2,500 atomic nodes.

You stop at any level you choose. Few decompose to a fourth level, but it depends on what you use the hierarchy to do. If you are using the hierarchy to analyze which activities create and use 1,000 data entities listed in your enterprise/business data catalog, then you might want a function hierarchy with 200 elementary functions.

If you are using the hierarchy to impose a meaningful structure on the content of your enterprise's 5,000 strong application portfolio, you might want a function hierarchy with 500 or more elementary functions.

Capability hierarchy

Almost everything said about function hierarchies can be said of capability maps.

Capability hierarchy

·???????Capability: a cohesive group of abilities within a system.

·???????Capability map: a hierarchy of capabilities.

·???????Atomic ability: the finest-grain ability to perform an activity or meet an aim.

A capability map is a diagram that represents the essential capabilities of a business in a hierarchical composition/decomposition structure.

Principles and lessons learned from decades of drawing function hierarchies and process models apply equally to capability hierarchies.

Following the abstraction principle: a capability map is decomposed to no more than 3 or 4 levels.

Following the strict hierarchy principle, no capability is duplicated under different branches of a capability hierarchy.

Following the consistency principle: capability maps and value streams come together at the bottom level where atomic abilities are required to perform atomic activities.

Mapping one hierarchy to another

A function or capability hierarchy is useful as an overview of a business, but even at a 3rd or 4th level of decomposition it doesn't tell us how the parts of that business interact in activities to produce desired outcomes. It does not define an activity system, or even imply the existence of one. It can, however, be associated with behavioral views that do define how its parts interact in processes.

Any two hierarchies may be different, similar, or exactly the same.

Homomorphic structures: the structures are similar, but not the same

Isomorphic structures: the structures are the same, every element and relationship in one structure corresponds to one in the other structure

Give two isomorphic hierarchies, although every element in one (such as a function) corresponds to every element in the other (say, the capability needed to perform that function), by virtue of composition and decomposition, elements in the two hierarchies are related to many-to-many..

Having said that, some methodologists impose arbitrary constraints on how the concepts in different hierarchies relate to each other. For example, they relate one capability to many functions, or one value stream to many processes.

Mapping functions to processes

Whereas a process orchestrates activities in a more or less formally-defined sequence, a function clusters activities using one or more cohesion criteria,

Diagram; Mapping activities to processes and functions

A function at the top level of composition may encapsulate one or more lower-level processes. And a process at the top level of composition may span one or more lower-level functions.

Mapping organization units to functions

In a “functional organization”, the organization structure matches the function hierarchy. In other cases, functions may be mapped to organization units in a matrix.

A function at the top level of composition may be performed in several organization units. And an organization unit at the top level of composition may perform many lower-level functions.

Mapping capabilities to value streams

Whereas value streams sequence activities into stages, capabilities impose a hierarchical structure on the abilities or resources needed to complete the activities in the value streams.

Diagram: Mapping activities to value streams and capabilities

An end-to-end value stream may require several lower-level capabilities. And a capability at the top-level of composition may perform one value stream.

Mapping functions to capabilities

Why does almost everything said above about activity hierarchies apply to ability hierarchies?

Given a list of 300 atomic functions or activities (such as buying, selling, shipping and delivering a product) it is always possible to define a corresponding list of 300 atomic capabilities or abilities (such as to buy, sell, ship or deliver a product).

Then, if you cluster the items in each list using the same cohesion criteria (say resources needed, or goals met), you will build two isomorphic hierarchical tree structures.

The trouble with “capability”

A business can be described at an abstract level in a model of functions and processes. A business can be described at an abstract level in a model of value streams and capabilities. The trouble is the terminology torture this has introduced into the world of business activity system modeling.

On the correspondence between function and capability

Although the concepts (function and capability) are different, the appearance and potential uses of the two hierarchical trees are the same.

Since a capability is the ability or wherewithal to do or achieve something, it is defined in 1-1 association with the something that is doable or achievable. When that something changes, the required capability changes.

There is much debate about the relationship between the capability and function concepts, because although the words have different meanings, it is always possible to map a function to a capability in a one-to-one correspondence. To perform a required activity (such as to play chess), you need the corresponding ability (chess playing). To perform the invoicing and payroll functions, you need the corresponding invoicing and payroll capabilities. One guru has presented “psychology safety” as target capability, for which it is perfectly reasonable to define a corresponding function called “psychology safety assurance”.

On the isomorphism of function and capability hierarchies

From the top down, if you subdivide functions and capabilities using different decoupling criteria, you will build different hierarchies. And from the bottom up, if you cluster activities and abilities using different cohesion criteria, you will build different hierarchies.

However, if you choose the same decoupling or cohesion criteria, you will get the same hierarchy. In other words, the function hierarchy and the capability hierarchy will be isomorphic. Their visual appearance and potential uses will be identical.

On attempts to draw a distinction

Over the years, business architects have proposed various ways to differentiate capability maps from functional decomposition diagrams.

Some say capabilities are target architecture, and functions are baseline architecture. This implies renaming capabilities as functions at the end of the baseline-to-target transformation,

Some say capabilities relate to strategic functions rather than tactical ones. However, you are free to make the same abstraction choice when modeling functions.

Some say capabilities relate to core functions rather than support ones. However, if your problems lie in high staff turnover and recruitment, then your strategy must address that support capability, whether it is in your capability map or not.

Some say functions are more numerous or fine-grained than capabilities. Yet the top of a function hierarchy is the same as the top of a capability hierarchy, and the same decomposition options are available to you.

In conclusion, the flexibility of the term “capability” is useful in conversation, but it is always in one-to-one correspondence with another business architecture concept, usually an activity or an aim, which means it adds no capability to the armoury of a business architect.

Remarks

Solution architects, working on specific projects, may not find a function hierarchy useful at all.

Should enterprise or business architects document all these hierarchies (to a 3rd or more level of decomposition) and relate elements in them?

Only where they have practical uses in mind.

Nobody can take in a three or four level function hierarchy all at once. EAs often post it on a wall. As they study different parts of the business, they grow increasingly comfortable they understand the business and how its parts integrate (or don't). They use the chart now and then to put some problem or requirement into context, and explain it to others. They also use it as a “shock and awe” diagram when newcomers ask what the business does or is able to do.

Can business data can be created and used by non-human business activities of interest?

Yes: in the Internet of Things,

Are all activities recorded?

No: social and material entities, containing human and mechanical actors, do more than we ever model, including eating and consuming electricity.

Where is the concept of an "Event"?

It may appear as the trigger of a Process; you can see Service as a subtype of Event; and curiously, Events can be recorded a Data Entities.

Is a business function or capability implemented?

Yes: in the sense that actors play roles that perform activities in the former, using abilities in the latter. But no in the sense that functions and capabilities are logical business components rather than physical actors.

Can you measure the success or failure of a function?

Yes by measuring atomic activities performed. For example, managers might want to know the average time for a function to complete any of its lower level functions, or the total volume of the lower level functions performed in a given time period.

Can you build a coherent meta model of all these concepts?

No, Since a value stream diagram represents a process, and a capability hierarchy can be isomorphic with a function hierarchy, if you try to build a coherent meta model in which these four terms are presented as distinct architectural entities, you end up drawing an incoherent mess of relationships, as you can see in at least on meta model of business architecture.

Further reading

This is one of several articles on business architecture

• Business architecture terms and concepts
• Business architecture hierarchies
• BA in EA: Slide Show
• More on "capability" in EA