Questions for DARPA/ISO Architecture Review Team

Response from Craig Thompson

Craig Thompson Object Services and Consulting, Inc. November 17, 1997

Executive Summary

As a member of the DARPA/ISO AITS Architecture Review Team, I attended the DARPA/ISO Integration and Transition Off-Site Conference held at the Arlington Hilton on 21-22 October 1997. This document lists

the initial recommendations of the review team provided at the meeting and
my responses to Signori's "Questions for DARPA/ISO Architecture Review Team," which includes my observations and recommendations based on the meeting.

I am sending my comments on Rich Ivanetich's High Level Framework for AITS Architecture and Teknowledge's AITS Reference Architecture separately.

Initial Recommendations of DARPA/ISO Architecture Review Team

These were the initial recommendations by the Architecture Review Team provided at the Off-Site Conference.

Rapid commercial development of middleware continues (info bus, ORB vendors, network management tools) so avoid over-commitments.
AITS Reference Architecture needs to begin to encourage design of capabilities for rapid-on-the-fly evolution (e.g., to support unforeseen additional functional requirements that arise during force deployment - i.e new kinds of distributed data)
need focused deliberate participation in OMG, W3C as well as other open forums
while we need a richer view of architecture to deal with heterogeneity, at the same time we need simpler ways to explain it. Decide on key themes. Reuse portrays certain issues, tie together heterogeneity, evolution view, … manage complexity.

Questions for DARPA/ISO Architecture Review Group - my responses

At the conference and then again by email sent November 8 1997, Ed Brady (Stategic Perspectives) and Rich Ivanetich (IDA) asked the AITS review team to complete the following questionnaire. Here are my responses, which incorporate my observations and recommandations from the meeting.

What should ISO's FY98 priorities be? (near term and mid-term architecture)

Shift from JTF-centered architecture to AITS-centered architecture

AITS must be viewed both inside and outside DARPA as the DARPA architecture whose job it is to show how to integrate command and control, intelligence gathering, logistics, crisis management, etc. for DoD in such a way that it does not result in a stovepipe of stovepipes but rather provides the architecture for an evolvable, configurable, and affordable system of components. Right now, it still suffers from the historical view that it is JTF with other architectures concatenated on the side. Some of the programs like ALP openly say their architecture is different from AITS (meaning JTF, I think). I recommend a careful pass through the foils to remove vestiges of JTF dominance and lobbying with the various PMs.

Managing the Complexity of AITS Architecture

To be useful, AITS must be understandable. It is complex and growing more so as it tries to cover more ground. But the complexity can be managed. Foilology does this to a reasonable extent but one is always wondering where the foils end and the architecture takes over.

Views of the AITS Architecture. A top node of the AITS presentation should be that the architecture must be understood from a consistent, interlocked collection of viewpoints or perspectives, where, as Rick said, each reveals and each misleads. I recommend more explicitly adopting the notion of views of the architecture -- this may not require many changes to the foils. The views must not just be foils. There must eventually represent reified systems and mappings that connect the views. Taken together they must become the architecture. You might eventually consider implementing mappings from some foils to architectural components via point-and-click on the AITS web site, to make the architecture more understandable.

Here are some architecture views yof interest (overly simplistic list, you have many of these already):

ABIS view - mostly notional, serves to connect 2010 objective to AITS
Joint Services' application view(s) - what services are they getting from AITS from end-user perspective
application program views

as an integrated system providing command and control, crisis management, ...
one per program, e.g., JTF view, Genoa view, ALP view, etc.

various abstract technical architecture views

OMG like services view of application/domain services and common system services in several variations, showing various AITS applications like JTF, Genoa, BADD resting on common services
data representations view
federation view - need core work on this - poorly understood. OBJS is working in this area.
ility view - need core work on this - poorly understood. OBJS is working in this area.
compositional view - AITS and OMG OMA need work in this area. It explains how a part is actually constructed or constructable from components it depends on.
evolution view - populated view vs. planned - critical investment and capability paths
process view
replication view
security view
system management view
survivability view - poorly understood. OBJS is working in this area.
bandwidth view
communications architecture view
cost and maintenance view

implementation view

implementation guidance as constraints
which specific implementations connect to which

Definitions of Basic Terms. Many basic terms are not defined. These include architecture, interoperability, framework, component, service or server, DSSA, application architecture, openness, view, federation. Each of these has several senses and a deep analysis could run to pages or more. But they are pivotal terms.

