Architect vs. Designer

Two very confused IT roles: the architect and the designer. They are used interchangeably, but they are essentially different. Presenting this with some sense of humour, the Architect as an archetypical role of the person who incarnates principles and ideas from the Platonic World of Forms to the physical or mortal world. Hoping it is not too great a sin, I have modified the masonic “pyramid of cosmic order” as below to show how the architectural principles are reflected to built systems:

architect-pyramid

The Architect works always with principles. He/she is by no means an expert in different technologies and tools, but is aware of them. The Architect is always engaged with the logic, the flow (communication) and the life cycle of a system. He/she describes how a system should be, sets the rules and understands its purpose, not its details. More importantly also understands how the system exists in a greater ecosystem, that is how it interacts with other systems. The architect’s work is larger than the specific tools and configurations, and is rather concerned on how the system can adapt to use new tools and new configurations in the future.

The Designer works with technologies and frameworks, and must deal with technical limitations and restrictions. He/she is concerned about specific tools, components and configurations, and how these are be used, within their capabilities, to be in compatibility with each other and to fulfill the principles set by the Architect. The Designer is responsible for producing the system documentation (blueprints).

The Builders (or the Developers) have practical knowledge of the tools, and the ways of working, the methods. They build the system by connecting the components and applying the configurations. Every day, they get their hands dirty trying different configurations in try-fail-retry iterations. They give life to the system, they make it work. The system has been so far in the Architect’s head (the world of ideas), or the Designer’s drawigs, but now the Builders put it in operation and test it before they hand it over to the Operators with any proper operational instructions (documentation).

The Operators are the carers. They know how to run the system and how to keep it away from danger. They troubleshoot, diagnose and fix it again and again. They maintain and replace components. They don’t necessarily know how exactly the system works, how the different components communicate with each other and why the system exists (its purpose).

architect-incarnation
The ladder of system incarnation

An Architect works with logic, ideas and principles. His work may be considered as interdisciplinary, i.e not of a specific IT field (an architect can be an architect in any IT field), or not even IT. The same architectural principles used in an IT system can be used in mechanical systems, or for example the same principles taken from flow dynamics could be brought to information flow between IT systems.

There are many Designers out there in IT, be it infrastructure or software, but there are few Architects. Designers can evolve from Builders and Operators after accumulating lots of experience from multiple technologies. But the Architect is a thinker, usually a challenger and a contributor to the future; a small “philosopher” as Raymond Llull would put it.

“Every philosopher has the ability to be a good mechanic.” – Raymon Llull, 13th Century

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s