For quite some time I have noticed that in the market in general there is a distortion, or rather, a lack of clear definition of what IT architecture really is. Seeing how the architecture department works in many organizations, I see that the architecture department really ends up acting as a battalion of experts in different things, but without addressing the real problems that make up the architecture of an organization and its strategy.

I have collaborated in places where when I began to understand the architecture area of each of these organizations, I noticed a common pattern where I identified that:

• They had not had an IT architecture map for a long time, or it had never been made.
• There was no definition of standards about how things are done or who does them.
• IT Architecture, did not have a clear, defined and documented methodology on how the organization's architecture is managed and even more evolved. It comprised a group of experts who dealt with demand overflows and specialized aspects of this, sometimes playing the role of project leaders or referents and many others as level 3 support.
• I noticed a total absence of using proven frameworks or methodologies for modeling and management as accelerators for catalog management and its connection with the business. In other cases an excessive use of these that created an unnecessary bureaucracy.
• Architectures whose change or evolution only responded to the rationale for approval and condition on the cost of development, implementation and maintenance of the solution and not to a strategically clear definition. The design rationale was "how much does it cost?"

Addressing some definitions

TOGAF: The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time. .

The architect, if we approach the TOGAF definition (in my opinion the clearest and most precise), is the person in charge or custodian of said component structure, safeguarding the strategy of how they should relate thus taking care of the semantics of the architecture and putting on the table the rules of the game on how these components and their relationships are governed, designed and evolved over time so that technology is a facilitator of business objectives. An interesting factor that arises from this definition, which I see as an immediate result, is that architecture ends up creating the mechanisms and knowledge for decision-making.

A comment that I like to add is that the architect is knowledgeable about many things related to the IT world, but he is also a business individual and especially he is a strategist, since what he seeks to solve is how these components and Their relationships will evolve over time to facilitate the objectives of an organization efficiently and effectively.

Other points of view

Some time ago, I was looking for the correct definition of all these matters to put the correct titles and words. I had a lot of things flying around in my head and I needed to somehow give them a first and last name.

In my eagerness to expand these horizons, I have read the book "Technology Strategy Patterns: Architecture as Strategy" de [Eben Hewitt] which was very helpful to me, since in some way it opened up my vision much more to put things into correct words and also understand the aspects of the practice of architecture that really give meaning to its function... also to establish a strategy and define those principles and guidelines governing to manage the architecture as a strategic plan instead of doing it as a group of experts who simply define whether to use docker or kubernetes, Java or Python, Oracle or SqlServer, etc ( that these are just some of the functions of a true architecture team).

Vitruvius

In his first attempt to define it, he surprisingly explains this analogy with Vitruvius.

Vitruvius (Vitruvio in Spanish), He was known as the father of architecture.
He was also the one who, in 40 BC, invented the idea that all buildings should have three attributes: firmitas, utilitas, and venustas, meaning: strength, utility, and beauty.

Vitruvius, by declaring these three premises, what he did was declare the principles of architecture, explaining in some way that (I will refer to the book):

• Strength: It's not necessarily building buildings or solid pieces of software. The buildings are solid but they are designed to be flexible, which transposed to the field of modern IT, I interpret as the design of robust solutions, designed to last over time, but also flexible to adapt and change.

• Utility: designed for the user. I think already around the time of 80–70 BC – after c. 15 BC,

  • Vitruvio was one of the first to propose the first definition of UX (User Experience) associated with architecture principles, or at least that user experience is important.

• Beauty: It does not reflect it in the strict sense of what enters through the eyes of the viewer. It is a way of capturing harmony, meaning and form.

  • In terms of IT Architecture, I could infer that he was one of the first to coin the definition of Semantic Coherence of architecture.

Continuing my reference to Eben's book:

The role of the architect

[...]
"The architect is hopefully not concerned with low-level details of the code itself inside one system, but is more focused on where data-center boundaries are crossed, where system component boundaries are crossed. Here’s my definition of an architect’s work: it comprises the set of strategic and technical models that create a context for position (capabilities), velocity (directedness, ability to adjust), and potential (relations) to harmonize strategic business and technology goals. Notice that in this definition, the role of the architect and technology strategist is not to merely serve the business but to play together. I have been in shops where technology was squarely second fiddle, a subservient order-taking organization to support what was deemed the real business.
That’s no fun for creative people who have something to contribute. But more importantly, I submit that businesses, now more than ever, cannot sustain such a division, and to create greater competitive advantage must work toward integration with co-leadership.

Over my 20 years in this field, I’ve come to conclude that there are three primary concerns of the architect:

1. Contain entropy.
2. Specify the nonfunctional requirements.
3. Determine trade-offs.
   [...]...
   Hewitt, Eben. Technology Strategy Patterns (pp. 11-12). O'Reilly Media

My conclusions

With this entry, I do not pursue the goal of removing those java ninjas who work as architects from the title of Architect. Or the data architect who knows a lot about python and gets into the mud to move things forward is not an architect for being in those details.


My goal in citing this book and Togaf's definition is that clearly, either for one or the other, the architect's primary concern should be strategy on how to make that architecture an enabler for the business to meet its goals.


A good data architect may not be a galaxy-level expert in making distributed processing programs, but he is the one who can work with those experts on the strategy of when it is time to use a Big Data cluster and thus have distributed processing to achieve those objectives that the commercial area has. He is a strategist.
This same person may not be an expert in the development of applications based on microservices, but he has the vision and experience that the strategy of translating the business logic into store procedures in the database is not a good strategy on how to manage that business logic and over time it will not be scalable not to mention that it will create vendor lock problems with that database provider.

Thanks for your time.

M.