Who gets the role of transformer?

Date: 2024-05-06 06:28

A new 'house'

The year before my senior year, my parents bought an old farm. Let's see what that 'old man' bought. I found a ruined building that we were going to live in and a stable with a crooked wall. There were large cracks in the living room ceiling. This floor was not accessible by stairs, but by a ladder. Chickens and an old lame cat were running outside. Should I still live here before leaving my parental home?

Eight months later my father asked if I could come and help. There had been a lot of talk at the dining table in recent months about the setbacks and windfalls associated with the renovation. But I have to say, I wasn't well informed. When I arrived, I found a completely different house. It wasn't finished yet, but something special was happening here.

A new home

We moved a month later. I settled into my small bedroom, very efficiently laid out with a beautiful built-in wardrobe, freshly plastered white walls and an authentic window that ran from floor to ceiling, next to my desk. The window offered a view beyond what I could see. Maybe I should live here for a while after all. My father had not changed this house, but transformed it!

Transform or change?

When I moved into my furnished student room, I put some new plants in the windowsill, moved the couch, and hung a new poster. I had changed the room.

Change is a task for managers and consultants. Transforming, changing how an IT organization works, is a task for an IT architect.

Why the IT architect?

Transformation is risky and challenging. I once heard a tester say: 'Not that kind of service again, eh'. The system engineer standardly starts the conversations with 'what you want is not going to work'. I hear from the designers: 'What we had worked well. Why are we being so complicated?' The IT architect may think 'why me?'. Help from a consultant can certainly contribute to a successful transformation. But lasting change is not achieved with a slide deck that comes from the drawer of an agency somewhere outside your organization. Lasting change starts with models in which stakeholders recognize their organization and clear answers. Answers to questions from both product managers on the business side and the system engineers working on the solution. Modeling, stakeholder management, making it clear what the trade-offs are, presenting and convincing. Isn't it the IT architect who has knowledge of these methods and masters these skills? To shape a transformation, good management is conditional. Management must know what needs to be changed.

Technological innovation, agile working and DevOps

Transformations are driven more than before by technological innovations. DevOps changes the trade-offs. Do we still have to choose between quality and speed? Agile working should deliver autonomous teams. But how autonomous are they if they often depend on other teams to release working software? How are we going to organize our teams? These are questions that an IT architect often has the answer to.

Sources:

• Digital Transformation Course, Arcitura
• The Software Architect Elevator, Gregor Hohpe, 2020 (part V, p. 271, part VI p. 327)
• ^ Wikipedia, Conway's law