Organizational Frameworks

There are some organizational frameworks that are not themselves the AITS architecture but that provide a list of considerations about AITS that can be iteratively institutionalized and evolved to prevent surprise and foster widespread adoption. These include questions like (very incomplete list of standing questions, a FAQ could evolve with answers):

Who are the customers, are they involved in the process, what are their requirements?
What is industry doing now and their likely vector? How can we leverge their efforts?
How can we make the system more affordable, easier for many folks to extend?
What are the priorities in the near, mid, long term?
How do we do it today and what are the advantages of the proposed change?
What are the technical discontinuities coming in the next 3-5 years?
Issues and Resolutions Log (e.g., how to specify component connectivity)

Managing Availablity of AITS Documents and Implementations

I have not checked lately but when I last checked I did not find the AITS web site to be a good central source for documentation on AITS or on various specifications of its parts. This is a missed opportunity. Major consideration should be given to how to make AITS information much more available. This includes all major architecture documents, all major specifications, accessibility information on getting implementations like Data Server, Web Server, ... If these are not available to ISO and ITO PMs and PIs and there is not a routine way to publish availability of new components into a DARPA marketplace of componentry, then AITS is likely not to succeed as well as it otherwise could. It should be very easy to do this, perhaps PIs just advertise their wares by program, nothing too sophisticated, no vetting or heavyweight promises of code maturity.

Tech Transfer Process needs more work

Right now, PIs in ISO programs are told that if they are to be successful, they will transfer technology via the following route: TIE, IFD, ATD, ACTD, GCCS LES, DISA (or variations on that). They are also told DARPA does not invest in areas industry will, that their customer is DoD, and that DoD is moving as fast as possible to COTS technology to reduce cost and take advantage of training. Finally, there is an emphasis on open systems standards in GCCS and some general encouragement, even mandate, to use certain technologies like OMG, Java, ... over some others. But I see the following problems in this picture:

PIs in ITO (and maybe ISO) need some more rapid way to become educated on DoD problems (scenarios), infrastructure (GCCS), process (DII COE levels of compliance), military doctrine, ... That is, it will help if it becomes easier for them to understand the DoD customer problem. Today, this is done by having some ALP etc people come to ICV etc workshops and give talks but there are not many other ways to understand DoD for many DARPA PIs.
The food chain from TIE to DISA is long but the pace of technology change is very fast.
DARPA projects do not often result in technologies that other DARPA projects can use except in one-on-one, human intensive cases. There is no marketplace for advertising your component technologies or pre-thought-out means to micro-license them -- see above, also more below on reuse.
Those technologies that run the gauntlet like Visage may have Achilles heals, like only 10 programmers in the world know how to use them, there is no installed base, there is no commercialization plan, so what is sometimes being delivered to DoD is beyond prototypes but not nearly COTS and DoD is left to maintain and extend complex DARPA software that has no route to COTS.
Universities and large DoD integrators tend to accumulate lots of DARPA technology within their proprietary walls (and on their shelves) leading to winning future DARPA contracts but there is a barrier to making it easily available outside those walls.
DARPA talks a lot about OMG and other open standards, is being influenced by them, but is doing relatively little to work with them to leverage DoD technology into the marketplace. DARPA could be the research arm of these open standards efforts, or at least active in influencing these groups to focus on problems DARPA needs industry to solve.

A concerted effort should be made to identify additional barriers to the DARPA technology transfer process and a plan plus some controlled experiments are needed to break through these barriers. It might be critical to get industry to buy into your detailed AITS architecture to broaden the applicability of the architecture, for instance. Right now industry trends "happen to" DARPA.

One major area where DARPA should invest in establishing a high leverage beachhead is in industry open systems forums, OMG, W3C, WfMC, IETF, joint workshops, etc. DARPA must take a leadership role, providing a research arm for these industry standards-setting groups, accelerating consensus leading toward standards that AITS will need.

Some general tech transfer things to do are:

require low-cost licensable technology as outputs of ITO and ISO programs
download as much technology as possible via the web
more focused DARPA-industry workshops

Some specific interactions that could happen between DARPA and OMG are (for instance):

DARPA AITS management team should meet with OMG's Richard Soley to plan a strategy. If you don't take concrete steps to plan a rendezvous with OMG, it will not happen. Rick Hayes-Roth or Dave Signori might do an OMG plenary talk. DARPA could sponsor an OMG meeting.
focused DARPA-OMG workshops

