Business architecture concepts
Natural language is messy. People who work together have to develop a consistent and coherent vocabulary for their domain of knowledge - a domain-specific language. EA emerged out of attempts to address the cross-domain nature of business information, and the need to standardise and/or integrate information systems.
Sadly, the history of EA itself (and the IT industry) is one of uncontrolled vocabulary, featuring neologisms, the abuse of existing words to mean something different, and changing meanings over time. Simple words like object, process, component, service, function, interface , and last but not least, capability mean very different things in different contexts
We'd rather have a consistent and coherent language for BA in EA. We want each term to be defined clearly, and in a way specific enough not to be interpreted variously, or confused with another term.
The aim of this article is not dictate how you use terms. Nor is it to promote or deprecate TOGAF or ArchiMate. It is only to ease the terminology torture by helping you to make coherent and consistent sense of their vocabularies, and so, understand BA in EA concepts. You can choose the words you use.
On capability (part one)
In everday language, a capability is the ability, possessed by an entity, to perform an activity and/or meet an aim. For example: suppose the aim of a piano player is to produce sounds you enjoy. You cannot see the actor's capability directly. You can watch the actor in action, and hear the output produced. You only know if the piano player has the desired capability when you hear the output. Generally, a capability only becomes visible when you observe outputs and/or state changes produced by activities.
We should distinguish the everyday capabilities addressed in BA and EA from the special kinds of capability discussed in management science.
Teece differentiates this senior management capability from "ordinary capabilities" which "may not provide competitive differentiation at the firm level, but are economically important".
There is an ocean of organisation theory out there. Academics of the industrial age (Chandller, Porter, Deming, Beer, Drucker etc) still appear in MBA courses. And many thinkers speak of seeking "competitive advantage" in some function or capability.
Below are five scales of capability, which are somewhat but not entirely related.
The first three scales may be related, but you might decide to compete by
EAs are rarely accountable for business direction and profit or loss, though they likely inform and advise business directors who are. And the academic tradition EAs draw from is general system theory rather than organization theory.
In the practice of EA, a capability map includes all capabilities that exchange information (and might be better designed, standardised or integrated) including ordinary ones. It serves as a taxonomy of all busines activities enabled and supported by creating and using digital data. It helps people understand a business and classify its resources, but should not be oversold.
Things to know about BA in EA concepts
A goal of enterprise architecture (EA) is to help people understand and manage a business, and change it effectively. In EA, business architects focus on business activity systems that are or can be digitized to some extent, on roles played by human and computer actors in business processes that create and use data.
An activity system can be specified by its boundary, its way of behaving and its state, as recorded in data. It is a collection of system elements including
Note the following points.
There is no fixed level of granularity for a concept.
Why - aims - can be hierarchically composed and decomposed as you like.
How - activities - can be composed and decomposed as you like. A process can be very long or very short.
What - actors, abilities, products, services, components, resources, can be composed and decomposed as you like. A capability or function can be very large or very small.
There are many-to-many relationships between concepts
You can force a 1-1 correspondences between two concepts; you can define the aim of one activity, or the capability needed for one process.
But since these concepts can be hierarchically decomposed, generally, there are many-to-many relationships. One coarse-grained capability may enable several short processes. One long process (or value stream) may need several fine-grained capabilities.
There is terminology torture
There is jealous guarding of existing vocabularies. Over the years, gurus have developed different vocabularies for EA and BA concepts. When their 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.
For example, is "capability" a purely logical concept? Or does it embrace the physical human and technology resources needed to perform an activity or to meet an aim?
Relating elements of one kind in a hierarchical composition
A business activity system might be defined as a network of actors performing a network of activities to meet strategic and tactical aims. How to make sense of it and manage it?
To understand or manage a network, people impose a hierarchy on it. There are hierarchies in cosmology (solar system, galaxy, galaxy cluster), in biology (organelle, cell, organ, organism), in society (individual, family, tribe), and in software (class, component, container, application).
There is no absolute level of detail. One person’s function is another’s fine-grained activity. There is no absolute start or end. Broaden a system, and an end-to-end process becomes an internal procedure. Elaborate one activity, and that too becomes a procedure.
Relating elements of different kinds in grids or matrices
Given any two hierarchies, you may map elements in one to elements in the other 1 to 1. For example you might declare "Manufacture more efficiently than competitors" to be the aim of the "Manufacturing" function.
Or else, you can use matrices to record many-to-many relationships. In an aim/activity matrix you might show 1 aim is met by 1 activity, or 1 high level aim is met by N lower level activities, or 1 high level activity meets N lower level aims.
Interpreting BA in TOGAF
Both ArchiMate and TOGAF inherit some concepts and techniques from structured business analysis as it was taught the 1980s and 90s, but do not clearly explain them.
Function and organisation hierarchies
An organisation hierarchy imposes a management/reporting structure over the atomic actors of a business. A function hierarchy imposes a more logical structure over atomic activities. One function may span several units in the organization hierarchy, and vice-versa,
So, a function hierarchy groups business activities in a logical and stable way, independent of the organization/management structure. If the two hierarchies correspond, then you have what is called a "functional organisation", but still the hierarchies are independent.
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. If you do, then functions in one hierarchy will map N:N to functions in another.
A function does not normally correspond to a process, but if your cohesion criterion for activities is "sequenced", then it could be.
Functions and processes
A function hierarchy says nothing about how a business accomplishes its activities. The how is to be found in process flow models, and in the mapping of roles and resources to the activities in those processes.
Structured business analysis features two ways of looking at the same atomic business activities.
ArchiMate says: “There is a potential many-to-many relation between business processes and business functions.” meaning that:
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.
Functions and capabilities
You can define free-standing functions or capabilities at any level of composition you choose. But it is normal in EA to arrange one or both in a hierarchy.
Some build a capability hierarchy that corresponds to a function hierarchy in which only selected activities are included - perhaps
Others use the term function or capability loosely to describe a combination of people, processes, technologies/resources needed or used to perform an activities or meet aims.
In practice, since a capability is, or corresponds to, a function of interest to business planners, a capability hierarchy corresponds to one of the many possible function hierarchies you could draw.
Where does capability fit in a meta model that already includes aims (goals and objectives) and activities (functions, processes)? If the difference lies in diagramming notations, that is cosmetic rather than conceptual. See "More on capabilties (part two)" below.
Value streams and processes
Some hierarchically decompose the activities of a system along these lines
Again, the scope of the system of interest may be broad or narrow. 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 and abstract.
On the structure/behavior distinction
ArchiMate is underpinned by a generic meta model that divides EA concepts in two ways. It distinguishes
Before retuning to ArchiMate, let me define some terms in a general way
The definitions below are edited from the ArchiMate standard (“4.3 Summary of Structure and Behavior Elements”) and the interpretation in brackets is 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." Much as in the TOGAF grid below.
The generic meta model presumes a layer is 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.
领英推荐
More on the active 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:
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.
Three graphics you may find helpful
The challenge for teaching EA/BA is to define a meta model that
In teaching TOGAF, I map a selection of its BA artefacts to a meta model as shown below.
When teaching EA/BA concepts in my own courses for enterprise and solution architects, I sometimes use this graphic.
Below, one more diagram for your interest, including concepts related to the motivation, direction and work to be done.
More on capabilities (part two)
"Capability" has a curious status in the armed forces, where regular operations are training to provide a nation with capabilities they hope never to use.
Let me speak more generally.
Again, systems and system elements can be composed or decomposed to whatever level you see fit. At any level of granularity, you may define the system of interest externally (in terms of aims, inputs and outputs) and internally (in terms of actors, activities, capabilities and system state data).
Unfortunately, EA/BA sources do use the term capability with several meanings. Some use it as a synonym for a management theory concept called "core competency" (look it up in Wikipedia). Some see it as an abstract concept; for others, it embraces the resources need to realize that concept.
ArchiMate use the term as an ability, or as an activity to meet an aim.
Differentiating functions from capabilities
People have proposed several function / capability distinctions, including:
In natural language, the concepts can be aligned 1-1, since to perform an activity you need the corresponding ability, and to perform a function, you need the corresponding capability.
The plain fact is, most of the function hierarchies and capability hierarchies that people draw are indistinguishable in their appearance and possible uses.
What purpose does one serve that does not? If the difference lies in diagramming notations, that is cosmetic rather than conceptual, so to include both concepts in the same meta model is a recipe for confusion.
Both functional decomposition diagrams and capability maps are hierarchies that start at the top of the enterprise. The first/topmost level of decomposition descends to nodes at exactly the same level of granularity (unless one hierarchy omits activity covered in the other, which begs other questions).
Given the top-most node of any hierarchy is the same enterprise, a functional decomposition diagram and a capability map look the same and have the same potential uses. Nodes in either logical hierarchy can be mapped to activities in processes, or stages in value streams, or organization units, or anything else you fancy.
Of course, you can differentiate the two hierarchies by using different criteria to cluster lower level nodes under a higher node. But why would you - since to perform an activity, you need the corresponding ability? Some methodologists do force a distinction between the two hierarchies, but there isn't a universal agreement on how and why.
Generally, a capability is, or corresponds to, a function of interest to business planners. Which is to say that a capability hierarchy corresponds to one of the many possible function hierarchies you could draw.
Impact of this on an EA/BA meta model
Top level capabilities or functions (Marketing, Sales, Delivery, etc.) require a combination of people, processes, and technologies. In a meta model, the people, processes and technologies are separate from, and related directly or indirectly to, the functions or capabilities.
Whatever you do to differentiate them, including both function and capability is almost certain to make a mess of your EA/BA meta model, bearing in mind that aims, activities, abilities and actors are all recursively composable and decomposable, and relatable to each other at any level you choose.
Simplifying the TOGAF meta model
Our enterprise and solution architecture training, which has been updated for 2024, explains what TOGAF doesn’t.
Here is a reduced and tidier version of the TOGAF meta model, with a suggested mapping to ArchiMate. It relates core concepts (or "architectural entities") as they might relate in system description artefacts you produce.
More could be added to the meta model above.
Q) Why is a logical data component shown with an interface symbol?
In the service-oriented tradition of TOGAF, building blocks / logical components are defined by interfaces that list the services they provide. A logical data component might be defined as a logical data model, or by an API.
Q) Why is data shown below applications?
Data does appear - higher in the inputs and outputs of business and application service contracts (recorded in TOGAF's requirement specification). And data entities are related to business functions in a matrix.
The pragmatic arrangement of element in the diagram minimises the spaghetti when (in a TOGAF course) I position the entities on a flip chart, later adding a relationship every time we find one in a TOGAF artefact.
TOGAF and BIZBOK
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
On EA arithmetic
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.
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?
What is the alternative? The single enterprise-wide database that Zachman envisaged in the 1980s? If you built that database today, the pressure to implement a "microservices architecture" would divide it up. The resulting application communication diagram would be as much or even more complex, with the concomitant 4Ds (duplications, disintegrities, delays and difficulties with cross-organization data analysis).?For more on the 4Ds, read my article on microservices. Now, what numbers are found in an EA repository?
On EA repositories
"We populated [our repository] in 2007 with about 10,000+ functions and services. It took 1,500 people to populate it fully." Anon.
Using a meta model to teach EA/BA concepts is one thing. Populating an EA repository, maintaining it, and using it to good effect are other things. Should we be talking about two meta models, drawn for different purposes, to show:
Surely, a maintainable EA repository structure is considerably simpler than the meta models in the TOGAF and ArchiMate standards might be read to imply?
Further reading
This is one of several related articles.
See also
And on BA
Also
Reduce your organization's complexity with ?????? ?????? ???????????? for a customer-driven ???????????????????? ?????????????? ???????????????????? ????????????????: a unique proposition for sustainable service delivery
9 个月[Q8] In your Q "Why is data shown below applications?", you don't answer the question. TOGAF images seem to say that there is no hierarchy: the BDAT stack is changed to [B]-[A+D]-[T]. Please explain.
Reduce your organization's complexity with ?????? ?????? ???????????? for a customer-driven ???????????????????? ?????????????? ???????????????????? ????????????????: a unique proposition for sustainable service delivery
9 个月[Q7] And *if* service is a unit of behavior, and activity is an element of behavior, how can an application provide services? Can an application component produce activities and, therefore, behavior? I always thought an application is dead as a doornail. Referring to your example of the meeting room as a service, the application is the facility (structure) and making it available to someone is the service.
Reduce your organization's complexity with ?????? ?????? ???????????? for a customer-driven ???????????????????? ?????????????? ???????????????????? ????????????????: a unique proposition for sustainable service delivery
9 个月[Q6] You refer to [service] as a unit of behavior: "a meeting room is a facility, and the provision of that meeting room, for a period of time, is a service". Let's try the case of that meeting room: when the user has rented the room for the duration of half a year and used it for a month, is there any unit of behavior of the provider involved? I think the provider could be dead for weeks without the consumer ever noticing it in terms of the experienced service... Does a service only exist when it is *actively* delivered or even only when it is *actively* consumed? Doesn't that falsify the definition of 'service' as an activity?
Reduce your organization's complexity with ?????? ?????? ???????????? for a customer-driven ???????????????????? ?????????????? ???????????????????? ????????????????: a unique proposition for sustainable service delivery
9 个月[Q5] You do the same when you treat functions and processes as if they are in the same dimension, composed of the same resources. Either they are or they are not. But which is it?
Reduce your organization's complexity with ?????? ?????? ???????????? for a customer-driven ???????????????????? ?????????????? ???????????????????? ????????????????: a unique proposition for sustainable service delivery
9 个月[Q4] The same question when you say [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 and abstract.] This agian looks like a conflict of dimensions.