Keynote to Surface Warfare Community

You must open this in IE & accept the cert. error: https://ww2.swonet.navy.mil/swonetweb2.0/live/OAForum2011.aspx

Don't worry, it's a U.S. Naval Surface Warfare Association site.

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.

Democratization of Architecture

Many IT professionals know they should do their architectures. How can you build a system, or preferably a capability, without an articulated architecture to backstop it? But UML is a complex inscrutable art. The tools to weild it can be daunting. So very few IT professionals, going by the name architect, actually build them. Most times, when built, they are a snapshot of whatwas wanted and are sent to the bookshelf to live out a long life.

It is with this as context that we undertook an effort, about 6 months ago, that we now understand as 'the democratization of architecture' - making it safe for the masses. The gist is that we wanted to accomplish 2 things:

1. Lower barriers to entry

2. Make IT capabilities more accessible at design time

Using a simple spreadsheet input approach we eased the entry barriers into a real UML tool, Rational Software Architect (RSA). Now we can consume customers' mission elements via a simple excel spreadsheet breakout. Customers sit with client personnel and talk about their 5-7 major mission elements that they need in the solution. Next they break each of those down to its constituent parts, and so on down to 4 or 5 levels of detail. RSA consumes these mission elements and produces a strategic mission model - simple, done!

On the IT capabilities side, we've done a market survey. For each of the major IT capabilities groups, e.g., Security, User Experience, Development Tools, Information Managment, Transactional Management or Enterprise Service Management. See pic below

.Basically all the horizontal middleware capabilities, we build simple models. These models were labelled using the customers' vernacular - the way they talk about these capabilities.

Now that we have consumed the mission elements & have resident the IT capabilities, we can produce a simple set of spreadsheets, one for each IT capabilties group. However, we can also put in juxtaposition, to the IT capabilties, the mission elements.

See pic for service management example of RSA produced spreadsheet that maps mission elements (columns) against the IT capabilities (rows). This simple form allows the user to sit with a client person and map IT capabilities, that could satisfy requirements, against the corresponding mission elements.

The cells, where IT capabilties and mission elements intersect, is where we note the correspondence. A simple x in the intersecting cell is all that is needed. Now, if we have a statement about that relationship, then that can be easily entered, in the cell, and will show up on the actual UML model. Once the six xlses are filled out (reference 6 pieces of the core above) then using a simple RSA plug-in (authored by Fred Mervine, the Grandaddy of this Democratization effort) we re-c0nsume the IT capabilities crossed with mission elements and produce a UML joint capabilities diagram. Essentially we join the mini-models from each sheet into one overall model that shows the collection of relationships. UML was never this easy (for the client).

A real UML jock, at this point, can take that joint capabilities diagram and decorate it with NFRs, sequences, and other essential architectural elements and produce a final actionable architecture. However, what we've done is to ease the process of IDing the basic mission elements in the solution and IDing the basic COTS architectural elements needed to satisfy those requirements. Architecture for everyone.

SOA Ecosystem & Sets of Systems

As net-centricity becomes a common term and SOA moves into its productive phase we increasing see sets of systems coming together. The tendency is to take the term system and extend it to 'System of Systems' SoS. However, I'll argue that this approach takes the hyper-specified method of defining and engineering a system and imposes it on a set of systems. Gone are the days where the world moved so slowly that requirements stayed put long enough to waterfall a system out. Now that the global village is hyper-connected change occurs in real time. We need a new method by which we conceive of and implement sets of systems. Even sets of systems themselves are being linked together. Organizing principles change as we go up the hierarchy of sets.

If I join 5 systems together I can not do so rigidly like they were built. One system can be built to clearly define its inputs and outputs & its behavior given them. However, once I conjoin several systems I must live with the randomness of their individual operations. It is not random in the sense that it is unpredictable - they are, after all, computer systems. Their individual behavior is random in respect to the goals of the set. This means that the operational rules of the Set of Systems (SetOS) must be at a higher level of abstraction than the individual systems. The SetOS must scavenge resources when it can get them and offer back, to the individual systems, resources as they may take advantage of them. The term loose coupling has been used for this kind of idea, however I believe this term misleads. It is all about the focal point. Loose Coupling puts the focal point back on the individuals systems - which are loose coupled. We need to pan out. We must come up with a language about sets.

Set talk makes people uncomfortable. It is the pluralistic nature of such talk that disarms us. How do we conceive of system operations (a system like Gregory Bateson would use it) that apply to the whole set of constituent systems? An ecosystem is a good model for such things. Sets of individual actors interplay with each other according to operational principles that show behavioral organization at a higher level. Using SOA as an example. We can have individual SOA-based systems but it is only when the aggregate decide to collaborate that you actually see useful cross-program services begin to populate the enterprise registry. A group of ACAT 1 program managers who all, individually, implement SOA will never place one useful service in the enterprise registry. It is only when these individual operate as a set of PMs that we begin to see the benefits of SOA as an ecosystem enabler.

