Rules of Evidence for Architecture
Yesterday I had jury duty; one of only two civic duties enumerated in the US Constitution – the other being voting (ok paying taxes might count as three, but let’s not go there). Anyway, several hours of sitting in a court house did get me thinking about the “rules of evidence” for architecture.
A common pitfall that IT organizations fall into when trying to formalize the practice of architecture is to setup an architecture review broad (ARB) without proper foundation; specifically without setting down the rules of evidence for architecture. In ancient times the village elders or some monarch dispensed justice without formal legal structure, but I’ve yet to see an ARB that wielded this kind of absolute authority over IT projects.
So just as modern courts are governed by rules of evidence, the ARB must define what is to be presented as part of an architecture review and what criteria is to be used to judge the fitness of what’s presented. TOGAF™ provides a succinct description of the function of an “Architecture Board” without trying to define any strict formula for an ARB to follow. Nor will I try. Instead I’ll just focus on some of the basics.
Standards
A common ARB function is to ensure conformance to standards. If the organization has not defined any standards or has failed to define standards that are relevant to the projects that the ARB will review, then this part of the review becomes little more than a debate between architects. It may be a debate in good faith, but that’s called a design review and whereas I’m all in favor of architects reviewing each other work and giving feedback, this process generally lacks the kind of demonstrable benefits that are required to justify anything beyond the most cursory investment of resources in the ARB.
I mentioned the importance of standards being relevant. Standards are defined because they either solve a common problem, thus saving time and resources from having to solve the same problem over and over again, or they support some other architectural objective such as security or ease of integration. If one can’t demonstrate how either of these is the case for a project under review, then the standard is not relevant and enforcing conformance becomes a challenge.
When deciding where to start with defining standards it’s a good idea to look in three areas:
- Look at what is in common use in the organization today. This represents a set of successfully applied solutions to a set of known problems. It also represents technology that is already familiar to the organization and skills sets that are already available.
- Look at the pipeline of projects in development or under consideration. This represents a set of problems that will need to be solved in the near future, but be sure to look for common problems, not simply interesting ones or even the hard ones.
- Look at known architecture priorities of the organization. E.g. improving security, enhanced analytics capabilities, or improved integration between systems.
Architecture Artifacts
A well defined set of standards is not the only requirement for a successful ARB. Defining what has to be brought into the review is also important. Besides allowing the project team to appropriately prepare for an architecture review it also ensures that the ARB get’s a complete and accurate picture of the project under review and solutions being proposed.
For many a project teams, an architecture review is nothing more than a hurdle to be passed with as little delay or disruption to the project plan as possible. Thus the project team is often incentivized to game the review process, not to embrace it. Gaming the review process is usually just a matter of presenting those aspects of the project that are most well understood and avoiding those areas that are less understood when presenting the project to the ARB. This is only possible when the material to be presented is left up to the discretion of the project team.
Defining what architecture artifacts should be brought into a review should be based on the artifacts that are already being created as a part of the project. The challenge here is that many an organization lacks a really well defined architecture methodology that all projects follow. Exactly what type of artifacts should be a part of a project architecture methodology, I’ll leave for another (much longer) posting. The key is that when defining the artifacts that should be created as part of the project and brought into the architecture review one should keep in mind what information about what aspect of the project or the proposed solution each artifacts is communicating and how each artifacts is used in future steps in the process.
Scope
The scope of the architecture review also needs to be defined. Is it just about application architect? Does it cover data and information architecture? Does it cover infrastructure? For whatever scope is defined for the ARB, the appropriate standards and artifacts need to be defined. Also the ARB needs to include subject matter experts across the full scope of the ARB.
Many organizations divide the architecture review process across multiple boards. This separation of concerns can be useful in ensuring that each area of concern is fully addressed, but it can also provide an additional burden for the project team to have to prepare multiple reviews. When choosing to separate concerns it is still important to have some coordinating function to ensure that all the appropriate concerns are addressed; this is often delegated to whatever general project governance process exists.
