The Architectural Role

The architectural Company is responsible for defining and maintaining the structure of the solution, and ensuring that it will meet the requirements. An agile company or consultant must also help the team to work together in an agile fashion, to jointly own the solution, and to interface well with other parts of the organisation.

There are five main parts to this:

• Understanding the requirements - identifying the stakeholders, helping to analyse the requirements and extracting those of architectural significance
• Formulating the design - creating a solution structure which will meet the various requirements, balancing the goals and constraints on the solution,
• Communicating the architecture - making sure that everyone understands the architecture. Different people have different viewpoints, so the architectural company has to present various views of the system appropriate to different audiences,
• Supporting the developers – making sure that the developers are able to realise the architecture, by a combination of mentoring and direct involvement,
• Verifying the implementation – ensuring the delivered system is consistent with the agreed architecture, and will meet the requirements.

The structure and organisation of the system is defined by the architectural company. The architecture describes the system’s components, their responsibilities and interactions. A complex system is more than the sum of its parts. It must have a unifying, coherent structure. Therefore they must also define and describe:

• Metaphors, design principles and patterns on which the architecture is based,
• The technology, tools and standards which will be used,
• Key mechanisms, such as data access and error handling,
• Specifications and interfaces of components to be bought or built.

In an agile development team many people will contribute to these things. The agile company will help all team members to contribute to the architecture, taking good ideas from everyone and making them part of a coherent whole. They may also adapt ideas originating elsewhere, but without losing the team's ownership of the solution.

They will lead choosing the technology, and confirm that the choices are viable. He or she must therefore be aware of the alternatives, and factors that choose between them, and understand what technical issues are key to the project's success.

They may frequently be an evangelist for new or different technologies, processes or solutions. However, he also has a responsibility to help manage change, which may mean reining in his enthusiasm where risks and costs would outweigh the benefits.

The solution must meet the users' needs, but not necessarily every wish and constraint. The company should help to identify and resolve conflicting requirements, helping to say "No", or "What do you really need?" if the requirements clash. Their objective is working solutions, and the best solution for the enterprise may not even need new software to solve the users' problems.

One of their main jobs is communicating the architecture. He or she must become the solution’s "champion", selling the vision and keeping it alive in the face of challenges. Each group of stakeholders needs to understand how the architecture meets their requirements. This requires multiple representations of the architecture directed at different parties. Any architectural company must model to communicate, but an agile business will follow the principles of agile modelling, and help the project to "travel light".

An expert visualiser, good at abstracting and modeling solutions, they see the "big picture", and views a system and its context as a set of interacting components. However, they must also be able to understand and discuss the system in terms of functionality, hardware, project or financial considerations.

The architectural company helps the developers to understand the architecture, its value and the reasons behind it. He may act as a mentor or consultant, assisting, training and providing leadership to the developers. He may even work within the development team, focussing on implementation issues of particular architectural significance.