Enterprise business architecture

"Love this"

Just as we want a consistent and coherent language for business operations, so, we want the same for business architecture. Sadly, different sources use terms like process, component, service, function, interface, and capability to mean different things in different contexts.

There is terminology torture. Over the years, gurus have developed different vocabularies for the same concepts, and jealously guard their vocabularies. When vocabularies are merged, people are reluctant to give up a term they already use, or rather, give up their preferred pairing of term and concept.

The aim of this article is not to dictate how you use terms. It neither promotes nor deprecates standards its mentions, like TOGAF or ArchiMate. The aim is only to ease the terminology torture by helping you to make coherent and consistent sense of their vocabularies, and so, understand business architecture concepts.

Contents: Business activity system elements. On business capabilities. On value streams and processes. Structured analysis. Service orientation. A business motivation model. Enterprise archiecture concepts in TOGAF.

Business activity system elements

Enterprise business architects help people to understand, manage and change a business effectively. They focus on business activity systems that are or can be digitized to some extent, and on roles played by human and computer actors in business processes that create and use data. They look to standardize, integrate and extend the use of information systems.

A business activity system can be specified by its boundary (its inputs and outputs), its way of behaving and its state - as recorded in data. System elements include actors that interact in activities that create and use data, to meet given aims.

The SFIA standard says the business architect role involves

• interpreting business drivers, and the goals they lead to,
• assessing capabilities, identifying required changes to them, and
• describing relationships between business system elements.

The business activity system elements mentioned in SFIA are

• services?- which encapsulate activities performed by a business or division thereof,
• processes?- which sequence activities performed to complete services,
• data/information?entities - which are created and used by activities,
• people - actors who play?roles in activities,
• organizations?- which employ people,
• technologies - which support and enable activities, and
• external entities - customers, suppliers and others who request and/or benefit from activities.

These business system elements may be related in concept graph of this kind.

Before exploring some business architecture elements in more depth, let me speak briefly to ways that descriptions of them can be abstracted, elaborated or related.

Generally, if you take an element of one type (say entity, service, process, function or capability) and

• abstract it to more general supertype, or specialise it into subtypes, or
• compose it with others into a larger whole, or decompose it into parts

the result is still of the same type (entity, service, process, function or capability).

One element can be composed and decomposed in a 1-N hierarchy

To understand or manage a network, people often impose a hierarchy on it. A business activity system is a network of actors performing a network of activities to meet a mix strategic and tactical aims. The aims, activities and actors can all be arranged under a hierarchical structure.

Why - aims, goals, objectives - can be hierarchically composed and decomposed as you like. Managers sometimes define a hierarchy of aims. Some use different terms for the same concept at different levels of a hierarchy. For example, some divide aims into higher level goals, lower level objectives, and requirements for architecture work.

How - activities, abilities, services and processes - can be composed and decomposed as you like. A capability or function can be very large or very small. A process can be very long or very short.

What - actors, components, data structures and resources, can be composed and decomposed as you like. Managers normally impose an organization hierarchy on actors. This division of labor has cons as well as pros. It can hinder cross-organizational processes, it can lead to duplication. The structure can be volatile - partly due to office politics.

Elements of the same and different kinds can be related N-N in matrices and diagrams

You may choose to draw a 1-1 correspondences between two elements. For example, you can define the aim of an activity or a function, or the capability needed for a process. You might declare "Manufacture more efficiently than competitors" to be the aim of the "Manufacturing" function or capability.

However, in general, since elements can be hierarchically decomposed, there are many-to-many relationships between elements, which you can record using matrices and diagrams. For example: One coarse-grained capability may be needed to peform several short processes. Conversely, one end-to-end process (aka value stream) may need several fine-grained capabilities.

On business capabilities

There is an ocean of organization theory out there. MBA courses still teach what academics of the industrial age (Chandler, Porter, Deming, Beer, Drucker etc) said decades ago. And the term business capability has long been used variously.

In everyday language, a capability is the ability, possessed by an entity, to perform an activity and/or meet an aim. ArchiMate defines capability in much the same way.

