Excellence by Design

A key principle of Excellence by Design is the that of ‘Design for Change’.   While the ability of any system to change over time has been important, it is becoming increasingly so due to the more rapid pace of change in technology, globalization, and consumer demands.  Simply put, the world is changing much faster these days than it did even just 5 years ago, and systems (both technological and  organizational) must be much more agile and responsive to this change.

Which means ‘Design for Change’ is more critical than ever.  Designing a system intentionally, to be more capable of change (in a managed, effective way) should now be a paramount consideration.  It is also one reason why systems that are rigid and inflexible to change, regardless of their maturity and function, are becoming greater sources of dissatisfaction.  Agility is becoming more important than function.  The Apple iPhone is the perfect example…it’s ecosystem of thousands of apps allowed it to be very flexible to new needs, while the typical cell phone providers struggled to provide more ‘fixed’ features in their phones.  It is fast becoming an unsustainable business, and ‘smartphones’ the norm….because they are ‘designed for change’.

An article by the Harvard Business School does an outstanding job of putting more explanation into this.  While it is very technical, the critical results can be summarized, and have great implications for Design for Change.  The full article can be found here.

Summary:

The  article analyzed complex software systems in terms of Core and Periphery Subsytems.  Their interest was to measure the level of core vs periphery use and understand its implications.  The study analyzed large software systems with a minimum level of complexity and usage  as measured by having a large number of end-user deployments.

Any complex technological system can be decomposed into a number of subsystems and associated components, some of which are core to system function while others are only peripheral.  Core components are those that are tightly coupled to other components. Peripheral components are those that are only loosely coupled to other components.

Some key findings:

• “How such “core-periphery” structures evolve and become embedded in a firm’s innovation routines has been shown to be a major factor in predicting survival, especially in turbulent technology-based industries.”
• they found “tremendous variation in the number of core components across systems, even when controlling for system size and function. Critically, these differences appear to be driven by differences in the structure of the developing organization.”
• The article notes research showing: that “tightly coupled (‘core’) components tend to survive longer and are more costly to maintain, as compared to loosely coupled equivalents… higher levels of component coupling are associated with more frequent changes and higher defect levels…teams developing components with higher levels of coupling require increased amounts of  communication to achieve a given level of quality.”
• There are substantial variations in the number of core components across systems of similar size. For example, variation from 7% (linux) to 64% (myboks) of a system as being core.
• Most interestingly different organizational forms appear to yield designs with different structures.  The difference between systems constructed in distributed (esp open source) methods, and closed/commercial (single company/team) environments was striking .  Even when comparing similar functionality, the closed/commerical offerings were significantly based more on core subsystems with an average of over 50%, compared to  avg of less than 10% core in those systems constructed from distributed, independent teams.
• And finally, their summary, which is telling:  “it is significant that a substantial number of systems lack such a structure. This implies that a considerable amount of managerial discretion exists when choosing the “best” architecture for a system. Such a conclusion is supported by the large variations we observe with respect to the characteristics of such systems.  In particular, there are major differences in the number of core components across a range of systems of similar size and function, indicating that the differences in design are not driven solely by system requirements. These differences appear to be driven instead, by the characteristics of the organization within which system development occurs.”

Implications/Recommendations:

Design is a key consideration in the design of systems, yet this study would show that design (in terms of subsystems) is variable, influenced by the organizational design, and yet has very important ramifications for future extensibility, flexibility, and resilience to change.  My experience has been heavily influenced by the focus on Core/Periphery subsystem design, and these findings match my observations.  As such, an organization developing a system (whether it be software, hardware, process, or organizational) would be wise to remember:

• constructing your ‘system’ with a minimal of ‘core’ components, and well interfaced (standardized, loosely coupled, independent of implementation) ‘periphery’ components, will lead to lower costs for change…which is inevitable, an increasingly the norm.
• avoid having your organizational structure unduly influence your system structure.  For example, while a ‘small tight team’ may be good to drive an effective design effort, ensure they design the system with the intention for ‘least core/maximum periphery’ system design
• these recommendations apply equally to business design, something to think about especially as a company expands globally and it is critical to determine (design!) the right balance of adherence to corporate consistency (core), while allowing regional/market adaptability (periphery) capabilities.

In any case, some good aspects to consider when you ‘Design for Change’ as part of Excellence by Design.