I endorse Carl Malamud for Public Printer of the United States
(Administrator of the US GPO)
Monday, March 9, 2009
Sunday, February 15, 2009
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:
- HR
- Intel
- Operations
- Logistics/Sustainment
- Planning/Doctrine
- IT
- Training
- Finance
- 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:
- Understand what questions are being asked from each perspective
- Extend architectures from models that produce schematics into queryable sources that can produce schematics and also answer questions
- Extract the answers to those questions automatically to an open, text-based format
- 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):
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?
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?
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?
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.
Tuesday, January 27, 2009
"Response" to Previous
Update 12.28.09: I just had to record for posterity the flames from some folks who tagged my previous post in Reddit. (So much for polite, constructive discourse.) In truth, I would like to have this conversation with some of these folks. Even the harshest ones. But I don't want to have to register for a service I don't use and I don't want to get into flame wars over comment threads. I get the frustration. I've experienced it. I too have been and remain rather skeptical of the hype. Some level of hype gets things noticed and forces conversations that need to happen but aren't. Some of what I said was written and/or read poorly. For example, Mac/Office is about culture, not interoperability. I know that Google came before Web 2.0. That was expressed poorly. My company also was doing a lot of this stuff before we ever heard of Web 2.0. I can't speak for Tim O'Reilly, but I feel confident he realizes he didn't invent something. He made salient observations about the Internet and human behavior and how the two have, do, and perhaps ought to work together. Many of these concepts go back decades to the roots of computer science and the Internet. I've been in workshops with Senior Technical Fellows, having extremely well-qualified CVs, who said, "we proposed all this in the beginning." My response was, "Exactly. Isn't it past time we got back to that?"
And I know how radical ("insane") my idea sounds, but I am not saying government should fund Web 2.0. This is not about a bailout, as some seem to think. Some of these comments come from the position of having no idea how government runs. I'm saying government is actively spending money, money is being wasted, and I know from education and direct, relevant experience that several of the concepts articulated in the original essay can help tax paying citizens spend more wisely.
Consider this from the Army:
"The Army spends, under 85 programs, approximately $6.7B annually on Information Technology (I.T.) without a method to converge these systems into a centralized infrastructure designed to improve robustness and dynamically deliver web services to hundreds of thousands of users while reducing risk"
And that is just service within DoD, DoD just being one (the biggest) government spender on IT. It's full of waste and the reason isn't just because Web 2.0 is magic Koolaid or that we are already on to so-called Web 3.0. It is because the government still looks at the Web the way it used to be in the 90s; i.e., with a 1.0 mindset.
More concrete thoughts on this later on how exactly government might use Twitter, for example. Think SMS. Twitter is a metaphor. The folks who run Twitter - for example - just might be the Pros from Dover who can help save government from itself. Think FEMA and USAID...
Sunday, December 28, 2008
Q: How Does Web 2.0 Make Money? A: Government.
A lot of folks are wondering how Twitter will monetize. Will they sell premium services to businesses that want to make Twitter part of a communications strategy? What about Flickr, YouTube, and Facebook? Are the ads working? Regardless, if this is Web 2.0 then why are we still talking about subscriptions and eyeballs on pages?!
I want to suggest another strategy: Sell to government.
I don't mean the general sense. I mean, specifically, Twitter, YouTube, and Facebook and a great many others should set up for-government operations. I wrote to the Delicious team years ago asking when they were coming out with a solution that I could bring to government, i.e., in-house. I never got an answer. Regardless, figuring out how to get these companies oriented toward government is not straightforward. Most Web 2.0 companies literally could not be further outside The Beltway. I suspect they don't have much in the way of strategy for state, tribal, or local either. Google does a good job selling into government with its enterprise appliance model, and with more than just search. But, of course, Google is a massive company.
Culture has a lot to do with things. The Pentagon is not a T-shirt and flip flops kind of environment. "The Bigs," i.e., large-cap companies that provide most of the contracting labor, are not at all oriented to innovate in the Web 2.0 technology space. You don't see Macs anywhere. You do see MS Office everywhere. I'm not entirely sure what conclusions can be drawn from these observations but I am sure the observations are significant.
I suppose the best example of Web 2.0 penetration into the government space is tele-presence. Adobe Breeze is ubiquitous on Defense Knowledge Online (DKO). Just about anyone with a DKO government account can create or attend a meeting. But tele-presence probably isn't the first thing that comes to people's minds when asked to name a Web 2.0 technology and I'm not sure Adobe is the best example of a Web 2.0 company.
Yes, there is something different about Twitter, Flickr, YouTube, Facebook, Delicious, et al. I happen to think that something different - whatever it is - translates into unrealized opportunity for both buyers and sellers in the government space. I choose to focus on these technologies specifically and there are others that I include. ProgrammableWeb has a solution for the registry problem, for example. I don't represent any of these companies, by the way. I call them out as (mostly) well-known examples of capabilities the government needs. I don't really care if Flickr, Picasa, or PhotoBucket is the image repository of choice. Vimeo and YouTube can and should compete for the video infrastructure.
The point is that government needs platform solutions.
Simple, content-based, platform solutions are the most obvious plays for Web 2.0 in government; images, video, audio. The federal government processes a staggering amount of this stuff. The DoD may be the first to get into the mix with TroopTube.
There also are plenty of outfits that would use social tagging tools if only they could bring them in house. By bring them in house, what I mean and recommend is providing enterprise services solutions. It's nice to have applications that provide tagging, but applications are seldom the best enterprise solutions and are hardly social (except, perhaps, in MOSS). Tagging is a domain, a Web 2.0 partition, if you will, unto itself. It is a simple-enough-but-not-too-simple utility that scales and it can be integrated with just about any other application, regardless of whether or not the application was designed with tagging in mind. Yes, government needs strategic guidance and support for tagging services and Web 2.0 tagging companies are just the ones to provide it...if we can figure out how.
The current providers, a.k.a. "The Bigs" are not oriented to provide Web 2.0 tech support.
This is either an opportunity to get new business before The Bigs or to create a business of showing them the way. In any case it is an opportunity to make money. More specifically, it is a way for Web 2.0 technologies to make money. In the government services space the biz-speak is generally referred to as "priming" and "subbing," as in: you are either a prime contractor or a subcontractor. I don't see many Web 2.0 companies subcontracting to big, traditional system integrators, though.
The government is not set up to acquire Web 2.0 technologies.
While services contracts are fairly common and understood, things are less well-defined in the products and solutions space unless the products and solutions are ubiquitous or otherwise extremely well known. Government, especially federal, wants to buy everything in bulk. See also: Indefinite Delivery, Indefinite Quantity (IDIQ). New technology is extraordinarily difficult to insert, especially in secure environments. Protocol, procedure, and process rule the land. Force-fitting into an existing model is too often the preferred method.
We are getting better at defining and avoiding undue process but process, by definition, is: 1) necessary and 2) inherently situational.
When doing business with the federal government, it's important to know how business is done inside The Beltway. There are most probably things in the mix that need to be undone, too. To a meaningful extent the situation is not different at state, tribal, and local levels. Education is needed on both sides of the buyer/seller relationship. We might "change the world" in the process of implementing Web 2.0 for government, but requisite is the obligation to have a fair understanding of "the world" first. The obligation goes both ways but mostly falls on the shoulders of sellers.
Choices for Web 2.0 companies to make money by doing business with government:
- Become or spin-off an enterprise systems integrations unit
- Sell enterprise systems solutions a) to government b) to system integrators (Note: probably can't sell solutions to government without either being an integrator or having the support of one.)
- Consult a) to government b) to system integrators on enterprise systems
Of course, "partner" is an option, but still implies one or more the previously listed options.
[Update 9:47 PM - I've decided I really don't like these choices at all. Need to come up with an altogether new business model, perhaps...probably]
There's so much more to this than I can wrap my head around now, certainly more than I am prepared or qualified to comment here.
[Update 9:47 PM - Forgot to comment on need for and evidence of government investment in backbone instracture and understanding of cloud architecture; significant issues arise once a bunch of these services are running around on a single network. And as always, security is different and harder.]
I think it's time Web 2.0 companies, government, and large-cap contracting companies had a grand introduction to one another. Believe it or not, there are plenty of people who have never even heard of Web 2.0.
Subscribe to:
Posts (Atom)
Kitchenfire 3 points 4 days ago[-]
I wonder if this guy knows that Macs can run MS Office. Or that he's insane.