TRI-Ada '94 topics

[crispen@eight-ball.boeing.com (Bob Crispen)]

Dick Dye asks about hot topics that ought to be considered for
TRI-Ada '94.

One topic which isn't hot, but which I think should be, is the issue of
architecture.  I heard an amusing story this morning about a person
(who shall be nameless) who went to visit three groups of people in
a company (also nameless) to talk about software/system architectures
and what such things as standard software templates, standard software
parts lists, and standard communications methods between parts can mean
for reuse and cost savings.

The common thread from each of the folks he talked to was that (a) they
didn't understand what software/system architecture was, (b) they didn't
buy the concept that it was important or even relevant, and (c) they had
a "way of doing things" (English translation: unexamined, unimprovable
process) that they were familiar and confortable with and had no interest
in changing.

The Air Force ASD/SEI Structural Model initiative that is going to
require structural models to be specified for new proposals seem to be
saying that they've run into people like that, too!  One of the reasons
I didn't name the company involved is that it might well be Everycompany.
I'm guessing we wouldn't have to search too hard, nor would you, to find
the same thing.

Of course, ASD's solution is a little Procrustean.  Nevertheless,
forcing you to think about things you don't want to think about sounds
on its face like it might be good for you.

The only problem I see with Structural Modeling is that it doesn't go
far enough.  The Structural Model as I (mis?)understand it requires a
methodology (art) but not a defined, repeatable process (cookbook).
In fairness, I understand that the SEI are developing a family of
defined processes to fit into Structural Modeling.

But I'm not trying to say whether or not Structural Modeling is mature.
I *am* trying to say that A METHODOLOGY IS NOT A PROCESS!  In particular,
the links between a methodology and an architecture are arbitrary, or at
any rate loose, while the links between a process and an architecture
are fundamental and deep.

This notion explains all sorts of things:  ADARTS can have its
architecture step late in the game because it's driven by a methodology.
The people who are complaining about that and tailoring ADARTS to put
the architecture earlier have a process in mind.  And why are people
having such problems using SEEs to gain productivity?  Because the
SEEs I've seen incorporate a methodology (or two) but not a process.

We've had a lot of debates about goodness of methodologies (OOD is a Good
Thing, Functional Decomposition is a Bad Thing, etc.).  Because we're
focusing on methodologies instead of processes and architectures on
which the processes are based, I'm guessing that we're not doing a very
good job of defining standards of goodness for architectures.  And I'm
guessing with a greater feeling of certainty that we're not doing much
of a job of evaluating the architectures that eventuate from our
methodologies (or that we've "always used") against a defined set of
criteria.

It just happens, by an amazing coincidence ;-), that I'm the co-author
of a paper that's being presented elsewhere that at least opens some of
these boxes.  And it seems to me that there's plenty more to be said
on this subject.

Well, I suppose I wouldn't be much good if I didn't think that what
I'd been working on was fairly important.  What do folks think about
the architectural issue?  Can someone define it a little better than
I've done here?  Am I the only one who cares about it?
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   Who will babysit the babysitters?  |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+