Review of the AITS Reference Architecture

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

Attached are my comments on the DARPA/ISO Advanced Information Technology Services Reference Architecture, Teknowledge Federal Systems (version: 20 October 1997).

General comments

There is a lot of good material in the document, arranged reasonably. Still, a careful pass will make sure it is presented in the clearest manner. Several of my comments suggest potential presentation improvements.
The document is two things - a reference architecture concatenated with programmatic information on evolving status, issues, and next steps. It might be better to separate these two more clearly and put the programmatic material in an appendix.
I am not altogether sure you have a totally clear idea of what a reference architecture is for -- sometimes the story is lost in the attempt to include so much.

Using the OMG OMA RA as a model, their high level OMA RA provides an architecture into which categories of kinds of components fit. Then other subarchitectures (e.g., Object Services Architecture, Common Facilities Architecture, Domain Objects architecture -- separate documents) define and populate the parts. Also, as OMG moves from descriptions to specifications, it replaces or adds to sections of the RA a specific mention of the subarchitecture documents and the specifications that populate the RA. AITS RA should be similarly expandable with URLs in future versions to point to specifications (and possibly implementations) of AITS components.
The Reference Model on OODBs (100 page .ps document) might be useful for some sample words about design spaces.
You might also need an appendix on architecture or at least an inline paragraph-long description of what a reference architecture is supposed to be for.

You need an appendex for Glossary terms and another for Acronyms. Define terms like {application, technical, functional} architectures, end-to-end, seamless, interoperable, many more}.
The AITS RA still raises JTF to a prominent, if historical, position. I think you will get more buy-in from other programs if you remove the bias. Just mention JTF as yet another architecture in Section 4. Diminish or remove the historical lineage.

Comments by section

Section 1

I like the general flow from Vision 2010 and ABIS to AITS but I wonder if the somewhat detailed descriptions of the architecures can become part of section 2, where they are again covered. It seems to me the first section of the AITS RA should be about the RA directly, e.g.,

Purpose of the AITS RA - to provide DoD with a modular, evolvable, affordable software architecture that allows the end-to-end integration of command and control, intelligence, battlefield planning, situation assessment, crisis management (elaborate). [Includes section 1.5 AITS vision.]
Motivation - the Vision 2010 and ABIS story briefly, industry changes like OMG and the web, DoD changes and needs, DARPA's role (1.6)
Who should read this RA

DoD customers - to understand the approach DARPA is taking ...
DARPA PMs and PIs - to understand the target architecture and help populate it and improve on it
industry partners and open systems standards groups - since some DoD technology will be useful to much broader communities

Organization of this document

Section 2

I feel we keep switching levels and organization in this section. The purpose of the section is (should be) to introduce the High Level Architecture for AITS. A better arrangement of parts might be:

Combine 2.1, 2.11, 2.2, 2.2.1, 2.8 into a subsection on High Level Architecture for AITS (the core of the Reference Architecture). Keep this view simple and try to get Figure 2.1 onto the first or second page.
Then have a section on Views of the Architecture. Say that the views provide important abstractions and they must all map to the evolving AITS architecture in a consistent manner. Include:

views showing the relationship to existing architectures. AITS ties these together. Say how.

JV2010 - notional views that motivate AITS
ABIS views - application view that shows what joint services need

side comment - the different layers of ABIS always seem somewhat arbitrary to me. Why Universal Transaction Services, for instance?

DII COE view - evolving COTS and standards based infrastructure floor for DoD open systems technology choices
OMG OMA view - how AITS relates to open systems componentware

views of subareas of the AITS architecture (these and maybe more)

application views - JTF, Genoa, ALP, ... - these are covered in more detail in section 4
domain-specific vertical generic view
platform, generic services view

ilities view (see next paragraph)

security view
system management view
federation view

Might want a separate section parallel to views on Architectural Properties (the same as the ilities view just above). Include OMG like principles as well as a description of desirable ilities - see Rich Ivanetich's HLA for AITS as a start as well as my comments on that presentation.. 2.4 does this to some extent. OMG OMA needs work in this area as I point out in OMA-NG. System management and Security & Availability are not the only global properties -- what about evolvability, afforability, scalability, survivability, more.

Some specific comments

DSSAs (2.6) is not well differentiated from OMG. If it is included as architectural heritage, then remove the description to a chapter on historical progenitors. If it adds specific value (which it might) then say what it adds to AITS that OMG OMA does not.

DICAM (2.6.1) - same comment
Information Logistics Framework (2.6.2) - same comment

OO Application Frameworks (2.7) - amazingly, the current OMG OMA RM has 3 pages out of 7 on frameworks but there is no real common definition of the term in OMG. So AITS is forging new ground here. Must say more about what sort of framework you mean. Highly overloaded term.

Section 3

Section Introduction

