"If you don't develop an architecture, you will get one anyway – and you might not like what you get!" (Linda Northrop, SEI)

Many times have I been asked what „IT Architecture” is, or what is the difference to system design, and what does an architect do that is different from an engineer.

Sometimes the IT architect is simply an experienced system engineer. In fact I can’t really think of someone doing IT architecture without having been exposed to the many aspects of engineering, to many different technologies and patterns, and not knowing at least a few of them in depth. There is however a difference between architecture and engineering. In fact there are many sides to engineering; for example, someone with a main background in software development tends to look at things differently from someone that comes from network design, IT operations or IT security.

Once you become an architect you are expected to deal with all of these functions and to understand them well enough to propose decisions.

For instance, security often wants their systems (controls) to be based on appliances because they tend to be more secure. However Operations will argue that they can’t manage so many boxes and would prefer instead to have standard images and virtualisation. As for the development team, they always need the latest versions because the older ones have either run out of support or are not good enough.

The architect has to consider all of these points of view and many more when designing a system or working on a change to an existing system. And this is just inside the IT department. The customers have their own concerns, which are not necessarily related to security, technical component versions or release cycles. They need to have their tools and information available, quickly and in an uncomplicated way. In addition, many times different groups of customers have conflicting requirements.

This is where architecture comes into play. It’s all about managing trade-offs. The architect has to understand the concerns or viewpoints of each stakeholder and design a system that takes all of those aspects into consideration.

Architecture is mainly concerned with non-functional requirements, or system qualities. When you buy a car you want it to be fast, beautiful, big, comfortable, reliable, secure, eco-friendly, not depreciating too much, with low maintenance, lots of extras… and cheap. You have probably seen a panoramic roof which you liked in some model, tinted glasses, MP3 connectivity, built-in GPS, a fridge, Bluetooth, parking aids. You want it all but then you realise that you need to compromise somewhere. So in the end you (sometimes) get the car that matches your most important qualities within budget. If the balance is not right you know you will regret it later, and probably end up replacing it and spending a lot more than you wanted.

So that’s the role of the architect: to find the right balance given the priorities that are communicated by each stakeholder and on which there must be agreement at design time.

Can you build a system without taking care of architecture? You certainly can. But inevitably the system will be unbalanced, neglecting the interests of key stakeholders, and problems will soon emerge. Like Linda Northrop from the SEI wrote “If you don't develop an architecture, you will get one anyway – and you might not like what you get!” (http://csse.usc.edu/gsaw/gsaw2003/s13/northrop.pdf).

There are countless examples of badly or non-architected systems. The consequence is that they usually have to be replaced quickly. That is what architecture tries to solve.