A New Approach to Architecture Partitioning

26 September 2022

Introduction

Attempting to understand the architecture of an enterprise is a daunting task – even for Enterprise Architects! Although there is really only one architecture for any enterprise (since, by definition, architecture is about things and how they are connected to each other, and everything is connected to everything else in some way), to attempt to capture and analyse this as one giant blob is not practical. Instead, Architects attempt to partition this architecture in some way in order to, as TOGAF states, “…simplify the development and management of the Enterprise Architecture” [1]).

The TOGAF Way

Chapter 36 of the TOGAF 9.2 specification discusses the approach that they take to this task. TOGAF motivates architecture partitioning in this way:

“Architectures are partitioned because:

• Organizational unit architectures conflict with one another
• Different teams need to work on different elements of architecture at the same time and partitions allow for specific groups of architects to own and develop specific elements of the architecture
• Effective architecture re-use requires modular architecture segments that can be taken and incorporated into broader architectures and solutions”

All true. There is an implication here; in order to attempt to understand and break-down broader architectures, a formal methodology is needed, based on the use of these partitions.

They also go on to say that it is not practical to present a definitive partitioning model for all enterprises because it is dependent on the organisation’s operating model. While this is true, at a conceptual level, I believe there are common criteria that can be leveraged across all organisations as they are universally applicable. This article puts forward a new approach that is applicable to all architectural analysis in any enterprise since it based on architectural concepts that are not dependent on organisational structure or behaviour.

The Zachman Framework

The grandfather of all EA frameworks, most EAs are familiar with his Enterprise Ontology diagram[2].

As Zachman points out this is a structural ontology and NOT a methodology. This matrix “…would necessarily constitute the total set of descriptive representations that are relevant for describing something... anything: in particular an enterprise”. But it does not tell you how to generate architectural representations, it simply provides the language to do so.

In this article we want to describe a simpler alternative, inspired by the Zachman Ontology but going one step further to provide a process to go with it – a methodology for generating comprehensive architectural specifications.

Let’s begin.

Zachman introduces two key concepts in this diagram: Perspective and Architecture Levelling [3]. Let’s deep dive into each of these important and closely interrelated concepts now.

Architecture Levelling

Audience perspectives are listed down the left-hand side of the matrix. These can be simplified to Conceptual (“The Owner’s View”, the Executive and the Business Manager), Logical (“The Designers View”, the Architect and the Engineer) and Physical (“The Builder’s View”, the Technician and the User). This concept of levelling is capturing the very essence of architectural analysis – abstraction of reality.

Typically, we begin to understand the world around us through abstraction and at the broadest level this is a conceptual observation; for example, we look at a tree and see the concept of plant. We may understand that trees provide shade and cooling when we stand near or under them. This is usually where understanding begins. The next step is a logical view of the tree; we note the tree has leaves that use the sun to produce food for the trees. Finally, we look at it as a physical entity; the physical is where understanding, ultimately, ends – in other words, where we enter the realm of science and engineering and can understand the universe to the best of our current abilities. In our example, leaves of all trees contain chlorophyll, a green pigment that has the unusual capability to capture light energy and (with the help of other components in the leaf) to convert that energy into a chemical form, such as sugar.

Before we move on the observant reader would have noticed that we have not discussed the Contextual perspective within the Zachman Framework. The Planner's View (Scope Contexts) describes the business purpose and strategy, which defines the playing field for the other views. It serves as the context within which the other views will be derived and managed. The reason we have omitted this view is because, as the framework indicates, this perspective is in the hands of the C-suite or Executive level within the organisation. It is very rare indeed that an Enterprise Architect is empowered to design or ideate corporate strategy or vision; typically these form inputs to the architectural initiative as constraints or assumptions, so we treat them as such here.

Perspective

Looking down the right-hand side of the Zachman matrix, we see Model Names. These have evolved to become what is commonly referred to as the BAT stack – Business (Scope and Business), Application (System Logic and Technology Physics) and Technology (Tool and Operations). This mapping is broadly accurate, as the goal is to arrive at a simplified version of this matrix with a strong practical use. If the reader prefers strict adherence to the Zachman Framework then please stop reading now!

Still with me? Let’s proceed.

These three perspectives are referred to as “Architecture Domains” in TOGAF. They represent the functional aspects of the solution – the response from an application API or the output of a business process. The functional aspects for each domain are always captured within any architectural analysis, unless the focus requested explicitly excludes them.

But wait – there are actually four domains in TOGAF – what happened to Information?

Information in the Architecture Quality Space

After many years of working with TOGAF I (and others like me) have arrived at the conclusion that in fact Information should not be classified as an Architecture Domain even though it really, really looks like one. But it fails one important test – it is not a layer in the architectural stack, it is in fact a cross-cutting concern. And while we are at it, so is Security. In fact, further reflection leads to the observation that there are a whole set of cross-cutting concerns that architects must consider in any system design, and they share the following characteristics:

????????I.???????????They cut across business, application and technology domains (that is, they can be considered within the context of each of these domains)

??????II.???????????They are not functional in nature (that is, they do not relate directly to system functions and behaviour)

????III.???????????They are orthogonal to both levelling and domains. This means that these characteristics need to be contextualized to both; for example, security at the conceptual level is different from the physical level but both levels add insight into the overall solution architecture.

