From the Editor: Graham Berrisford from Avancier Ltd has provided us with a series of articles related to modelling of business systems. This is part 1. Have a read and let us know what you think in the comments section below.
Our kind of architect and system
“EA regards the enterprise as a system” TOGAF 9.
“Architecture descriptions are formal descriptions of a system.” ArchiMate 2.1
Enterprise architects see the enterprise as a system of business systems that can each be modelled in terms of roles and processes.
Our kind of architect is very unlike a building architect. Building architects model passive structures. Our architects model dynamic activity systems, where the primary requirement is for regular behaviours – repeatable processes that can be at least partly digitised – often human processes, sometimes mechanical processes, and mostly if not always information-dependent processes.
Our kind of architect is very unlike a mechanical engineer. Engineers model physical things, hardware, matter, forces and energy. Our architects model logical processes and data flows – roles and processes that create and use data – data that encodes information about entities and events that the business needs to monitor or direct.
The systems to be architected are islands of orderly behaviour. The solar system is an island of stable and orderly behaviour in the ever-unfolding process that is the universe. We can model its regular behaviour. A business system (a car production line, insurance claim processing) is an island of stable and orderly behaviour in the ever-unfolding history of an enterprise. We can model its regular behaviour.
What people say and do that is spontaneous, intellectual or creative may be mentioned in business system models, but only as a context for work that can be formalized and modelled in terms of regular event-driven behaviour. Enterprise architects are not sociologists. As Boulding suggested, in his 1956 paper on applying system theory to management science, business system architects do not model people; they model their assignments to roles.
Our kind of system is a formalised social system. Social systems are composed of actors who communicate and perform activities according to messages received and memories retained. Business systems are social systems in which roles are formalised, messages are formalised in data flows, memories are formalised in data stores and activities are performed in response to discrete events.
Our kind of architects plan changes to this kind of system. Enterprise architects do this at a more strategic and abstract level. Solution architects do it a more tactical and detailed level.
Enterprise and solution architects don’t build airplanes, develop new drugs, design production lines, dig holes in roads or make movies. They do strive to optimise and integrate business roles and process through the better use of business information created by those roles and processes. They don’t innovate in the fields of mechanical engineering, bio-chemistry or the creative arts. They do look for new opportunities to digitise and integrate roles and processes, and exploit information collected.
The need for such enterprise architecture is not new, and it will never go away.
In short, enterprise architects don’t model everything a business is or does. They do focus on where the physical (manual, mechanical, material) world connects to the logical information world. On roles and processes that create or use information in the course of delivering business products and services. And on enhancing business operations by integrating information created and used across an enterprise.
The need for a controlled vocabulary
How does a business system formalize a social system? Inter-actor transactions are formalized by defining what actions a message can trigger, and by agreeing the contents of messages conveyed and memories retained. To formalise and integrate behaviour, parties must agree the meanings of symbols they create and use in messages and memories. This applies equally to people working in operational systems and architects modelling those systems.
Natural language is loose and ambiguous. The words we use to describe things are verbal encodings of fuzzy mental models. The English language is said to contain over a quarter of a million words. Often, different words have the same meaning, and one word has several meanings. Ambiguous terms in architecture frameworks include “service”, “function” and “interface”.
Take this example:
“Jeeves provided butler services. His role definition identified service types to be provided: receive guests, direct the serving of meals, polish the silver and perform various personal services. He completed countless service instances, from start to end. More broadly speaking, service was his function, his role. During his service as a butler, his service was exemplary, his function was valued, his role was vital to the well-being of his client.”
Is “service” a process type, a transient process instance, a persistent function or a role with responsibility for a variety of process types and instances? How does it differ from a “function” or “role”? This doesn’t trouble us in everyday discussion. But professional specification of business systems is a different matter. If the graphical symbols in a system modelling language merely represent words as people use them naturally, then the modelling language will be as large, loose and ambiguous as natural language.
We don’t naturally use words in a logical and disciplined way. Yet that is exactly what we strive to do when describing formalised systems that are be built, deployed and used by others. Professional system architects need a controlled vocabulary. A language for describing business systems ought to differentiate system element types (like service, function and interface) rigorously and unambiguously, so business system architects can use them in a consistent way and readily understand each other.
A professional system modelling language has to be more disciplined than natural language. It must help architects describe system actors and activities using a small number of symbols/words whose meaning is constrained – to avoid the looseness and ambiguity of natural language. Professionals may have to translate their models into whatever natural language untrained stakeholders use.
This table illustrates some challenges in mapping natural language phrases to generic system element types named in ArchiMate.
| Wording example 1 | Wording example 2 | Wording example 3 | Wording example 4 | Wording example 5 | Which system element type fits the example? |
| Complaint handling | Customer Relations Management | Transaction processing | Messaging | Network service | Service, Role or Function? |
| Complaint handler | CRM System | Transaction processor (CICS) | Message broker | Router (CISCO) | Role, Function, Component or Node? |
Agreeing a vocabulary is a huge challenge. Using variety of tools (which is necessary in practice) makes it harder. Agreement across all divisions of a global business is harder still. The state of the industry art is not good. UML is controlled but limited and difficult to understand. ArchiMate is only loosely controlled, and conceptually flaky. TOGAF is loose and inconsistent. The British Computer Society reference model is probably closest to what solution architects need, and it can be used to make ArchiMate more consistent and coherent, as we shall see.
Copyright Avancier Ltd 2016
There is a lot of important ground covered in this short article. However, it would be helpful to have had more of an introduction to UML, ArchiMate, and the BCS’s Reference Model since they are quickly mentioned at the end. That noted, I anticipate the next article(s) will clear this up? Regardless, as to the puzzle offered at the end of the article: It appears to me that one would have rules within an Architecture Definition Language about how to name different elements. We shouldn’t need to rely purely on intuition/logic.