Thursday, December 8, 2011

5 Reasons: Why you need an Architect

Today I’m starting off a new topic, called “5 Reasons …”. Five reasons why you need things, why you should do things or not, or why to love things or just hate them. I’ll start this by giving you five reasons why you need an architect in your software development project.

The reasons provided here are inspired by the great article of Daniel Akenine in the Microsoft Architecture Journal No. 15 (
Link). The article gives the results of a study from IASA Sweden on the roles of an architect.

1. Architects can handle complexity
I guess everyone is fully aware that software projects got more and more complex over the last years. Today we are building huge software environments that can deal with lots of traffic and data. Why do we do this? Well, because users expect software or a device to deliver some kind of functionality or data just on a fingertip. They want to see personalized data, expect automatic notifications or even advice. They want to access their data everywhere at every time without worrying about network protocols or security. They need intuitive user interfaces, easy access and of course they expect performance. Users are mostly impatient. They don’t want to wait. If you have an application that is slow or ugly, you’re out.
Architects take all these concerns – and even more – into account when planning and designing software systems. They have a birds-eye view on the application landscape and can face the complexity, whether it is fundamental or accidental (see …). The goal of an architect shall be to reduce at least the fundamental complexity as far as possible in order to achieve a manageable, scalable and extendable application design.

2. Architects know patterns
You have heard of patterns? You should! You’re using patterns? You should! Patterns provide proven and well understood solutions to common problems. They make software or its components more understandable and deliver a common grammar for all developers in a team. You can find and use patterns in every phase of a project and on every layer inside your application. There is already a lot of work done on patterns and numerous pattern catalogues exist (e.g. “
Design Patterns” by the Gang of Four, Pattern Oriented Software Architecture (POSA Series), Hillside Group). While most software developers know implementation specific patterns, architects are well aware of design and system wide patterns. They know more specialized patterns related to application architecture. Together with these patterns they help plan and build manageable, understandable software systems.

3. Architects plan for non-functional features and think beyond the project
Imagine an application that is beautifully designed in terms of the user interface. It is intuitive, the colors and control elements are well aligned and it just pleases the user’s eye. But all the design gimmicks lead to very bad responsiveness. Opening up a new dialog takes five to eight seconds. One might say, that’s okay, but imagine such software used by an agent in a call center. That would not be acceptable. This is just a very simple example where you see, that there are more concerns to be taken into account when designing software systems: functional and non-functional concerns. Especially non-functional concerns are often not clearly defined or even spoken out in software projects. It’s the task of the architect to plan the overall design regarding to these concerns. Additionally they have to provide a long-term strategy for the solution and its environment. Most business applications are integrated in an existing information infrastructure and are operated at least five years, mostly longer. Architects have to plan their integration and the whole maintenance lifecycle.

4. Architects act as agents between analysts, project managers and developers
Architects play a key role in a software development project. Analysts mostly talk to customers in order to identify their need and requirements. Developers in turn try to interpret these requirements and implement them in form of a feature. Project managers pay attention that features are not beyond the budget. These three roles have different goals and motivations. They even speak different languages. Analysts speak the domain language of the customers. Developers speak a very technical language. A good architect understands and speaks all the needed languages. They can talk with analysts about the requirements and can translate the information to the developers using a more technical language. Architects can talk to the management and understand their needs are possibly reflected by an efficient architecture where features can easily be added.

5. Architects can communicate, present and defend their architecture
When it comes to present or even defend an architecture, architects are some kind of diplomats. They must explain their architecture to the various stakeholders in a project and have to make sure, that everybody involved accepts that architecture and feels comfortable with it. This again means that a good architect is able to present her architecture in an understandable way on every level in a project, from top management down to the developers.

I’m well aware that there are dozens of other good reasons why you should employ an architect, but that five reasons provide the quintessence from my point of view.  If you need even more reasons or want to learn more about the role of an architect, read the Architecture Journal, No. 15. You may also visit the IASA Homepage and look for a chapter near you. Additionally there are a lot of related books out there to get you started in the field of software architecture.


  1. Nice Article, but...
    I know 5 reasons why you do not need an architect:

    1. Architects are responsible for complexity.

    Architects like to think about things that might happen in the future. But when the future has actually become the present, the problems have become quite different. This opens the gates for complexity. So don't think too far towards the future... Solve your present problems. Don't rollback, roll forward.

    2. Architects have heard of patterns.

    The architects I know are non coding architects. A non coding architect might have heard about some nice patterns, he might have heard that they are useful. That's why he wants to have patterns everywhere... The developers I know try to use patterns where useful and avoid patterns where not.

    3. Architects plan for premature optimization.

    I think there is nothing more to say...

    4. Everyone can act as an agent between analysts, project managers and developers.

    We are not anymore in the times of IT medieval.
    Every developer should have enough social skills to communciate to analysts and project managers...

    5.Architects can not communicate, present and defend 'their' architecture.

    Sorry I might be wrong, but in my experience I have never seen an architect beeing a diplomat. The ones I know are more like leaving scorched earth behind them...
    Every developer should be able to take responsibility for her code!

    See 4.)

    These are only some reasons why you do not need an architect. I could list hundreds of reasons ;-)

    But seriously, in some cases there might be reasons why you need an architect but in most cases you don't. Every experienced developer should be able to do an architects job.
    By the way: Define an architects job :-)))

    Best wishes,

  2. Hi Tom,

    thanks for sharing your thoughts on that. I surely may find dozens of reasons why you don't need an architect when you have architects that behave like sitting in ivory towers as you described in your comment.
    I wrote this article because I often see people in projects working without defining an architecture role. The results are always the same. The software is not felxible, not manageable and not understandable. That's wyh I think you need someone who is responsible for making decisions on architectural problems. Ideally such a person has strong knowledge about programming and the used technologies. So I agree with you. It's just a matter of the definition of an architect, his role and his responsibilities.
    The points that I listed are not only reasons, they also imply how a good architect should be.
    A note to your fourth point. I think that's unfortunately not true. I still see so many developers not able to communicate properly. Of course, it's getting better but there's still need for improvement. So I would not say in general that every developer has enough social skills.

    You said that every experienced developer could do an architects job. That's totally right. But then, is he still just a developer? Maybe he is already an architect. That leads again to the definition of an architects role and job.