IT Architecture matters. Let me tell you why
During the 5 years that I worked on IT Architecture, I had to justify the mere existence of the Architecture function even to myself. Sometimes also feeling like we were intruders surrounded by the people that really do the job (Developers, and sys-ops, Product Owners, etc.).
I am still convinced that architecture Matters. Lets see why…
Best value for money
If I have to choose just one mission for IT architecture I will choose this one. IT departments and platforms are typically just growing. Some of them because the company is growing, others because the company is in the middle of a Digital Transformation. In any case, the result is the same, year over year you have more systems, more teams, more complexity.
I like to hyper-over-simplify an IT platform as the following:
The main Architecture function is to keep the relationship with the IT Platform cost and the value it deliver in a good shape.
A while ago I worked in a Travel company with a business model based on Online Product Distribution through API’s. Those API’s were strongly coupled with a huge monolith system based on Oracle Exadata. That means every time we grow on API traffic (and traffic was growing more than Conversion Rate) we need to vertical scale our Database.
Architecture proposal at that time was to decouple API services creating a new micro services layer on the cloud to handle all the traffic with lower costs while keeping the Database infrastructure just for the booking and operations (that unfortunately do not grow exponentially). The result, was no more new Infrastructure needed for the DB the following years and a better relationship between traffic and IT costs.
Use the same language
Don’t worry I’m not talking about programming languages (java, python, etc). As an Architect I’m more than open for diversity with some control (not chaos). Here I am referring to Conceptual Integrity, term that I read first time on Mythical Man Month and Other Essays on Software Engineering from Frederick P. Brooks Jr.
In the Book, Fred Brooks explains how IT teams grow and how that growing impact on their productivity. For Fred, one of the biggest problems to tackle when you try to scale an IT team is the communication between teams. In order to parallelize tasks you need teams to be as independent as you can. But, as soon as all the teams work on an interconnected platform we need some communication between teams. Is in those scenarios when having a common language is key to success.
I still remember endless conversations with my former team mates discussing about what is a system, a technology component, an interface or a building block. If you work on a big IT department you probably know how frustrating is that things are named differently by teams. Sometimes is even worst when they use the same name for different things.
A common example of that last one, is naming a monolith application with just one name. Even it make sense (as it is a monolith), when you want to break that monolith, you will need more detail. Introducing different names for the database, the frontend, the data model, etc. will help on the process.
Even you are in an small IT department or a bigger one, it is always a good time to start with a naming convention, a service/system/solution catalogue, etc. You never know how big you will be in the future.
About Conceptual integrity, bare with me, the sooner the better.
Force design conversations
In my mind every solution to a problem always start with an analysis of the situation and the design of the solution before implementing. The reality for a development team is that every week we have new problems on the table to solve. After some months of Business as Usual routines, the teams start running on autopilot and just find solutions to problems without too much thinking about the mid and long term implications.
Having architecture function integrated in the development teams always help on increasing the design conversations to find the best solutions to the problems we face.
Also, I like to challenge the old fashion development process where the design is seen as something to be done just at the beginning of a project. In the article The Architect Elevator — Visiting the upper floors, Gregor Hohpe describe my understanding of Architecture role perfectly:
“… So instead of entrusting all crucial decisions to one person, the project risk can be reduced by minimizing the number of decisions that are irreversible.”
Architecture have to be there on all the development process. Indeed, if you are working on Agile, you will be taking decisions on every iteration.
Strategy Discussions
As an IT guy I will love to be in the company board having very specific and detailed technical discussions. The reality for medium and big companies is that Board members can’t afford to go too deep on the details. But, should the company Board take decisions about strategy without understanding the IT situation?
In the current world, there are just a few companies that can say that IT is not in the centre of their strategy. Then, who is the responsible for translating the strategy to IT and vice versa? — you already know the answer.
One of our biggest contribution in TUI Destination Experiences architecture team was to draw a Target Architecture Model. The TAM allow non IT people to understand our main solutions and systems and how they are connected to our company value streams. After distributing the TAM, most of our strategy conversations started by looking how our architecture look like and how we should adapt to a new situation.
But be careful, a Target Architecture Model is not meant to be an static picture of the “as-is” and “to-be” architecture. Trying to do that kind of exercise will end up with something ephemeral that just fit for an specific project. In my opinion, is better to focus on drawing the main components of your architecture and selecting the things you want to preserve (because are the core of your business) and pointing things that you will need to change or evolve.
Always remember what Dee Hock, Visa Founder said:
Simple, clear purpose and principles give rise to complex intelligent behavior. Complex rules and regulations give rise to simple stupid behavior.
To infinity and beyond
The obsession for being agile is sometimes transforming the IT teams to a short term decision makers. As we already discussed, we need to be sure that the decisions we are taking today are future-proof. Sometimes it means to have a clear view on the strategy for the long term. Sometimes it means to be careful on not being lock in a solution that do not fit your future. Most of the times means assuring a default level of quality and being able to adapt to whatever came.
As we already commented, Architecture have to work also on an strategic level. That means that probably will have fresh information about future possibilities that could affect the IT platform. Sometimes those strategic changes are even confidential. Being able to influence on some decisions trying to avoid regret movements is sometimes a hard task because not-informed people will never understand the real reason behind.
At some point in time, we were in the middle of the discussion about improving the architecture of the B2C platform. It really make sense to improve a lot the architecture. But, some of us knew that we were in conversations to acquire a company that will substitute our B2C platform.
Trust me, is not always easy being an architect, but you have to always think on what is the best for the company.
And also…
… Also we love drawing and we will make the office a lot more cool.
Hope this modest post contribute in the future to understand such a beautiful job.
Migue Coll, Head of Technology Domain at Tui Destination Experiences.
