EA vision and reality

"Great summary" ?"Great thanks" "I love this" "Interesting" "Really good." "Thank you for posting" "You are a true system thinker".

Repeatability is a mark of science. Different cosmologists will produce similar definitions of the solar system Different software engineers will produce similar architectural descriptions of a given software system.

A vision of "enterprise architecture" is that different architects will produce similar architectural descriptions of a working enterprise. The reality is that moving the discipline from art to science is a challenge. Where to look for help?

TOGAF says: "The TOGAF Standard considers the enterprise as a system" and an architecture expresses "the fundamental concepts or properties of a system.” The implication is that enterprise architects should employ a systems thinking approach to describing the operations of an enterprise in terms of how:

• entities (actors, components or variables) interact in
• processes (activities, services, or operations) to produce
• effects (results, outputs or state changes), with or without
• purposes (aims, goals or intents).

This article elaborates on the vision that an enterprise can be seen as one system. It builds ontological concept graphs for EA and BA. It is compatible with newest versions of TOGAF and ArchiMate.

The ontological concept graphs have improved the consistency and coherence of my EA and BA classes. I hope you find them helpful, not too abstract, and not too detailed.

Having said that, the reality of what architects can document and maintain in an EA repository falls well short of the vision. This article steps back to consider what might be a minimum viable EA.

Contents: The EA vision.. A business architecture ontology. A business-oriented EA ontology. EA layers, levels, and domains. Service orientation in EA and BA.. A minimal viable EA. Remarks. Related articles.

Foundational principles

First, let me point to some foundational principles. You may not fully appreciate them now, but later, they will help you to resolve the terminology torture in enterrprise architecture

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.

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 EA vision

The enterprise as a system

TOGAF says

• "The TOGAF Standard considers the enterprise as a system"
• "Architecture: The fundamental concepts or properties of a system.“

The implication is that EA employs a systems thinking approach to describe how

• entities (actors, components or variables) interact in
• processes (activities, services, or operations) to produce
• effects (results, outputs or state changes), to meet
• purposes (aims, goals or intents).

The different schools of systems thinking use different terms for the same concept, and one term for different concepts. TOGAF and BIZBOK, by collating contributions from multiple authors and sources, are inconsistent in their use of terms like "process", "service", "function", "capability” and “interface”

The enterprise systems of interest here are event-driven activity systems that are:

• open - consume inputs and produce outputs and
• dynamic - change state in response to inputs and/or time events.

Such a system may be defined internally, by how elements interact to produce the effects of interest, and externally, by an interface that defines inputs and outputs of interest.

Inside such a system, actors interact in regular activities, using resources, to meet aims, by advancing the state of the system and transforming inputs into required outputs.

EA as a product of the information age

A brief history of civilization

• The birth of civilization: Sumerians recorded transactions on clay tablets.
• 1800s the industrial age: making and delivering goods, accompanied by information flows
• 1960s the information age: businesses began digitizing the information they collect, record and transmit.
• 1970s enterprise architecture: emerged to help us take the opportunities, and resolve the problems of the information age.

Some architects focus on material structures and processes (buildings, bridges, motor cycles production lines, and shelving systems). Enterprise architects focus on information processing, on the behavior of actors in activity systems that create and use information.

A business architecture ontology

Discussions of enterprise architecture (EA) and business architecture (BA) are terminology torture. Different schools use different terms for the same concept (synonyms), and one term for different concepts (homonyms).

When editors of EA/BA frameworks such as TOGAF and BIZBOK collate contributions from multiple authors and sources, they introduce inconsistencies both within and between frameworks. For example, they use terms "process", "service", "function" and "capability" with various meanings. Can we do better? Yes.

Business activity system elements

Business archiecture is centered on modelling business activity systems. The SFIA standard says the role involves

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

The business activity system elements include:

• 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 a concept graph - and onotology - of this kind. Note that organizations and people can include ones in the external environment.

EA documentation records entities of the types in the ontology above; it relates them in the ways shown, and other ways to be discussed.

The ontology is primarily to help architects understand the concepts, and to create coherent, consistent documentation, which is understandable by somebody else. In the absence of other evidence, you should assume that in a relationship is:

• Many to many (N:N). e.g. One organization may employ several people, and one person may work for several organisations. Generally, naming concepts in the plural (as a set rather than a type) makes it easier form grammatically sound predicate statements.
• Optional: e.g. Not every person is employed by an organization.

