The primacy of
external and behavioural views (over internal and structural views)
This page is published under the terms of the licence summarized in the footnote.
Abstract
"Enterprise architecture ...regards the enterprise as a system or system of systems." TOGAF 9.1
OK, but where do we start in describing a system? Usually, with the external and behavioural views.
Inside a system, the structure/components of a system are more visible than behaviour/processes.
However, the principle of encapsulation tell us to hide internal structure/components
All we see from outside are the effects of behaviour/processes.
The precedence of behaviour/processes over structure/components is a principle of system theory that was declared long ago.
"It is the pervading law of all things
organic and inorganic, of all things physical and metaphysical, of all things
human and all things superhuman, of all true manifestations of the head, of the
heart, of the soul, that the life is recognizable in its expression, that form
ever follows function. This is the law." Architect, Louis Sullivan,1896.
Contents
Enterprise
system elements (recap)
The
primacy of external and behavioural views in popular methods
P.S.
Addressing challenges to the premise.
The word “architect” comes from the Greek “master builder”.
In enterprise and solution architecture frameworks, the
buildings are “systems”.
“Enterprise
architecture regards the enterprise as a system, or system of systems” (TOGAF)
“Architecture descriptions are formal
descriptions of a system.” (ArchiMate® 2.1 Specification, The Open Group.)
The ArchiMate standard employs a conceptual framework of
generic system elements, presented in a simplified form below.
|
After ArchiMate |
Behavioural view What a system does |
Structural view What a system is made of |
|
External view requirements of external entities |
Events/Services each encapsulates
the processing of
a discrete event or service request. |
Interfaces each is a facade
that presents services for access
by clients |
|
Internal view the workings of the system |
Processes each comprises one
or more activities that respond
to an event or meet a service request. |
Components/Roles each is a subsystem
that performs
process steps. |
One architect’s whole system is another’s component in a
wider system, so this model can be applied at any level of granularity.
There is a fifth kind of system element: an object: an item
or structure that is used, moved or made by processes.
For some, the architect’s primary, even only, job is to organise components in a structure.
There may be no process definition; only some hierarchical and/or network structure diagrams.
This can make sense if the task is to deploy components that are known to perform the required processes.
However, EA is about more than defining structures in which components are organised or deployed.
The systems of interest contain behavioural elements (processes) as well as structural elements (components or roles).
It is not easy see behaviour in the ISO 42010 standard definition of architecture.
§3.2): “architecture〈system〉fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.”
It is possible to misread the definition as meaning the “elements” are the components of an enduring organisation structure.
But in fact, elements include processes as well.
Most system stakeholders are primarily concerned about the system’s behaviour, rather than its structure.
The care about inputs and outputs, products and services provided.
They care more about the processes performed than the structural organisation of components (unless, of course, the stakeholders are human components playing roles within the system).
You can “refactor” the internal structure of a system’s components, with no effect on the inputs, outputs or external entities.
Provided the system executes processes that produce required outputs from inputs, then the system occupies the same space in its environment.
All popular methods and modelling languages include external and behavioural views of a system's architecture.
I would go so far as to say they prioritise those external and behavioural views over organisation structures.
Early analysis and design methods, (HIPO, SADT etc.) combined step-wise refinement (system decomposition) with out-to-in design.
At each successive level of system decomposition, they defined the external view before turning to the internal view.
Separately, Michael A Jackson taught software designers to start with the external view of a system, to define the input and output data structures, and from there to divide the system into cooperating components.
In OO, the first-drawn architectural model of a system is the use case diagram, which divides a system into processes that external actors engage with.
Each use case is documented using a template that records the goal, the external behaviour (service offered) and processes (main and alternative paths) that actors engage in.
The progression from this external behavioural view to internal behaviour and structure is considered to be a refinement or detailed design step.
Given requirements in the form of a use case, the designer may draw UML sequence diagrams to show how components will cooperate in each process path.
In refining the sequence diagrams, the system’s components are decomposed to the level of classes for OO program design.
The UML class diagram is a structural model, but it shows only the external methods (operation signatures) of each class.
The progression from an external method to the detail of the internal method body (the operation) is a further refinement or implementation step.
A raison detre of The Open Group is open specification of systems, as in the POSIX and UNIX standards.
They form open system specifications by defining the services a system should offer, leaving the structural organisation of components to the manufacturers.
TOGAF versions 1 to 7 were based on the Open Group’s principle that architects should abstract from a system’s components to define the services delivered (in a Technical Reference Model).
TOGAF defines a system primarily by the services delivered, rather than the internal components.
It says: "The Business Architecture describes the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment." Notice the services come first.
TOGAF defines a service as:
“an element of behavior that provides specific functionality in response to requests from actors or other services.”
“A logical representation of a repeatable business activity, has a specified outcome... is self-contained, is a ‘‘black box’’ to its consumers.
E.g. check customer credit, provide weather data, consolidate drilling reports’’.
In phase A, TOGAF starts architecture definition by defining process-based business scenarios.
The first steps are to define a business process, the environment of the business process and its end result, in a SMART fashion.
In phases B and C, TOGAF considers the behavioural view so fundamental that it places Business and Information System services in the Requirements Specification rather than in the Architecture Definition.
DoDAF starts with “desired effects” of required “capabilities”.
The
ArchiMate modelling language is based on the idea that five general concepts
appear and reappear (in various forms) in architecture descriptions. The
definitions below are from the ArchiMate 2.0 standard.
· Object: object on which behavior is performed.
· Service: a unit of functionality that a system exposes to its environment, hides internal operations, provides a value; accessible through interfaces.
· Interface: a point of access where services are made available to the environment, provides an external view on the service provider and hides its internal structure.
· Behavioural element: a unit of activity performed by one or more active structure elements.
·
Structural element: an entity capable of
performing behaviour.
ArchiMate gurus recommend progressing
· from external services and interfaces to internal processes and components (calling that realisation) and
· from behavioural elements to structural elements (calling that construction).
ArchiMate includes services in the system’s architecture. A
service is a unit of external behaviour that a customer (client or consumer)
can ask for, or will be given.
For the external users, only this external functionality, together with non-functional aspects such as the quality of service, costs etc., are relevant.”
Finally, from "Systems Theories: Their Origins, Foundations, and Development"
“The method proposed by systems theory is to model complex entities created by the multiple interaction of components by abstracting from certain details of structure and component, and concentrating on the dynamics that define the characteristic functions, properties, and relationships that are internal or external to the system.” Laszlo and Krippner.
The primacy of external and behavioural views appears to be universal in architecture and design methods.
Methodical processes work from a system’s goals to its outputs to its processes and then to the internal organisation of components.
First, architects define the requirements and context for the system(s) to be designed and described.
Architecture definition is a service-oriented process in the sense that architects start with the required outputs, products and services
The architect then turns to define processes and components to deliver what is required. There is:
· A realisation process - in which external requirements are realised by internal design.
· A construction process - in which required processes are assigned to designed components.
The process is also iterative. So architects interleave thinking about processes and components.
And where a system is decomposed into subsystems, the process repeats at each level of decomposition.
At each level, architects start with the required outputs, products and services.
Then divide the system by behaviour (into use cases or processes) and by structure (into subsystems or components).
For each use case and/or subsystem, the architects may define:
· The desired outcomes or effects: the aims, along with other contextual information.
· The external behaviour: the outputs, products or services the system can produce to meet the aims; often, a prototype user interface
· The internal behaviour: the processes (scenarios) needed to produce the outputs
·
The internal structure: the components (modules,
classes) needed to perform processes.
Of course, architects must prioritise critical and risky services for attention.
If investigation shows a service to be too costly, risky or impractical, that will lead to a change request.
There must be continual requirements change management.
Given any system larger than small, it is bad practice to complete a specification of all outputs, products or services before turning your attention to internal processes and components.
It is bad practice to document scores of use cases without pushing some forward as far as testing, or at least prototyping.
It is good practice to identify the most mission-critical and riskiest use cases and push those forward as above.
Still, for each use case, the natural methodical sequence is goal-outputs-processes-components.
The OMG's model-driven architecture progresses from platform-independent model (PIM) to platform-specific model (PSM).
But the purpose of the PIM is to define all the required behaviour.
The PSM merely plugs in specific components to assist in performance of the behaviour defined in the PIM.
What if an external service appears trivial, but the necessary internal data and/or processes turn out to be very complex?
Fine, so be it. The purpose of a complex algorithm is to produce a result, and the purpose of stored data is to enable some output report.
The process designer best starts from the end result of the process; and the data designer best starts from the information required in system outputs.
What if the external service is easily defined and presented to clients and users, but this gives a false impression of progress?
It is later discovered the external view cannot be realized because internal processes cannot be written, or the necessary components cannot be readily procured.
OK, but wherever you start, you may discover unexpected costs, risks and complexities.
And if you start to design a system for which you don’t know the required output or behaviour, then you are less likely to discover the most critical costs, risks and complexities.
"I imagine a system architecture, depicted with hundreds of beautiful use cases, making each and every stakeholder very happy.
Then, one day, someone points out that although the process flows are lovely, the user interfaces are exquisite, the data sources have all been identified.
There's just one problem: there's no algorithm that can produce these outputs given those inputs in human-scale time.
The necessary algorithm is shown to be equivalent to another problem which is NP-complete.
Sorry, Architect—you've failed! It would have been better if you figured this out much earlier, before wasting everyone's time on hundreds of pretty, irrelevant use cases."
Yes indeed. That is an illustration of the bad practices mentioned above.
Nevertheless, in the architecture and design for each use case, the natural methodical sequence is goal-outputs-processes-components.
Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0
Attribution: You may copy, distribute and display this copyrighted work
only if you clearly credit “Avancier Limited: http://avancier.co.uk” before the start and
include this footnote at the end.
No Derivative Works: You may copy, distribute, display only complete and verbatim
copies of this page, not derivative works based upon it.
For more information about the
licence, see http://creativecommons.org