In addition to rules—which we covered in the article How Rules Translate Architectural Intent into Action—I use measures to make architecture requirements concrete. While rules state the specification, measures are used to determine effectiveness. By approaching architecture requirements this way, we gain structure with less rigidity. It gives us multiple ways to define and discuss what matters, and the linguistic flexibility to move between statements and questions to better articulate our intent.

In the article When Architecture Requirements Meet Organizational Politics, we discussed the need for architecture requirements and how they fit into the broader machinery of Enterprise Architecture. Now it’s time to work through what these requirements actually are and how to approach creating them. I recommend reading the article Effective Enterprise Architecture Principles—if you haven’t already—where we introduced the following structure:

We started with asset management and have now worked our way through principles and policies. All of this puts us on a trajectory that leads directly to establishing architecture requirements. I prefer to structure architecture requirements as rules and measures, which we will cover in the next few articles. But there are, of course, other ways to structure and define requirements.

We covered policy integration in the post Unstoppable Enterprise Architecture. That part of our discussion was about how to structurally insert Enterprise Architecture into an organization’s policy machinery and drive value through that intervention. But we still need to address policies specifically, and we will do that now. Again, let’s have a look at how a few of the major Enterprise Architecture approaches define and address policies:

In the post Key Steps for Effective Enterprise Architecture Programs we introduced the idea of a conventional structure for Enterprise Architecture methods, comprised of four parts within a hierarchy: We then focused on policy integration in the post Unstoppable Enterprise Architecture, emphasizing the value that Enterprise Architecture can provide, in a way that’s likely not addressed very well in a lot of organizations.

On any given day, I can scroll through my feeds and see posts about Enterprise Architecture. Most describe it as broad in scope, hard to define, and difficult to measure. Almost all will have an under...

In the post Defining Enterprise Architecture: A Practical Approach, we defined Enterprise Architecture as the discipline of aligning business strategy with the design and implementation of computer systems. We’ll call this Alignment and Focus. We’ve also established that there are three things we need to do: Translate Strategy into Technology Execution Integrate Policies from Across the Organization Design Solutions…

I recently reread a book on a popular Enterprise Architecture framework. I hadn’t finished it the first time because it read like watching a bad movie, in that you either leave or suffer through it, thinking it might get better. But this time I was determined to read it, and I had chosen the worst option. What Are We Supposed to Do, Exactly?