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.
