Composition hierarchies: What’s wrong with using one word at all levels?

Composition is one of the four scales of abstraction introduced in ref. 1 and included the table below.

Abstraction	Omission	Composition	Generalisation	Idealisation
	Vacuous	Coarse-grained composite	Universal	Logical Concept
	Sketchy	Mid-grained composite	Fairly generic
	Elaborate	Fine-grained composite	Fairly specific
	Complete	Elementary part	Uniquely configured	Physical Material
Concretion	Elaboration	Decomposition	Specialisation	Realisation

You may find it helpful to review the definitions and examples of composition given in the paper on abstraction. For example:

a car contains static and moving parts,
a department contains employees,
an egg contains white and a yolk.

And remember that architects describe different, clashing, structures of the same thing. Often, there is a more physical structure and more logical structure. For example,

a book (physical or printer view) contains pages, which contain symbols;
a book (logical or author view) contains chapters, which contain paragraphs, which contain sentences, which contain words, which contain symbols.

Here are a few more examples of hierarchical decomposition. In business organisation domain:

Top level business goals are hierarchically decomposed into lower-level objectives.
Organisation or management structures. E.g. The Army is composed of Corps, which are composed of Divisions, which are composed of Brigades, which are composed of Regiments or Groups, which are composed of Battalions, which are composed of Companies or Squadrons, which are composed of Platoons or Troops, which are composed of Section or Patrols. (With apologies to readers who have a different structure in mind).

In the information systems domain:

An application or software system contains programs, which contain modules, which contain instructions.

Files are stored in some kind of folder tree or directory hierarchy.
A input/output data file contains records, which contain data groups, which contain data items.

In the technology infrastructure domain:

Computer devices are usually composed of modules, which are created out of integrated circuits, which are internally organized using hierarchical methods (e.g. using standard cells).
Internet (IP) addresses are increasingly organized in a hierarchy (so routing will continue to function as the Internet grows).

This paper explores the idea of hierarchical decomposition, and introduces some hierarchical structures used in our reference model.

Decomposition levels

Divide one thing into ten smaller things, divide each of those into ten smaller things and you have defined a two-level decomposition hierarchy (the top isn’t counted as a level) with 100 elementary things and 111 things in total.

The conventional advice is that it is difficult for one person to maintain the integrity of a hierarchical structure with more than three or four levels of decomposition, or more than a thousand elements. How many levels in a complete enterprise architecture description? I address that question only in presentations!

Pure and redundant hierarchies

In a pure hierarchy, everything appears once and once only, there is no repetition between branches, no redundancy. A classic example is the management structure of an army listed above. You can document a pure hierarchy as a tree or folder structure, or as nested boxes. (The latter is common in the IT world.)

In a redundant hierarchy, one (lower-level) node can appear in, be reused in, many (higher-level) branches. How to avoid repetitious documentation? You can draw a matrix, a node-relationship network diagram, or document the lower level nodes separately.

You can draw a matrix in which the repeated nodes are mapped to the nodes above them - as row and column headings. For example:

Core Divisions “Shared Services”	Investment Division	Insurance Division	General Loan Division	Home Loan Division
Accounting	x	x	x	x
Procurement	x	x	x	x
Human Resources	x	x	x	x
Debt Collection			x	x

A matrix is not good for recording complex multi-level structures. You could instead draw a node-relationship network diagram, retaining the top-down structure where possible. Or you could break off the lower level nodes into distinct hierarchies, and document the mappings only in supporting documentation. This last is essentially what enterprise architects do when they divide architecture into several domains as shown below.

Decomposition from one architecture domain to another

The table below shows three architecture domains as a hierarchically layered structure. The components in one layer invoke services offered by components in the layer below. This is a useful mental model for enterprise and solution architects alike.

This architecture domain	is composed of systems called	that provide services to each other and to	by executing processes called
Business	Business functions	Customers	Business processes
Applications	Client-side applications	Business functions	Use cases
Applications	Server-side applications	Client-side applications	Automated services
Infrastructure	Infrastructure apps	Applications	Platform services

The overall structure of the enterprise is a redundant hierarchy, meaning that a service provided by a system in one level can be reused by several systems in the level above. The dependency of a component on a service in layer below is recorded in supporting documentation.

Composition of things into a different kind of thing

Aggregating smaller things into a big one can result in a new kind of thing. If you squash a number of circles together, you arrive at a triangle.

Similarly, if you merge the logical data models of several enterprise applications, then you don't get an even larger application, you get an enterprise-level business data model of different character. They may look similar, use the same notations, but they are different things.