• "an ability that an active structure element possesses, realized by various elements (people, processes, systems, and so on)"
• "classified as behavior.. what the enterprise can do?(or will do), typically aimed at achieving some goal."

If these definitions of a capability sound to you like definitions of a business function, you’d be right. Since to perform any activity you need the corresponding ability, and to perform any business function you need the corresponding capability.

Sources use the term capability with various meanings. Some use it as a synonym for "core competency" (see Wikipedia). Some see it as an abstract concept; others include the physical resources need to realize that concept. And some distinguish senior management capabiilities from operational capabilities, along the lines below.

Senior management capabilities

Capability theory. Alfred Chandler (1960s) developed a “capability” theory of business enterprises, in studying large industrial enterprises. (This article says modern enterprises are less well explained and appreciated using Chandler’s ideas.)

Strategic capability is defined in this article as "the mix of knowledge, skills, tools, processes and behaviors that combine to deliver organizational objectives… delivering on business strategy to gain competitive advantage in the market."

Note: you might decide to compete either by providing the best services or products, or else, by reducing the variety or quality of services or products - to reduce prices.

Institutional capability is defined in this article as "heuristics, skills and routines that underpin successful institutional strategies", and may be "proprietary firm-specific".

Dynamic capability is defined by Teece as sensing, seizing and transforming. In other words

• a) assessing threats, opportunities, and customer needs,
• b) mobilizating resources to address them and capture value, and
• c) ongoing organizational renewal.

Operational capabilities

Turning to the regular operations of a business, the broadest capabilities can be decomposed into narrower ones. Some use different terms at five or six levels of decomposition, perhaps along these lines

• capabilities (perhaps subdivided)
• services (perhaps subdivided)
• functions (perhaps subdivided).

But this is to make arbitrary naming distinctions, since the scope of an enterprise or system of interest may be broad or narrow. What looks like a broad capability in a small business can look like a narrow function in a large and variegated business.

A capability map is a hierarchical decomposition of broad capabilities into narrower ones. It helps people understand the scope of a business and identify their place in it. It serves as a taxonomical structure for classifying other EA elements (activities, roles, data, applications).

Below are some dichotomies and scales on which capabilities may be placed

• Core to Support (after Porter).
• Competitive advantage to Ordinary (after Teece)
• Best practics to Worst practice
• Flexible to Rigid.

In the armed forces

The "capability" concept has a curious status in the armed forces, where regular operations are training to provide a nation with capabilities they hope never to use.

There is now

• a Unified Profile for older armed forces architecture frameworks (DoDAF and MODAF)
• a Unified Architecture Framework? (UAF?) implemented as a UML profile on top of SysML.

UAF has been described as "a complicated framework that makes enterprise architecture even harder."?I don't recommend it for general use.

Differentiating functions from capabilities

Traditionally, business architects define the scope an enterprise by building a logical organization hierarchy, called a functional decomposition diagram, or a capability map.

Some use the term function or capability to describe a combination of people, processes, and technologies/resources used to perform particular activities or meet particular aims. That is, in effect, to equate a function or capability with a system.

Others use the term function or capability to mean a more abstract concept, a cluster of related activities or abilities.

• A "functional decomposition diagram" is a tree structure that clusters atomic activities into successively larger functions until you reach a single composite function.
• A "capability map" is a tree structure that clusters atomic abilities into successively larger capabilities until you reach a single composite capability.

The nodes in either tree structure can be mapped to activities in processes, or stages in value streams, or organization units, or anything else you fancy.

You can use any cohesion criteria you like to cluster atomic activities into functions, or abilities. into capabilities. But since you can't perform an activity without the corresponding ability, it is always possible to align the two tree structures. And in common practice, the two hierarchies are indistinguishable in their appearance and possible uses.

Having said that, people have proposed several ways to distinguish functions from capabilities. Some propose.

• functions are fine-grained capabilities, or vice-versa.
• functions are logical, capabilities correspond to organization units, or vice-versa

