Where is my Architect?

Not all IT Architects have a technical background (eg. as developers or data analysts), although the majority of us come from such experiences: knowledge of the technical challenges of an architecture is a powerful asset, but sometimes this can lead to confusion in organizations, especially when in a not mature state of growth.

In fact an architect is not necessarily a developer anymore (or at least not full-time), and she/he should be requested to have a wider understanding, vision, leadership over the set of components composing the overall architecture of an organization, to help both business (eg. C-levels, product managers, product owners) and IT (eg. operations, development, quality-assurance) taking the best decisions on the development of their tasks.

Ultimately, this person is a glue between the business management and the technical world, trying to clarify the challenges from both parts, in the language that is understandable from one and the other.

Anyway, it often happens that the roles and functions of architects are interpreted by the organizations, since the lack of common understanding of the processes and deliverables: we (architects) have invested time studying architectural frameworks (eg. TOGAF, Zachman Framework, etc.), to learn about the standard way to carry out the role, through artifacts, processes, roles, but we cannot expect others to have done the same effort, as much as we don’t always do an effort learning product management, communication or marketing frameworks.

As such, and because the deliverables from our work are not objective (as a software or a finite product might be), and thus we cannot be evaluated objectively, we should strive to be available, understandable and clear enough to provide value to the organization with our presence, although sometimes this means going against the architecture processes commonly adopted by the industry.

Most architects I have worked with within the spanning of my career expressed frustration for not being understood, sometimes even by those colleagues with more technical roles (such as developers), who ideally should be the ones with more understanding on the meaning of their work.

Such misunderstanding has several causes, some are personal (eg. conflicts of personalities), some political (eg. overlapping functions, primacy and visibility), some simply given by ignorance (lack of knowledge of responsibilities), and we must always be ready to attack them, trying to defuse conflicts, to better prove our value in the creation of a communication and collaboration channel.