In this blog I discuss what an IT architect is, and the common expectations that I normally have on all architects – Regardless of whether they are Business Architects, Infrastructure Architects, Enterprise Architects or otherwise.
There are many definitions of what an architect is if you google the term “architect definition” – but all of them have some common threads between them. The reason we re-use the terms that we have from the physical world is designing information technology systems require the same levels of discipline and structure. In traditional architecture you need to plan before you build because rebuilding is a costly exercise; and this holds true of IT architecture, even though the nature of IT architecture is changing and we now see trends towards more agile thinking. Agile methodologies don’t mean that we forgo the design processes, it means we work with smaller units of work and a slightly different focus – they still need scoping, goals, to provide clear value, a design, and plan for execution.
Today I am discussing the general traits for all architects – Its true that specific architecture roles have specific definitions and needs – Infrastructure architects, for example, need a basic grounding on technical concepts that relate to their roles – We should be careful not to blur the roles of architect with those of technical specialist; a good architect can capture requirements from different stakeholders, and leverage their expertise – technical specialists are stakeholders in the architecture, and architects can leverage that experience. Another important differentiation between the roles is focus – technical specialists are often good at creating technical designs but do not focus on other aspects of architecture – i.e. they capture tools and technology, but do not think of processes & roles, information flows, governance & People.
Some other common things I see in the definition of an architect:
- Architects design structures. It doesn’t matter if we are talking about physical structures or information structures – we start with a skeleton or a concept and we build upon it.
- Architects oversee the building of structures. In many places its stated that architects build things – which can be easily misunderstood. If you look at an architect on a building site, hes not there laying bricks. although he may take an interest in the work that is happening – he may check the quality and make sure his requirements are met – Its the architect that has specified the type of brick and ultimately where it goes. In the execution phase of a project an architect is there to ensure that everything goes according to plan. The building industry has many regulations that need to be followed, many risks, and methodologies and redesigning part way through a project is expensive – just as it is in the IT world.
- Architects design and plan. They need to be able to turn a fluffy vision into something more concrete that meets many sets of requirements – from legal, from the customer, from their own best practices, they need to understand risk and cost, and they need to be able to communicate these things in industry standard ways with different stakeholders. They interact heavily with managers to realize their visions, and need to be able to clearly manage risks and requirements, as well as apply methodology in order to help identify risks in areas we may not think of. For example, in IT, we might teach architects to know about the TELOS acronym when looking at requirements – assessing Technology, Economy, Legal, Operational, Scheduling. If you think through those words when you are assessing an architecture you can easily start to spot things that may be missed otherwise.
We need to train our architects to think, and to practically utilize methodology, and follow standards such as ISO 42010, the standard for architecture description.
To me, Tom Graves said it well – “Things work better when they work together on purpose” – and to my mind fundamentally architects are there to facilitate this.