Ana Brenes

Ana Brenes
ERNI Switzerland


In the current Digital Era, the concept of architecture is fundamental yet very often misunderstood, misused, and ill-practiced. In almost any company, software is required to do business, even if software is not directly produced.

Architecture (and those who practice it) always focuses on a particular subject or set thereof. This subject or group of subjects can be any of the following: an organisation, a solution, a product, an application, a system, or a component.

I will use a “Saga” to explain what is behind the words Architecture, Architects, and Agile. I believe that currently, there are misunderstandings behind each of these concepts, and I would like to try to bring some clarity using my years of experience. At the very least, I expect that after these articles, readers will have a better framework to use their thinking capacity when confronted with any of these words in the future.

The first article will cover the first element of the Triad: Architecture. I will set the context in which the concept shall be understood, provide a definition, and use examples to describe it.


What is Triple-A? Why a Triad?

Behind Triple-A, there is the highest competitive level of achievement. But not in the context of a credit rating agency, baseball, gaming, military, or any other industry. It is no surprise that this concept is generally associated with high quality. Triads have been of significant importance in myths and cultures since ancient times. For example, there are well-known trinities like “Mind, Body, Spirit”; “Mother, Father, Child”; “Past, Present, Future”; and “Power, Intellect, Love”, amongst others. All of these are known triad concepts. The number three can be described as having a mystical aspect and is also related to balance. The number two is an expression of the ultimate expression of balance. Still, three is an evolution of that balance: a set of influences and energies forming an exquisite balance.

In our digital world, one of the primary artefacts used is Software. Software is anything used in the organisation to provide a “service.” This “service” runs on a computer or device (virtually or physically running). The software can be as simple as a program that enables a fax or printer to work, or one needed to start a computer, or applications like Word or Excel, or the Accounting and HR applications in an organisation, or the ones used to run a bank, or do complex calculations, the ones predicting customer behaviours (machine learning) or making a robot walk. In all these examples, the software is needed and is required.

Most of what we do today in our daily life, for work, fun, and communication, requires software. Most organisations today cannot do what they do without using software. In this reality, it is of utmost importance to make things work for the greater good of humanity: we need to bring order and orchestration to these new “human-created logical/virtual worlds.” Here is where Architecture, Architects, and Agile come into play.


Architecture: Let us set the framework

Architecture has many different perspectives. I find exceptionally fitting the picture of an elevator (see Figure 1) like the one in the article “The Architect Elevator – Visiting the upper floors” (Hohpe, 2017). The main idea is that depending on which floor the elevator is, the concerns to be addressed are different and need to be adjusted to the audience. And consequently, the required involvement and skills of the practitioner (the Architect getting out of the elevator) are different and need to be adjusted to the audience.

Figure 1 – The Elevator Metaphor
Figure 1 – The Elevator Metaphor


For example, if we are considering architecture from an Enterprise perspective, the kinds of artefacts needed (Business Capability Maps, Catalogues, Principles, Processes, Best Practices, etc.) are very different than if we are considering architecture from an Application (Software) perspective where other artefacts are needed (Context Diagram, Execution Diagram, Sequence Diagrams, Component Diagram, Data Flow Diagram, etc.).

Since the areas of applicability in architecture are manifold, so are the skills, type of work, and artefacts needed; part of the difference is the form and detail in which it shall be addressed.

The key to the success of any architecture is communication (besides the fact that it needs to be adequate for the problem at hand). Communication shall not automatically imply cumbersome or heavy, and this is where creativity takes an important role: find the right level of detail, the best medium to communicate and preserve, and the best process to enable its evolution.

Since Architecture is not just done for its own sake (hopefully), we need to consider the ecosystem in which it takes place: an organisation, a product, a solution, an application, a system, etc. It is here also where there are different strategies to get things done. And the strategies for getting things done are as manifold as the cultures or species in nature.

Over time, many methodologies were created and used to get things done (Waterfall Approach, Extreme programming, SCRUM, Feature-Driven Development, Dynamic Systems Development Method, Crystal Clear, or other frameworks). Some of them are what one could say is the concept of Agile, and some are not. I will address this last concept in the last part of the saga.


Architecture: The important stuff

Martin Fowler, in his paper “Who Needs an Architect” (Fowler, 2003), shared the thoughts of Ralph Johnson about architecture. He said, “Architecture is about the important stuff. Whatever that is”. I agree with that statement and would like to extend it, in that it is also about communicating this (important stuff) to the relevant people.

