Ana Brenes
ERNI Switzerland
Abstract
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:
- 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.
- Social: the ability to communicate and make sure that the Architecture is understood by everyone that should.
- 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.
References
Fowler, M. (2003, July/August). Who Needs an Architect? Retrieved from MartinFowler.com: https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
