Architecturally Significant Requirements

By Paul Preiss

I am very excited to be teaching the Iasa Core in Las Vegas this week. The restaurants and the shows will be a welcome change and I have a great list of students lined up. In Core we go through an entire corporate lifecycle including project selection based on business case, project implementation and governance of projects. One of my favorite parts about Core is the part where we begin to teach mapping of architectural requirements to a working architecture design. This is the part where people start to understand how important having business architects can be! As you progress in your career you will learn that architectural requirements are hard to determine, primarily because they need to be gathered so early in the lifecycle before anything is really known. We know that architects should start early in project lifecycles based on when an architect engages in a project, with the end goal being integration into the innovation and project funding lifecycle itself. Hopefully, your organization has learned that getting an architect engaged before the project kickoff will not only save you money but is at the root of incremental innovation. Either way at some point the solution architect will be faced with a business case and business architecture (note: if you are a solution architect and you are not being given a business architecture when you start the project - your process is broken and you have to write the business architecture) and will have to begin extracting relevant architectural requirements. So what exactly are 'relevant' requirements? There are three primary types of requirements which will be important to your architecture design decisions:

1. Requirements which deeply impact relevant product or framework selections.
2. Requirements which impact managed quality attributes.
3. Requirements which imply innovative business models or approaches.

Architects are(n't) engineers, so we should be looking for requirements that help us understand critical design decisions but doing so based on best case overall value. So first you should define what makes for a relevant architecture decision. Although this is a complicated topic in more mature environments which should use a calculation based on strategic importance, I find that cost implications are almost as good, kind of like newtonian physics, maybe they aren’t perfectly accurate but they get the job done.

Significant Architectural Component Decisions

What is an architecturally significant component? This is a full article in its own right but for the sake of clarity let’s define it as a component that should be decided by the architect of a project instead of another stakeholder such as development, operations or business stakeholder. A significant architectural component is controlled by two decisions. One decision is controlled by architectural complexity but can be decided based on total cost of ownership. This may be an application server, a new type of client we will support, an ESB or a rules engine, but it is definitely not a minor development pattern such as singleton or even minor component frameworks. The other type of decision is strategic importance. If we have done our jobs as architects we will have a target state architecture. Architectural component decisions that move us closer to our target state architecture are also significant at the project level. When you are in the process of design you should gather any requirements that lend themselves to decisions about architecturally signficant components. This is a skill that most seasoned architects take for granted since after many projects you will get a sense for these that is almost a bit like a ‘Spider Sense’.

Quality Attribute Impacts

Another area of requirement decisions are those that deeply impact quality attributes. Often called the ‘~ilities and ~illiancies’ of a system, these are the horizontal cross-cutting concerns that impact a system such as performance, security, usability, RAS, and flexibility. During a requirements gathering phase the architect should be deeply alert for any requirement or idea that impact one of these items and should illicit requirements that allow for measurement of effective quality attributes. A great tool for the practicing architect is to build a set of questions which have definite impact on quality attributes and can be measured. Here are a couple of examples from my own practice: “How many concurrent users do we need to support and in what portions of the system?” “How flexible and decoupled should the system be? Which functional components will change often over time?” While this article does not dig into architecture analysis, architects should be aware that the two industry analysis methods, PBAAM from Iasa and ATAM from SEI, are very helpful in teasing out additional quality attribute requirements and solutions.

Incremental Business Innovation

The final type of architecturally significant requirement often comes from the architects themselves. These are technical capabilities that allow for incremental innovation in projects close to the customer. For example, if we are building a web interface to our system, could this be extended to a mobile application? If so, how beneficial would that mobile usage be to our organization? Often architects and project members identify innovative components which do not deeply impact a project scope or timeline. Even if they do, these ideas form the opportunity to innovate in the next round of projects or innovative ide-ation.