Overall I like the structure of this chapter into some partitioning of AITS and subdivisions of the partition with descriptions of each.
3.1 - remove Figure 3.1's historical status view of AITS -- thats not the way to start the section. See comments above and below on why (it stresses JTF, diminishes others)
you might want to move 3.2 and 3.3 into section 2's HLA for AITS. Or start this section with them. You need to connect Figure 2-1, 3-2, and 3.3 so it is easy to see how the three relate to each other.
move text in 3.2 on "Principal high level objectives" to section 2 discussion of Architectural Properties
reconsider if you mean Layer in section 3.2 or partition. Layer gives the sense that things in that layer depend on those in lower layers. But User Environments might be independent of many other layers. One is striving for maximum independence of parts in a component architecture (good separation of concerns).

The rest of the section is a detailed reference model of each section of the architecture shown in Figure 3-3, organized by subsection and subsubsection. This is generally a good organization. However I might quibble with many, many details. I like the diagram but foilology is creeping in replacing architecture in some places. Here are just some questions that came to my mind when I read this section. This section is where the rubber hits the road in componentizing AITS. Its really the most important section to get right and the hardest.

Object Management is in one partition, Core Services in another (but they are OO oriented), System Management in another (is it OO?, probably)
Some places, there seems to be an overcommitment to detail in this diagram, for instance

all the boxes having to do with System Management and similarly Availability and Security.

Why are Data Server and Query Server in different partitions?
Why put the OMG security service in a different box than Availability and Security?
I still do not like the word *-server for * = {Map, Situation, Plan, Trigger, ...}. It is needlessly misleading. Replace with service.
Security and Systems Management seems to sneak into a lot of separate descriptions. Why not all other ilities as well? The are all meta architecture properties that cut across services.
Some servers, like Pedigree, Trigger, and Logging might be OMG services or building blocks. Others, like Workflow, might be OMG common facilities that are compositions of services.
I get the feeling that Information Logistics Services and Agents are just concatenated in with the rest. It might not be clear to me as an AITS designer when to use objects and when to use agents.

Section 4

This section should be about showing how the AITS architecture relates to nearby architectures, especially the application architectures for JTF, JFACC, ALP, Genoa, etc. Say more in the section introduction about the purpose of the section. This is an important section.

[AITS architecture is a specialization of the OMG OMA architecture -- say more about what this means. AITS depends on DII COE -- say more about what this means. I think these architectural relationships should have been covered in Section 2 and should be removed from this section, which should then just focus on application architectures which are specializations of AITS.]
JTF, Genoa, BADD, ... are all further specializations of AITS. -- You have done good work on showing an AITS architecture and its relationship to many of these application architectures. More work along this line is needed (as you indicate).

This section should not be primarily about the contributions made by the various architectures JTF, Genoa, ... but rather about the relationships of these architectures, how you subset or tailor AITS to get each.
The division into 4.1 Current and 4.2 Upcoming is not right for the Reference Architecture since all application architectures are more or less mature or immature -- rather, mention all application programs at the same level -- just say in each subsection when the relationship is not yet determined (those in 4.2).
Fitting ALP in seems like a challenge. I suspect that AITS needs a concept of federation/clustering that other AITS application architectures may not yet have realized they also need.

Section 5, 6, 7

There appears to be redundancy and incompleteness in the organization of sections 5, 6, and 7. Reorganize these three sections into one section, perhaps called Status and Issues FAQ (which may not actually be part of the reference architecture itself).

start with status (6.1.1.) if you want to.
the main thing is to retain and consolidate {Challenges, Issues, Open Questions, Remaining Questions, and Holes} into one list instead of several overlapping lists

One does not always get the impression that this Issues Log is at all complete or that its issues can always connect back to the architecture or some specific architectural element. There should be a more detailed plan on how to resolve each issue than is given here. Issues should use an issues template {id-date-submitter, name, issue, alternatives, resolution} or similar
Some odditites

Section 6.1.2 seems like a random selection of security and workflow as topics to mention.
Section 6.3-6.7 - these sections seem a little randomly chosen and somewhat overlapping.

Do you expect inputs from ITO for Configurable User Environments?
I'd think that AITS itself (the sum of BADD, I*3, ...) is aimed at information logistics.
Killer Apps seems a programmatic issue.
Distributed System Management is important but is likely to be solved by the same approach as more generally ility insertion which also subsumes Security.
There seem to be several commercial Distributed OO Development Tools, so why is this here?

expand on the issues not so far expanded on since what is there is often too terse
conclude the Issues Log with Priorities of Issues and Next Steps. What issues are the true critical path issues that will make it or break it for the architecture? these must be identified for FY98 work.

Section 8

the references section seems skewed. You should add

Vision 2010 including web address
ABIS web address
web sites for ISO AITS, ALP, Genoa, ...
web sites for ITO programs feeding into AITS
DISA and GCCS LES web sites
OMG OMA Reference Model and OMG web site
W3C, WfMC, IETF and similar web sites

the work of Albus
the citations on DSSAs

it might be worthwhile annotating references so it is clear why they are included in the RA References section