Featured Post

A Brief Introduction to Software Stability in the Enterprise

Software stability is an interesting term.  As a software design paradigm, the concept was first proposed by my good friend, Dr. Mohammed Fa...

Monday, February 1, 2016

A Brief Introduction to Software Stability in the Enterprise (part II)

In the previous blog post in this series, I introduced the concept of Software Stability as it applies to the Enterprise. However, it is important to understand what is really at stake when we examine the life-cycle of typical enterprise software solutions.  There are two prominent lifecycles that permeate enterprise computing.  The first type, I will refer to as "the Serpent" because it snakes a path through the a software wilderness sustained by fundamental business needs, while undergoing numerous evolutions, tranformations and redesigns.  The second type I refer to as "Wag the Dog".  Such enterprise software solutions become so fundamentally core to the operation of the business that there is no amount of investment that is too much to dissuade the enterprise from investing in larger and larger change initiatives.  In fact, the entire viability of the enterprise may be dependent on the operation of the solution.  And at it's core, it constrains the solution space for any business changes or transformation to the point that the entire enterprise is beholden to the software and cannot adapt to changes in the marketplace without exhorbitant cost to the enterprise itself.  So many departments or divisions within the enterprise may be dependent on the Wag the Dog solution that it is impossible to transform the company in the way that the business executives would like.  In far less worst-case scenarios the cost of maintaining or supporting the Wag-the-Dog solution may be so high that it literally eats into corporate profits to the point that the Board of Diretors must consult with the CIO on a routine basis to address even modest changes to the solution as the budgetary impacts are so high that it makes ordinary capital expenditures seem trivial.

Software Stability is not only a better way to define Enterprise Requirements, and generate Enterprise Solution Design, but it is the only way technique that I have found that builds adaptability directly into a Software solution.  Through Software Stability methods and techniques, we can envision software solutions that will adapt not only to the structural changes of the marketplace, but also can adapt fully with the evolving nature of the enterprise itself.


“How can this be?” you may ask, “How is it that the software engineering and information technology departments the world over have been doing things wrong all of these years.? This is the wrong question.  To be certain, successful shops have keep a close eye on best practices and developed careful standards.  During nearly 30 years of designing and developing enterprise scale solutions for my clients, I have become acutely aware that each organization that I worked with used different terms to describe identical software artifacts, database objects, and even business concepts that were at their core the same thing.  This awareness caused me to ponder, “How is it possible to build quality enterprise solutions when enterprises cannot even agree on the same names for core business and technology concepts?  To be certain, some deviation in terminology that I observed was not the result of two companies using the same term at the same time, but an evolution of terminology as one best practice was supplanted by another best practice.  This is little more than the wagging of the dog in practice. Best practices evolve over time.  Software stability concepts start from a foundational taxonomy of terms that are enduring.  These terms which do not change over time.  Using these terms a concise taxonomy of Stable Analysis and Design patterns are defined.  This is fundamentally different from ordinary design patterns.  


Current practice in Software engineering, analysis and design owe a debt to Christopher Alexander’s seminal volumes, “A Timeless Way of Building”, “A Pattern Language”, and “The Oregon Experiment”.  Yet our attempts to disrupt the practice of software engineering have been far less bold than Alexander’s stated objective: “The books are intended to provide a complete working alternative to our present ideas about architecture, building and planning – an alternative which will, we hope, gradually replace current ideas and practices.

To Wit, the Gang of Four did not assert that the patterns that they published in their seminal book were the comprehensive list of design patterns.  They merely documented a glossary of patterns that they observed being used repeatedly by highly skilled engineers. Software Stability employs hard and fast definitions of analysis artifacts upon which stable design patterns can be extruded.  Software Stability aspires to achieve a disruption for the ages and an alternative which gradually replaces current ideas and practices.  At its foundation is the premise that “software has no moving parts; therefore it is contrary to reason that it should routinely break or age.   Stable design patterns can be identified through different analytical methods than we use today, by changing our approach to design we can model truly stable software systems and through stable analysis and design patterns we can build software components that are truly stable and enduring, and these artifacts can be employed as the foundation for software solutions that are stable over time and simultaneously adaptable over time at a far lower cost than conventional approaches. Software stability provides a solution to both the Serpent lifecycle of enterprise systems and to the Wag-the-Dog lifecycle of enterprise systems.

No comments:

Post a Comment