Also, a concept can relate to itself in a recursive relationship. In the graph above, the looped arrow may represent a hierarchy of organization units, and/or a network of related organizations. In practice, almost every element might be related to others of the same kind - in a hierarchical or network structure - but I wanted to keep this ontology simple.

Is this concept graph a schema for an EA repository? Possibly. But I doubt any enterprise can document more than a fraction of what could conceivably be documented using an ontology of this kind. I'll return to that point at the end.

Drawing longer, direct, relationships

The central and basic element of an activity system is the atomic activity (aka "action" in UML.), which is presumed to be self-evident, meaning it can be performed without further elaboration or explanation.

Process flows, capability hierarchies and role definitions can all be seen as higher level structures that group atomic activities in some way. So, in a complete business architecture model, you would expect an atomic activity to:

• appear in at least one Process flow,
• be assignable to at least one Capability and/or Role.

However, very few attempt to complete a comprehensive model of all the system elements in an enterprise. People document what they need to understand and explain things, especially things relevant to some proposed change. E.g., you might draw a direct relationship between Processes and the Technologies they use - skipping over and not documenting the central Activity element.

To draw every possible relationship between elements makes an ontology difficult to read, not to mention impossible to populate and maintain in an EA repository. The convention is to show the essential “short” relationships, and omit longer ones derivable by following short ones.

Documenting views of an enterprise architecture

For analysis or design purposes, and discussion with stakeholders, architects construct partial views or models of the EA, often called artefacts.

An artefact is a model or view that relates entities (of the same or different types) to each other in hierarchy, matrix or network structure - in a.

• a hierarchical catalogue or diagram (such as a Capability Map), or
• a grid or matrix (such as a Process / Technology matrix), or
• a network diagram (such as a Communication diagram or Logical Data Model).

A business-oriented EA ontology

Again, in defining business activity systems, terms are used with different meanings in different BA schools. Below is a consistent and coherent vocabulary, as compatible with TOGAF (version 10) and ArchiMate as I can make it.

Behavioral system elements

• Process: a sequence of activities (sub processes) that runs from start to end, and delivers a result or effect of value. (A value stream diagram is nice informal way to represent a high-level end-to-end process; at lower levels people speak of processes and use cases).
• Service: an act performed by one entity for another. Many identify a service with the result or product of a process, but here it is a behavior or process - defined declaratively in a service contract without reference to any sequence of activities.

Structural system elements

• Organisation unit: a group of actors clustered under a manager.
• Function - as in a functional decomposition: an atomic activity, or a group of activities clustered logically using some cohesion criteria.
• Capability - as in a capability map: an atomic ability, or a group of abilities clustered logically using some cohesion criteria.

Whether you build a hierarchy of functions, or capabilities, or combine them in one hierarchy, depends on which school of EA or BA you were schooled in.

Functional decomposition diagrams and capability maps are logical, hierarchical, organization structures. They look the same. They have the same possible uses. Many have declared a way to differentiate one from the other. But although abilities and activities are different concepts, to perform an activity, you need the corresponding ability. So, function and capability hierarchies can always be brought into correspondence.

Some call higher, coarse-grained, nodes "capabilities", and call lower, fine-grained nodes "functions". You can do that if you want, but it doesn't make sense in the context of a wider BA ontology.

The ontological network below includes more Business Architecture concepts. Some might be recorded in an identity management system. Notice that People (in the first graph) has been generalised to Actors, to allow that a machine or AI agent can play a Role.

Can we relate Goals to Organization units? Yes. However, a decades-old tradition in EA is to leave the organization's management structure to managers, and relate Goals to more stable, logical, Function or Capabilitues

Should we relate Goals and Services to Processes or Functions? Either or both.

Why do Function and Capability occupy the same place? Because they have the same relationships to other concepts. A function or capability hierarchy is a logical organization structure that clusters activities, or abilities to perform them, but does not sequence them.

How is Capability defined? You can define the concept however you choose. For consistency ask: Does every stage in a Value Stream, and every Activity in a Process flow, need at least one Capability? If not, you might want to extend the Capability hierarchy.

Should we distinguish Business objects from Data objects"? ArchiMate does that. You can do it. However, duplicating definitions (say, for Customer, Product, Asset, or Employee objects) is a hostage to fortune, and implies the need to maintain a relationship between them. So, I don't want to imply you must document data entities twice,.

