Enterprise Architectures As Data 2

I wrote about this topic last December. Now I want to drill down on a key element of our approach for turning enterprise architecture models into queryable sources. Furthermore, I should address why anyone would ever care about "turning enterprise architecture...blah blah blah."

There is a technology aspect and a human aspect. Both are necessary, but technology alone is never sufficient. Far more important to our success has been a strategy focused on answering key stakeholder questions.

My experience is mostly with Department of Defense Architecture Framework (DoDAF), so I will use examples from that domain. But to the best of my ability I will use language that is portable to other domains.

So, what are "key stakeholder questions?" To what does "key" refer, "stakeholder" or "questions?" The answer to the second question is: both. The answer to the first question is: depends on which stakeholder(s) we are talking about.

In the Army, and DoD in general, organizations are broken down at the general officer level from 1-9 as follows:

1. HR
2. Intel
3. Operations
4. Logistics/Sustainment
5. Planning/Doctrine
   
6. IT
7. Training
8. Finance
9. Civil-Military Cooperation

These are the key stakeholder perspectives at the highest level.

An Operator wants to know, "How will architecture help me win the fight (i.e., get the work done)?" A Budget Analyst wants to know, "How does architecture help me making smarter spending decisions?" These are reasonable questions.

UPDATE 2009-09-28: THERE IS AN ERROR IN THIS GRAPHIC. THE G8's perspective in this case is "Force Development." He is asking the question, "Is the Force we are developing in line with my capability expectations?"

Indeed, no model exists except to answer questions.

But when presented with architecture in forms that speak only to the IT/engineering perspective, i.e., schematics, flow diagrams and the like, the multi-stakeholder conclusion tends to be, "Architecture doesn't help answer my questions." That's unfortunate because architecture, especially at the scale and complexity of federal government, can be effective in answering many useful questions for all perspectives. The trick is to:

1. Understand what questions are being asked from each perspective
   
2. Extend architectures from models that produce schematics into queryable sources that can produce schematics and also answer questions
3. Extract the answers to those questions automatically to an open, text-based format
4. Transform answers into views that are "fit for purpose," i.e., can be understood and used from many perspectives

Therefore, the question IT people should be asking is, "What can I do to make architecture better able to answer stakeholder questions." To be sure, there are questions architectures can't answer. But it is more productive to focus on the questions that architecture can answer. Following are actual endpoints in use (though they don't point anywhere in this post):

GetCountOfPlatformsForArch
Returns an Xml Node containing a NewDataSet for the distribution of platforms for the given architecture
Answers the question: What are the platforms of this architecture and how many of each?

GetCountOfPlatformsForArchAndTOE
Returns an Xml Node containing a NewDataSet for the distribution of platforms for the given architecture and TOE
Answers the question: What are the platforms of this architecture and TOE and how many of each?

GetEquipmentForONN

Returns an Xml Node describing the equipment used by the given ONN in the given architecture
Answers the question: What equipment does this ONN use in this architecture?

Believe it or not, this type of view can be automatically produced

from an enterprise architecture model

There is added value in this approach, too. From the technology side of the coin, opening up architecture models through relational databases and ubiquitous, text-based formats makes it much easier to relate architecture data with other data. An architecture can tell you "how many," but "how much" is probably in another database. In fact, there are about 85 software programs the Army knows about that are being used to track costs for systems. To be sure some will be eliminated. But many will stay and those that do must support data portability.

Ok, so...why does any of this matter?

Let us start with the fact that government is an enormous compiler of data. It really doesn't matter if we are talking about enterprise architecture, a Line Item Number database, a "portfolio management" system, or even good, old-fashioned spreadsheet. Analysts will never part with their spreadsheets. Wonks stuff data into tools.

Unfortunately, many useful tools that are good at capturing data are lousy at both storing it and saving it back out. Applications too often co-mingle their own data with the subject matter data, making it difficult to separate later. Many tools don't have export in mind. (All tools should have export in mind.) Owners of online, enterprise databases typically only offer their contents in human-readable formats; PDF and HTML pages. Applications built for one perspective are lousy at supporting other perspectives. The list of interoperability challenges goes on.

A battalion commander is not typically nimble with UML. Same goes for a budget analyst and resource director. In the world of enterprise architecture the consequence is that a lot of people are taking a lot of time away from their primary tasks so that they can manually shuffle data into views their many customers demand. Time is money. My back of the napkin estimate is that architecture shops are working twice as hard for half the output that they could otherwise achieve if they offloaded the ETLV problem to IT and got back to building architectures. Of course, plenty will point out that architecture and reality are often different. That's a topic for another discussion. Like it or not, enterprise architecture plays a huge role in government organizations, especially DoD. This is just about getting better return on that investment. It's opportunity for both a current cost savings and future "force multiplier."

Finally, I would argue that the strategy of answering key stakeholder questions is useful to knowledge management in general, regardless of subject matter domain or technology form factor.