Designing an architecture (or “architecting”) can be seen, like any other design activity, as a set of decisions representing a path/trajectory in the design space (defined by all the choices that designer could make) that leads from the starting point to the final design (represented by a point in the design space), see H. A. Simon. The Sciences of the Artificial. The MIT Press, third edition, 1996. and D. Garlan, and M. Shaw, An Introduction to Software Architecture.

On the kinds of design decisions and their attributes in the architectural design of software systems see P. Kruchten, An Ontology of Architectural Design Decisions in Software-Intensive Systems.

There are two important questions related to this:

1. Is it enough to document only the design decisions taken during the architecture work, as a path to the final result?

   

To that we must answer, that although it is important to record/document all the design decisions, this documentation alone will not be sufficient to document the final architecture, because this would force each reader to “replay” all the steps taken by the architect to be able to find out what the architecture is looking like (i.e. build itself the final architecture). Couple of random examples from such decision sets, which show this problem: OpenAttestation and ADR Tool.

While this could be educationally a good exercise for introducing new team member to the architecture and the related reasoning, this will not be suitable for many other stakeholders, who need to see the whole architecture (as a possible input for their own decision making processes).

Therefore we need also a description of the final architecture provided possibly from different viewpoints that correspond to the different sets of concerns of different stakeholders, see P. Merson, P. C. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, and J. A. Stafford, Documenting Software Architectures: Views and Beyond, 2nd Edition, 2010

2. Is the order of design decisions important or not – i.e. are all paths to a certain design through the design space equal?

   

To that we must answer with the usual “answer from architect” – it depends!

If we are doing the “dreaded” BDUF, then the order of design decisions is not important, because the steps from one point to another in the design space do not cost anything and any constraints on the steps between the two points in design space are due to the overall set of steps taken (due to the relationships between the design dimensions) independent of the order in which these steps are taken (see my thoughts on agile methods and architecture).

But if we are trying incrementally build the design, making the design decisions as we go, then the order of design decisions becomes very important, because if certain design decisions have been implemented, this will rule out some other design decisions in the future (due to the aforementioned relationships between the design dimensions) – we can literally “paint our-self in the corner”.

So to be successful in the agile (incremental development) and keep our options of choice as wide as possible, architect (or who-ever is the “master-builder”) must have the BDUF in his/hers “back pocket”, although there might be situations, where it’s better not to show this to the others who are involved in the journey.

All systems must have some way of separating and protecting their internals from the external environment, because without such protection, leaving the internals of the system open to the destructing forces of the environment, the system will cease to exist very quickly. For open systems such boundary should not only protect the system, but also allow it to interact with its environment – pass information, energy and matter in a controlled manner, which is safe for the system (so that nothing dangerous and potentially destroying will be able to enter the system). When the border between external world and internals of the organism is broken or removed, all organisms cease to exist (i.e. die) and will be decomposed – same is the case with the software systems, and to be able to talk about a specific software system at all, we need to define (and control over time) the system scope (i.e. define what are the parts of the software system and what are not).

Additionally to allow software system to interact with its environment in a controlled manner, we need similar mechanisms like in the case of other open systems (incl. natural organisms), which allow software system to exchange information with the external environment in a controlled and safe manner.

• In case of natural organisms such boundary is cell/plasma membrane for the cells, epidermis for plants and skin for the animals, later being rather complex and large organ.
• In case of social systems like states, such boundary is defined border together with the border guard and customs organizations.
• In case of the software systems, such boundary is composed of the interfaces offered to external systems (which could be software systems, hardware systems, users, etc.) for connections, and such components of the software system that connect directly to external systems.

If software systems need to maintain the control over their internals and avoid destruction/corruption by external forces, they need to enforce that all exchange of information between the software system and its environment happens through the well-guarded and strict interfaces. As soon as the interfaces are bypassed and software system internals are directly accessed and manipulated from its environment without any restrictions, or software system internals are accessing ts environment without any control, the software system starts to “die” (i.e. gradually corrupt to the point where it cannot be maintained anymore and must be replaced by some other system).

What is an interface

There are many definitions for the interface:

• An interface is a boundary across which two elements meet and interact or communicate with each other [CMU SEI].
• Interface is an interconnection and inter-relationships between, for example, people, systems, devices, applications, or the user and an application or device [Open Group TOGAF 9.2].
• An external active structure element, called an interface, represents a point of access where one or more services are provided to the environment [Open Group ArhiMate 3.2].
• An Interface is a kind of Classifier that represents a declaration of a set of public Features and obligations that together constitute a coherent service. An Interface specifies a contract; any instance of a Classifier that realizes the Interface shall fulfill that contract [OMG UML 2.5.1].
• Interface is [IEEE SE VOCAB]
• a shared boundary between two functional units, defined by various characteristics pertaining to the functions, physical signal exchanges, and other characteristics, or
• a hardware or software component that connects two or more other components for the purpose of passing information from one to the other, or
• an abstraction of the behavior of an object that consists of a subset of the interactions of that object together with a set of constraints on when they can occur.

As we can see, interface is most often seen as the boundary of a system or a special component, through which the environment can interact with the system and which is abstracting (or mediating) the behavior of the system for the environment (i.e. interface is providing a “language” and the mechanism to communicate with the system and request/access the services it provides).

From the differences of these definitions it comes clear that in some sense the interface can be also viewed as a contract between two systems, because it embodies a set of conventions which both systems must follow for the interaction to be successful.