Why no "Locations"? Since everything in the ontologu exists or happens somewhere, drawing relationships to a Location concept makes a mess of the concept graph. (By the way, Location is less significant than it used to be, thanks to the growth of mobile computing for end users and cloud computing for servers.)

What about "Resources"? The term is a vague generalisation. It might include Actors, Data stores, Applications, and Technologies. But EA teams are rarely concerned with more concrete resources such as buildings, vehicles, machines, except where they are recorded as Data Entities.

What is the vocabulary behind the concepts in the concept graph? Our certification courses include a vocabulary, not far removed from the ones in TOGAF and ArchiMate.

EA layers, levels, and domains

How to position digital information systems in a picture of an enterprise as a system?

Architecture layers

Both TOGAF and ArchiMate see the enterprise as a layered system architecture in which components (some call "building blocks") provide and require services.

• External entities, including customers, require services from
• Business functions and roles, which provide services to external entities, interact by invoking services from each other, and require services from...
• Application components, which provide services to the layer above, interact by invoking services from each other, and require services from...
• Technology (aka platform) components, which provide services to the layer above, and interact by invoking services from each other.

In each layer, the services have non-functional qualities such as duration, throughput, availability, and security.

Architecture levels

Again, although EA regards the enterprise as one coherent system, in reality, an enterprise is an infinitely rich and complex social entity, in which a mess of business systems may be observed. In a large enteprise there may be:

• enterprise architects - thinking at a strategic and portolio level
• solution architects - thinking about a particular problem/solution/system
• software architects - thinking about the internal structure of an application

An enterprise architect takes a cross-organizational or portfolio level view of business functions, processes, applications, data or technology resources. (In a large organization, segment architects do this for a division of the enterprise). Enterprise architects produce road maps for changes at a strategic level, with a view to standardization and integration of systems.

A segment architect does the same for a division or domain of an enterprise.

A solution architect shapes and steers the high level design of a particular system in response to particular problems or needs. With or without governance by enterprise architects, they elaborate a subset of the enterprise architecture. They engage with and coordinate software and other technical architects.

Often, a solution is a centred on an application to bought, hired or built. A solution architect is concerned with the external view of the application (use cases, UIs, APIs, integration with other applications), data maintained, design patterns for integration and deployment, and with the meeting of non-functional requirements. Where a solution requires software development, the solution architect may shape that, or delegate detailed design to a software architect

A software architect details the internal structure and behavior of an application, and its deployment to platform technologies. Other kinds of technical architect strive to ensure information technologies work effectively and efficiently, are deployed and available to users across a secure network.

Architecture domains (perspectives or views)

The PRISM report of 1986 presented Business, Data, Applications and Technology (or Infrastructure) as the four primary views or perspectives of a distributed system's architecture. They are commonly referred to as the BDAT domains. They are found in each level of architecture.

Architects look at all levels of architecture from all views or perspectives. The grid below shows how enterprise architecture spans business, IS and IT architecture, and positions common artefacts in the cells of a level/domain matrix. Note that one architecture term may span two domains. And business architecture may include or exclude data.

Note that security is a "cross-cutting concern". Security architects address what is needed in each layer and domain to ensure the confidentiality, availability and integrity (CIA) of the data produced and consumed and produced during the operations of the enterprise as a system.

Service orientation in EA and BA

• "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 terms service and interface are used ambiguously in EA and BA (and in the IT industry). In this article, the terms are defined thus

• Service: a discrete act performed by a system or component. It is triggered by a request or event and may deliver desired effects of various kinds, including information, material products or state changes (and even emotions).
• Interface: a collection of acts provided or required by a system or component, a menu of services, sometimes with instructions for how to invoke those services.

Today, IAF, TOGAF and ArchiMate encourage architects to envision the enterprise as a network of components or building blocks that are a) defined externally by the services they provide and require, and b) arranged in layers that are also defined by the services they provide and require.

The practice, an ontology of the kind above cannot show every posssible relationship between concepts.

Why no "Data services"? Data entities and stores are "passive structures". Data is created and used by application services (aka use cases).

Where are I/O data flows? You can document input and output messages in services contracts.

Where are TOGAF's logical components? Logical components are technology-independent requirement specifications for physical components. You might expressing them in the form interface definitions associated with components.

EA reality

The enterprise as a mess of systems

EA is about design, planning and managing changes to systems of the kind above.

