Better Architecting With – systems approach

All blogposts on this topic are at the URL http://improving-bpm-systems.blogspot.ch/search/label/%23BAW 

1 The systems approach basics

The systems approach is a holistic approach to understanding a system and its elements in the context of their behaviour and their relationships to one another and to their environment. Use of the systems approach makes explicit the structure of a system and the rules governing the behaviour of the system.

The systems approach is based on the consideration that functional and structural engineering, system-wide interfaces and compositional system properties become more and more important due to the increasing complexity, convergence and interrelationship of technologies.

The goal of the systems approach is to walk people and organisations working on complex systems through various stages and steps of analysis and synthesis in order to build a comprehensive understanding of the system-of-interest and, ultimately, be able to architect and engineer that system at any desired level of detail depth.

The systems approach helps to produce the following digital work products.

• artefacts (entities made by creative human work) which are used to implement the system-of-interest;
• system-of-interest terminology to explain various system approach concepts and relationships between them
• nomenclatures (or classifications) of artefacts of the same type;
• models to formally codify some relationships between some artefacts;
• views (collections of views) to address of some concerns of some stakeholders, and
• architecture descriptions which consists of several views.

To facilitate the production of those digital work products, the systems approach provides:

• system approach terminology to explain various concepts of the system approach and relationships between them;
• several templates to define various artefacts;
• several nomenclatures with artefacts related to the systems approach;
• several model kinds which formally defines views;
• several architecture viewpoints conventions which can include languages, notations, model kinds, design rules, and/or modelling methods, analysis techniques and other operations on architecture views; architecture views are system-of-interest dependent and architecture viewpoints are system-of-interest independent, and
• several patterns with techniques for transforming (not necessary fully automatically) some model kinds into other models kinds.

Many viewpoints and views are possible.

   

Different stakeholders see the same system differently and recognise different artefacts. 

2 Four levels of architecting

If the system-of-interest is rather complex, then it is recommended to use the following four levels of architecting:

1. reference model is an abstract framework for understanding concepts and relationships between them in a particular problem space (actually, this is terminology)
2. reference architecture is a template for solution architectures which realizes a predefined set of requirements
   Note: A reference architecture uses its subject field reference model (as the next higher level of abstraction) and provides a common (architectural) vision, a modularization and the logic behind the architectural decisions taken 
3. solution architecture is an architecture of the system-of-interest
   Note: A solution architecture (also known as a blueprint) can be a tailored version of a particular reference architecture (which is the next higher level of abstraction)
4. implementation is a realisation of a system-of-interest

The dependencies between these 4 levels are shown in illustration below.

The purpose of the reference architecture is the following:

• Explain to any stakeholder how future implementations (which are based on the reference architecture) can address his/her requirements and change his/her personal, professional and social life for the better; for example, via an explicitly link between stakeholders’ high-level requirements and the principles of reference architecture.
• Provide a common methodology for architecting the system-of-interest in the particular problem space, thus different people in similar situations find similar solutions or propose innovations.

In case of the very complex system to be implemented in several projects and the necessity to collaborate and coordinate between those projects, it is recommended to develop a reference solution architecture and, if required, a reference implementation (see illustration below). It helps to identify smaller systems elements (e.g. services, data, etc.) and relationships between them (e.g. interfaces) thus they can be shared between projects.

The reference solution architecture and the reference implementation are often experimental prototypes which are not production quality.

3 An example of digital work products

The digital work products below are listed in an approximate order because some modifications of a digital work product may necessitate some modifications in some other digital work products. The patterns to transform some digital work products into some other digital work products are not mentioned below.

3.1 Value viewpoint

The value viewpoint comprises several digital work products which describe the problem space, and provides some ideas about the future solution and its expected value for the stakeholders. The digital work products of this viewpoint:

• problem space description;
• system-of-interest terminology (as an initial version the system-of-interest ontology);
• business drivers;
• problem space high-level requirements (or some kind of guiding principles);
• dependencies between viewpoints, stakeholders and stakeholders’ roles;
• dependencies between viewpoints, stakeholders, stakeholders’ roles, stakeholders’ concerns and categories of concerns;
• beneficiaries, i.e. stakeholders who/which benefit from the system-of-interest;
• beneficiaries’ high-level requirements;
• scope of the future solution space;
• mission statement and vision statement, and
• goals (if the vision statement must be further detailed).

3.2 Big picture viewpoint

The big picture viewpoint comprises several digital work products which describe the future solution as the whole::

• system-of-interest ontology as a reference model;
• some classifications which are specific for this solution space;
• illustrative model;
• essential characteristics of the future solution;
• dependency matrix: high-level requirements vs. essential characteristics;
• architecture principles model kind, and
• dependency matrix: essential characteristics vs. architecture principles.

3.3 Capability viewpoint

The capability viewpoint comprises several digital work products which describe the future solution as a set of capabilities:

• level 1 capability map;
• level 2 capability map;
• level 3 capability map (if necessary), and
• heat maps (if necessary).

3.4 TOM engineering viewpoint

The engineering viewpoint comprises several digital work products which describe the future solution as sets of some artefacts:

• data model
• process map
• function map
• service map
• information flow map
• document/content classification
• etc.

3.5 Some other viewpoints

• Organisational viewpoint
• Operational viewpoint
• Implementation viewpoint
• Compliance framework
• Regulations framework
• Security, safety, privacy, reliability and resilience framework
• Evolution viewpoint
• etc.

4 Some definitions

1. reference model

abstract framework for understanding concepts and relationships between them in a particular problem space or subject field

• Note 1 to entry: A reference model is independent of the technologies, protocols and products, and other concrete implementation details.
• Note 2 to entry: A reference model uses a concept system for a particular problem space or subject field.
• Note 3 to entry: A reference model is often used for the comparison of different approaches in a particular problem space or subject field.
• Note 4 to entry: A reference model is usually a commonly agreed document, such as an International Standard or industry standard.

2. reference architecture
template for solution architectures which realize a predefined set of high-level requirements (or needs)

• Note 1 to entry: A reference model is the next higher level of abstraction to the reference architecture.
• Note 2 to entry: A reference architecture uses its subject field reference model and provides a common (architectural) vision, a modularization and the logic behind the architectural decisions taken. 
• Note 3 to entry: There may be several reference architectures for a single reference model.
• Note 4 to entry: A reference architecture is universally valid within a particular problem space (or subject field).
• Note 5 to entry: An important driving factor for the creation of a reference architecture is to improve the effectiveness of creating products, product lines and product portfolios by
  • managing synergy,
  • providing guidance, e.g. architecture principles and good practices,
  • providing an architecture baseline and an architecture blueprint, and
  • capturing and sharing (architectural) patterns.

3. solution architecture
system architecture (or solution blueprint)
architecture of the system-of-interest

• Note 1: A solution architecture can be a tailored version of a particular reference architecture which is the next higher level of abstraction.
• Note 2: For experimentation and validation purposes, a reference solution architecture may be created. It helps in the creation of other solution architectures and implementations.

4. implementation
realisation of the system-of-interest in accordance with its solution architecture

• Note 1: A reference implementation is a realisation of the system-of-interest in accordance with its reference solution architecture. It can be production quality or not.

Thanks,
AS