The key concept posed in the research is: Software deterioration is caused by changes in software, and although change cannot be avoided, it's impact can be minimized. By examining the aspects or characteristics of software engineering that lead to stable software solutions, enterprise IT departments can mitigate the risk associated with change resulting in reduced cost of ownership related to support and maintenance. Furthermore, the expensive IT resources employed to support the IT systems landscape in the organization can be better leveraged to deliver added value to the enterprise rather than being consumed with lower-value maintenance tasks.
While Dr. Fayad and several of his colleagues have published a book and a good number of articles on the subject, it is a near limitless field of study. For this reason the scope of this series of blog posts will address those topics relating to software stability in enterprise computing. While Dr. Fayad and I would like to see practicing the the comprehensive methodology of software stability throughout all software teams, he and I are both pragmatic and sensible. We realize that there will be corners of the software professions that will pick up on these concepts. Still, others will adopt similar approaches without realizing that they are employing the tools, patterns and practices laid out by Dr Fayad and other researchers. After all it is a wonderful, if not confusing thing about software engineering -- researchers and practitioners often have two or three names for the same principle. For example the concept of design patterns is nothing more than a codification of what good developers had been doing for years prior to ever seeing the concept in print. For example, while working in various software development teams before the Gang of Four (GoF) published their famous treatise on Design Patterns, we did not merely talk about lines of code, but we had consistent names for software artifacts that we created in the course of our work, often these names were reflected in the name of a code modules that participated in specific features of a software product. Our names did not match the nomenclature of the GoF, but there were striking similarities. For example, what GoF referred to as a "Factory", we may have termed a Machine, Processor, Compiler or Builder, often borrowing terms from other disciplines both disciplines outside of Software Engineering (Often terms borrowed from the very domains in which our Software Solutions were built to aid in efficiency of automation and of data collection), and inside of the Software and IT spheres as well.
The term "software stability" should be a standard in the vernacular of software practitioners in the enterprise, just as the term "design patterns" is a universally understood term in software development circles. It is important that it be treated with some consistency when we talk about software quality, reliability, controlling costs and increasing value to the enterprise. This series of blog posts is intended to explain why software stability is a vital discipline in the enterprise. That said, there are still many who struggle with the concept of software stability. To characterize this challenge, let me first share a story about my first attempt to convey the value of software stability in corporate America:
When I first mentioned the concept of software stability to a software development director at a fortune 500 company eight or nine years ago, he was actually offended that the word "stability" would even be mentioned in the same breath as software. His reasoning was that software in the enterprise is constantly fluid, and therefore, we have no business trying to make it stable. Stable software in his opinion was end-of-life software. While I understood his concerns, it was clear that his sense of stability meant something different than what I was talking about. I realized that it can be difficult to get even the most well meaning IT professionals to appreciate the need for software stability. Even years later, many in the industry are not ready for software stability. Perhaps it is due to the explosion of the "App Store" mentality where software is expected to morph and change all the time -- where would we be without our updates? Perhaps it is due to the broad adoption of agile concepts -- certainly it is intuitive that being agile is the opposite of being stable, right?
Wrong! Agility is not the antithesis of stability. The two are complimentary -- if not necessary and integral to success in an ever-evolving software landscape. Software updates do not imply that the software is inherently unstable. In fact, it is the stability of software that ensures that a software product is viable over time and remains reliable over numerous updates. Enterprise software platforms such as SAP, and Oracle's ERP and Database technologies are inherently stable they run reliably and they have been around for decades. These products are continually updated. Of course, those opposed to the concept of software stability will suggest that SAP and Oracle are not agile companies and they don't offer downloadable apps that are updated on a regular basis, so maybe these are not good examples. It's a fair concern. So, what about the IOS and Android platforms? Surely these are agile technologies and downloadable just as the applications that are downloaded onto these platforms. I rest my case. IOS and Android OS are agile technologies they are also stable technologies.
But what is it that makes these technologies stable and what is it that enterprise solutions architects and developers and IT managers and executives can learn from these technologies and from the concept of Software Stability? To a degree it is infrastructure and architecture that contribute to the stability of these technologies, but there is more to it than that. There are important concepts at play including Enduring Business Themes, Enduring Business Processes, Business Objects and Industrial Objects. In Enterprise computing, we need some standards and discipline that allow us to characterize the processes and characteristics of software stability in the enterprise. We need formal techniques that allow us to measure that stability. Disciplines such as unit and regression testing help with this but software stability is much further reaching and starts from the principle that quality and adaptability must be designed in to a solution.
The concepts of Enduring Business Themes, Enduring Business Processes, Business Objects and Industrial Objects are important and I will describe how these concepts ought to be leveraged in the development enterprise software in future blogs on the subject. It is important to point out that my concept of software stability in the enterprise is even broader than what you might glean from the academic literature on the subject.
It seems that enterprise software solutions come and go and we in enterprise computing have become accustomed to 5 or 6 year obsolescence cycles where software gets re-written from scratch or replaced by a commercial product which is then jettisoned after another short 5 years, IT professionals do not necessarily need to accept that inevitability and Software Stability is a discipline that can help to add valuable and value-added years to the typical lifespan of software products. Even more important, Software Stability techniques can reduce the cost of ownership of software within the enterprise and allow software teams to be more effective. In upcoming blog posts on this topic I will outline specifically how Software Stability practices deliver on this promise and I will explain what some of those key practices are. Software Stability should be a primary consideration of decision-makers in enterprise computing, because the cost-savings and value that a stable software solution provides is vital in controlling and intelligently allocating IT spend in the enterprise. Software Stability is an important consideration because stability and sustainability of software solutions does not happen by accident. In fact, in practice it rarely happens by design. Software Stability methods are a game-changer in the quest to deliver higher quality solutions with a longer viable lifespan and which yield a greater return on investment (ROI) to the enterprise.