A Capabilities-based Architecture

Root Cause Analysis

My wife once decided that her GMC Yukon Denali was “too much of a truck”. Of course, that’s why she liked it to begin with, but that’s beside the point. Here we have identified a problem (perhaps with dubious metrics and/or value calculation) that needs to be solved in order for marital harmony to reign. As she pointed out at the time, if Momma ain’t happy, ain’t nobody happy. I’m sure all y’all can understand it.

So I was faced with a classic problem-solving situation for which I am suitably equipped. Where do I begin? How do I discover root cause? In fact, what problem am I actually trying to solve?

I started with a fact finding mission using a deeply ingrained behavior known as “the interview”. What exactly made the Yukon a truck in her eyes? Cataloging the range of statements and opinions and observations she made, I synthesized the vehicular pain points into two main categories: hard issues and soft issues (I could say ‘logical’ and ‘wifely’ categories, but I won’t go there).

In the Hard Issue category, we have three key considerations. First, the vehicle is too big both in size and power. Second, as a result of the first issue, the vehicle consumes far too much gasoline at an increasingly too great of a cost. Third, the vehicle just costs too much out of pocket in terms of monthly payments, maintenance and insurance all combined with a likely precipitous drop in trade-in market value as a result of increasing (at the time) cost of gasoline.

In the Soft Issue category, we have slightly more…intangible issues. First and foremost, it isn’t the right color. She’s put up with it for this long but she’s fed up and she’s not gonna take it anymore. Second, the DVD entertainment system is in the ‘single, center, flip-down’ mode and that creates untenable situations with multiple kids on the drive to the beach house. Third, the cargo area of the ‘short’ version of the Yukon with 3 row seating is just not enough. Enough for what, unclear. Just not enough. Fourth, and utterly inexplicable, General Motors believes in ‘auto-down’ power windows but not ‘auto-up’ power windows. One would expect the electro-mechanical solution to the ‘down’ would resemble the ‘up’, but hey, I’m an architect not an automotive engineer. Fifth, the navigation system is based on in-dash DVD’s that by now are so insanely out of date that we frequently end up getting lost. So… navigation fail.

That Ol’ Consulting Magic

When searching for a suitable solution to these problems, I used the same reasoning that I use in my day-to-day work. I evaluate, at a conceptual level first, the capabilities of the ideal future state platform. In this case, it would be smaller, fuel-efficient, cost tolerable, value retentive, color-appropriate, child-pacifying, cargo-capable and technically advanced. These are things that I can measure, attribute relative value to and prioritize. I can, in fact, architect the ideal platform without ever referencing or getting bogged down in General Motors versus Ford versus Toyota versus Land Rover versus apple dog cat spaghetti.

If, however, I followed the line of thinking of many in my field, I would begin by identifying the ideal brand of fuel-injectors, the patented style of tread on the tires and/or the molecular and chemical composition of the materials constituting the floor mats. In other words, things that are utterly irrelevant to expeditiously solving the problems at hand.

In corporate information technology, when retained by our business cohorts to help solve problems, we should be focused on solving their problems. It is of no concern to them whether the solution is the best solution out there in every conceivable technical aspect so long as it properly addresses their problem. If that can be done using the best or worst technology is of little concern to them unless it ultimately costs them more money in the short or long term. It is about assessing requirements and ascertaining the technical capabilities required to fulfill those requirements with the right blend of cost/benefit.

Yes yes. Okay. It is helpful, often indispensable, to have at our disposal a grand plan, a reference model for what an ideal overall technical architecture for the company may look like. If we have zero exposure, experience or competence with, say, Microsoft, it factors into the solutioning process. Does it matter if technology x is free but we have no skills in that technology? Should we consider approach y if it is more expensive but we’ve had great success with it previously? Does doohickey z get automatically eliminated from consideration because of market or industry conditions or positioning? Possibly. And yes, those things matter. But it makes no sense at all to start with those questions unless your ultimate goal is to reinforce the stereotype of IT failure. Before we ever even get to the point of asking or answering those questions, we are faced with the highest level consideration possible: does this even make sense to be talking about?

Speaking the Right Language

How do we, as architects of technical solutions to business problems, think deeply and speak intelligently about cost-effective means of addressing pain points? Well, we don’t start with the type of memory chip on the motherboard of the server that may or may not run the system that hosts the middleware from company A or company B on which we’ve deployed clever code that we developed in house in language “foo” using IDE “bar”. While it may be interesting and dazzling to plot all that on a giant 60×40 color printout and amaze our peers with our surely impressive grasp of minute detail, it isn’t particularly useful or relevant. Yes, I just implied that your unrivaled knowledge of BIND9 isn’t applicable to architecture at this level.

Starting At the Start

We begin by speaking in conceptual terms. We speak in terms of capabilities. What is it that we, as IT, need to be able to do, at a high level, in order to fix this problem? Forget cost. That comes later. Forget vendors. That comes last. Give me a sentence, in 140 characters, that describes the means by which we succeed. If you can’t, I submit you’re ill equipped to be in the business of architecture. You may call that bold talk, but hey, it’s my blog.

