Grady Booch on DoD software management

Back to this month's "Crosstalk" that is the issue on architecture. This issue also has an interview with Grady Booch, now with IBM but probably best known as one of the three main authors of the Unified Modeling Language, UML. [Historical note: IBM bought Rational a few years ago, and Booch was a key guy at Rational inventing UML]

Booch gave his opinion about the DoD software community:

It really used to be, decades ago, that the DoD was leading the marketplace in the delivery of software-intensive systems. The harsh reality is that the commercial sector is leading best practices and really pushing the arc relative to software engineering and software development. So, in that regard, the DoD is behind the times. That is not to say that they are not pushing the limits in some areas. The kind of complexity we see in certain weapons systems far exceeds anything one would see commercially, but ultimately, there are a lot of things that the DoD can learn from the commercial world.

I wonder if the commercial "best practices" he refers to are Agile, or something from the CMMI? I'm not sure I would put Agile under "best practices" for general development, but certainly for cases of evolving and emerging requirements that are not fixed in anyone's mind, Agile is a risk management solution for that dilemma.

And, I certainly wouldn't call Agile "software engineering". Test driven design--TDD--might qualify as an engineering practice, so also refactoring, but most of the rest of Agile is management not engineering.

Those are my opinions. Booch had something different to offer:

Three recommendations for large scale organizations

Booch has three recommendations for DoD software managers and practitioners, but really these apply to any large scale organization doing software intensive systems:

1.  Increase leverage of open-source tools and resources. This is not just a cost issue; it's an issue of leverage for innovation and transparency.  Specifically, Booch says push 'Forge.mil' along, the services arm of 'SourceForge'

2.  Build more elaborate and deployed infrastructure for collaboration. [I think he means: It's not that programs should be managed from Facebook or Twitter....they shouldn't...] There should be more emphasis on leveraging the worldwide expertiese of DoD and its contractors

3.  Go beyond functional modeling and get down to modeling the system itself.  Make architecture an artifact of the project. To this, I say: Amen!

The DoDAF [DoD architecture framework] as a means to bring more emphasis and utility of architecture to DoD programs. Booch thinks DoDAF is effective for modeling the 'enterprise of the warfighter', but is less effective in modeling software intensive systems.

Perhaps so. However, the DoDAF is certainly in evidence in the battlefield robots now under development and being deployed. We'll see how that works out. Advantage: USA [for now]

 Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.