Future AITS Architectures

Craig Thompson
Object Services and Consulting, Inc.
29 July 1997

The Homework Assignment (Tuesday, 29 July 1997)


Dave Signori has put together a small tiger team to further work out the AITS architecture and roadmap.  We had our first meeting on 17 July and the next is scheduled for 12 August (with plenty of assignments in between!).  The goal is to have a good briefing on the architecture and roadmap in October.

In this context, Dave asked me to put together some high-level descriptions of what future AITS architectures might be.  The purpose is to have some idea of how the current architecture might change (possibly radically) in the longer term so that some of the right "hooks" can be put in it now.  There are (at least) two things to be addressed here:

I would appreciate input from you on these subjects since I'm sure you all have some definite ideas!  So please pepper me with your thoughts -- anything from a snippet or two to a well elaborated thesis!  This is a real chance to start coalescing some ideas that will affect the eventual evolution of the AITS architecture.

I would appreciate it very much if you could start feeding me input this week or early next week so I can begin to collect my thoughts for the August meeting.  Thanks in advance for your help.

Richard Ivanetich

The Solution

Requirements driven architecture

The AITS architecture, like all enterprise-level systems, will be built to meet requirements.  There are three kinds: There is real value in trying to write down the requirements and review them periodically since they represent a way to scope the system and also avoid rework.  The scope today is the requirements you can check off as satisfied.  A growth path is to assign dates to requirements on a roadmap.  Since AITS is a large, evolving architecture, one can immediately predict that it involves programming in the large, which always involves discovery of "the (previously) unknown requirement" -- either due to size or time related scaling.  We cannot protect against this.


A big question for me is, where does the scope of AITS end?  Right now, it is at least a command and control, crisis management, simulation, logistics, and infrastructure architecture.  Most of these architectures are, at the moment, loosely coupled.  There is much more that a DoD architecture could cover and the architectures could be more tightly coupled.  What are the scope bounds and how do you know when you have reached them.

What is an architecture really?

Along these lines, do you want to think of AITS as one architecture meeting all needs or a composition of architectures?  Hint:  the latter. If so,  it makes sense to consider a requirement that the multiple architectures be capable of interoperating.  Given these intuitions, how do we characterize architectures, treat them as units, and characterize potential inter-architecture interfaces? What type of information and mediation is needed to enable architectures based on different architectural assumptions (of what type?) to interoperate.  Along these lines, how do we characterize stovepipe architectures and how do we know AITS as implemented is not one?  Is there evidence of module replacement, mix and match, best-of-breed modules?  Is there a notion of a lightweight and heavyweight variant of the AITS?

AITS and the ilities

The ilities are generally cross-cutting meta-architecture constraints that are often hard to add to a conventional system when designed as a stovepipe or missing an ility.  DARPA ITO has or is planning whole programs devoted to some key ilities: There are more ilities (e.g., understandability, affordability, agility, performance) but focusing on just these, one could use them as a metric to measure AITS against now, with the presumption that AITS must grow to meet these predicable architectural framework requirements.  For instance, One can say much more about the ilities.  (Including trying to list ilities and characterize what exactly they are.  To what extent to ilities have to built in to all modules and when can they provide a framework that is imposed from outside without requiring cooperation from the managed components, which might be ility-unaware?

AITS Business Model missing

Right now, AITS has a technical and application architecture and a rendezvous path for taking ITO technologies and testing them in ISO programs, then migrating these in DISA/LES/COE.  But there is less focus on how DARPA work can affect industry standards or industry technology trends.  NIMA and HLA have aggressive models of getting industry to partner in the adoption of their critical path architectures.  How will DARPA do this with AITS (which includes HLA and might also include NIMA's architecture if DARPA pursues the Dynamic Database program)?

Technology Trends

Focusing together on infrastructure and evolution, we can predict several industry trends the AITS architecture must take into account.  These are environmental in nature but can affect the core nature of the AITS architecture.  The following sample of Nostradamus-like predictions will surely be true to some extent so the issues are, how to accelerate these directions since there are technical and social barriers for each, and how will these trends affect AITS.


Some of the technology puzzles that seem relevant to AITS that I hope to understand more about in the next year or two are:

AITS Future Architecture

Now, to be specific, and not knowing enough about the AITS architecture yet, here is my current view of some components that could change in the next few years:


The above is a "getting started" list of AITS architectural futures that might start up more discussion or aggregate with other lists.  The long list of possible things to do provides some views of the future.  Prioritization helps to pare this to the current resources.  But seeing the possible future helps defend against being blind-sided.