Subscribe
Sustaining success in complex situations presents challenges where classic approaches to projects, programs, and processes may fall short. This series of blogs will present a tool for dealing with those challenges, resilience engineering (RE). I’d like to start with two terms from RE: robust and resilient. Why? In a word, Relevance. These terms will give a taste of RE and set the stage for the rest of the series.
Robust Systems
Robust: A system is robust when it can continue functioning in the presence of internal and external challenges without fundamental changes to the original system.
An example of robustness may help. Company XYZ is an early entrant into a new market with Product Line A. In supporting Product Line A, a series of integrated databases are built in the back office and end-user operations are superb. As time goes by the industry morphs and there is opportunity for introducing Product Line B. The database requirements for Product Line B are a mix: 60% can be handled with the current systems and the remaining 40% present new requirements.
Time-to-market can be reduced if a commercial, off-the-shelf (COTS), stand-alone product is purchased to cover the new requirements. The problem is it does not integrate with the existing system and double entry in both systems is required. Specifically, products and services for Product Line B clients will be tracked in the COTS system while accounting will be done separately in the original system.
While an integrated solution is desirable it will take 6-9 months and is decided against. Another reason for deciding against the integrated solution is Company XYZ is in a recession in their market and keeping costs down is a “must.” Those in functional operations, the end-users, are told they will have to figure out a way to handle the double entry and insure problems don’t arise. The database end-users absorb the changes, create new policies and procedures, and the entry into the new market achieves sales and margin projections.
This is an example of robustness, i.e., the organizational system responded to a challenge and met its functional requirements while the original database systems are not modified. People absorbed the changes. This absorption comes at a cost, though. The stress level of the end-users rises and they are a little less masters of the database system and a little more victims of double entry.
Resilient Systems
Resilient: A system is resilient when it can adapt to internal and external challenges by changing its method of operations while continuing to function. While elements of the original system are present there is a fundamental shift in core activities that reflects adapting to the new environment.
With a resilient approach the integrative change would be adaptive in nature. Database operations would morph to reflect and environment comprising a composite of Product Line A and Product Line B. This is in stark contrast to the robust solution, which is still Product A-centric.
In its simplest form with the resilient solution, the end-users would focus on serving the customers and be free of the clunkiness and increased potential for failure associated with the double entry system.
Robust or Resilient: What’s the Difference?
Is the robust decision a bad one? Not necessarily. It just comes at a cost; a cost incurred while deciding on trade-offs, a cost that may be invisible to the culture. This issue of trade-offs is at the core of RE.
In the next blog we will look more at the accrued costs associated with trade-offs and a rather scary element that can be associated with robust solutions – drift. As the series progresses more innovative ways to approach trade-offs will be presented.
—