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 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.
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.
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