Advanced Information Technology Services (AITS) Architecture

Off-Site Review
Washington D.C.
25-26 June 1997

Reviewer Report

Craig Thompson  (bio and contact info)
Object Services and Consulting, Inc.

Revision history:  Initial comments posted by cwt on 6/30/97.  Annotated in red by cwt on 7/16/97 (most important comments) -- see changes in sections

Executive Summary

AITS Architecture is on the right track.  The AITS Architecture is impressive in scope and appears to be on track to provide DARPA and JPO/DISA technical and programmatic guidance as well as a technology transfer route to the rest of DoD for a family of command and control architectures covering command centers, crisis management, planning, situation modeling, logistics and interfaces to simulation and modeling architectures.  The emphasis on an architecture-driven approach makes excellent sense because it can focus an overarching design on -ilities, which are desirable, system-wide qualities that the system, system of systems, or family of systems is intended to have.  Some of these -ilities include: Some midcourse corrections.  To realize the objectives of the effort, there are some mid-course corrections that probably need to be considered.  These fall into the following areas

Reviewers Feedback

Ed Brady (reviewer team spokesman) gave a 30 minute summary of a two-hour reviewer meeting held the evening of day one. He covered (from my notes):

The rest of this report is my individual comments in general and on the various presentation topics.

Technology-related Feedback

Technology Transfer and Business Model Feedback

Research may produce technology but its value diminishes if it is not transferred to operational practice (widely used) in a way that becomes economically sustainable (business model). Leverage describes the idea of targeting transitions to solve increasingly complex problems and maximally accelerate community progress in adopting the solutions.   Currently, the AITS Architecture appears to be the locus for a significant paradigm shift from research programs disconnected from service needs to more focused R&D.  AITS begins to rationalize and create a transition model between DARPA ISO application programs and the rest of the JPO, DISA and DoD.

Right now, the AITS presentations only include a technology transfer process for moving research to applications and fanning it out to DoD services but is missing several ingredients.  It does not include non-DARPA researchers, industry, data flow back from DoD as partners in development, and standards.  The DARPA technology transfer process should think big.  It should include information flow back and forth among research, industry, DoD, and standards.  You might find the foil I made for Kevin Mills' IC&V program a useful start.  Its here with some commentary here.  A  useful phrase we invented some years ago with respect to participation in industry forums and standards was "accelerating consensus leading towards standards".

Leverage Industry and Accelerate Community Progress by Participation. Most DARPA projects are underfunded to solve complex problems in a way that will allow meaningful, affordable transition to the field. Now seems to be a time to augment this process into a collection of dialogs with industry, which can be done with a variety of mechanisms. Goals are to take the deep knowledge of DARPA programs and accelerate high leverage transitions of DARPA technology out to industry (and equally important back in). The variety of mechanisms available include:

Though there is anecdotal evidence that some DARPA projects have attended OMG meetings and possibly made a presentation now long forgotten, there is limited evidence of active interchange where the DARPA-funded work made a traceable advance.  That is unfortunate because there are many opportunities for interchange.  Recommendation on Standards Participation. Take an inventory of which teams are interacting with which standards groups or other industry groups (e.g., consortia) or even product groups productizing DARPA software technology. Recommendation -- Develop an explicit Tech Transfer Plan.  If you don't have a plan, you are unlikely to succeed in this form of technology transfer.  Be proactive -- don't passively assume standards happen to you or happen "over there" -- instead engage in and possibly lead the process. But choose your battles -- not all standards are worth the time.

Specific Opportunities for OMG-DARPA engagement.  Organizationally, OMG can be viewed as a big data structure of communities of interest where many of industry's better system architects and middleware technology vendors meet (every two months) and where consensus-based standards evolve. OMG has no real research arm. DARPA could play that role where OMG might plays one of the major tech transfer routes out for some kinds of DARPA technology. Additionally, DARPA interaction with industry can short-circuit adoption of good ideas into broad communities that allow the services to adopt these from industry. Finally, the process of interacting with experts (from industry and also from other centers of excellence in DoD!) gives DARPA some out-of-band ways for their experts to talk to other industry experts to share expertise and get ideas critiqued so that the tech transfer route is DARPA to industry to DoD rather than just DARPA to DoD to industry.

