Ana Brenes

Ana Brenes
ERNI Switzerland


As much as many would want to think that Architecture can happen by accident, I would have to disagree with that conception. Can you imagine a house, building, car, or plane happening by accident? I do not think so. These “objects” created by humans and for humanity to serve some purpose could not be used if they were just made by accident. At first, yes, the ideas came perhaps by accident; someone observed something that made them think of something else, and then a trial-and-error process took place until the final “object” came to life. Here is where the second element of the triad comes in place. The person who is responsible for the Architecture: The Architect.

The Architect is essential since, to this day, no Architecture has been self-created nor created by another piece of software (yet). The Architect may officially have the role of someone who is implicitly responsible for the Architecture.

As mentioned before, the perspectives in which Architecture shall be considered are manifold. In the same way, then, this applies to the practitioner’s (the Architect’s) skills, responsibilities, and areas of concern.


Architects: The enablers

Who are they? What do they do?

I mentioned before that Martin Fowler (2003) said, “Architecture is about the important stuff.” I want to add that it is also about how that important stuff is communicated to the relevant people. All the concepts and properties of a system in its environment are not helpful if the relevant people do not understand them. And the person who is responsible for this is the Architect.

Also, using some ideas from Fowler (2003), let’s consider the two types of Architects he described: The Architectus Reloadus and the Architectus Oryzus.

Do not be confused by the names; they are certainly not names of dinosaurs. The first definition, “Architectus Reloadus,” claims that architects are the most essential part of the “team” since they will make the decisions and no one else has the skills to do it. The second one is “Architectus Oryzus,” describing a person who is a team player. This person needs to be very aware of all that is going on and look out for critical issues and track them before they become a severe problem. Constant collaboration and communication are part of their daily work.

I like these two concepts but maybe not for obvious reasons. On the one hand, I think there are a few catches in what they imply, but they do give me an excellent basis to present my opinion of the architect’s role.

I believe it is important to have teams to achieve things since we do not have unlimited time to create the systems that a business needs. If a team works well, more can be done. Yet, I believe there is always a need for technical leadership and ownership. If everyone in the team does whatever they want, then the chances of achieving what is required are slim. In my opinion, a team is effective if each member does what he is best equipped to do and communicates and collaborates well with the team. And following that logic, the Architect will be the most qualified person to do the Architecture, but of course, in close discussion and collaboration with the whole team.

Architecture is the base of any “system” (remember, a system could be a simple program, set of programs, or an organisation). If the bottom of the “system” is not stable, reliable, and adequate (to say the least), then the system will not be successful and probably will not exist for long. Hence, I think that, yes, an Architect should be part of the team and be a team player. Yet, in this context, I also believe that someone must “own the responsibility” for the Architecture to drive what is desired and needed for things to be done in the best and most acceptable way (both technically and economically). For the team to do what is required, the team needs to be involved, fully understand, and be on board. This only can happen if someone can “lead” the team in doing what is needed. Leading the team and owning the Architecture requires that someone feels responsible for it, which will be, to a great extent, why a system will succeed.

Let’s return to the picture of a building and the different floors (remember the elevator metaphor). Each Architect is performing a job on each different floor, so depending on the floor, the required skills will be different even if there are similar tasks in some cases. Despite that, anyone who has the role or is called “Architect” should have excellent skills in the following areas:

  1. Technology: the subject matter skills required in the domain (floor). If on the floor of Enterprise Architecture, the skills are different than those on the Business Architecture floor or in the Software (Application) Architecture.
  2. Social: the ability to communicate and make sure that the Architecture is understood by everyone that should.
  3. Psychological: although somehow related to social skills, this implies another focus – about being able to take a leadership and team player role. The Architect shall support, mentor, and guide the team towards performing the work they need to do by doing any of the following: making decisions, evaluating technology, defining principles, selecting patterns or designs, etc.