This duality comes from the fact that there are two kinds of (architectural) structures in the software systems [CMU SEI], which should not be mixed:

• module structures, which reflect how the software systems code (which has to be constructed or procured) is structured, and
• component and connector structures, which reflect how the software system elements (components) are structured and connected (via connectors) at run-time.

If we look at these structures, then both these have interfaces, but:

• in module structures interface defines what is available (visible) to other modules, it is the mean of communication between the developers:
  
  
  
• in component and connector structures:
  • component interface, called port, defines the potential interactions (behavior) of component with its environment, and
  • connector interface, called role, defines the ways how connector can be used (specifying protocol of interaction – i.e. prescribing what patterns of events or actions are allowed to take place over the connector).
    
    
    

There could be only one module interface of given type (signature) per one module, but there could be many component and connector interfaces of same type per components and connectors.

Following rules apply for the component and connector structures:

• Attachments can be made only between compatible ports and roles – components can be attached only to connectors, not to other components and vice versa.
• In case of interface delegation component ports can be associated with one or more ports in an “internal” structure (similarly for the roles of a connector) – this allows us to progress from the “black-box” view to the component to the “white-box” view.

Characteristics of an interface

There are several important characteristics that an interface as the boundary and a contract between two systems must define.

When looking at the interface as a contract between two systems, interface must answer the following questions:

• Services – what services or functions can be accessed through the interface (i.e. operations, actions, …)
• Content – what data flows through the Interface (i.e. entities, attributes, value sets, …)
• Quality of Data – what are requirements on data that flows through the Interface (i.e. consistency, completeness, …)
• Protocol – what is the order and nature of (inter-)actions taking place at the interface (i.e. synchronous conversation, asynchronous conversation, …)
• Quality of Service – what are the requirements to the actions taking place at the interface (i.e. timeliness, security, …)

All these questions need to be answered by the description of the interface.

Although in some sense the interface, which connects two systems together as a contract between those systems, is positioned between these two systems, it still usually belongs to one of these systems.

Which of the two systems “owns” the interface and therefore defines the contract between two systems, is the decision that the systems designers have to make:

• interface can be “owned” by the system that provides the services to the other system, in which case it is usually called provided interface, or
• interface can be “owned” by the system that requires the services from the other system, in which case it is usually called required interface.
  

Why we need interfaces

As was described above, module interfaces are needed for communication between the developers – defining these things that are visible to the developers using the module, while hiding all other information about the module, isolating this way the developers, who will use the module from the developers who will develop and maintain the module.

Component and connector interfaces are needed to control the information and control flows between the elements of the running software system, and this way support isolation of components, modifiability, reusability, and help manage the complexity in the run-time structures of the software system.

During the last years, the agile movement in the IT development, has transformed IT development organization into very efficient pipeline or engine, which can develop software and deliver the tasks “thrown at it” with a great speed and efficiency, but the outcome of this efficient engine is only as good as is the input.

But when there are different competing views in the organization about what is needed to be built, and the sponsors of all these competing views generate parallel streams of inputs to the IT development pipeline(s)/engine(s), having in their minds their own target(s), then the output produced would be a chimera – a mix of the pieces from the different targets, put together in the order defined by which sponsor at which time had a strongest bargaining/prioritization position.