Using different words to distinguish levels of decomposition

Using the same term at all levels of granularity can create difficulties – leading architects to talk at cross purposes with each other, let alone with business people.

E.g. consider the word “capability”.

You may hear a business architect using the term capability to mean a top-level business function or service; perhaps one that is still only a business goal and is to be delivered via a project under business change management.
Decompose a top-level business function six or seven times, to a level where the components are a million times smaller, and you may find software architect using the same term, capability, for a single web service.

That’s OK providing the two architects don’t talk to each other about capabilities, and you don’t try to write a generic architecture framework that both architects will find helpful.

The usual way to avoid hierarchical decomposition confusion is to use different terms at different levels. For example, in the hierarchy of architecture layers above, you’ll see the processes and services are given different names at each level. Some other examples are shown below.

Decomposition of inputs into outputs

The inputs to architecture definition include high level aims, directives, targets and plans. These are decomposed and elaborated alongside architecture definition. So outputs include lower level definitions of the inputs, commonly given different names.

The table below shows four hierarchies of inputs and outputs included in the reference model:

Aims	Directives	Targets	Plans
Goal (KGI)	Principle	Solution vision	Strategy
Objective (KPI)	Policy	Solution outline	Programme
Requirement	Business rule	Solution to build	Project

Depending on the scope of the system being described, a hierarchy can include two, three or more levels of decomposition. The names used along a row may or may not correspond to each other in any real-world situation. The “right” granularity and detail for a level of decomposition varies with the scope and complexity of your enterprise, system or project.

Decomposition of values and risks

Some say enterprise architecture is all about delivering value and managing risk. But what do these words mean exactly? They can (in the world of corporate governance and legislation) mean delivering value to shareholders and managing enterprise financial failure risk. The latter is some kind of science, embodied in automated calculations run after every financial transaction.

High level values and risks, like every concept the architect deals with, can be decomposed into lower level values and risks. What kind, what level, of values and risks are EA and IT architects most concerned with? Deep thought is needed about:

Who gets value from the systems to be built: Shareholders? Business managers? Customers? Users? Taxpayers? Beneficiaries? Local Government? National Government? International Government?
What kind of risks must the architect address: Enterprise financial failure risk? Public humiliation? Legal action? Technical failure risk? Project business case (ROI) risk? Project deadline risk? System quality risk?

In practice, Enterprise Architect usually strive to deliver value to the business sponsors of the IT department, and manage the risks attributable to that department.

Decomposition in architecture reference models

The TeleManagement Forum (TMF) has produced three architecture reference models. These are somewhat generic structures that a specific Telecoms enterprise can specialise and realise, or least use to do a gap analysis by comparing them with their existing systems.

· By way of business architecture: there is a business function hierarchy (called eTOM) which has 3 levels of decomposition leading to about 500 elementary business functions.

· By way of data architecture: there is a data structure (called SID) with 8 domains, decomposed to about 80 entities, decomposed (in places down to a fourth level) to several thousand classes documented using UML.

· By way of applications architecture: there is an applications structure (called TAM) in which the same 8 domains are decomposed to about 70 applications, with some further decomposition below that.

These three models could be placed in the naïve abstraction schema shown in the paper on abstraction. They are all fairly specific (to the Telecoms industry) but are completed to different levels of detail.

Generalisation Composition	Universal	Fairly generic	Fairly specific			Uniquely configured
Coarse-grained composite			eTOM	TAM	SID
Mid-grained composite			eTOM		SID
Fine-grained composite					SID
Elementary parts

Decomposition affects concept definitions

Authors don’t always appreciate how hierarchical decomposition undermines their attempts to draw 1-1 or 1-N relationships between concepts in different hierarchies.

For example, systems can be decomposed into subsystems, and process flows can be decomposed into sub processes. You cannot say in general that a system encapsulates several processes or that a process requires several systems. You can only say that:

A high-level system encapsulates many lower-level processes.
Several low-level systems are needed to execute one higher-level process.

And this applies to all sentences in which synonyms of system and processes are used. So, all sentences including the words function, capability, service, operation etc.

Hierarchical specialisation is another matter

Decomposition hierarchies are not inheritance hierarchies. Some terms in our reference model terms do inherit from each other in a generalisation-specialisation hierarchy. For example: System is a super type of Actor, Broker, Client, Component, Function and Server. However, the inheritance tree between the c400 terms is complex and not formally defined.

Ref. 1. “Abstraction in all its variety” at http://avancier.co.uk .