Hey DoD, Enough About SOA Already!

I know I’m about to dis a sacred cow, but here goes…

There is this widespread fiction in the DoD that if all the IT systems just get SOA religion, seamless interoperability and operator nirvana must follow. I hear it over and over, “if the 3rd party applications or ‘capability modules’ ‘expose their data’ via SOA interfaces we’ll be able to readily put together composite mission threads, workflows, applications, and etc.”

So…, if I have a command center full of independent client server applications today, written in different languages, and built on a variety of DBMS implementations, how do I modernize them to meet the user’s real needs? Answer: “Make them SOA.”



Nope. Insufficient answer.




Adding web services to an aged client server application, that instantiates an obsolete process, and that has no ability to participate in a composite application environment, does not create NetCentricity (whatever that is exactly). The broad trend of opening up application stovepipes via service orientation to permit much wider and faster information sharing is absolutely critical, but it isn’t by itself sufficient.

Yet, architects and their architectures seem to be fixated on “NetCentricity” as manifested in the term “SOA” while all the other things that go into making a viable enterprise seem forgotten; including the actual meaning of the term NetCentricity. In reality, there is an entire stack from silicon to OS to middleware to application frameworks that support a successful capability (plus other non-stack things like a consistent and effective user experience). Somehow we seem to have forgotten all of that in our rush to genuflect before the SOA god.

If “access to the data” was all that mattered, we could solve that problem by storing everything in one big spreadsheet on a network drive (rumor has it, that’s been done); but obviously, there is more to an effective capability than that. And regarding the definition of NetCentricity… I think you’ll know you are NetCentric when with the support of technology you fight differently; not when your already existing processes have been automated.

I know some people will say all the other stuff besides SOA is already being accounted for in the available guidance. Well, that may be true, but the slides I keep seeing rarely seem to mention anything but SOA. It’s as if user applications are going to spring fully formed from the silicon as soon as this ambitious but ambiguous SOA materializes. “We won’t build applications anymore, we’ll build web services and operators will consume them.” No they won’t, SOAP is for machines.

Maybe a concrete example is in order. Let’s say one of the services wants to build a new airspace management and de-confliction capability. Today what would most likely happen is that a “three-tier in two-box” (UI/App + DBMS) application would be delivered to run in a workstation (i.e. significant client code running on a user’s workstation).

It probably wouldn’t be shipped as a disk, it would be shipped in a green plastic shipping container with all the servers, monitors, and maybe even networking gear that was required. If there was a requirement for a “thin client”, the application layer might also support a web client; but that would still most likely be provided from that one box running its own web server.

To meet existing “NetCentric” requirements the client workstation, running both the presentation and “middle” tiers, would probably just expose some web services for things like “get airspace” or “request de-conflicted flight path” (or maybe “run this query: query string”). These services could run from a single, non-horizontally-scaling workstation-class box on the command center floor while also serving the needs of the primary local user, and still satisfy NetCentric guidance today.

The result of this approach would be an inability to horizontally scale the back end of this thing in a data center-like environment (for fun, count the number of unique stand alone workstations on a wall street brokerage firm trading floor, now count them at a DoD command center). Additionally, equipment purchases would likely be tied to the program directly making enterprise-wide sourcing of infrastructure difficult. Integration of the capability into processes or workflows would be dependent on some external application to integrate them at the “SOA” level and would require significant application-level coding (can’t “mash it up” at the user level). Finally, there would be no ready way to add components of the new capability at the presentation layer to other composite applications. In short, you get a workstation or two with one user at each one, and unless additional applications are built to consume the exposed services, no one else gets to play.

I think this also illustrates one of the issues associated with a Capability Description Document (CDD). A CDD that would be satisfied by the scenario illustrated above probably would say something like “command center must have capability to develop airspace plan and perform dynamic de-confliction” or something like that. It says nothing about how many users should have access to that capability or how they might be able to integrate the capabilities into their various workflows or composite application environments. It assumes if the capability is “in the building” the requirement is met.

But…

What if the developer of this capability didn’t have to spend money on the basic presentation-layer functions at all? What if the capability was going to be deployed into a horizontally scalable server environment that established an application framework including geo-spatial presentation, micro formats, JSR-168, or some Rich Internet Application framework? In other words, what if there was a focus on infrastructure to support presentation-layer integration in addition to the enterprise application integration focus usually implied by “SOA?” Or put another way, what if there was a “facebook or Salesforce-like platform for C2″ that the capability developer was targeting for deployment?

The capability developer would then be able to focus on the core of the functionality and key user interface components knowing that the physical and software architecture for meaningful integration into the command center plus a bunch of available pre-integrations to other data sources would be provided. Build the application logic, write your widgets, integrate to the existing data sources via nice clean api’s and deploy.

The Department certainly must continue to press for service enablement of current and planned line of business applications in support of enterprise integration, web enablement, and the broader idea of NetCentricity. But let’s recognize that this is only a piece of the enterprise architecture conversation. And please, as October approaches, remember that you can’t buy a SOA, even when a “SOA vendor” approaches you at the end of a fiscal year with a deal you can’t refuse.

Hmmm, I know this is getting long, but just one more thing. You know, maybe the problem is that we expect the words words “SOA” and “NetCentricity” to convey too many kinds of meaning, and as a result they convey none. Enterprise integration, a style of architecture, a class of integration products, a kind of non-hierarchical human interaction, and maybe even AJAX programming styles and lightweight web interfaces all are somehow being crammed into these two words. Outside the DoD we would use many more words to describe these ideas including at least: Enterprise Integration (MOM, ETL, ESB, …), SOA, Web 2.0, Collaboration, Social Networking, content syndication, Rich Internet Applications, Enterprise 2.0 and so on…

After all, the way we think is shaped by the words available to us. Oceania introduced (and kept pruning) Newspeak to make its citizens dumb. Limiting ourselves to SOA/NetCentricity-speak is doing the same thing to us.

Leave a Reply

Your email address will not be published / Required fields are marked *