I invited DARPA PMs to come to our OMG-DARPA workshop in January.
DARPA could sponsor workshops with OMG on agents, workflow, ...

PMs and PIs to participate in OMG meetings

I'll invite Sami to OMG Security SIG to brief his DARPA Security Reference Model
I'll invite David Wells (OBJS) to OMG Security SIG to brief his DARPA Survivability work
There is almost no connection between DARPA QoS and OMG/ISO/ODP QoS in industry - I could talk to Gary Koob and send him OMG documents on QoS. Then invite him to OMG.
Brian Sharley could start up an OMG Logistics SIG or Task Force. I could help him do this.
We could push the Query Server design through OMG as a Data Access Facility.
Whatever AITS learns about federation, scaling and other ilities will be useful to OMG. I am trying to get this onto their OMA roadmap.

DARPA has many extra-CORBA services that would be useful to OMG -- webserver, policy, versioning, trigger, publish and subscribe, replication, … many more. If they are moved to OMG, then DARPA will not be alone with idiosyncratic approaches when OMG gets around to similar but different services. DARPA helps to "accelerate consensus leading to standards."

OMG has a C4I SIG but no DARPA JTF representation
OMG is working with WfMC on process, task, and workflow.
No OMG work on a planning service -- an opportunity to introduce this into OMG

DARPA might not want to adopt every little thing about OMG's OMA or process, but the general architecture and model approach and many of the service are well aligned to AITS.

Having said all this about OMG, I must also say that intersection with W3C might end up being at least as important. We might be able to help here too with some initial tech transfer ideas. Our work on Web Object Model is a starting point. The AITS WebServer is kind of a cross between ORB representations and web representations, if you stand back far and squint. It must align with evolving standards like XML. I commented on some WebServer direction changes earlier.

Who are your customers. Insure that DoD architects for NIMA, DMSO, as well as some industry enterprise architects are involved in AITS DDB, etc. Insure Deputy Under Secretary of Defense/Logistics (USD/L) coordinates with ALP via Logistics Community Manager (contact Janet Putman, who says the connection is tenuous). [This reminds me of a past life in a big corporation where there was no way for the researchers to really provide value to the product groups, at least in software -- a lesson was to get early and continuous buy in.]

Architecture Hot Spots

Software Architecture in General. The area of software architecture is still pretty new and evolving -- not that much is known. DARPA might consider funding efforts in ISO on software architecture.
AITS and Federation. It would be worth convening an effort to see if there can be a consistent one architecture story on federation (clusters) across JTF, ALP, HLA, DDB and whether you could transfer this federation story into OMG. I'd volunteer to lead such an effort. I view this as critical to scaling systems because big and centralized does not always scale well. But do not expect over night answers.
AITS and Survivability. We at OBJS are starting to understand how to insert Survivability into Object Service Architectures. This effort should be accelerated over the next year. It is related to QoS, Security, and other ilities, which we talk about in our OMG OMA-NG paper.
AITS and HLA. An effort to see how to hook these two architectures together seems worthwhile sooner rather than later. The interface to DMSO seems organizationally and technically weak though there is great opportunity to make it aligned. The HLA interface is on the list for the AITS architecture working group. One promising area is to focus on overlaps in schemas. By the way, the DMSO HLA has already established a beachhead in OMG, having formed the Simulation SIG; DARPA should support this effort.
Resolve Object-Agent wars before they start. AITS RA objects must be able to accept delegated work, must know their resources, etc. DARPA should decide on the relationships between object and agents early on, I hope, taking the view that objects are degenerate agents that can be made more mobile and intelligent. The idea is to ward off the school of thought that objects and agents are very different, so different that we need an AITS based on objects and another based on agents, or a similar bifurcation of the AITS community.

Implementation guidelines and waivers

consider Lisp for planning
allow Java generally, not just for applet GUIs, begin to prefer Java over C++
add UML to representations list. Some OA&D tools can generate IDL or Java or ... making transitions easier for object modeling.

What are commercial trends which will have the greatest impact on mid-term architecture? What is their basis (if any) in OMA/Corba?

I wrote a paper on Future AITS Architecture in July and another on OMG OMA Next Generation in September. These try to lay out commercial as well as research trends that will affect AITS and OMA/CORBA futures. Some candidates for big impacts are:

understanding architecture, don't assume industry will provide all OMG, web technology infrastructure you need

architectural properties (ilities) - especially security, reliability, scalability (composability and federation), evolution, survivability)
OMG does not yet provide mix-and-match, plug-and-play
the January Workshop on Compositional Software Architectures will identify the state of practice and barriers to component software
after all this time we do not have good definitions of interoperable, framework, ...

web-object convergence

web object models (like XML, DOM, WIDL, ...) - situation modeling using the AITS web server may need rethinking [I need to learn more about the web server]
HTTP-ORB integrtion architectures
federated web object DBMS
a big variable is Java/CORBA convergence or divergence; divergence will hurt OMG.
mobile objects/agents
converge Common Object Base with Simulation object models
doctrine as business rules

The approach to developing the architecture thus far has primarily been to extend the layered view developed in the JTF ATD. Are there important changes that should be made to the current architectural approach?

AITS is leading down the right path toward an integration architecture. But, as mentioned above, it is time to defuse a JTF-centric architectural view with a JTF-historic view and make AITS architecture the center and JTF yet-another-program. One pass over the foils and Reference Architecture is needed to re-orient. This is needed to increase buy in of AITS and reduce jealousy regarding JTF. Also, JTF does not really handle federation at all and that must be a hallmark of AITS application architectures including future command and control architectures. But the basic approach of AITS-JTF of modular services seems right to me.

What role can the Architecture Review Team play in terms of the long-term framework?

Current Role as Reviewers

So far, I have wondered if the review team is adding sufficient value. It has seemed our current role is to act as fairly knowledgeable reviewers to provide Dave Signori a variety of independent points of view on the AITS architecture (including providing longer term technical and programmatic guidance) based mainly on reviews of documents presented at more or less quarterly meetings. To date, several review team members do not seem to be participating. In some cases, you might not need continuous membership but mainly targeted expertise, e.g., for briefings on particular topics.

Recommendation: switch to once-by-invitation or semiannual/annual, renewable terms for reviewers
Recommendation: give the review team some feedback and visibility into how their recommendations are being used. What would be more useful than what we are providing?
Recommendation: get some reviewers from outside the DARPA community. Candidates are:

DoD customers - especially services architects for major initiatives (e.g., HLA, NIMA, DUSD/L, …)
industry gurus - from OMG, W3C, OGC, academics. This might better connect AITS to industry and it lets DARPA provide these organizations a much needed research arm.

Future Role of Review Team

It has been suggested that a second role of the review team might be to rough out a long-term architectural framework for the AITS. I'd certainly welcome this role. And I believe AITS needs to have a long-term as well as near-term target. In my experience, architectures break when they fail to be able to evolve to meet unanticipated requirements. So having an advance team aimed at early identification of significant relevant trends, issues identification and resolution, and continuous evolution is well worth the investment. Such a review team must be at least a little more closely coupled and proactively involved in setting AITS directions than the current review team has been. Ideally, it should be made up of current area architects as well as reviewers. Also, it must help the current process become more proactively involved in industry directions than current AITS has been.

Recommendation: identify a small core team; they must be full participants with today's ITO program architects. Their job is to identify and resolve architectural direction changes and issues with the help of the programs. This is probably a more than part time position; it might be full-time. The team works with Signori to pull in the expertise they need to get their tasks accomplished.

An example study might be like the one Rich is working on (High Level Framework for AITS Architecture) regarding inserting architectural ilities into AITS (based on inputs from the current review team, MCC, and his own insights) -- see separate comments. Other examples are:
an issue resolution log for AITS;
web object models and directions and how they will affect AITS;
study in how to connect DARPA programs to DoD data sources (or how to converge DataServer, InfoSleuth, BADD, I*3) to result in an AITS Data Access Architecture;
study in how to componentize and microlicense DARPA ISO technologies so they will fit into ITO applications in a more streamlined way;
study in the ITO process and how to connect it into the industry-products pipeline so US research results in US products and not one-of-a-kind fielded DoD prototypes.

How important is the "reuse concept" in an organization like DARPA (internally, externally)? Should it be included in parallel development efforts?