Before software existed (before the 1940s), several concepts were unthought computers, computation, software engineering, or software architecture. In fact, yes, there were already some mechanical calculators created as early as 1623 (Wikipedia, Wilhelm Schickard, 2022) and then later the first “Difference Engine” in around 1822 (Wikipedia, Computer Science, 2022). This was the closest to the beginning of something like the first computer and maybe a primitive type of software.

Let’s think of the word architecture. The traditional definition of architecture says, “the art and technique of designing and building” (Encyclopaedia Britannica) as applied to physical buildings or any physical structure. It is also clear that there is a difference between this and the skills associated with construction. Architecture implies the need to fulfil some practical and expressive requirements, and traditionally speaking, it should satisfy the following main goals:

  1. It should be suitable to be used by humans in general and to adapt to human activities;
  2. It should be stable and permanent; and
  3. it should communicate a particular experience and ideas by its chosen form.

Although this definition is taken from the Encyclopaedia Britannica and was made long before the concept of software existed, I nevertheless believe it is very applicable.

After software was created, myriad new concepts were born like software engineering, design, architecture, development, methodologies, etc. The world as it was known began changing, and new concepts came to “life” and had many other implications that no one could have thought of before.

Yet I think this architecture definition can still apply to the “new world,” where the leading “players” are an organisation and the digital products needed to run it.

Many well-known experts have tried to explain or find a suitable definition for architecture from the software perspective. Many attempts have been made, leading to confusion and discussions; they are either too general or too specific.

When talking about architecture, in this part of the saga, the context is related to software. One example from the ample number of definitions is Carnegie Mellon University’s compendium of software architecture definitions (CMU, 2017). An excellent example of why chaos and confusion exist.

I use a simple and structured approach when trying to understand a concept. Take a general enough definition of the concept (in this case, architecture) and then apply it to the aspect I am thinking about.

I will take the following definitions of architecture as baselines:

  • “The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution” (ISO/IEC/IEEE-42010, 2022)
  • “(1) A formal description of a system, or a detailed system plan at the component level to guide its implementation.  (2) The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time” (TOG, 2018)

They both give a very good idea of what Architecture is – somehow abstract yet simple enough. I personally prefer the first one from IEEE, assuming that a system can be anything from a simple program to an organisation.

I use this definition and apply it to the different aspects or areas of concern (software) and then can imagine that the artefacts and type of work can and will be different.

I will use some examples to explain this. Let us take Enterprise Architecture, Business Architecture, Solution Architecture, and Application Architecture (sometimes also known as Software or System Architecture) and present some concrete examples of what “the important things are” in them.

In Business Architecture, the goal is to model, address, and drive the business that is done in the organisation.

What would be necessary for this context? It is essential to understand the nature of the business that the company does, what all the capabilities are, how value is generated, how this is mapped to the organisation, how the process is also mapped to the previous artefacts, and how the company will need to operate to achieve the business goals and respond to strategic drivers, etc.

In this domain, some artefacts used are Business Capability Map, a Value Stream definition and mapping, Organisation Mapping, Stakeholder Map, etc.

Examples of a few artefacts generated in this domain are shown in Figures 2 and 3.

Figure 2 – Business Capability Map


Figure 3 – Value Stream Diagram


Enterprise Architecture (EA)’s main subject is organisation and business strategies.

What would be necessary for this context? It would be essential to know what the organisation’s vision is; what the main goals are; the structure; the principles, guidelines, and standards; what the business architecture is; etc. All those aspects are essential to driving the Enterprise (Organisation) to achieve the desired goals (financial or strategical, or otherwise relevant).

One important note here is that the other architecture domains shall be guided from the context of the EA, except in relation to the Business Architecture, which will instead be a complement and shall drive the EA.

An example of an artefact generated in this domain is presented in Figure 4.

Figure 4 – Business Principal Example


In Solution Architecture, the main subject is a solution that resolves a business problem, which usually goes beyond a simple application or system. It will likely include several software components, hardware components, information, and resources needed to resolve a particular business need. This implies working within the constraints established by the Enterprise Architecture and defining the integration needs of the existing assets or those that may need to be acquired or created.

What would be necessary for this context? In this domain, it is essential to know what the principles, guidelines, or best practices are that define the constraints of the solution; what the existing applications are that may need to be created or acquired; what kind of communication is required between them; what kind of gaps exist and whether they will be covered and when; etc.

An example of an artefact generated in this domain is shown in Figure 5.

Figure 5 – Solution Architecture Diagram


In Software Architecture (as well as Application Architecture), the main subject is the internal behaviour of a given application or system.

What would be necessary for this context? In this case, we are interested in patterns that can be used, design and coding techniques, services and how they interact with others, etc.

