by Nick Rozanski
In my last blog post I discussed those qualities which TOGAF characterize as essential to successful architecture governance: discipline, transparency, independence, accountability, responsibility and fairness. These are important qualities, without a doubt, but in this post, I will present my own guidelines for success.
My guidelines are particularly relevant if you are working in an environment which is less formal and structured than you typically see on large projects which are following a heavyweight methodology like TOGAF.
For me, effective architectural governance has five important properties.
- It is timely. You must do your architectural governance at the right times during the project. You need to get involved in development projects early on, when the architecture is still formulating and important decisions about it are being made: decisions about the fundamental structure of the system; the way that it will manage its data, and use other systems’ data; how it will scale, and be resilient and secure; how it uses advanced or unfamiliar technologies or approaches; and so forth. These decisions are hard to overturn or change later on in the project lifecycle.
- It is objective. It must be based on clearly-stated principles, guidelines, and patterns, rather than your subjective opinion of the soundness or otherwise of a system’s architecture. This helps ensure the process is seen to be fair and impartial. A good way to achieve objectivity is to have a set of written guidelines, standards and patterns which project teams can follow (or may be required to follow). These guidelines should quickly lead projects to the right decisions, while leaving room for innovation and creativity.
- It is systematic. It must follow well-defined, repeatable processes, whose objectives and outcomes are clear and well-understood. A systematic oversight process, whether lightweight or thorough, will follow a defined sequence of steps, with known inputs and outputs, to achieve a well-defined goal in a finite (and hopefully relatively brief) period of time. The participants are known, and everyone understands the role they are playing and what their responsibilities are. The tasks which are carried out, together with their inputs and outputs, are clearly defined, and the overall objective is similarly well-understood by all participants.
- It is constructive. It must lead to better architectures. Constructive architectural oversight results in real, significant and valuable change to the architecture. In practice, this often means that the resultant architecture is more scalable, resilient, highly-available or secure – qualities that are often given less attention than they should be when developers are focusing on making sure the system meets all its functional requirements.
- Above all, it is pragmatic. It must take into account real-world constraints, such as time, cost, and availability of skills, but without diluting its purpose or effectiveness. Time and cost constraints are the ones that you will most often have to deal with. There is no point in insisting on an architectural capability or feature if implementing it would blow the project’s budget or cause it to overrun substantially. You need to be ready to make compromises here, while ensuring that the overall integrity of the architecture remains sound.
The purpose of architectural governance is to ensure that development teams design and build their systems in the right way for their stakeholders – the people who have an interest in the system’s success. A governance framework which is timely, objective, systematic, constructive and pragmatic has a much better chance of achieving this goal.
This blog post is an extract from a longer article due to be published in the Pragmatic Architect Column of IEEE Software (http://www.computer.org/portal/web/computingnow/software).
Nick Rozanski CEng FBCS is is the functional architect for a front-office IT department in a major British bank. He has oversight of the systems landscape for the whole department and also provides architectural guidance and support for key systems and projects. He produces some of the department’s architecture descriptions himself, which requires him to create all types of views and address concerns in almost every perspective described in this book.
Nick has worked in IT since 1980 for several large and small systems integrators, including Logica, Capgemini, and Sybase. He has taken senior roles on a wide range of programs for clients in finance, retail, manufacturing, and government. His technology background includes enterprise application integration, package implementation, relational database, data replication, and object-oriented software development. He is also an experienced technical instructor and certified internal project auditor.
