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 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.

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):

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):

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: 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:

Some specific interactions that could happen between DARPA and OMG are (for instance): 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

Implementation guidelines and waivers

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:

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.

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.

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.

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.1  One good reason to invest in the CORBA/open systems camp is to set the blueprint for infrastructure technology2 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.