I had the pleasure of meeting software development guru, Grady Booch, at IBM’s Innovate Conference in June. SearchSOA followed up with an interview with Booch, further exploring the ‘system of systems’ concept.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
In the interview, Booch says that the idea of systems of systems is not new.
You can go all the way back to the work of [researcher] Herbert Simon, the book Systemantics by John Gall, and the NASA gentlemen that built their deep space network. Their notions about systems are things that have been part of the generic practice for decades. The difference is the increased amount of software that we’re seeing injected into these systems.
Booch compares the idea of system of systems to the growth of cities, stating that some of the problems that are encountered are similar.
There’s no one that really controls [the whole thing], there are lots of sorts of cost cutting concerns, and scattered and tangled sorts of things. The lessons that we learn from cities can be applied to software systems as well.
Booch describes “ultra-large systems” as those which any one organization is unable to control.
The best you can do with ultra-large systems is to kind of nudge them in certain ways. You also are in a situation with these systems that you can’t ever replace them. They are too large. They are – dare I say it – “too big to fail.”
The interview continues with further comments from Booch about the history of systems of systems using the automobile as an example. Booch also talks about his early career at Vandenberg Air Force Base working two real-time projects: a telemetry processing system and a range safety display system. Booch talks about the importance of embedded real-time even in “days of yore.”
What we realized back then is that here was a crowd of people that had traditionally been — and I don’t mean this in a pejorative sense — tin-benders — they built hardware. But the amount of software that was going into the missiles, trains, radars and the like was a hockey stick. There was a knee in the curve. And the ability of those companies to understand how to develop software properly — to architect and manage it as part of the system — that was all new ground.