Abstract
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.
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:
- It should be suitable to be used by humans in general and to adapt to human activities;
- It should be stable and permanent; and
- 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.
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.
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.
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.
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.”
References
AManifestoGroup. (2001). Agile Manifesto. Retrieved from Agile Manifesto: https://agilemanifesto.org/
CMU. (2017, January 22). What is your definition of software architecture? Retrieved from resources.sei.cmu.edu: https://resources.sei.cmu.edu/asset_files/FactSheet/2010_010_001_513810.pdf
EARForum. (n.d.). Enterprise Architecture Definition. Retrieved from Enterprise Architecture Research Forum: https://samvak.tripod.com/earf.pdf
Encyclopaedia Britannica, 8th ed. Chicago: Encyclopaedia Britannica, 2009
Fowler, M. (2003, July/August). Who Needs an Architect? Retrieved from MartinFowler.com: https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
Hohpe, G. (2017, May 24). The Architect Elevator – Visiting the upper floors. Retrieved from MartinFowler.com: https://martinfowler.com/articles/architect-elevator.html#MinimizeUp-frontDecisionMaking
ISO/IEC/IEEE-42010. (2022, January 8). Defining Architecture. Retrieved from Systems and software engineering – Architecture description: http://www.iso-architecture.org/ieee-1471/defining-architecture.html
TOG, T. O. (2018). Core Concepts. Retrieved from TOGAF Standard, Version 9.2: https://pubs.opengroup.org/architecture/togaf9-doc/arch/index.html
Wikipedia. (2022). Computer Science. Retrieved from en.wikipedia.org: https://en.wikipedia.org/wiki/Computer_science
Wikipedia. (2022). Wilhelm Schickard. Retrieved from de.wikipedia.org: https://de.wikipedia.org/wiki/Wilhelm_Schickard