Architecture and Design - Nine Abstraction Varieties
One of more than 300 papers at http://avancier.website. Copyright Graham Berrisford. Last updated 24/08/2017 23:13
Grady Booch has written that all architecture is design, but not all design is architecture. What does he mean?
This paper is mainly about ways to abstract an enterprise architecture from more detailed design.
Contents
Abstraction
of behaviors from structures
Abstraction
by encapsulation of system behaviour, structure and data
Abstraction
by separation of parallel views
Abstraction
by delegation from clients to servers
Abstraction
by generalisation of features
Abstraction
by idealisation of features
Abstraction
of data from applications
A few points to get us started.
An “architect” (from the Greek for “master builder”) is typically defined as one who designs and supervises of the construction of a building.
And “architecture” is defined as the art of designing and constructing buildings, or the style in which a building is designed and constructed.
But discussing building architecture doesn't get us far, since EA is about activity systems rather than visible concrete structures.
The “buildings” are business activity systems in which humans and computers play roles in the performance of processes.
Business systems
“Enterprise architecture… regards the enterprise as a system or system of systems.” TOGAF 9.1
Business systems can be seen as formalised social systems, in which the principal actors are humans and information/communication technologies.
EA is about why, when, where and how business roles and processes create, store and use information.
It defines business activity systems by typifying inputs, outputs, actors and activities that capture and use business information.
These systems are unlike concrete buildings in several ways, for one, they are recursively composable and decomposable.
Architecture
The meaning of
“architecture” in relation to business systems has been a cause of debate from
the outset.
John Zachman did not introduce the term in this context; the term was already in common use.
“In 1978, Zachman stated: “architecture is a term that is rapidly losing meaning".
https://www.zachman.com/resources/ea-articles-reference/321-the-zachman-framework-for-architecture-revisited-by-paul-hermans
Here, an architecture is an abstract model of
an operational system (which reifies or
realises the architecture).
Obviously, documented models are more stable and shareable than mental models.
Professional architects can’t and don’t keep their architectures in their heads.
Zachman put it thus.
“If… you can’t remember everything… you have
to write it down (Architecture).”
“If you are not building primitive models, you are not doing Architecture. You are doing implementations.”
Zachman proposed
maintaining architectural documentation at 5 levels of abstraction from
operational systems and in “excruciating detail”.
This elaborate proposal
has (so far, at least) proved impractical.
Nevertheless, architecture
is more abstract than detailed design.
Abstraction
Abstraction as two general meanings:
1. Abstraction from reality (physical matter
and energy) to description of it.
2. Abstraction of description - from more
detailed descriptions/models to less detailed ones, sometimes called
architectures.
This table illustrates the first - abstraction from reality to description of it.
|
Abstraction in system theory |
|
System descriptions/models <create and
use> <abstract
from> System describers <observe and envisage
> Systems in operation |
The second definition – abstraction of description - masks many varieties of abstraction.
Zachman proposed architects should abstract from detailed designs in one particular way called idealisation
In practice, architect use several kinds of abstraction at once, both consciously and unconsciously, when describing an operational system.
They may abstract in these ways more by artistic intuition than by scientific reasoning, but skilled architects do consciously manipulate them.
When you are done reading this paper, for more on abstraction, read “Abstraction in TOGAF”.
“The principal heuristic
innovation of the systems approach is what may be called ‘reduction to dynamics’
as contrasted with ‘reduction to components’ ” Laszlo and Krippner.
"Cybernetics does not ask
"what is this thing?" but ''what does it do?" It is thus
essentially functional and behaviouristic.” Ross Ashby.
Building architects design physical and persistent structures - concrete buildings.
Business systems feature logical and transient behaviours – they can be seen as formalised social activity systems.
· Passive thing: a structure that is described as being acted on or in.
· Active thing: a structure that is described as acting on other things; it performs behaviours.
· Activity system: a collection of structural entities (e.g. planets) that perform orderly behaviours (e.g. orbits).
In operation, social and business systems feature actors (structures) performing activities (behaviours).
A social system may be designed with the requirement that the activities should satisfy given actors.
However, mainstream EA is about designing and planning of changes to business systems.
In most businesses, the requirement is for actors to perform given activities to provide required services.
What a client requires of a business system are the products of activities, rather than the structures needed to perform those behaviours.
An architect that describes only internal structures fails to describe what matters to owners and customers of an enterprise.
Behaviour before
structure
ArchiMate 3.0 says “it is often useful to start with the behaviors that the system must perform”.
Architects designing business activity system must clarify and define:
1. Goals, desired outcomes (collecting problems, requirements and other motivational/contextual information).
2. Outputs to enable the goals to be met (that is, the products/services required of the system to be built).
3. Inputs needed to make the outputs (these resources include inputs taken from stores).
4. Processes/rules to transform inputs into outputs using resources (that is, behaviours that will deliver the required products/services).
5. Actors to perform the processes (that is, active structures that will perform the required behaviours).
6. Technologies and other resources needed by actors to do the work.
Of course, a huge amount of the behaviour in an enterprise is very human indeed.
Enterprises depend on intellectual, intuitive and creative abilities, social skills and empathetic behaviour, and on manual labouring skills.
The human actors – who play roles in a business system - need management and motivation.
It is important to acknowledge that enterprise architects do not describe or design all that matters in an enterprise.
In the 1980s, the work of architects was divided into four domains.
The aims and activities of architecture and design may be divided also into levels of detail, along the lines in this table.
|
Domain Level |
Business |
Data/Information |
Applications |
Infrastructure technology |
|
Enterprise architecture |
Business roles &
processes, standardisation,
integration and road maps |
Business data standardisation,
integration and road maps |
Business application
portfolio standardisation,
integration and road maps |
Platform technology
portfolio standardisation,
integration and road maps |
|
Solution architecture |
Outline design of a
solution’s required processes |
Outline design of a
solution’s data architecture |
Outline design of a
solution’s application architecture |
Outline design of a
solution’s IT production environment |
|
Detailed design |
Detailed design of processes & use cases |
Detailed design of data stores and flows |
Detailed design of software architecture |
Detailed design of an IT production environment |
Most other kinds of abstraction (below) can be seen as hiding details in one way or another.
Again, system descriptions are unlike building drawings in that they are recursively composable and decomposable.
Architects usually stop decomposing a system well before reaching atomic elements.
So what they describe are usually coarse-grained compositions.
Other people (designers or builders, perhaps even system actors) are left to define finer-grained elements.
Architects may decompose a large system (even an enterprise) from the top-down by dividing it into successively smaller subsystems (units, functions, capabilities, components).
But they rarely describe the lowest conceivable level – atomic, indivisible - actors and components.
They may decompose a long business process (perhaps a “value stream”) from the top-down by dividing it into successively shorter process steps.
But they almost never describe the lowest conceivable level – atomic, indivisible – actions performed by actors and components.
Architects are sometimes taught to stop system decomposition around the third level, but all is relative.
The granularity of a third level element is variable, since it depends on the scope being described.
An architectural description of a human society likely ignores the internal architecture of a human body.
An architectural description of a human body likely ignores the internal architecture of a human cell.
An architectural description of a human cell likely ignores the internal architecture of a molecule.
Encapsulation (below) can be seen as a kind of abstraction by composition.
Architects are taught to define systems from out to in, starting with the input/output boundary.
First, they define the external view of a system - hiding details of internal behaviours and structures.
ArchiMate 3.0 distinguishes “an external (black-box, abstracting from the contents of the box) and internal (white-box) view is common in systems design.
The external view depicts what the system has to do for its environment, while the internal view depicts how it does this.”
ArchiMate classifies these ideas as shown in the table below.
|
ArchiMate |
Behaviour
elements |
Active
structure elements |
|
External view |
Services |
Interfaces |
|
Internal view |
Processes |
Actors/Components |
Services are discrete behaviours that clients can request of a system.
Services typically consume and produce data flows (they can also consume and deliver materials).
Their input and output data can be defined declaratively in service contracts that encapsulate (hide) internal process flows and components.
Architects define systems, “building blocks” and “components” by defining the services required of them.
They may go on to group services into interfaces.
An interface is a collection of services that are made
available to specific clients.
An interface encapsulates the internal actors/components and processes that implement or realise services.
External before internal
You can “reverse engineer” interface specifications from
existing, physical, operational systems and components.
But a basic principle of system design is to define the external view before the internal processes and structures.
E.g. ArchiMate (see 20016 reference) defines service accessible via interfaces in an external view.
It defines process and components, to deliver those services, in an internal view.
Similarly, TOGAF (2011 reference) defines required services in an Architecture Requirements Specification.
It then defines the internal process and components to deliver those services in the Architecture Definition Document.
Architects commonly define parallel views of a system, each view omitting details found in the other views.
The architecture of a system may abstract by hiding other systems which run alongside it and interact with it.
E.g. an architectural description of the human nervous system may hide the blood system, lymph system, etc.
Delegation (below) can be seen as a kind of abstraction by separation of parallel views.
Architects often simplify a complex system by organising it into a hierarchy of client and server layers.
Clients abstract from servers by delegation - by requesting services without knowledge of the servers’ internal structure or workings.
This idea is used in network architectures, software architectures and business architectures.
The primary EA domains are often presented as client-server layers, as in the table below.
|
Domain |
Required behaviours |
Logical structures |
Physical structures |
|
Business |
Business
Services |
Functions, Roles |
Organisation
Units, Actors |
|
Applications |
IS or Application
Services |
Logical
Application Components, Interfaces |
Physical
Application Components |
|
Technologies |
Platform or
Technology Services |
Logical
Technology Components, Interfaces |
Physical
Technology Components |
Business before
technology
Many speak of business and IT, without reference to IS.
Some then misguidedly classify IS under the IT heading rather than under the business heading.
But business processes and data are not owned by IT departments or IT services providers.
The business is responsible for ensuring it captures the data it needs, and maintains it sufficiently well for successful use.
Enterprise architects have to understand what information technologies can do.
Architects must attend to modern technologies and standards, if they are to digitise business operations that create and use information.
They may recognise opportunities that arise from technology innovations.
However, the technology is only there to capture and provide business data, and automate business rules.
And the data and rules are there to enable the provision of services by business roles and processes.
So architects ought to start from the business services, processes and roles, and the data they need.
Architects are asked to comply with generic reference models, design patterns, principles and standards.
The “buy before build” principle steers architects in the direction of deploying generic systems and components.
They look for what is general to an industry (say telecoms), general to a function (say accounting) and common to all (say, email).
The generic components may be coarse-grained (packaged applications) or fine-grained (atomic data types).
Architects should specialise only where there is a significant advantage to the enterprise in having different or unique business systems.
Central government departments or agencies tend to have unique business systems.
Local governments are more likely to share business systems and components thereof.
Abstraction by idealisation (below) can be seen as a special kind of generalisation.
Confusingly, the term “logical” is used by architects to mean abstract in any or all the ways above.
However, in the tradition of systems analysis and design methods, it means abstraction by idealisation.
The process of idealisation is commonly described as moving
stepwise from real to physical to logical to conceptual.
ArchiMate 3.0 distinguishes between “conceptual, logical, and physical abstraction levels;
this corresponds with business objects, data objects, and artifacts, and the realization relationships between them.”
Architects draw
various other distinctions between conceptual, logical and physical.
In the tradition of architecture
frameworks, the logical level is usually considered to be technology
vendor-neutral.
Logical architecture definitions often define system components in a vendor-independent way.
They are rarely if ever technology
independent.
Logical before physical
You can “reverse engineer” a logical system specification from an existing, physical, operational system.
E.g. The modern OData standard protocol enables you retrieve a logical data model from a remote web data store.
But the natural design sequence is logical definition before physical definition.
E.g. TOGAF promotes logical (technology vendor-neutral) system specification.
It defines logical process, data and application components in the Architecture Definition Document.
It then proceeds to define physical components to realise those logical components.
When you are done reading this paper, for more on abstraction, especially idealisation, read “Abstraction in TOGAF”.
Business systems retain memories; they store input data for future use.
Business system architects must address the location(s), confidentiality, integrity and availability of stored data.
Data before
applications
You can purchase a COTS application with little or no prior analysis of its I/O data flows and data store.
The risk is that the application’s user interface, APIs and persistent data store will not fit your needs.
So, it is usually recommended you consider data architecture before applications architecture.
Business data can now include what can be transmitted to and captured from social media.
You may consider using social media applications to reach potential customers and gather information about them.
But first, you have to think about what it is you want to say, and what you want to learn.
Business data can now include what can be transmitted to and captured from the Internet of Things.
You may consider using monitoring devices to collect “big data”.
But first, you have to understand what data can be collected, and find a good use for it.
Some descriptions of a reality model that reality more accurately or completely than others.
Some architectures of an operational business system model that system more accurately or completely than others.
In short:
· an architect/architecture steers and constrains more detailed designers/designs.
· an architecture is a relatively abstract design for how a new thing is to be built, or description of an existing thing
· an architecture is a model that can take several forms - mental, documented and physical.
· in its most definitive form, an architecture is documented for approval by clients and for use by designers and builders working at a lower level of abstraction.
This paper outlines nine ways to abstract an architecture from more detailed design.
For more on the nine abstraction varieties below read “Abstraction in TOGAF”.
· Abstraction of behaviour from structure
· Abstraction from detail
· Abstraction by composition
· Abstraction by encapsulation of system behaviour and structure
· Abstraction by separation of parallel views
· Abstraction by delegation from clients to servers
· Abstraction by generalisation of features
· Abstraction by idealisation of features
· Abstraction of data from applications
For a list of EA
sources and standards history, read “EA and Digital Enterprise”.
Enterprise
architects deal with business systems that are under change control.
A change request is
first evaluated again a system’s description before permission is given to move
from version n to n+1.
Analysing the
impact of a requested change is facilitated by documented models.
Having
said that, few rely only on documented models when evaluating change requests
to a business system.
A building architect’s
drawing visibly corresponds to a real building – a change to one directly
corresponds to a change in the other.
A business
architect’s process models (for example) are more abstract and indirectly
related to reality.
So change requests
are evaluated also against the mental models held by the members of a change
advisory board (CAB).
Physical space, measurements and locations are central to building architecture.
They are side issues in much EA work.
How often does an EA specify the length, breadth, height, weight or position in space of an EA model element?
Building architects define components related in a persistent structure.
Their drawings show the shape and structure of physical things, their locations and abutments in physical space.
Every view they draw (of walls, doors, windows, floors, lift
shafts, plumbing, wiring etc.) corresponds visually to the physical reality.
By contrast, the buildings of interest to enterprise architects, the objects of design, are business activity systems.
These architects start by considering the business activities to be supported and enabled.
They draw views of business activities and software applications, but these views are not visibly like the things they represent.
Their drawings are abstractions, far removed from physical
materials and locations.
Enterprise architects define activities related in a
transient behaviours or process flows.
EAs rarely model physical human actors, but do model
their logical roles.
EAs might model physical organisation units, but
prefer to model logical function/capabilities.
EAs might position human roles or business
function/capabilities in specific geographic locations.
But they more likely map them to logical location types (say, home or data centre).
Do you include server-side IT architecture in EA?
In today's virtualised and cloud computing world, it
is difficult to map even server-side platform technologies to physical
locations.
People commonly confuse realisation and delegation relationships.
A butler does not realise his master; he serves his master by realising discrete service requests.
The opposite of realisation is idealisation; the opposite of delegation is serving.
This table distinguishes the two relationships.
|
View |
Client to server relationships |
Application to platform technology relationships |
|
Client view |
A client actor <delegates to> servers. |
An application <delegates to> platform
technologies. |
|
A
client role <is realised by> actors. (The
actors perform actions that are the responsibility of that role.) |
A
coded application <is realised by> executables. (Executables
perform actions that are the responsibility of that application.) |
|
|
Server view |
A
server <serves> clients that make service requests. |
A
platform technology <serves> applications that make platform service
requests. |
|
A
server <realises> service requests made by clients. (The
server does not realise the clients themselves.) |
A
platform technology <realises> service requests made by applications. (It
does not realise the applications themselves.) |
Other sources also place architecture above – at a higher level of abstraction than - detailed design.
“Architecture design is more abstract than
detailed design.
“Detailed design focuses on …
implementation details.
“The ultimate purpose is to create a system that fulfills
a set of valid requirements.”
http://sce.uhcl.edu/whiteta/sdp/architectureDesignAndDetailedDesign.html
And here are some graphical images that place architecture above detailed design.
http://sce.uhcl.edu/whiteta/sdp/architectureDesignAndDetailedDesign.png
http://www.atl.external.lmco.com/projects/rassp/RASSP_legacy/appnotes/HWSW/images/HWSW3_1.gif
https://melsatar.files.wordpress.com/2012/03/v-shaped.png?w=584
https://sinergique.files.wordpress.com/2013/10/v-model-illustration.jpg