SOA is not dead, but the ACAT 1 acquisition system is trying its hardest to kill it off. SOA will continue to shear at the cultural & programmatic aspects of our acquisition system until the SOA ecosystem arises. There are interesting examples where it is beginning to happen. Portfolio owners are beginning to see that they can organize across their SetOS to drive a higher level benefit. This benefit is almost always to the greater good and echews the hyper-specific needs of individual programs.

AFEI.ORG Industry SOA Acquisition Reform Recommendations

(See attached file: SOA_Acquisition_Final_Report.pdf)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -

Ooops, for some reason Blogger didn't clip it, so let's try this:

http://www.afei.org/whitepapers/SOA_Acq/SOA_Acquisition_Final_Report2.pdf

Let me know if you an access it without being surveymonkeyed with.

VWs as 3D Visualization of Complex Technology

The commodification of user experience technologies & immersion methods have presented an opportunity to leapfrog a generation of user interface innovations. 3D Virtual Worlds & Flexible gaming engines present the possibility of bringing 3D immersive user experience to everyday applications. The example clipped below shows an environment mocked up in a Virtual World that both accepts data (X,Y,Z coordiantes) from the real world & dispatches new X,Y,Z coordinates back to the real world. The coordinates coming in are a directive to move the warfare platform to an exact location and that is done automatically. Then, when the commander desires, he directly manipulates a warfare platform and then that (new) location is dispatched out to the real world. Imagine that is a commander receiving an order to move his warfare platform to that spot, i.e., those new X,Y,Z coordinates.

Changing the Mindset from Systems of Systems to Sets of Systems

The problem with Systems of Systems is that they are the rigid stepchildren of their Systems(Hyper)Engineered parents. Replete with design-laden characteristics they belie the core functionality they were built to embody ~ agility. Agility, if truly desired, must be the core design principle. What this means is that as important as determinism, or your Most Important Requirement(s), agility must be. A SySofSys ends up with additional functionality but no leverage to change and add additional additional functionality. A SetsofSys approach takes as a guiding principle that you are creating an IT toolbox which parses functionality into meaningful chunks and provides for quick assemblage. This requires an overlay approach where an organizing principle, the overlay, is created. An overlay governs which capabilities are brought to bear, not the original design. The original design design is of the IT backplane & the core capabilities. An overlay design facility must exist that allows mildly experienced analysts to whip up an new app config quickly. Not during run time mind you; we must allow for solid run time performance & rarely does reconfig occur during the execution of business. It is normally during a pause, or lull...business is still occuring, like a heartbeat, but you are not hot in the race.

next post: SW moves from a design-time activity to a run-time (design)

What Makes the Millenial Gen Tick

Someone asked recently "What do you technical peers think of Second Life"? The question was aimed at a potential culture war. If the technorati didn't believe in Second Life, or its peers, it wouldn't be worth getting involved - even though the 3Dsocialnet is a very real evolution. My answer is...If you are over 35, and you go into SL, you look around, see, perhaps, interesting things, but are not compelled to act. You may never go back in, or if you do it is unlikely that you will become part of the socail fabric. If you are under 35, this is how it works. You are sitting next to your friend, say close enough to reach out an touch them, but you are text paging him on your cell. This is the equivalent of passing (paper) notes in class, but does not take place in the physical world. Similarly, when you are liesuring, you sit on the couch, across the room or next to your friend - doesn't matter. You are interacting, with your vehicle or avatar, through the TV screen. Since you can remember the internet, IM, and online video games have existed. SL is nothing but a more faithful rendering of the IT disintermediated world in which you live - - why wouldn't you gravitate toward it? Why doesn't Gen X or Gen Boom think this way? Why does IT often seem like an impediment to interacting with other humans?

Gen X. If you think about it, this is how it worked, once you woke up in the morning, got dressed, ate your breakfast, you were out - of the house. Playing with your friends, on the weekends all day long. One game after another, whether it was city stickball, combing the woods, or kickball, you were physically interacting with other humans as your primary means of social interaction. Even today, when I call my friend, we spend about 2 min.s otp, and only to determine where, in the real world we will meet. IT was not the social fabric of our formative years. Can we adjust, yes, but it is just that an adjustment from dead center.

