Architecture Principles: Where do they fit in the RAC model?

Eric Wright recently asked, “Is open source a true technical requirement?” A great question that Eric explores well, and after reading his article it felt like we could quest a little further. So please, go read Eric’s article if you haven’t already, then pop on back to keep the conversation going.

Everybody Expects the RAC

If you’ve encountered a few decently documented solutions you’ve no doubt found out that RAC is a lynchpin of good design. RAC or, requirements, assumptions and constraints, capture the goals and limitations, verified or not, of the solution in a way that let’s us measure them. Granted, that measurement may be as simple as “met” or “unmet”, but measured none the less.

They’re so ubiquitous in design that they’ve become muscle memory for many. The metric definition becomes, itself, a metric. “Do you have enough RAC in your design?” Sometimes, when asking ourselves whether something is a requirement, or a constraint, or an assumption, I wonder if we shouldn’t be asking ourselves, does it fit the RAC model at all?

It’s the Principles of the Thing

An ask to use Open Source software reads, to me, more like an architecture principle than an explicit requirement. What’s a principle? According to the Open Group, creators of TOGAF, “principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission.”

From a principle standpoint these considered guidelines become agreed upon and writ into the corporate rule book, or at least IT’s. I’m inclined then, in any technical design document detailing requirements, to specify “R1 – Must adhere to architecture principles”. Does this skirt the discussion about whether these types of considerations are, themselves, distinctly requirements? Yeah, to a point.

Principles inherently read as considered requirements. Imagine writing a brief business case for each of your requirements. Kind of that. But they’re also specific. “Must use OpenStack” is not a direct technical or business requirement. It reads more like a constraint. So principles straddle that line between requirements and constraints.

They’re also not inviolate. They’re guidelines, after all. So while it may be an exception to allow an exception to a principle, it can still happen. As long as the business is getting value out of the solution and reasonable risk levels are maintained.

Think about our example from the opposite standpoint, where a client strongly prefers off-the-shelf solutions with minimal customization. Would OpenStack contradict their principle? As open source software, yes, it would. But it might be the right thing to do given their particular solution’s goals.

What’s Done is Never Done

This is my take on Eric’s question. I’d love to hear what your answer would be. Would you approach it differently? Do you agree that a carefully worded requirement can adroitly include principles in design? How would you do it differently?

Chime in, keep the conversation going. We’ll all be the richer for it.