Ga naar inhoud

The IT architect who doesn't wobble

Date: 2024-02-29 08:03

Why can't we do it?

Where before we hardly let each other talk, there were now long silences. We had been instructed by management to evaluate our work. A year ago we started setting up IT architecture in an organization with an IT department with designers, testers, developers and infrastructure specialists. Armed with my knowledge from the book 'DYA - dynamic architecture - step by step to professional enterprise architecture' and what I learned in the course 'IT architecture in practice', I and our team very enthusiastically started drawing up and implementing our 100-day plan. It started with a session with management. They were easy to convince of the usefulness of IT architecture. Logically of course, they had just given us the assignment. The project managers were less easily convinced. But they indicated that they mainly focused on time and money. They missed focusing on quality, and they were prepared to do that; A project start architecture (PSA) would now also be delivered before the start of the project. But often the customer could not wait, so drawing up the PSA was not convenient at this time. And when it was clear in the PSA that the interface would be described based on the target data model and then a translation would take place, this did not always mean that the designer would work this out in his design. For example, a designer once gave me the answer, 'yes, that is a nice solution described in the PSA, but I didn't know that I actually had to apply it'. We worked hard, we had a lot of knowledge together. Extensive knowledge of the IT landscape and extensive knowledge of the technologies. In the evenings I controlled patterns and the various methods of the IT architect. But why didn't this work?

Problem

When we think about what a good architect should know and be able to do, we initially think that he or she should know the methods and have an overview of the available technologies and patterns and know how to apply them well. No matter how good the IT architect's ideas and solutions are, if he or she is unable to convince the stakeholders, the hard work is virtually in vain, IT architecture gets a bad name and management starts to doubt whether scarce resources should still be spent on architecture. The architect sits on a stool with only one leg. If he or she sat on a stool with two legs, the stool would still fall over.

Solution

As an IT architect, you ensure that the people around you can count on you. You will need to know the technologies and patterns so that you can make the right decisions for the organization you work for. In addition, you will have to be able to convince the people around you, and especially the person who decides on the deployment of people and budgets. Once you have succeeded, you are not there yet, you will have to motivate, support and occasionally correct the teams that realize the solutions. In short, you have to show technical leadership.

Sources: