SOA Acquisition Requires Re-thinking Contractor Ecosystem

Here is some description of what we talked about the Gov't doing vis a vis SOA Implementation models with DIB (3.0?). Let's talk, tomorrow, about what, if any, of this & your groups' stuff we want to put in front of the DCGS Board next week.

Contemporary models of SOA Implementation leverage the investment of software companies. Commercial customers take advantage of the investments software houses have made to pre-integrate pieces of their SOA solutions. SOA stack solutions interoperate via well established industry standards, e.g., service management, transactional, security, etc. Therefore commercial SOA stack implementations can participate in a collaborative transaction while optimizing their internal operations (amongst their constituent parts). Commercial companies noticed, some time ago, that their commercial customers had passed through the 'SOA experimentation' phase where they desired a vendor heterogenous stack sometimes called 'best of breed'. Commercial customers no longer were focused on experimenting with SOA infrastructure - they intended to consolidate vendors gains in infrastructure and focus their effort on business, or mission, capability.

Basic SOA Infrastructure Components

SOA Middleware vendors have improved their stacks over the last 5 years, both organically & by acquisition, to the point where the major vendors all have the basic SOA components: Security, User Experience, Transactional, Information/Data Management & Service Management, e.g., Microsoft, Oracle & IBM. Standards exist for infrastructure interoperability amongst vendors, e.g., SAML, SOAP, etc. Commercial customers enjoy both the optimizations and standardization of commercial SOA stacks. They do so because they buy the stack from one vendor. Separate enclaves may have a SOA stack from a different vendor. This is possible because of the horizontal interoperability amongst vendor SOA stacks. Benefits can be achieved by singling up one on SOA vendor within a commercial enterprise, e.g, lower license costs, synergies amongst a single vendors products, or workforce training economization. Most of the changed buying behavior, in the commercial marketplace, is driven by CIOs being pressured to deliver business/mission capability and to place experimentation dollars in areas that are not commoditized or mature, e.g., further up the SOA stack with advanced capabilities, e.g, event processing, high volume ingest, or real time.

SOA Mission Service Components

Commercial companies separate business/mission functionality from the core SOA stack. There are a variety of reasons for this separation of concerns. One driving reason is that enterprise seek to leverage business functionality across their business lines. Business/Mission capability designed to infrastructure standards, e.g., WSDL, SOAP, HTML, etc., should be deployable across the infrastructure. Often businesses employ a common configuration management tool that ensures sets of services are developed by the experts, in an line of business, but deployed via a central run time repository so they can be found and leveraged across the lines of business. Additionally, when centrally managed, common process, data, and user models can be deployed ensuring portability and interoperability of mission services. Horizontal integration, of services into orchestrations for example, is what businesses desire from mission capability. Infrastructure standards, like BPEL, allow mission service integration to occur in a way that optimizes mission capability but retains a separation of concerns that fosters later mission service reuse.

A DoD Worst Practice

It has long been understood that mixing infrastructure capability in with mission capability complicates reuse. However, in early SOA days, prior to SOA infrastructure maturing, it was sometimes necessary to mix these concerns. The drawback of 'concern mixing' is it minimizes reuse and ensures vendor lock in. If mission functionality is written with vendor proprietary features, or extensions, then later porting that functionality to an alternative vendor is unlikely. Similarly, the ways that one could access the functionality become unique to that particular implementation making service chaining, or orchestration, and other more highly performant requests more difficult. However, it has long been a DoD practice, owing mostly to the desire for an LSI to have ultimate responsibility for a weapon systems, for vendors to build mission capability right into the infrastructure. In the past this may also have been necessary to achieve a particular set of Nonfunctional Requirements (NFRs), e.g., speed, availability, throughput, etc. That is no longer the case. Now vendors have very high volume SOA solutions as well as Real Time quasi-SOA solutions (not loosely coupled, but un-coupleable). What is noticed is that the acquisition models lag the commercial best practices for separating SOA infrastructure from SOA mission services.

SOA Infrastructure Implementation Model

DoD must first endeavor to change its SOA Acquisition model. This change premeditates a change in typical vendor roles. It thinks forward to a set of roles that parse along the same lines as the final system should, i.e., vendor/contractor roles should be split along functional lines. Similarly, ultimate responsibility for a piece of the overall SOA infrastructure should lie with the supplier who is expert in that piece. For example, Software Houses have spent a significant amount of R&D ensuring their stacks are both complete and compliant with commercial SOA standards. This represents a source of investment upon which the Government should capitalize. The Government should reap this investment in two ways:

1. Accept the end product of the investment, e.g, the SOA stack, as is. Do not attempt to repeat the investment with Government money (and then repeat the sustainment investment)

2. Buy the SOA stack from the Software House as a working unit. Do not buy the parts and GFE them to a 3rd party for fabrication; Hold the Software House responsible for their proper functioning as a SOA Infrastructure

The Government should apply its specs & standards to the stack buy & expect the software vendor to deliver the stack(s) in compliance. Furthermore, since the Government desires tech refresh it would behoove the Government to measure stack vendors on currency. Currency could be a combination of ensuring the vendor adds contemporary features, with each maintenance rev, and that the vendor stay current with infrastructure standards. Currency could be a condition of ELA option renewal. The Government should make it the interest of the Software House to ensure that the SOA stack does not get stale (or it gets replaced). However, the Government should not exercise the hybrid option of buying the stack but hiring someone other than the stack author to keep it current. This model puts the Government back in the T&M business where the Government is incenting the 3rd party to develop more code to sell more hours.

SLAs for SOA

It is very important that the Government not attempt to be overly prescriptive of how vendors fabricate their SOA solutions. Commercial companies prescribe the desired outcomes & leave the vendor free to innovate, within certain bounds, to achieve them. This was touched upon with the 'currency' requirement above. The Government should prescribe the behavior of SOA Infrastructure stacks (features, NFRs & standards) but should shy away from prescribing how to fabricate them. The Government should desire this black box approach where the behavior of the stack is how the vendor gets paid. This model gets the Government out of the escalating costs dilemma where the contractor does precisely as was prescribed, the Government receives what it instructed the contractor to build, but the results remain elusive. Hold software companies responsible for knowing the performant characteristics of their offerings - that is what the Government should contract for - SOA performance.

It is also important that the Government select their performance requirements in consultation with the software vendor. Often times a performance requirement can be met, for example 99.9999% uptime (referred to as 4 9s), however the cost is prohibitively expensive. Software vendors can work through the permutations so that the Government can apportion its SOA budget in a way that maximizes the features received and the level at which those features should perform. Additionally, the Government should think in terms of a sliding scale of SLAs, loose SLAs for new features and tighter SLAs for features with well known performance characteristics. Loose SLAs can be tightened up over time, if consumers actually use them. Loose SLAs allow the Government to onboard new features without issuing a long term expensive commitment for features that might never see large user uptake. Similarly, vendors will be inclined to 'lean into' such a deal if they don't have to take on an onerous risky SLA from the start.

Market-based Financial Incentives

One piece of the 'getting to SOA' puzzle which Government finds particularly vexing is changing how it governs contractors. Moving from tightly prescribing a software build, and accepting whatever comes out as the overseer, to financially incentivizing a outcomes is difficult. Software vendors are quickly moved by their commercial customers because they know that if they develop the killer app/service that customers will flock to it. Government contracting has numerous barriers to fast adoption of software innovations. There are a number of actions the Government can take to change the focus from 'build inspection' to 'run time operations' payments.

Interoperability amongst software vendors is a problem the Government has wrestled with for some time. No matter how the interoperability is prescribed, it always seems as though there is some other configuration or set of special conditions necessary to achieve it. Once again the focus is on prescribing how interoperability amongst competing vendor's SOA stack should occur vs that it should occur. Acceptance of a stack should have, as a precondition, inter-vendor interoperability. Vendors should know that they won't be paid unless interoperability comes of our the box. By the Government creating a market for interoperable stacks it establishes the financial incentive in the appropriate place to incent the behavior it desires. The Government should pay for interoperability vs require it as a condition to be achieved during the job.

A demand stream must be ensured, by the Government, to entice commercial software vendors into assuming the R&D costs necessary for Government SOA. The Government must cauterize current Government-distributed stacks, e.g, DIB 1.x, so that future buyers create a demand pool for software companies who invest.

The Government should incent mission services deployments (to common SOA stack). For commercial software vendors to make money they need to have vibrant platforms, i.e., many mission services must be deployed upon them. Part of the new ecosystem model the Government should endeavor to create involves content. Simply getting SOA vendors to supply interoperable stacks is part of the solution. Another part is incentivizing mission systems vendors to expose their mission services over these SOA backplanes. The Government could first focus on services that are likely to have enterprise appeal and should consider that new programs may be deployed directly to the Enterprise SOA platform/backplane. These mission services must be available day 1. Often times the example of the iPhone app store is used. It is important to note that Apple works very hard with its content partners to ensure that the app store is full on day one. If mission services are considered content and SOA stacks are content backplanes, then both pieces are necessary for the success of the ecosystem.