In the past and present, DARPA-funded effort has played a key if limited-bandwidth role in moving OMG forward:

Recommendation to engage with OMG.  It would be beneficial to both OMG and DARPA if DARPA programs participated in OMG more actively to share their expertise.  Here are specific opportunities for interchange: Similar targeting strategies are needed for AITS to engage in or closely follow other related standards groups like IETF, W3C, OGC, WfMC, ODMG, and more.  By no means are all standards groups are worth following so you need an investment strategy.

Dual Use Tech Transfer and Business Process. DARPA AITS is solving a "business problem" and some kinds of agile businesses could use all or parts of the architecture.

The point is that it is possible to begin to envision a DoD-industry partnership. The sooner systems like this become part of industry, the sooner key technologies will become available to much larger communities, including the DoD community.

Procurement practices.  Rick mentioned reward structure, compromise, willingness, synchronousness. I'll add availability, in the sense of low cost of entry to the community working in this area.  At one point in one presentation, the issue is raised about the "high complexity of the overall product."  Right now, the cost of newcomers into the DARPA application programs is high and sharing less than it should be because of reward structures.  Your need to work to lower the entry bar.   A related point is that there may need for changes in procurement practices.  Most DARPA/ISO contractors are DoD software integration specialists.  But while they may be innovative they do not provide a direct route to the part of industry that builds COTS products.  Better mechanisms are needed so that software developed for AITS does not get locked inside monolithic or proprietary walls.  Publishing specs and putting code in the IE Repository may provide parts of the answer as will working with OMG.  [Personal note:  the reason OBJS principals left TI was that TI made a business decision not to productize Open OODB and we saw no point in continuing to develop it as a proprietary non-product. Are there commercial plans for AITS servers?  is the source code available for others to use?  are the specifications available?  if two parties implemented the same specs would they get the same capabilities, that is, how much semantics is described in the spec?

Think Big and Market your Work.  Outside of ISO-related application projects (and perhaps ITO and the JPO-DISA chain) not many know much about the AITS architecture. It has so far had relatively little impact on some other major DoD architectures like NIMA, HLA, probably others or on community architectures like OMG's. While this is partly because the work is young, it may also be because the effort is not advertising its vision and impact to the communities it wants to influence. The communities are definitely within DoD but the impact could be business-pervasive. So think big and begin to think out the implications of your architecture work and who may be the benefactors. As a very minor side-note, be sure you keep your AITS web page up-to-date and current.  When I tried to come up to speed by browsing the ISO Architecture web site, I did not find that much there.

Comments on Presentations

Off Site, Dave Signori, 25-26 June 1997

Advanced Technologies to Enable the Advanced Battlespace Information (ABIS) Vision: How Well are we Doing?, Dave Signori, 18 June 1997

Roadmap for the Evolution of the AITS Reference Architecture: Background, Motivation, Directions, Rick Hayes-Roth, 25 June 1997

ISO Architecture and Roadmap Report, James Just, 25 June 1997

DARPA ISO Server Study, Phil Barry, 25 June 1997

Overview of Implementation Guidance for DARPA-DISA Advanced Information Technology Services (AITS) Reference Architecture (RA), Rick Hayes-Roth, June 1997

Dec'96 Transition Schedule/Status, 9 June 1997, Don Eddington

DMIF II Architecture, Bob Tenney, 25 June 1997

Security Architecture for the AITS Reference Architecture, Sami Saydjari, 2/10/97

AITS Architecture: Modeling and Simulation (M&S), Jack Kramer, 25 June 1997

AITS Communications Server