The view here mainly focuses on the application or system at hand, how it works, how it resolves the business, and how it interacts with others (users, systems, or any stakeholder) outside its environment.

For example, some common artefacts in this domain are a class diagram or a sequence diagram.

Figure 6 – Class Diagram


Figure 7 – Sequence Diagram


By now, I have given you a definition of architecture and presented you directly with the “important things” in different areas. The “important things” need to be used (they shall be understood, documented, accessible, and can evolve); otherwise, they are unnecessary. Here is where the next element of the triad plays a significant role. The “enabler” is responsible for creating and communicating the “important things,” the Architect. In the next part of my saga, I will present the primary skills and responsibilities and explain the differences between the different types of architects required in this “Digital Era.”




AManifestoGroup. (2001). Agile Manifesto. Retrieved from Agile Manifesto:

CMU. (2017, January 22). What is your definition of software architecture? Retrieved from

EARForum. (n.d.). Enterprise Architecture Definition. Retrieved from Enterprise Architecture Research Forum:

Encyclopaedia Britannica, 8th ed. Chicago: Encyclopaedia Britannica, 2009

Fowler, M. (2003, July/August). Who Needs an Architect? Retrieved from

Hohpe, G. (2017, May 24). The Architect Elevator – Visiting the upper floors. Retrieved from

ISO/IEC/IEEE-42010. (2022, January 8). Defining Architecture. Retrieved from Systems and software engineering – Architecture description:

TOG, T. O. (2018). Core Concepts. Retrieved from TOGAF Standard, Version 9.2:

Wikipedia. (2022). Computer Science. Retrieved from

Wikipedia. (2022). Wilhelm Schickard. Retrieved from



News from ERNI

In our newsroom, you find all our articles, blogs and series entries in one place.

  • 06.12.2023.

    Streamlining software development: The journey from multiple to unified requirements management tools

    Productivity in software development is slowed down by managing specifications across various requirements management (RM) tools. Although moving to a single, updated RM tool involves an upfront investment, the long-term benefits are considerable. These include increased process efficiency, enhanced collaboration, superior traceability, improved software specification quality, cost reductions, scalability and better integration with other RM tools, among others.

  • 22.11.2023.

    Recognising trends: An insight into regression analysis

    Data plays a very important role in every area of a company. When it comes to data, a distinction is made primarily between operational data and dispositive data. Operational data play an important role, especially in day-to-day business. However, they are not nearly as relevant as dispositive data. This is because these data are collected over a longer period of time and provide an initial insight into the history or the past.

  • 08.11.2023.

    Why do we need digital transformation for medical devices?

    For hospitals, it is not up for discussion as to whether they want to digitalise. The increasing age of the population in western countries and the progressive shortage of medical professionals mean that without digitalisation, the healthcare system will not be able to provide the quality that patients want in the future.

  • 25.10.2023.

    Mastering the challenges of mobile app testing: Strategies for efficient quality assurance

    Discover the unique challenges faced in testing mobile applications and learn how to overcome them effectively. From selecting suitable devices and operating systems to leveraging cloud-based test platforms, test automation and emulators, this article provides seven essential strategies for optimising your mobile app testing process.

  • 11.10.2023.

    Incorporating classical requirements engineering methods in agile software development for a laboratory automation system

    Traditional agile methodologies can sometimes struggle to accommodate the complexity and regulatory requirements of laboratory automation systems, leading to misalignment with stakeholder needs, scope creep, and potential delays. The lack of comprehensive requirements documentation can result in ambiguous expectations and hinder effective communication among cross-functional teams.

  • 27.09.2023.

    Unveiling the power of data: Part III – Navigating challenges and harnessing insights in data-driven projects

    Transforming an idea into a successful machine learning (ML)-based product involves navigating various challenges. In this final part of our series, we delve into two crucial aspects: ensuring 24/7 operation of the product and prioritising user experience (UX).

  • 13.09.2023.

    Exploring Language Models: An overview of LLMs and their practical implementation

    Generative AI models have recently amazed with unprecedented outputs, such as hyper-realistic images, diverse music, coherent texts, and synthetic videos, sparking excitement. Despite this progress, addressing ethical and societal concerns is crucial for responsible and beneficial utilization, guarding against issues like misinformation and manipulation in this AI-powered creative era.

  • 01.09.2023.

    Peter Zuber becomes the new Managing Director of ERNI Switzerland

    ERNI is setting an agenda for growth and innovation with the appointment of Peter Zuber as Managing Director of the Swiss business unit. With his previous experience and expertise, he will further expand the positioning of ERNI Switzerland, as a leading consulting firm for software development and digital innovation.