The answer depends on DARPA's changing role and its research investment portfolio strategy. DARPA essentially has a fixed pie of money/resources to invest to get maximum technology gain for DoD. It seems to be dividing its investment portfolio into two parts: ITO technology and ISO applications that both require leaps forward to stay leading edge. But recently, the joint services are coming to depend on DARPA technology to create at least the skeleton of next generation fielded systems; hence the major emphasis on the TIE-IFD-ACT-ACTD-AJPO-GCCS LES technology transfer process from ITO to ISO to JPO. In the ITO technology area in programs like IC&V/IM, this seems to call for opportunistic funding of a sparse collection of program-theme-related technologies; there is less emphais on any program-imposed architecture. But ISO application programs are driven to provide architecture frameworks that can be created then populated with a common suite of technologies and fleshed out over their lifetimes in an open modular manner. The process puzzle is to see how to accomplish the twin goals of (a) funding revolutionary, continuously leading edge opportunistic but sparsely-related technology and (b) technology that must fit into an evolving architecture framework in such a way as to flesh out critical paths to solve pressing DoD problems. A tall order.

Now, to try to answer the question about reuse more directly.

If the only goal was the first one, DARPA could afford to ignore reuse. But it would lose a lot of the value of its investment by doing so. In fact, I think right now it does lose a lot of its investment in ISO programs. There is not currently a good way to encourage or require PIs to provide their technology in modular chunks and there is no encouragement in setting up a marketplace that permits microlicensing or sharing such results. So the main kind of tech transfer is very human intensive and a few more mature technologies are transferred one at a time. This encourages prototypes over engineered solutions, low amounts of code sharing, and no direct link to ISO needs except through a kind of shopping when ITO architects visit ISO programs often in person looking for technology to reuse. Missed opportunities seem to be a marketplace of code that others than the developers have access to and almost no real interactions with industry or insight into the ISO program architecture needs.
There is no way to accomplish the second goal without reuse. Rick Hayes-Roth was elegant about reuse at the DARPA Off-site Conference and largely I agree with him. A major consideration in AITS is architecture driven reuse across ISO programs to decrease investments. If this is so, then it should be more visible what technology is available (e.g., what components of JTF are easily available for reuse) and the opportunity for reuse should be extended to not only other ISO programs but also ITO programs.
Some barriers of reuse are:

prototypes versus engineered solutions
researchers aversion to productization
unavailability of code (ISO and ITO) in modular pieces
no marketplace of code or expertise
no model for microlicensing
institutional IP barriers (e.g., integration contractors, even universities) do not make code reuse easy. Each licensing experience is unique, involves lawyers, try-before-buy is not the rule.
need for constructive descriptions of AITS architecture so people can see how to populate it
routes to transition technology to industry then DoD versus the primary emphasis being to DoD. It is a false economy to transition technology prototypes to JPO for maintenance since they will die an expensive death or become one-of-a-kind maintenance hogs without amortizing continuous development costs

At the same time, reuse is not the ultimate mindless goal in all cases: DARPA must continue to fund some percentage of new starts and retire some percent. A certain percent must be in areas that have promise even if they do not fit into today's view of the architectural direction. In addition, it is probably good for DARPA to encourage loose coupled architectures and not require every component to be built and transitioned as part of an existing high level framework.

Parallel development efforts make sense especially in areas where there are more than one interesting different approaches or where there is a rich design space of alternatives and it is especially important to get a variety of results or to get results quickly.

How should CORBA and DCOM be viewed (competing concepts, different ways of doing things for different purposes)? Should DARPA be investing in only one, both (security features)?

CORBA and DCOM represent competing concepts, different ways of doing things for the same general purpose. But they are at different levels of maturity, align differently with Java and the web, have different openness properties, and have attracted different communities. CORBA/Java represents open systems and multiple vendors; DCOM is less mature but Microsoft has focus, market strength, deep expertise and has a good chance of winning the entire middleware and enterprise computing war over the next 10 years. So investments in both camps will be needed.¹ One good reason to invest in the CORBA/open systems camp is to set the blueprint for infrastructure technology² which is ultimately what AITS must do for DoD -- but that will require a much more active presence in open forums than DARPA is currently encouraging in its PM and PI community. A reason to invest in Microsoft is that DARPA currently has too little investment in Microsoft technology and culture so it should encourage a balanced portfolio from its PI community. Generally, DARPA might consider some industry wide initiatives that encourage vendors and PIs to work together and increase communication bandwidth -- our upcoming OMG-DARPA workshop is one example.