A business evolves - both informally in an adhoc way and through designed and planned changes. EA and BA are about the latter, about changing business activity systems under change control, sometimes in strategic or transformational way.

• "Enterprise Architecture is needed to manage complexity when change involves multiple systems with multiple inter-dependencies." (TOGAF)

The big idea, that EA envisages an enterprise as one holistic (joined up) activity system is easy to say, rarely well explained, and difficult to realise, because in reality, the enterprise is a mess of more or less related activity systems.

A minimal viable EA?

The article above finishes with a service-oriented EA ontology, shows how EA and BA concepts are related in general. It helps architects to document systems of interest. Architects present views (in diagrams and matrices) that typically relate instances of one, two or three of the concepts. The onotological concept graph helps them understand the concepts, and create coherent, consistent documentation, which is understandable by others.

However, I don't think there is a universal or right EA ontology. You might turn any ontology into a repository schema. If you define the entity types in this graph as tables, along with tables that link them, then populate those tables with data, you can generate reports showing views of the EA.

That doesn't mean you must do it, or populate it completely and "in excruciating detail", as Zachman used to propose. I doubt any enterprise can document more than a fraction of what could conceivably be documented using an ontology of this kind.

Many enterprises find it challenging to populate and maintain an EA repository. In practice, why do architects fall short of documenting all the concepts and relationships in shown in the ontological concept graphs above?

• First, in reality, the enterprise is a mess of systems. Whereas EA envisages an enterprise as one holistic (joined up) activity system, in practice, actors play roles in systems large and small, nested and overlapping, more and less connected, ?synchronized and out of step, cooperative and competitive. Typically, a system has its own domain-specific language.
• Second, most projects tackle a small part of the bigger picture. Whereas EA battles to improve, standardize, integrate and extend an enterprise's many systems to make them more efficient and effective as whole, in practice it proceeds project by project, system by system.
• Third, the sheer number of system elements in an enterprise is beyond what the typical team of architects can document and maintain. A large enterprise might have a portfolio of 1,000 applications and a data dictonary of 100,000 data item types.

So, if you are starting out to build an EA repository, what can you reasonably aim to document? This simple EA concept graph spans and relates the four primary architecture domains of Business, Data, Applications and Technology (BDAT).

In building your own EA repository, best start with some idea of what you want know, such as: Q) Which Applications access the Data Stores that contain the Customer Data Entity?

Why is "Data entity" in the business layer? Because business operations create and use data regardless of IT.

The size or granularity of a "data entity" and the completeness of a data entity catalogue is up to you. In practice, enterprise data architects may focus on "kernel entities", especially those that appear in more than one data store, such as Customer, Product Type, Employee and Asset. ArchiMate users might call them "business objects".

Remarks

Other difficulties include multiple ways to model the same concept, and trade offs between aims.

Multiple ways to model communications

We have at least three ways of recording a relationship between two communicating components. We can record

• individual data flows that pass between components (as in TOGAF's "interface catalog").
• more abstract "dependency" or "serves" relationships between components, which may each cover several discrete data flows.
• input/output data flows in the definitions of "service contracts".

While this gives architects the freedom to record interactions between components as best fits the situation, it does lead to some inconsistency of approach and vocabulary.

Trade offs between aims

"The art of progress is to preserve order amid change and to preserve change amid order." Alfred North Whitehead

It is often said that EA aims to

• De-duplicate business systems
• Facilitate strategic/global change
• Increase efficiency and effectiveness
• Standardize processes
• Integrate processes

However, there is always a tension between the pressures on a busness to centralize and to decentralize its operations, and all is trade offs, since

• De-duplication may facilitate global change, but hinder local change
• Increasing flexibility tends to decrease efficiency
• Standardization may simplify, yet reduce effectiveness
• Integration tends to complicate and increase dependencies.

The challenge is to find the optimal balance.

The enterprise as complex social entity

There is a limit to how far an enterprise can be described as one system, or even a collection of systems. Human actors often act outside their roles in any describable system. A human organization, like any other social entity, is more than any system we can model it as instantiating or realizing.

The actors in a human organization perform some regular activities. They also act in ad hoc ways, in creative or innovative ways. And they sometimes break the rules of a given system to meet some aim, be it personal, or an agreed goal of the enterprise.

Since an enterprise is more than any system, or set of systems we can abstract from it, business managers must attend also to other things, including the procurement and maintenance of physical resources, and the motivation and management of human resources.

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.