Even if each of the pieces of this “Big Ball of Mud” [see http://www.laputan.org/mud/mud.html#BigBallOfMud] would be build according to the highest engineering standards, the result would not be fit for executing the enterprise strategies, and whole enterprise landscape would be difficult to improve or evolve.

If previously IT development included also the business analysis and architectural design as part of IT development, where the first stages of the development project, analyzed the full picture and developed the full understanding of what needs to be built, then in agile world this is seen as waste (see YAGNI [https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it]) and pushed out of the IT development, hoping that this will be done by somebody else before development starts, and that if developments lead us to the dead end, we can always backtrack and redo (refactor) everything.

Because it would be possible frequently to refactor whole enterprise, and because the big picture of the target this is required to avoid “going with great speed and efficiency to nowhere”, somebody else, than IT, in the organization must develop and maintain this big picture.

To avoid building very efficiently such a “Big Ball of Mud”, employing the agile IT development organization requires, that business will build their own strong business analysis and development organization, which is capable of developing and maintaining the holistic picture of the enterprise target, which needs to be built to support execution of the business strategies of the enterprise, and also be able to divide this target into the suitable size pieces, which could then be in correct order (to avoid for example sunk costs) fed into the IT development pipeline/engine.

There is a constant discussion in software engineering community about the use and usefulness of modeling in software development, but often in these discussion, visual representations of models are mixed with the illustrations.

So what’s the difference between an illustration (a picture) and a visual representation of a model?

The main purpose of model in software engineering (as in many other engineering disciplines) is to answer certain questions about some object (to be built or studied), but the purpose of an illustration is to communicate (make clear) a certain message (which in case of engineering can often be one of the answers provided by some model or something else).

Both are needed, but for different purposes, and therefore the properties of the good model are very different from the properties of a good illustration – visual representations of models generally do not serve as good illustrations, and illustrations do not serve as (good) models.

Do not blame an illustration, if it does not give answers to your questions, and do not blame a visual representation of a model, if it does not communicate a clear message!

An example of illustration of the idea that we should build a platform that allows a set of plugins to cooperate, could be following:

Although such illustration could convey rather well the main message, it does not help us to answer the questions of what to build as a platform, how plugins must be built, and how their interactions with the platform and between themselves would happen, as many other questions that we would like to get answers before we even start building such thing.

If we want to have answers to these questions or record the design decisions that we have made to be recorded precisely to allow different teams that might be involved in the building of platform and plugins to reach the end result that fulfills all the requirements, we need a model of the platform, plugins and possibly also model of their interactions.

Such models could have following visual representations:

and

First describing the static structure of the platform and two plugins (providing answers to the questions that are related to to the development and building of such system), and second describing the dynamic behavior of a plugin, it’s interaction with the platform (providing answers to the questions that are related to the ability of such system to work as required).

Because this function of the model, the most important properties of a model are correctness, consistency and completeness – model must act as a single source of truth for the development activities.

When we need to automate the software engineering (or any other engineering discipline), another important property of the models is existence of digital, machine-readable representation, which is required to be able to process models with different analysis and development tools – human-readable representations of the models does not have to be even exist.

The illustrations in other hand need always always be human-readable.

The whole activity of modeling (incl. building and analysis of the models) is very different from the activity of creating illustrations – different skills and tools are needed for both.

If there exists a model of an object, then also various illustrations could be created, but because the good illustration is not just representation of facts, but for better communication, must contains aspects that influence emotions of the intended audience, this is rather complex task, which requires artistic talents, and therefore has been more difficult to automate, than just creating a visual representation of some information taken from the model.

By trying either to use illustrations as models, to answer questions, or visual representations of models as illustrations, to communicate something, neither of the goals will be fulfilled, and we will be disappointed in the results.

People often talk about the levels of business processes, but based on the possible relationships between the business processes according to OMG BPMN and Open Group ArchiMate standards, there could be several different relationships of hierarchical nature, between the business processes, which all could form levels.

Let’s look at the examples of two such relationships that allow forming of hierarchies (like specialization/generalization and containement):

or

There could be also other relationships between business processes, which allow formulation of levels, although in these cases the relationships themselves would allow forming of more complex networks, not only hierarchies, and therefore notion of levels gets even more unclear.

If talking about the levels of business processes it is important always clearly state which relationship between the business processes is taken as basis for the particular levels, otherwise the meaning of being in one or another level is lost.

If other modeling concepts (like groups/categories of the processes or activities or something else) are mixed into the hierarchy, then we cannot anymore talk about the levels of processes.

For example on following picture, only second level of hierarchy contains processes, therefore we cannot talk about first or third level processes:

Therefore, when business processes are combined into same hierarchy with other modeling concepts, it would be important to clearly identify on which level which modeling concept resides.

According to the WikiPedia, business capability maps/models are one of the most widely used Enterprise Architecture artifacts (see Enterprise Architecture Artifacts).

If looking at the different business capability maps, then an interesting thing sticks into eye – some business capability maps of the same business area/domain are more generic than others, up to the point, where only small part of the business capabilities, if any, are business-specific.

Although the definitions of business capability are rather well converging (see various definitions in Business Capabilities vs Business Processes) into „an ability or capacity that a business may possess to achieve a specific purpose”, there seems to be two different schools of thought in respect of what is the purpose of business capability map/model and how to identify and define the business capabilities.

This is especially well illustrated by the change that happened in BIAN between versions 6 and 7 (see BIAN v7.0 Release Notes), when additionally to already existing business capability map, called in BIAN “Service Landscape” (SL) a new business capability map (BIAN “Business Capability Model”) was added, and (business) service domains, which previously were considered as „business capabilities” (see BIAN How-to Guide and Design Principles & Tehniques) were re-considered/-purposed as „business capacities”.

Therefore we could consider both models as actually business capability maps, but created from different viewpoint (using different method).

The reasoning behind these differences is given in the BIAN white-paper on BIAN BCM alignment with the BIAN SL (see BIAN Business Capability Model Statement of Alignment with the BIAN Service Landscape):

If we now compare these two maps/models, we see that the BIAN BCM isa much more generic than BIAN SL (i.e., much smaller part of the Business capability model deals with the banking-specific functionality ):

vs

That seems counter intuitive, if we think that the purpose of BIAN BCM is to support the strategy work, that this particular model is actually less banking specific than BIAN SL.

The same school of thought is also visible in the ACORD Capability Model (see ACORD Capability Model) and in the example for business capability map/model for public libraries (see A Brief Introduction to Business Capabilities and Capability Model).

All these three examples consist mostly of the same business capabilities, which any enterprise or institution would need, see:

Even if we could agree that strategies for banks and insurance companies could be similar, then I is difficult to see that a strategy of a public library would be similar to bank or insurance company strategy, although the business capability map, supporting the strategy work, might let us think that way.

Obviously the cause is over-generalization, which on certain level of abstraction makes all enterprises and institutions (in western culture context) similar, but that will not help to make strategic analyzes or development of the strategy (especially the strategy that allows enterprise to distinguish itself in the marketplace).

From time to time, I see that in the discussions about the business architecture part of the enterprise architecture, somebody again raises the question “what is the difference between the business capabilities and business processes?”.

Although this difference must be rather clear from the most widely accepted definitions (see below), and has been stressed in many enterprise/business modeling frameworks and methodologies that the capabilities define WHAT business needs to (be able to) do (implying all that is necessary for that), and processes define HOW that must be done, for some reason there is still some confusion.

It seems to me that this confusion arises mostly from these enterprise/business modeling methodologies, which see the business processes as the primary element in the business architecture or concentrate on the process architecture. In these methodologies (like APQC, ARIS, Cordial, …) business process together with the categories and groups of business processes are included in a common decomposition hierarchy of business functionality, bringing the confusion and difficulties described in Dividing the Enterprise.

It is common that in such methodologies both WHAT business needs to do and HOW it does that, are bundled together, although it is clear that WHAT business needs to do could be implemented/realized by many different ways of doing this (i.e., many different business processes), and in some cases it might be not known/decided yet.

Because the purpose of business processes is to implement/realize the business capabilities, and because for a given business capability there could be zero-to-many business processes, business capabilities are actually a good choice to group together a set of business processes, the same way as business capabilities are a good choice to group together also other enterprise/business architecture elements, needed to implement/realize them (see Open Group TOGAF Business Capability).

Some definitions:

Many authors are claiming that architecture of (software) systems is abstract – a good example is ISO standard on systems architecture description (see ISO 42010) (where it is also added that “architecture is … not an artifact”).

According to the Cambridge Dictionary abstract, being an opposite of concrete, means “existing as idea, feeling, or quality, not a material object” (see Cambridge Dictionary : abstract). One of the important characteristic of the abstract things is that these are considered non-causal (see Stanford Encyclopedia of Philosophy) – that is, abstract things cannot be cause of anything.

If we follow the rather largely accepted definition of (software) systems architecture (for various definitions, see for example CMU SEI), according to which the architecture has been defined as consisting of following three parts:

• a set of the components (or elements) of the software system,
• a set of the connections (or relationships) between the components themselves, and between the components of the software system and its environment,
• a set of rules and principles guiding the design and evolution of the software system (incl. rules what kind of components, and what kind of connections the software system can contain).

Then we cannot always treat the architecture of (software) systems as abstract, because architecture of an existing (software) system is embedded in the structure of that system (at least this part of the architecture that is consisting of the elements and relationships), and therefore it is real/concrete in the same way that given system is real/concrete.

Architecture of a (software) system exists “within” the (software) system, and can be observed and recaptured/recovered from the (software) system after it is built, even if the specific description of the architecture, which was used during the building of that (software) system is lost.

We can have different perceptions or conceptions of architecture of a (software) system, and we can describe these perceptions or conceptions in different ways from different viewpoints and on different levels of detail, but that does not make the architecture itself abstract.

But because the (software) systems architecture is based on the ideas and principles that define how to divide the system into the components and connections, then we can say that (software) systems architecture is always conceptual (according to Cambridge Dictionary, conceptual means “based on the ideas or principles”, see Cambridge Dictionary : conceptual).

Only in the case when the actual (software) system is not yet built (i.e., not yet existing), the architecture of such (software) system, described in the plans and design documents, can be considered abstract (i.e., existing only as an idea).

The important implication of (software) system architecture not being just an abstract, but a real/concrete thing, is that:

• architecture influences the actual qualities and behavior of the (software) system, that is (software) system architecture can be cause of certain things (but, as we saw above, abstract things are considered as non-causal, see Stanford Encyclopedia of Philosophy), and
• architecture is something that can be acted upon – it would be possible through the changes of the (software) system, change the architecture of that (software) system.

It is usual, that different disciplines, which deal with the analysis and design activities of an enterprise from different viewpoints and for different purposes, divide the whole enterprise based on their primary interests and according to the main methodologies in their area, organizing the elements that describe the enterprise according to different criteria.

This could be illustrated for couple of such disciplines (process modeling/management, information modeling/management and applications modeling/management) for example as follows:

Because for both analysis and design these elements are usually needed to be viewed/described in their context(s) (e.g. processes create and use some information and are supported by certain applications; applications master, provide and consume certain information; etc.), this leads to the need of connecting the elements identified/used by different disciplines, to avoid creating several separate and possibly inconsistent views on the same enterprise.

This all leads to the following problems:

• Multiple different decomposition hierarchies will be created, from different viewpoints, for different purposes, and by using different methodologies, and these are usually created/maintained by separate communities of practice – this tends to lead to multiple inconsistent and non-reconciled views on the (same) enterprise.
• It will be difficult to decide upon the primary decomposition hierarchy, which should be used to organize the whole picture (and all its elements), because of the different interest groups / stakeholders, different communities of practice and different methodologies used to create these decomposition hierarchies – this will lead to the situation, where each of these disciplines tend to maintain their own context(s) needed for their primary elements, creating duplicate representations, neither of which provide the holistic view of the enterprise.
• Due to the need for context, multiple different type of relationships will be crossing the various decomposition hierarchies to connect things on right hierarchy levels – such relationships are usually difficult to maintain, as different ends need to be agreed by different communities of practice and there’s no natural master/owner for the relationship.
• Because the relationships that cross the different hierarchies are most often connected to the leaf elements of these hierarchies, all decomposition hierarchies need to be fully developed until the relationships that cross the decomposition hierarchies can be created – which leads to the need of coordinating large efforts between the different communities of practice and difficulties in sequencing these efforts (e.g., due to the circular dependencies).
• In several of the disciplines of analyzing and developing the enterprise, there is an additional problem, making creation and maintenance of these decomposition hierarchies difficult – from certain decomposition level the main element and sometimes also criteria for decomposition change.
  For example:
  • processes on different decomposition levels are rather different things (therefore apart of the name also the level number becomes important to understand what we are dealing with) and the leafs of process hierarchies are usually tasks and other elements, which are not processes at all;
  • information decomposition starts usually with the subject areas, progresses to entities and ends with the attributes;
  • application decomposition also starts with the groups of applications, progresses to the applications and depending on the needs and methods might end with several levels of application components;
  • etc.

To avoid all these problems we should decompose the whole enterprise only according to one criterion, and do this recursively, breaking the enterprise into the self-similar smaller pieces (self-contained parts of the enterprise), which could be thought of possible to completely outsource to some other enterprise (if needed). Only at the final level of decomposition, in the leafs of such decomposition hierarchy other elements, that describe the enterprise (or parts of an enterprise), appear. Therefore such decomposition will collect together and organize according to the same schema all the various elements used in the analysis and design of the enterprise.

Such decomposition could be represented as follows:

And this leads to the following benefits:

• Only single decomposition hierarchy to maintain – easier governance, and on every level of decomposition we will have a holistic view of the particular part of the enterprise, containing all the necessary elements for analysis and design.
  Same single decomposition could also be used to conduct and present strategic analyses on the enterprise (e.g., using “heat-mapping” to identify places where the changes are needed and will provide most strategic value, etc.).
• Only the relationships of single type “serving” are crossing the decomposition hierarchy levels (i.e., are showing how various parts of the enterprise are serving each other), and all the other relationships between the elements are nicely contained within the particular part of the enterprise – which leads to easier maintenance of such relationships.
  Such networks of parts inside the enterprise form a value network (as opposite to the set of linear value streams used by many other methodologies), which gives a more realistic picture of the value creation inside the enterprise.
• The decomposition hierarchy doesn’t need to be fully developed for describing:
  
  • the relationships between the “leaf” elements, as these all are contained in a single part of the enterprise, and
  • the relationships that cross the decomposition hierarchy levels, as it would be possible to start from the derived/compound relationships between the higher level parts and decompose such relationships according to same criterion as the whole enterprise is decomposed.
  Due to that it will be possible to organize the work so that detailed representations of both the parts of the enterprise and the relationships between those parts are developed “on-demand” (i.e., only for these places in the enterprise that need it due to the analysis needs or planned change).
• The task of coordination between the different communities of practice and stakeholders is simpler and analysis and design tasks themselves become smaller due to the division of work following the decomposition of the enterprise – because all different interest groups / stakeholders and different methodologies work together on the holistic picture on every level of hierarchy, and due to smaller tasks/efforts concerning single parts of the enterprise.
• When created, such hierarchical decomposition becomes a “blueprint” for the ideal organization for the given enterprise, which would give hints for and could drive the development of overall organization.

Such decomposition method has been earlier described and employed for example by:

• IBM as Component Business Model, where the self-contained parts of enterprise are name “business components” (see IBM Component Business Models. Making Specialization Real and IBM banking Architecture) and
• BIAN as Service Landscape, where the self-contained parts of the enterprise are named “service domains” (see BIAN Semantic API Practicioners' Guide).

Although in some cases business capabilities are defined nearly the same way (see Archimate 3.2 Capability and TOGAF Business Capability), many business capability models are built in such a way that business capabilities in these models cannot be viewed as self-contained parts of the enterprise (which could be possibly outsourced), therefore not representing holistic parts in the recursive decomposition of whole enterprise.

A good description of the problems involved by negotiating such business capability model with the decomposition of the enterprise done according to the way, described above (i.e., Service Landscape) is provided lately by BIAN (see BIAN BCM Relationship with BIAN Service Landscape).

So, what we should consider as an architectural change of the software system?

In many previous works on software systems architecture, the architecture has been defined as consisting of following three parts:

• a set of the components (or elements) of the software system,
• a set of the connections (or relationships) between the components themselves, and between the components of the software system and its environment,
• a set of rules and principles guiding the design and evolution of the software system (incl. rules what kind of components, and what kind of connections the software system can contain).

For example the definition of (software system) architecture, adopted by many standards organizations, the (software system) architecture is "fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution" (e.g. ANSI, IEEE and ISO).

That definition, which is revolving around building a structure for certain purpose, is well in sync with the definition of architecture in civil engineering (by which the discipline of software architecture is inspired), where architecture is mainly seen as “the art or practice of designing and building structures and especially habitable ones” [Merriam Webster].

Although the latest incarnation of the ISO standard on systems architecture description [ISO 42010:2022] has for some reason dropped “elements and relationships” from the definition of system architecture, I will stick with the previous definition, as the elements and their relationships of the software system, which representing how the software system is built, are the most important things to consider in the context of the change of the system.

To clarify what is the architectural change, we need to bring in one more concept – the architecture style – which represents what is architecturally common to a family of software systems, being a kind of design language for the software system architectures, and is usually seen as consisting of following things [Garlan & Shaw, Shaw & Clements and SEI CMU]:

• a set (or vocabulary) of component types,
• a set (or vocabulary) of connection types,
• set of constraints/rules, which need to be true for all the architectures in given architecture style.

Well known architecture styles are for example: data flow (a.k.a. pipes and filters), data centered (a.k.a. repository) repository, layered systems, etc. [Garlan & Shaw].

Now, based on these definitions, we can define what we mean by the change of architecture (or architectural change) of the software system.

Two first ones are simple and local, because they do not affect the architecture style of the system, but the last one is in nature complex, as it can affect the architecture of the system globally, and can lead to the change of the software system architecture style (e.g. by changing set of allowed component and/or connection types, and the way how the software system can be built using the components and connections).

Simple description of architectural changes could be given by coloring the corresponding elements on the diagram ("green" for additions and "red" for removal):

Defining architectural change this way means for example, that if the existing rules and principles of a software system architecture allow implementation of components on several platforms, then reimplementing an existing component on different platform, allowed by the architectural rules and principles, is not an architectural change. But if the new platform is not yet included into the architecture rules and principles and will be by this change, then this change is an architectural change.

If the change is such that the meaning/purpose of one component or connection has been changed, then this must be considered as being equal to the removal of the old component or connection and introduction of a new component or connection.

A good example of the later case is (a rater usual case of) change of the core schema of a central database (or repository) of a repository-centric system in case there has not been established any interface schemas for connections with the processing components of the system or otherwise insulating those from the central database (or repository), we in architectural sense actually replace one (in this case very central) component and all its connections to all other components.

Therefore one, seemingly small, change becomes actually a massive architectural change, affecting whole system (causing cascading changes and possibly leading to many unanticipated side-effects).

If we consider the simple measure of the complexity of software system the number of components and connections (see Complexity in/of the enterprise architecture), then this way of treating the architectural changes allows us also simply measure the effect of the changes to the complexity of the architecture, by the added/removed components and connections.

Although the reasoning above is about the architecture change of the software systems, the formulation of systems architecture as a set of components, their interconnections and rules of composition, does not rule out any other types of systems -- so we can apply same definition of architecture change also to the business system (or to the combinations of both business and technology systems).

So what's the relationship between architecture and agile methods, if there's any?

If we take the definition of (system) architecture adopted by many standards organizations, which is "fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution" (e.g. ANSI/IEEE/ISO 42010), then we could rest assured, that whatever is the method or way of developing the software system, it will always have an architecture – that is, architecture will emerge when we develop the software system.

From the studies of the different styles of software architecture we can see that software systems, that peform the same function, can have rather different architectures – so why to bother?

The problem is raised, because apart form the function that software system performs, we often are interested of some other properties of the software system (usually specified as non-functional requirements towards the software system), and because software system architecture is the cause of many important properties of the software system, which are usually requested by several stakeholders.

The core of the agile methods is to design and build the software systems piece-wise, but while the functionality of the software system is usually possible to divide into pieces or decompose rather easily, the software system architecture, being a set of global structures, affecting the software system as a whole, does not lend itself to such treatment. Usually some global structures, that define the software system architecture need to be first developed and completely built (at least up to certain level of completeness), to be able to implement the pieces of the functionality (i.e. system functions).

SAFe represents the larger pieces of the system functionality (or system functions) by the capabilities, which themselves can be decomposed into smaller pieces of functionality, called features (see Features and Capabilities in SAFE).

Admitting the insufficiency of the emerging architecture alone and agreeing to the need for the intentional architecture of the software systems, SAFe proposes an Architectural Runay as implementation of software system architecture (i.e. the code and infrastructure needed to implement the features), which can be itself evolved/extended by implementing the Enablers.

So far so good, but to be able to divide the work so that we can build first just a part of the software system architecture, needed for a set of features, we need to be able to map these features onto the software system architecture, for which we need the full architecture designed first.

Therefore, in the best case, we can build the implementation of the software system architecture piece-by-piece, but before that we need to design it as a whole. Another slight complication is the global nature of the software system architecture structures – if for any reason we need to change the software system architecture in such a way that is not supported by the extension mechanisms of the existing architecture of the software system, we need to implement the new software systems architecture an then re-implement/-build all the features that have been built so far (because the system architecture defines how the features are built). All development teams try to avoid later as long as possible, as a very costly exercise.

Another complication arises from the fact that, if the overall software system will be designed and developed incrementally as a response to the stream of requirements stated by the stakeholders, the software system architecture will very much depend on the order in which these requirements arrive.

For example if we build the communication system (e.g. a chat system) and the requirement for high security of personal information and communications is received within the first requirements, this might lead to the selection of an architectural style of independent components, where none of the components has complete knowledge of all the users and communications within the system, but if this requirement is not received early enough, then it would be natural to select the architectural style with central reporsitory for users and communications.

When now the requirement for high security of personal information and communications arrives, there could not be possibility to completely re-implement the system according to different architectural style, and therefore architects might select compensating techniques, adding encryption fo a central datastore, leaving the architecture of the system same (which will not meet the requirements in best possible way).

Recently I stumbled upon a strange „feature“ of ArchiMate language that brings some ambiguity into the models.

In the ArchiMate specification (see Open Group ArchiMate 3.1) chapter 3.6 is written „The ArchiMate language intentionally does not support a difference between types and instances.“.

This design decisions brings ambiguity into the meaning of the diagrams. For example, what is described inthe following diagram:

Does this mean that:

• „There exists a set of data objects of type A, each consisting of 'one-or-more' data objects of type B, and 'one-or-more' data objects of type C“, or
• „There exists a data object A, which consists of data object B and data object C“, or even some mix like
• „There exists a data object A, which consists of 'one-or-more' data objects of type B, and a data object C“?

There are situations, where it would be possible to deduce, whether diagram is describing the types or instances (because for example certain reflexive relationships, like „composition“, would not make sense for the instances), like:

But in some cases it would be impossible to know without some indication of what kinds ofelements are in the model or on the diagram, like:

Therefore indicate the usage of types or instances explicitly, using for example through ArchiMate specializations (similar to UML sterotypes) and the naming convention similar to UML, either for the types:

or for the instances:

Although in ArchiMate specification it is stated that „At theEnterprise Architecture abstraction level, it is more common to model types and/or exemplars rather than instances.“, there are still many cases where the model of the actual enterprise architecture consists of instances (like capability maps, process maps, or application landscapes, which all represent certain enterprise portfolios), and therefore it makes sense to clearly indicate on the diagrams, where are the types (for example when describing conceptual models or solution patterns) and where are the instances, especially if both are mixed on the diagram.

I have seen many times the wish to fix the number of levels in the decomposition hierarchies (like for example in the maps of business capabilities), with the reasoning that it would make things easier by always having known number of levels. One result of this approach is the appearance of branches with single elements on certain levels.

There are such hierarchies, where the elements with just one sub-element will make sense, and there are other hierarchies, where this doesn’t make sense.

For example in case of taxonomy, each element is representing a set of features – it is a class hierarchy.

In the class hierarchy it makes sense to have even single sub-class for a particular class, because this sub-class represents a different set of features than its super-class. It also could make sense in class hierarchy, if needed, to have a fixed number of levels – because on each level of each branch you have different set of features (which you can distribute evenly).

It makes sense to have:

either , or .

On the other hand, in case of functional decomposition,like hierarchy of business capabilities or application components, each element is a whole – it is a composition hierarchy.

In the composition hierarchy(which consists of instances, not of classes) it doesn’t make sense to have an element that has only one part, because these are then the same thing.

It makes sense to have:

, but not .

It also would not make sense in the decomposition hierarchy to have fixed set of levels – because this would either enforce the designers to come up with "dummy" levels just to follow the scheme, and results decomposition that is not natural, causing branches with single elements just to „fill“ the levels of hierarchy, introducing multiple ways to name what actually is the same thing.

This is the reason I wouldn't advise to create for example business capabilities with only one sub-capability or application components with only one sub-component.

I see more and more, that the usage of models (referring to traditionally used qualitative, often graphical, models and modeling languages) and model building is diminishing in the software engineering (if we can talk about the software "engineering" anymore at all).

The reason seems to be that developers do not want to use the models and therefore making or maintaining these is perceived as "no-value" overhead. Behind the reluctance of developers to use models is often the agile movement's argument that everything could be seen/found from the code, and because in DevOps same team that does the development, does also maintenance, there’s also no need to communicate between different teams.

But actually:

• it is very difficult, if not impossible, to write code so that all the requirements or high-level design decisions would be presented directly in the code (not to mention being easily readable/understandable for the ones that did not write the code),
• it costs time and money if developers make mistakes because they are not able to understand from the code the requirements it implements and the design intents/constraints, and
• it costs even more time and money if developers go away and need to be replaced by new ones who don’t know anything what has been said "at the water-cooler" (possibly two or more years ago).

Because additional information (same that has been traditionally represented by the models) is needed and because code isn’t usually very much commented and often also not very readable,so often developers and others, involved in the software development activities, try to find other ways to collect and maintain this additional information, representing it usually in non-formalized textual form in their work-organization tools (e.g. Confluence wiki and in Jira tasks).

Additional reason to drop models in the software development in favor of informal textual descriptions, seems to be the inability to automate anything in software development process apart from the simple "automation" of build tools to manipulate software artifacts in correct succession (thing that has been around already past 60 years) – so there’s no perceived value to have requirements or high-level abstract knowledge about the software to be represented in machine-readable form.

Today still a very big part of the development of business software is solving rather standard/common problems and is filled with the repeating tasks, which are very easily automated (like development of GUIs (where they are not the distinguishing factor), integrations, transformations, reports, etc.), and doing so would economize a lot of development time, but this will be only possible, if the requirements and high-level design would be formally specified and represented in a machine readable form.

So, the main question is "Dowe want/need to automate also our software development activities?", or do we just want to automate only the various business activities and continue with manual software development?

If we want to automate software development (i.e. digitalize the software development), we need a formal, machine readable, representation of requirements and high-level designs (with the focus on formalization and machine readability, not just some pictures with "boxes and arrows"), in the same way as for example to automate the credit origination, we need formal representation of customer, loan, collateral, sales process, involved business rules, etc.

Lately the question of automating the development of software has turned towards AI (using large language models trained on the existing code).

The problem with this approach is, that because the models developed by the machine learning are non human-readable and non-transparent to the users, the way to control and guide the generative AI is via prompts, which quickly becomes rathere similar problem as controlling and guiding the human developers through the natuaral language (which is ambiguous by nature).

The term “business capability” is synonymous with BIAN “Service Domain” (see BIAN Practitioners Guide), with “business component”in IBM’s CBM methodology (see Component Business Models), and with “business function” in general business management.

A “business capability” describes ability to perform certain set of related activities for providing a set of business services, by combining people, processes, resources(incl. needed technological systems) and governance, using the business services from other business capabilities, if needed.

Where “business service” describes externally visible unit of business functionality of a business capability, which provides value to service consumers, is provided via explicit external interfaces, and realized by business processes.

You can think of a business capability as a self-contained part of business that could be outsourced as is.

Business capabilities themselves can be hierarchically sub-divided into smaller business capabilities if needed, or combined into larger business capabilities up to a business capability to provide all the services of a certain business (for example to provide all banking services).

Business capabilities are connected to other business capabilities through the business services and form a value network.

The business capabilities for a given business domain can be found/formulated, taking as the starting point the lists of key activities needed for all the business models of given business domain. The set of business capabilities describes what things given business domain must be able to do, to support the business strategy and execute the business models.

1. Prerequisite is the traditional architectural layering of application, where:
   1. Presentation layer contains only "presentation logic" -- code, that is needed to organize the presentation (mapping) of business information on screen, and to accept and validate the user input from the input devices (e.g. keyboard and mouse). Presentation layer is usually specific to the given user interface device (e.g. web, GUI, mobile phone, ...). As much as possible presentation logic should be declarative (e.g. layout and mappings) or generated.
   2. Business Process layer contains "process logic" -- code, that integrates the business functions into business processes, organizes the access to the business rules, and flow of control and information through the business functions. Business process layer manages conversational state and business transactions (sessions). Externalization of process logic and business rules allows easy reconfiguration of business functionality and provides flexibility required by the business. Business rules should be side-effect free and as much as possible declarative.
   3. Business Service layer contains "business logic" -- code, that performs transactional business functions or business services, packaged into business service components (usually business functions are grouped around "subject areas" -- e.g. business functions dealing with same business information should be grouped together). Business functions are usually transactional and stateless, they delegate all the state-management and data-intensive functionality to the database layer components. Business service layer could be further divided into two sub-layers: complex business functions and elementary business functions that are reused by the complex business functions to perform their task. Statelessness of business services allows easy scalability by deploying more instances of business service components.
   4. Database layer contains "data access/processing logic" -- that is code, that encapsulates access to business data (implements mappings to data store structures), enforces syntactic integrity constraints on business data, and performs or delegates data-intensive business functions to the data store execution engine (stored procedures). As much as possible data access logic should be declarative (e.g. mappings) or generated.
   5. Integration layer contains "integration logic" -- that is code, that encapsulates connections to other applications (implements mappings to external data formats, and manages conversational state connected to integration). As much as possible integration logic should be declarative (e.g. mappings) or generated.


2. All layers could be, if needed, distributed over different processes and/or computers.

1. To identify what is the business functionality in given application, following question should be asked: "What remains unchanged, if the user interface and data storage technologies will change?".


2. As much as possible (when using J2EE platform):
   1. All presentation logic should be implemented in presentation layer (using JavaScript/Java or Flex or whatever has chosen).
   2. All process logic, management of conversational state, and business rules should be implemented in business process layer (using BPEL/Java).
   3. All business functions that do not need large amount of data should be implemented in business service layer as business services (using Java).
   4. All business functions that need large amount of data should be implemented in database layer (using stored procedures).
   5. All business state should be managed in database.


3. Interfaces for business functions should (when using J2EE platform):
   1. Be defined using Java (and all bindings to other systems (e.g. WSDL/XSD for WS) will be generated from the service interface definitions),
   2. Should be coarse-grained to avoid latency problems related to the remote access,
   3. Conform to rules for remotable interfaces (take into account that methods could be called remotely),
   4. Always have a service context (representing business context, time context and technical context) as a required input/output argument of every method (this could be used for carrying conversational state is such need will arise -- e.g. partitioning result of a method that returns large amount of data),
   5. Contain extension points that could be used to extend/customize the business function (without changing the public interface of business function),
   6. Use synthetic technical IDs or keys (which should not containing business data) to represent identities of business objects in the interface (such IDs should be considered temporary -- e.g. users of business functions should not rely that they are same in successive uses of given business function),
   7. Use return values for communicating business exceptions,
   8. Use Java exceptions only for technical exceptions.
   9. Be documented according to the JavaDoc best practices, so that for every method in the service interface following is described:
      1. The business function performed ("what"),
      2. The meaning of input and output parameters,
      3. The meaning of technical exceptions,
      4. The purpose and usage of the method illustrated with examples.


4. Business service components should have following interfaces:
   1. Business service interfaces, through which all business functions that given business service component offers, could be accessed.
      If needed business service should have two separate business service interfaces with different granularity to be used for different situations:
      1. Fine-grained interface (where single transaction requires small amount of data and provides small piece of business functionality) for local usage where transport mechanism provides low-latency connection to the service component, and
      2. Coarse-grained interface (where single transaction requires large amount of data and provides large piece of business functionality) for remote usage where transport mechanism provides high-latency connection to the service component.
   2. Configuration interface, through which the variability offered by the business service component is configured (usually during setup/startup process).
   3. Management interface, through which service component could be identified (for configuration identification) and managed during run-time.
   4. Service provider interfaces for other business or supporting services that given business service component requires for performing its functions


5. Reusable assets should be treated same way as third-party products:
   1. Reusable assets should have:
      1. Dedicated development team.
      2. Its own development goals, roadmap (together with a process for collecting feature requests), and release cycle (changes to the public interfaces should be done through deprecation and phase-off cycle).
      3. A support service (together with a process for reacting to the defect reports and releasing fix-packs).
   2. Reusable asset should be isolated from the "client code" by isolation and customization layer.
   3. Package of reusable asset should contain:
      1. Release notes.
      2. Developer's package:
         1. Programmer's Guide;
         2. Programmer's Reference;
         3. Installation scripts and database scripts (creation and upgrade);
         4. Interface definitions;
         5. Development binaries (if such are different from production binaries) and parameter files;
         6. Source code for debugging purposes;
         7. Development dependencies (if such are different from production dependencies);
         8. Usage (and customization) example(s) with the build scripts.
      3. Operational package:
         1. Installation and Configuration Guide;
         2. Operation and Administration Guide;
         3. Installation scripts and database scripts (creation and upgrade);
         4. Production binaries and parameter files;
         5. Production dependencies.