Some build a capability map that is smaller than a function hierarchy because only selected activities/abilities are included - perhaps

• activities/abilities for which competitive advantage is sought, or
• core (rather than support) activities/abilities, or
• future/desired (rather than baseline) activities/abilities.

So, you can differentiate the two hierarchies, but there isn't a universal agreement on how or why.

On value streams and processes

Much as the broadest capabilities and functions of a business can be decomposed into narrower ones, so the processes of a business can be decomposed into shorter ones. Some use different terms at different levels of decomposition, perhaps along these lines

• value streams
• processes
• procedures
• work instructions.

But this is to make arbitrary naming distinctions. Much as the scope of a system of interest may be broad or narrow, the scope of a process of interest may be long or short. What looks like an end-to-end value stream in a narrow system of interest can look like a short procedure if you widen the scope of the system.

Structured analysis

Both ArchiMate and TOGAF inherit the principles of structured business analysis, which features two views of the same atomic business activities.

• Structural view: a functional decomposition imposes a hierarchical structure over activities.
• Behavioral view: processes arrange the same activities in sequences.

Notice that if you are "completer", then atomic activities will appear as both elementary processes in process flow diagrams and elementary functions in a functional decomposition hierarchy. The function hierarchy does not show how a business accomplishes its activities. The how is shown in process flow models, and the mapping of activities to roles and resources.

ArchiMate says: “There is a potential many-to-many relation between business processes and business functions.” meaning that:

• One end-to-end process may span several finer-grained functions.
• One coarse-grained function may encapsulate several short processes.

Many other terms can be seen as synonyms or subtypes of process, notably: procedure, operation, method, work instruction, use case, user story and value stream. And even what look like atomic activities or actions may be further decomposed and defined as a process.

A function does not normally correspond to a process, but if your cohesion criterion for activities is "sequenced", then it could be.

The cohesion criteria (perhaps goals, resources, roles or skills) for clustering atomic activities and lower level functions into higher level functions are up to you. Most build only one function hierarchy, but you can build any number of them.

An organization hierarchy imposes a management/reporting structure over the actors of a business. Functions may be mapped to organization units 1-1 in a so-called "functional organization" structure, or else N-N, as may be shown in a function/organization matrix.

Service-orientation

• "Service-orientation: viewing an enterprise, system, or building block in terms of services provided and consumed." (TOGAF).

Both ArchiMate and TOGAF inherit the core principles of the service-oriented architecture movement. Not only do they distinguish structures (things that persist), from behaviors (things that happen over time), but they also separate the external and internal views of structures and behaviors.

• Components are encapsulated by interfaces - which expose services to clients
• Processes are encapsulated by services - defined declaratively.

The definitions below are edited from the ArchiMate standard (“4.3 Summary of Structure and Behavior Elements”). The interpretation in brackets are mine.

ArchiMate chapter 1.2 says the modeling language "uses service-orientation to distinguish and relate [enterprise architecture layers] and uses realization relationships to relate concrete elements to more abstract elements across these layers."

As in TOGAF, the enterprise architecture layers are contain:

• Business components, which provide services to external entities
• Application components, which provide services to business users
• Technology/Infrastructure components, which provide services to application components

Each layer is a system, is bounded, is encapsulated behind contracts for the services it exposes, which are found in and accessed via interfaces.

You may also model processes in the environment outside a system of interest, but the implication of the generic meta model is that those processes are internal to a wider or higher system, which can also be encapsulated - in theory at least.

Terms and concepts

Client/Server relationship: a relationship between parties or actors in which the two roles are service provider (a?server) and service requester and/or consumer (a user or client of services).

Service: an act performed for another, defined declaratively as a service requester or consumer sees it. A unit of behavior that is exposed by a system or subsystem, and produces an outcome of value to an external entity. It is triggered by?an event - an input or a state change. It delivers a result – an output or a state change. It may give access to a resource (such as a room for hire). It may access a data store to create/update data or read/retrieve data.

Interface: a menu of services provided to external entities (customers, suppliers and observers).?It can be point of access where services are exposed and accessible by service requesters. It defines the inputs and outputs (matter, forces, energy or information) that flow across a system’s boundary.