You might be able to gauge someone's level of IT disintermediation by walking the sequence of IT across which they have traversed. Just to use myself as an example:
-1. A Pong console
0. 1982 purchased a Smith Corona Correctable Typewriter for college
1. 1983 Second semester I was acquainted with an Apple IIe for wordprocessing, $325 down the drain on that SC. Very difficult to use, cntrl-x for 20+ key combos
2. 1984 Moved to the computer lab, maybe 20 IBM ATs/XCs with which we did word processing on wordvision. I was hooked at that point
3. 1985 Took Fortan 77 & Pascal on the Burroughs 5500
4. 1984 Took Fortan IV on another MF
5. 1985 Commodore 64
6- IBM PCs
7- Sperry-Univac
8-Prime
9-Mac
10-and so on util today IBM T43

Somewhere in the middle of the span, which is still moving, is my burn in point for the computer concept & my relation to it. Sure, it will change, but it is an anchor nonetheless, from which I perceive the world.

Conrtol Points on the Internet

Google has declared its mission 'to organize the World's information'. How is this relate its movement into 'commerce brokering'? Google's attempt to capture commerce as an internet control point is, however, a common business model strategy. The strategy is to own a critical nexus of the internet complex through which internetting behavior must pass. Google earth is a similar control point. Perhaps there are a set of control points which users rely upon to use the net. Commerce, 3-D backplanes, media exchanges, social backplanes, and other nexuses will become the control structure of the internet as it moves beyond Web 1.5 into a true 3-D internet that moves from centralized control points to value-based control points.

Vectored Thought

Our educational system is inherently sequential. One page follows another, chapters follow each other, classes follow each other, and so it goes. This is a bad template for understanding the natural world. By our system for inculcating information into children we decieve, not purposely, them into believing that one thing usually follows another. One thing is usually inside another. Teaching a fair amount of pedagogical skepticism is probably the best innoculation against this bad thought template.

Likewise, I am not sure that the Euclidian 3-space alternative is any better. I suppose it's not worse, but something nags me about it. Perhaps "linear" algebra was the best 'user exit' from these. Interestingly enough, Wikipedia has this to say about the Euclidian method of describing space: "An implication of Einstein's theory of general relativity is that Euclidean geometry is only a good approximation to the properties of physical space if the gravitational field is not too strong." Maybe that's the answer, teach our children that each description is just 'a good approximation'.

Advancing Reality, at the Expense of its Distinctions

Computer technology is growing new appendages, e.g., 3-D, haptics, sound, collaborative, high trust, time-based. Each of these enriches the capability of automation to model the real world and interact with it. With these computer capabilities we come closer to making the computer disappear into the landscape. Computers took our world and first made it 1-space (command line), then moved us into 2-space (motif, OS2, windows), now we are moving beyond flatland. Virtual Reality, High Fidelity Simulations, Gaming & Virtual Worlds are creating hi touch computed environments. These environments will take us beyond 3-D and cause us to blur the boundaries among concepts normally separate, like media vs education, or work & play, or advertising vs eduction. A feeling of immersion, in a computer-based environment, entails mastering the combination of these recently enablable factors to recreate our real world experience.

A Tolerance For Ambiguity

As the shift happens an interesting personal litmus test takes place. Some will pass through the shift, while others will be asked to stay. In a conversation with a friend recently an idea occurred to me. He has had a number of successful careers, first as a guitarist, then as a designer of spacecraft, and now as a software avante garde. He was wondering why he made it through paradigm shifts that trapped others. I noticed a theme running through the variety of solutions he had developed - a tolerance for ambiguity. Others were deeply engrossed in their point of view, but he explored multiple points of view. The more deeply invested, involved, or otherwise glued to a framework on is, the more difficult to see outside it. A healthy skepticism for whatever paradigm in which one sits will make it easier to escape it when its limits are found. This skepticism of complete solutions and tolerance for the ambiguity it assumes both appear as mileposts on the journey through a breakneck cognitive evolution. Given the complexity of the natural world, it is likely that the limitations we see in our explanations for it are indicative of the cognitive limitations we own. As we develop cognitive tooling, like computers, we are able to decomplexify the natural landscape. Innovation of those tools and mastery of them will be the guiding principles as we surf the n-space that is the natural world with its constantly reconfiguring set of factors.

Shift Happens

I believe we are in the middle of a technology perterbation. While most technorati consume themselves with Web 2.0 muse, the technology continues to be nothing but a set of tools for improving the 'expression of the crowd'. A more fundamental shift is occuring...technology is being parted out and recovered in ways that we can never anticipate. Web 2.0 is a pluralistic parting & reassembly method. To that end it accellerates the shift from a system being defined by its physical boundaries to ephemeral systems. The new e-systems are more akin to carbon-based, rather than iron or silicon-based. As these whole systems are parsed and reassembled, there will be mistakes. But as the parse becomes right, the reassembly will happen more naturally. It will look & operate more like a biological entity.