Musings On the Role of an [Enterprise|Software|IT] Architect — An Enterprise’s Pilot in the Clouds or Chief Coder?

The role of an architect in a technology organisation or in the context of IT is second to none to other roles when it comes to widely differing or even ambiguous interpretations regarding its meaning or even its main defining characteristics.

As they say, ask two architects about their role or responsibilities, respectively, and you will get at least five non-overlapping and partly contradicting answers. Many an author who has failed miserably at the task of defining the role of the architect.

Early in my carreer, this lack of a clear and precise definition of an architect’s role, was really bothering me. With all these other roles in the organisation demanding so much of an architect there had to be a clear understanding of which balls one can drop as an architect without being crucified.

Of course, there are many good descriptions and even essays and book chapters (maybe whole books?) about the architect as a person, architecting as the doing, and skills and methodologies that are helpful to be potentially successful in the architect job. Only all these are not really concise, or precise enough for that matter, so that one can take them out and recite them to a demanding colleague and expect understanding for what is or is not the architect’s job.

I haven’t been thinking about this lack of a precise definition of an architect’s role or how to safeguard against undue demands from other roles. Maybe the sands of time brought enough experience to somehow get a feeling for what is within my circle of influence and what is not. I think it is a law of (human) nature in professional life that ambiguity and grey areas are blurred over time in a way that the whole bothering aspect fades out. On the other hand, though, the human brain miraculously transforms all these missing definitions, unclear situations, absent information, as well as, mistakes or failures and successes, into a fit for purpose decision mechanism.

Which really leaves us at the start of our discussion. All that blurring and transformation of unusable inputs to practical decision happens over — sometimes substantial — time frames. And as we know, nobody — not even architects — fall out of the sky fully ready for their mission. Alas, somehow we have to continue our quest of describing, defining, reciting, showing, and maybe also examining, different aspects of the architect’s traits, necessary skillsets, helpful methods and methodologies, efficient tooling, and, of course, the architect’s role in itself. That is, every aspiring architect can learn, and more so, train ones decision capabilities through exposure to all these wonderfully diverse ideas about our profession.

The trigger for me writing about the topic of the architect’s role was a valued and renowned colleague of mine asking his LinkedIn community what they thought enterprise architecture was. Surely, he suggested that there is no simple answer to this question.

For himself he presented his current understanding of his positioning in the role with a few statements along the lines of a focus on the whole enterprise, being a critical voice for necessary change (especially, digitisation and agile transformation), getting together the right people to work on the right problems, and being hands-on by seeing change initiatives through to the finish(see: [1]).

These statements resonated with my own understanding of an architect’s role. If I had to pick one key aspect of an architect’s role I would choose “be open to your surroundings and tune into it’s vibes”. Of course, that is the non-decision because it encompasses a whole lot of characteristics and statements.

But let me get a little bit more concrete regarding my opinions about architecture and architects as a profession. As explained above, in the past I struggled with creating a concept of this matter in my mind. Over time I started to emphasise different aspects of the job depending on the situation— one could say I learned to modulated my behavior along different roles altogether. This notion of an architect encompassing different roles and playing them out as need be really resonated with me when I was introduced to “The Architect Elevator” by Gregor Hohpe in one of his training sessions. Gregor wrote a whole book on the topic of “Redefining the Architect’s Role in the Digital Enterprise” [2] and in Part 1 he explicitly manoeuvers the waters of different roles an architect typically finds oneself in.

This concept of architects operating on different levels of abstraction (“The Architect Elevator” in Gregor’s terms) and, therefore, embodying different roles depending on immediate needs, is the most useful instrument for my work as an architect at the moment. Gregor has a whole lot more to say about architects and architecture than only about roles an architect engages in — there will be more references to his work in my future texts, for sure. At this point I would say that of the roles presented in the architect elevator book there are a few that have been especially pronounced in my life as an architect up to now — sequence numbers expressing my evaluation of relative importance from most to least:

• “Court Jester” — speaking truth to power, having the powerful’s ears [3]
• “Guide” — architect as a tour guide or “architecture without architects” ([2], originally coined by Erik Dörnenburg)
• “Gardener” — trim and prune [2]

This assessment is, of course, valid only for the specifics of my professional background. Other people and other organisational and situational circumstances will come up with different assessments.

Besides the above personas there is one important aspect that I think is essential for all architecture work. There has always to be a strong connection to the engine room (stressing the elevator metaphor from [2]). Overall I judge it more bearable to lose the connection to the penthouse than to lose credibility with the engine room. Without entry clearance to the penthouse things might get a little muddier or slower. But without the engine room your cause is lost. So my suggestion for every architect is to have enough time on your calendar for working with the engineers hands-on creating systems.

I am sure that there is no single correct definition of an architect’s role or for what architecture really is. For me, the real value of an architect in an organisation comes straight out of this multitude of different tasks and responsibilities architects are able to take on — from designing complex technical systems to realising that the organisation itself is unfit to bear that envisiond system’s weight. The saying goes that “there is nothing permanent except change” (Heraclitus). So we might see many more musings about architects and their roles down the road!

References

[1]: Hannes Lischka, LinkedIn Post, 2021–02–05, (https://www.linkedin.com/posts/hannes-lischka_enterprisearchitecture-digitalisierung-agiletransformation-activity-6763416180343537664-Xu_-)

[2]: Gregor Hohpe, The Software Architect Elevator, O’Reilly, 2020.

[3]: Gregor Hohpe, The Architect as Court Jester, LinkedIn Post, 2016–10–09, (https://www.linkedin.com/pulse/architect-court-jester-gregor-hohpe/)