An IT Architect’s 3 Most Important Words

“As Measured By” Sounds simple, doesn’t it? Not hard to say nor understand. However, they are also the least executed words in any IT solution today. In terms of “as measured by”, IT has much to learn from the example set forth in the business strategy tools we use. Norton & Kaplan Strategy Maps have a column labeled metrics; Kim & Mauborgne’s Blue Ocean Strategy relies on measurable differences in the factors of their four actions framework; Carlson & Wilmot’s NABC promotes a measurable Benefit from the offered strategic Approach. The pattern here is that since “as measured by” is built into these strategy tools, we might consider building it into our IT architecture tools as well.

Business Technology Strategy

Let’s start with the IASA Business Technology Strategy pillar. When we architects analyze and model business requirements, we include justifications, reasons, and tradeoff considerations in our designs, but rarely do we clearly define success and value for the business – in distinct business measures.

If we add “as measured by” at the end of every business requirement and require our business stakeholders to define that “as measured by” in distinct business measurables, then we can design our solutions to provide the necessary evidence to show that business value is being achieved.

An example is to set a success business requirement to something specific and measurable like, “a 10% increase in online sales,” and then build the necessary metrics into the solution that can measure and provide evidence of this.

Quality Attributes

When examining the IASA Quality Attributes pillar, it only seems natural that we include “as measured by” in our definitions, yet, this area is probably where we fail most often.

There are Quality Attributes we blindly set without any “as measured by” perhaps thinking their definition alone means we will achieve it. Think of the many times we state a usability QA of “a simple user interface” without any explicit definition as to what that means. Leaving it up to user response after deployment may be disastrous. Rather, if I choose an “as measured by” along the lines of “as signed-off from a UI focus group acceptance review,” then my QA also secures a commitment of having resources assigned.

For those times when we do include a measure for a given QA, we often get ourselves into trouble when we don’t assign a meaningful metric that we can measure in the solution itself. For example, creating a performance QA like, “a sub-second screen refresh” on an internet solution when I have no control over the network delivery from my server to my client just might signing up for failure. Rather, if I set my “as measured by” to something along the lines of “a refresh equivalent to that of a search site,” then I have a metric that is measurable and attainable.

It Extends to all Pillars

BTS and QA are the most direct applications of “as measured by”, however, they can creatively fall into usage in the other IASA pillars of Design, Human Dynamics, and IT Environment. For example, an architectural design might be approved “as measured by” passing an Architecture Tradeoff Analysis Method (ATAM) or Perspectives-Based Architecture (PBA) review.

Three Simple Words – Huge Business Value

By applying “as measured by” to our architectures, we will not only clearly understand our business goals, we will also be able to better achieve them by delivering a solution that, through its operation, produces its own evidence of its business value.