The vocabulary for this initial discussion has to begin at a high level by its nature. The discussion is in terms that allow us to begin to dissect business requirements in a language that is understood by both the business and IT. We build rapport and confidence by speaking in business language and not leaping into nibbles, megabytes and petaflops.  The discussion is about teasing out pain points and bringing a problem that was originally described in business terms to a place where we can talk about solving the problems in technical terms. The mechanism for this, the lexicon, is in terms of the capabilities we wish to employ to solve a business problem, not the products, vendors, tools or frameworks.

The Art of the Possible

These capabilities may be things we can do, do well, don’t do or don’t do well. They are independent of our org chart, they are product and vendor agnostic. The practical considerations of competence, skills, cost, timelines et cetera are secondary at the outset. We have to start with the Art of the Possible. What is the ideal set of capabilities that could be brought to bear on this situation? If there were no limits, how would we solve the problem? If you fail, at this critical juncture, to think in an innovative fashion, you may fall into the stereotype trap of IT waste. You’ll spend too much, take too long and do them both while delivering the wrong thing. Your customer will look askance at you, grudgingly release funds from their GL and definitely not be eager to work with you again. This crucial Art of the Possible phase is where we can be creative, inventive and clever. We can and should be thinking about doing things that are better, faster and cheaper. This is our opportunity, as IT, to impress, outperform and…wait for it…OVER-deliver. Yes. I said it. Deliver MORE than was asked of us. Shocked?

Thinking in terms of what is possible without limitations is only doable if the lexicon of capabilities is used. Technical capabilities themselves can be defined as abstracted descriptors of what technology does. It’s important to note that they’re not about who makes them, or what department ‘owns’ them or what buzzwords or acronyms you apply to your credentials. They have roles associated with them. They have activities associated with them. We’re talking about functions of IT and the types of people that execute those functions and what they have to do, generally, to execute those functions.

If there happens to be, by some lucky stroke, a comprehensive business architecture at your company, you are in luck. If thought has been put into what the business of the company is, how that business operates, what functions and activities and roles are needed to operate that business, then as a technologist you might as well have won the lottery. The business capabilities are defined. A business that knows what it does, how it does it and who it is that does it, is a business that has set the proverbial ball for IT to spike. Frankly the hardest part is done. All YOU have to do is come to terms with what IT does, how it does it and who it is that does it in support of the business. In fact, you should now be able to directly relate the things that the business does, the business capabilities, with the things that IT does, the technical capabilities. You can actually draw their relationships. You can model them in a generic way so that these relationships can be described, understood and any related assets reused.

If a business capability at an insurance company is “Enrollment” then you should be able to define the technical means by which “Enrollment” is enabled. That might include some web app or green screen presentation components, data integration, storage, messaging, some platform elements, pieces of enterprise security, perhaps identity management, some third party gateways, etc. Each of these comes implicit with specific roles and actions that are performed. In a perfect world, they’d also have performance indicators which, as we measure and report on them, give us some indication of success or failure in enabling “Enrollment”. No product mentioned. No vendor stroked. No group or fiefdom elevated. Just a purely conceptual discussion of what we need to do in order to deliver value.

Rocket Scientists

This literally isn’t rocket science. I go back and forth on the question of whether it is more art than science. But at the end of the day I come down in favor of some blend of the two in a mixture of varying ratios, depending on my mood. I do know that it isn’t strictly science, reducible to algorithms and rigidly enforced in a step-by-step, three-dimensional framework. We’re talking about people and what they do for a company in order for the company to make money. There is bound to be variation. And that fact, coupled with the reality of ongoing change in the market and in technology, reinforces the notion that the initial discussions of solutions can only be successful if held in the conceptual fashion.

As technology and architecture professionals, we can only be successful and valuable to those who pay us if we frame our work in terms of capabilities at the outset. Yes, details must follow. Yes we must ultimately choose a vendor and a product. Yes we live in a world where cost and time dictate the boundaries of our actions. But if we start with those things, we’ll ultimately fail.

If I had started with the excruciating detail of who makes the brake pads of every vehicle model that may or may not please my wife, then I was absolutely doomed to failure (and perhaps endless nights on the sofa). Instead I began with what I understand, at a conceptual level. She wants white. She wants lower overall cost. She wants sibling rivalry to subsist. I may not understand or agree with everything she wants (what’s wrong with the black/brown leather combo anyway?), but my mission is to enable her wishes and deliver a solution that addresses her concerns. I want to solve the problem she has identified. While there are several root causes, not necessarily all of them understood by her, if I can solve those things, I deliver value and enhance my overall desirability as a husband (as if my strikingly youthful good looks weren’t sufficient). It isn’t about what I know or what I think is a good wattage number for the stereo. It is about what solves the problem at hand in the most efficient manner.

Be Clear, Be Simple, Be Valuable

Our solutions, our architectures, must start with capabilities. They must be capability based. They must be informative without clobbering our customers with unnecessary details. They must speak to the things we will do as IT, the people that will do them and the activities that they will perform, and these things must be in a language that is understandable by our customers. This effort must be about the what of our technical prowess. As important as the how may be to us, it isn’t, in the end, about us. It is about the business and the capabilities they need to have in order to be successful.