TOGAF lists a comprehensive set of these Quality-of-Service (QoS) attributes [4]. ?

However, there are more cross-cutting concerns, which are not technically Quality of Service (QoS) attributes, like Scope, Risk, Assumptions, Constraints, and so on, which we include in this set as well, so that we can represent all aspects of architecture. We add information to this list as it satisfies the above three criteria. And this becomes our third axis (referred to as the set of Non-Functional Aspects, or NFAs) in our architecture solution space shown below – we call this the Architecture Quality Space and each quadrant a Segment (of which there are at least 18, since Information and Security are always included as NFAs).

Each of the N segments can be referenced using the notation [Domain, Architecture Level, NFA]. For example: [Business, Logical, Security].

Structure and Behaviour

The “space” we have defined above is three dimensional but there are further orthogonal dimensions to consider. Every architectural element within this architectural space also possesses two characteristics – structure and behaviour (shown as S/B). For example, a [Business, Conceptual, Information] segment architecture describes business entities such as ‘Bank Account’, ‘Doctor’ or ‘Patient’. Every entity such as these demonstrates both behaviour (for example, a Patient visits Medical Clinic) and structure (a Patient is 180cm tall).

We can extend the notation when needed to add this dimension: [Domain, Architecture Level, NFA, Structure/Behaviour]. For example: [Business, Logical, Security, Structure].

What now?

Now that we have this quality space defined what do we do with it?

The goal of this construct is to use it to guide the Architect in considering all aspects of architecture when capturing the design of a system. By moving through the space within the boundaries of the quality space we can define a methodology that can be used within any solution domain to arrive at a comprehensive architectural description for a system or systems.

Let’s work through an example.

Where do we start?

The starting point in 99% of cases is always with the business requirements. And since we initially rarely know much about the problem domain we are attempting to address, we must stick to the Conceptual level. Our primary concern when capturing business requirements is what will the system do and what information/data will it be creating, using or manipulating? Not coincidentally this puts us in the bottom left corner of the quality space [Business, Conceptual, Information]. ?

It is also practical to take a structure-first approach; not surprisingly it is difficult to describe process before you know what is being processed. Typical structural entities are data entities with their attributes. Meta-models are also useful in some use cases.

Now let’s see if we can map this to a typical (waterfall) Systems Development Lifecycle as shown below [5]:

• The Initiation Phase talks about identifying needs and an opportunity – this is the process of eliciting business requirements. We are in the [Business, Conceptual, Information] starting point of our quality space.
• The second phase talks about scope, constraints, risks, benefits, and so on. These are part of the set of NFAs.
• Planning is not primarily an architectural concern, although obviously it does require a contribution from architecture.
• Requirements feed the architecture process but are not an architectural artefact.
• Design is where all the magic happens, from an architectural perspective. And it is this phase which will benefit the most from using the Architecture Quality Space.
• The objective of the remaining phases is to realise and operationalise the architectural blueprint that was created in the design phase; in TOGAF terms to implement the target architecture.

The Design Phase

The SDLC shown above is based on waterfall development, however, the same lifecycle can be applied in a similar way iteratively, within an Agile methodology, such as SAFe [6] (see below).

SAFe defines three architect roles: Enterprise, Solution, and System architect, that address architectural concerns at their respective levels (portfolio, program, and solution). Each role as shown above maps naturally to the architecture quality space:

1)?????The Common Domains axis maps to the Domain axis in the Architecture Quality space for Business, Application and Technical (Technology).

2)?????The Information domain maps to the Information NFA as does any other architecture domains such as Security Architecture domain.

3)?????Each SAFe role has a Scope (across value streams, systems or within one system) and this is also another NFA within the Architecture Quality space.

In this way SAFe architecture roles apply to a subset of space within the Architecture Quality space as we would expect if we had in fact created a “complete” space that captures all architectural aspects (as we are claiming).

How Do We Use It?

Having established that the quality space is for use when performing architecture and design phases regardless of the development philosophy, the next question is “How do we actually use this?”.

Another way to look at this is that the Architecture Quality space acts as a kind of map for architecture and design; as an Architect you can choose to start anywhere in the quality space and navigate to anywhere else in it. In doing so, you are guided to address every quality aspect of architectural analysis and create a “complete” architectural blueprint for the target system, solution or enterprise by combining this with the functional analysis undertaken within each domain.

The definition of a “complete architectural definition” is not universally agreed or well-defined. The best definition we can propose is that an architectural description is complete when there are enough design artefacts to address all the specified business requirements (functional and non-functional). In other words, you stop when you have enough to describe the solution, and anything you produce in addition to this is superfluous.

Conclusion

The stated goal for this article from the very beginning was to provide an Architect with a formal technique for ensuring that when they are architecting a system or an enterprise or anything in between they are able to ensure complete coverage of all key architectural aspects, both behavioural and structural, delivering a complete architectural description for the solution.

What we have described here is a practical visual “space” that can be used by the Architect to navigate a path through every modelling aspect required to achieve a complete representation of the final target state. We have leveraged some of the concepts in the Zachman framework but extended it beyond just defining an ontology, into processes, people and policies. We are fully aligned with agile and SAFe thinking, so there should be no pushback form these practitioners.

Hopefully the reader will find this approach useful.