The Federal Government finds itself at a watershed. The old practices of procurement to satisfy government requirements are being squeezed by a strong need for agility, visibility of information and our ever decreasing ability to pay to “reinvent the wheel.” There is an old saying that goes like this: “It’s not that you have what you want, but do you want what you have.” When it comes to looking at how to create new systems and processes to handle new requirements, government agencies won’t be asking how to build or buy something new, but asking what exists now that can be reused and shared among programs to get the best value for government dollars spent. And the time for this is now, not 5 or 10 years from now; so we’d better learn to want what we have.
With world events being what they are, there is an enormous pressure on federal budgets and organizations to not only do more with less, but share what they have so that their systems, organization and people have the greatest value. Service-Oriented Architectures (SOA) and Service Infrastructure software enable the Federal Government to take the critical steps toward sharing information and processes among other agencies. This article provides an overview of what a federal agency needs to think about both organizationally, politically and technologically with regards to SOA technologies and practices.
There has been much hype about SOA in the last few years; however, the thing to understand about SOA technology is that it represents a significant leap in the maturity of distributed systems. Sharing resources is the foundation of a sound SOA strategy. These shared resources should be available to consumers with as little effort as possible. Organizations should expose their shared system via completely standards driven interfaces and does not require specialized software or hardware to be purchased by those wishing to use that shared service. The most important software category of SOA software with respect to strategic SOA initiatives is SOA Infrastructure software such as Enterprise Service Bus (ESB), Service Enablement Platforms and Data Service Platforms. The reason infrastructure software is so important to consider is because it provides the technology platform that enables proactive sharing of services while mitigating many of the risks and issues that have killed other distributed systems or data/service sharing efforts.
Strategic SOA presents some significant challenges to the organization of any federal agency. Most significantly, shared services represent a completely new way of doing business. Instead of a “need to know doctrine” where agencies do not share information unless there is a specific need from some specific other agency. The doctrine now is better characterized as a “need to share” doctrine. Agencies need to proactively begin sharing data that is or maybe useful to other agencies. The organizational preparation that an agency needs to accomplish this reversal of doctrine should not be underestimated. Part of that preparation begins with selecting the correct SOA Infrastructure software but even more vital to this transition is partnering with a System Integrator that offers extensive consulting practices that that covers many organizational areas such as cost, budgeting, governance and business strategy.
The politics of SOA will most likely be quite simple. Government agencies shall share data proactively; actively encourage other organizations to utilize their shared services and utilize the shared services of others to the greatest extent possible, or face budget cuts and poor performance reviews. The technology is there and is ready to be utilized today to get maximum value from the federal governments existing assets. The “need to share” doctrine can be realized and the momentum toward a shared service infrastructure across the government is growing and doesn’t look like it’s going to stop any time soon.
Subscribe to:
Post Comments (Atom)
4 comments:
Good analysis!
The most urgent problem for SOA in Government today is not understanding "the need to share", but understanding "the most flexible way to share". Service Infrastructure provides the framework for making sharing "easier" than the point integrations we've done in the past. Ease-of-use of any software/system architecture and framework will determine which SOAs are "good" (funded) and which "go away" (de-scoped).
Does the government have a viable enterprise architecture or is it just about documentation?
That's an interesting question. The first thing to point out is that the government as a whole does not have a single Enterprise Architecture. Several years ago all agencies and departments were under major pressure from the OMB (Office of Management and Budget) to produce an Enterprise Architecture for thier functional area within the Government. Largely this was done to comply with demands from the Federal Enterprise Architecture Program Management Office (FEAPMO) to map what organizations were doing with thier business planning to how they were spending thier money. The departments and agencies were then "graded" by the GAO on thier EAs, but that's another story. These EA submissions and the accompanying OMB 300 forms (see my link to the FEA PMO) was done ostensibly to check to see that agencies were not spending money on things they already have or see if there is duplicate efforts across agencies that might be somehow consolidated.
I'm not sure exactly what you mean by "viable" but various agencies are executing according to thier EAs. However, there seems to be little or no linkage between their implementation architectures (which are created primarily by Systems Integrators such as Nortrup Grummand and Lockheed Martin) and their links to the EA. So there is surely some drift off the EA even in the best managed organization. From an SOA perspective it should seem like a natural fit for systems built with SOA in mind to enhance the "viability" of an organizations EA. However, how that goes in reality is still in it's infancy in the Federal Government and much remains to be seen.
The ability to share services is a major prize that SOA can deliver, to the wider world as well as to government agencies. But it implies a standards infrastructure - and more importantly a commercial infrastructure - that isn't yet there.
Post a Comment