SAIP: Air Traffic Control

Air Traffic Control

Although this system was never put into operation because of budgetary constraints, it was implemented and demonstrated that the system could meets its quality goals.

The past two case studies in this book have never been utilized commercially. This is particularly disturbing since this is a book on software architecture. What use is an architecture if the project never takes off? Would we not consider cost as a non-functional requirement that has to be taken care off also? What's the use of the best architecture out there if no one is using it? How can it be the best if people are still using other products that have various shortcomings?

Of course, there is plenty of driving forces that might compel people to use the older software instead of a newer one. This resistance to change itself is an interesting topic to analyze when developing software. As we have seen, one reason will probably be because of cost. The second reason, as presented in the book, is ease of upgrading. The system proposed in the chapter required a more elaborate upgrade and installation path that could not be done in isolation of the other older systems (even though the interoperability software quality attribute was part of the stakeholders's requirements). Another reason that I can think of is backwards compatibility. Data stored in the old format readable with the hackneyed computer is still better than no data on a super fast computer.

It would be good if we could address those software quality attributes in this book as well.

Undeniably, there is plenty to learn from the two case studies presented in the book so far. I just find it very ironic that we are reading a book on software architecture in practice and the case studies in this book are not being practiced at all.

Of course, future cases studies will probably be successful projects. The one in chapter 8 seems successful.