An Architect is successful when constant and clear communication with the stakeholders is guaranteed. That collaboration happens in order to find solutions to challenges, ensuring that unknown or potential risks are known, transparent, and handled.

An Architect succeeds when “the important stuff” is being addressed, documented, discussed, and decided on. Also, evolution must be guaranteed by having the necessary measurements, practices, and processes in place that enable the expected goals to be achieved.

Hence, I make the analogy of them being enablers: the Architect is the agent that enables the critical stuff to be known, handled, understood, and of course, brings the expected value.

If we think about the different domains of Architecture, we can understand that the work an Architect does is different. There are some shared responsibilities or intersections, but it is not always the case. Let us consider some examples to understand this.

An Enterprise Architect (EA) will be helping the Business Architects understand the Organisation’s Application Landscape and the impact on their business, defining processes or quality gates to ensure that synergies are known in the organisation. The benefit is created, assisting other architects in understanding the impact of the overall strategy in their areas of concern and constantly reviewing that what is done (at the enterprise level) is compliant and, if not, making sure that change takes place.

An EA will be, for example, assisting the Management in understanding the Application and Technology Landscapes of an organisation to define the adequate strategy or also defining the principles, guidelines, and standards needed to support the business objectives.

A Solution Architect will communicate with the Enterprise and Business Architects to understand the constraints to be used for the solution to be created. He may also negotiate with internal teams or external providers about a particular “service” that needs to be part of the solution and decide what the best strategy is, creating an analysis of the impact in other applications when the desired solution is implemented, discussing with the Software (Application) Architects the non-functional requirements that are to be considered in the different parts of the solution, etc.

A Software (or Application or System) Architect will communicate with the Enterprise and/or Solution Architect depending on the organisation’s constraints and requirements to ensure that the application implementation complies with them. The Software Architect is the person who provides the main Architecture and design of the application and supports the developers in delivering what is expected.

In all Architecture domains, an Architect is responsible for identifying and handling any issues that arise and placing them where they are relevant, even if they impact other areas outside their responsibility.

Architects should constantly be communicating, collaborating, and alert to ensure that work “flows” and gets done as best as possible and complies with what is needed and expected.

It is imperative to understand that not everyone can be an Architect. I have seen the misguided assumption that a “veteran” developer or anyone for that matter who can write code is or can be an Architect. Another misconception is that just because a person can make some diagrams (like a flow chart or the like), that also means that they are doing Architecture.

I think this misconception shall be eradicated. And on top of that, one should keep in mind that the different domains where Architecture can be practiced require other skills than those of the practitioner. Some can be learned, some not – but it requires practice and more practice. Besides this, it is vital that the person feels responsible or takes ownership of the work that shall be done.

For example, someone who has never done any development could be adequate for being an Enterprise Architect or a Business Architect. Yet this person is less likely to be able to do an excellent job as a solution or software architect. It is not impossible, but it is certainly not advisable. In my opinion, it would be very similar to taking a developer and giving him the responsibility of building the city’s next skyscraper without the existing knowledge and previous experience. Of course, there may be exceptions if we consider geniuses or brilliant people.

In the same line of thought, it is not recommendable to have as a Solution or Software Architect someone who has no knowledge nor previous experience in Software Engineering and Software Development. A Solution or Software Architect should understand deeply and hopefully have experience developing software for a considerable amount of time. But also, this person should care and want to take ownership of what will be built and be prepared to guide others towards doing this. This person should understand the responsibility implied by this role and should also want to do it.

As in anything else, a person is good for a job if there is the will, skills, and experience. In the absence of experience, there needs to be the will and patience to gain it by doing the job supervised by others who are more experienced (and by practicing and practicing some more).

Now that we know what Architects are, their role, and what they certainly should not be, we will discuss the last element of the triad, Agile, or what I mean by it, in the third and final part of this Saga.



Fowler, M. (2003, July/August). Who Needs an Architect? 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.