More on the structure / behavior distinction

It is said that the structure/behavior distinction reflects the noun/verb distinction. One convention is to distinguish functions and processes thus:

• Name functions as gerunds (Marketing, Selling, Accounting, Testing)
• Name processes as imperatives (Advertise, Sell, Deliver, Test).

However, natural language is flexible: an “Order” can be viewed as a structural entity or an event. A “Marriage” can be seen as an event, an entity recorded on a certificate, or a process lasting years.

The ArchiMate standard points out that functions can be seen as either structural or behavioural, since a function hierarchy is a structural view of activities, and a process is a behavioral view of the same activities.

Interfaces are classified as structural, yet they also group behaviors. If you define a Function by the services it offers to other Functions, then it may be seen as an Interface definition.

By the way, don't confuse a resource or facility (a structure) with a service (a behavior). E.g., a meeting room is a facility. The provision of that meeting room, for a period of time, is a service. The facility and the service are different things, which are in 1-1 correspondence only during the period of time the service takes place.

A business motivation model

Below, a diagram including concepts related to the motivation, direction and work to be done.

Enterprise architecture elements in TOGAF

The diagram below relates TOGAF's core architectural entities in a simplified version of the TOGAF meta model, with the addition of ArchiMate symbols.

You could, in addition, relate application components to technology components, relate business drivers, goals and objectives to business services, functions or organization units, and relate locations to any kind of physical structure.

Note the use of ArchiMate's interface symbol for logical application, technology and data components. A logical data component could instead be modeled by logical data model.

Business architecture artifacts in TOGAF

A challenge is to define a concept graph that helps people to understand business architecture concepts includes a judicious subset of the countless possible relationships between concepts, and shows which concepts appear in which artefacts.

Another challenge is to fit capability in a concept graph that already includes aims (goals and objectives) and activities (functions, processes), If the difference between capabilities and functions lies in diagramming notations, that is cosmetic rather than conceptual; so, to include both concepts in the same concept graph is a recipe for confusion.

In teaching TOGAF, I map a selection of its BA artefacts to concepts as shown below.

Mapping BIZBOK to TOGAF

Most EA and BA frameworks are confused or confusing at some point. And trying to merge one framework with another makes things worse. The Open Group have inserted BizBok concepts (Capability and Value Stream) into both TOGAF and ArchiMate standards. Sadly, this has made both standards less coherent – more conceptually messy.

To align the two standards is a bigger challenge than people like to admit. Since BIZBOK doesn't apply the structured business analysis principles underpinning TOGAF, introducing "capability" and "value stream" into TOGAF has given its users a hodgepodge of concepts, terms and techniques.

Assuming their glossary definitions mean what they say, this table draws some mappings, exact or near enough, between BIZBOK and TOGAF.

Remarks

Using a concept graph to teach business architecture is one thing. Populating an EA repository, maintaining it, and using it to good effect is another thing.

• “When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind.” Lord Kelvin

Why is EA arithmetic so rarely discussed? How much of any EA meta model reasonably be populated in an EA repository? Consider the 3-level capability map or function hierarchy of a traditional bank.

• The capability/function hierarchy has 7 7 7 = 350 elementary units.
• Each capability/function has 2 business apps = 700 apps.
• Each app pair is connected by 3 data flows = 1,000 data flows.
• Each app data store has 50 tables = 35,000 tables (cf. data entities).

Now imagine drawing the application communication diagram. Does it look like a mess? Or is that mess the result of the system integration that EA promised to deliver?

• "We populated [our repository] in 2007 with about 10,000+ functions and services. It took 1,500 people to populate it fully." Anon.

Surely, a maintainable EA repository structure is considerably simpler than the concept graphs in this article might be read to imply?

Related articles

This article is included with 12 others in “A Systems Thinker’s View of Enterprise Architecture”, a book made available to community-tier members of Cyb3rSyn Labs.? You can subscribe here: www.cyb3rsyn.com.