In Data And IT, There Are Various Levels And Classes Of Complexity Which Our Design Methods Need To Adapt To

To choose our methods for consulting in data and IT design, architecture, and strategic consulting, we need to understand the data and IT environments. For instance, Enterprise Architecture came of age during the heyday of Management and Information Systems (MIS) in the 1980’s as standalone applications on mainframes moved to various technologies. However, MIS was used mostly for predictable and common corporate functions. Then, EA came about as a perfect solution into the mid 1980’s to help improve processes, provide for more data access, and support technology integration.

But in the late 1990’s along came the concept of using IT solutions for the end-consumer via the internet. EA was still pitched as the savior. However, over the first decade of the 2000’s solid, decade-long strategic plans ceased creating valuable guidance and standardization. Consequently, EA became more of a nuisance. Some observations on EA from these events are as follows:

• Moore’s law kicked, introducing the hockey stick curve as well as technological disruption, and the enterprise became overwhelmed.
• The lower cost of technology has completely changed the data supply options as well – data is coming from new sources that were not considered before.
• Data was coming from Private and Public Partner data sources instead of employees.
• New interfaces and devices in pockets are helping people crowd-source data or conduct data production where considered “dirty” data collection only a handful of years back.
• A plethora of cheap, low to high-resolution sensors created a data Armageddon, creating problems of sourcing and eventually connecting  into the Internet of Things (IoT).
• Project Management methodologies adapted instead to responding to “epic” challenges of the period, and luckily technology caught up so the design and development could be done in shorter cycles using Agile methodologies (no more waiting).

3 Facets Of Complexity Theory

Looking at the 3 facets of complexity theory, we can understand better how to place our finger on what level of Operating Model change is needed.

1. There are various landscapes to the organization and problem space we support. Simple, Rugged, Dancing.

• Simple landscapes are like a single mountain peak, and we know the challenge, it is not moving.
• Rugged landscapes are a complicated set of multiple peaks like a mountain range have many peaks, but are set. What one group may see as their peak is either small or large compared to another group in another area. But, just like a mountain range, generally speaking, the peaks do not change locally, just perspective of peaks are one moves across or interacts across the different areas.
• Dancing landscapes are like rugged landscapes with multiple peaks, but if you throw time and it is more like ocean wave peaks. There are many variables that change over time, and what may be average predictable peaks one month, is completely different the next, or a tsunami comes and breaks the operating models apart.

2. In addition to the landscapes, we need to classify the level of change.

1. Static, Steady State, unchanging, achieved equilibrium
2. Periodic, Seasonal, Regular Cycles, Sinusoidal
3. Chaotic, Sensitive to initial conditions, Complicated, enterprise
4. Complex, Non periodic, highly interconnected patterns, emergent structures and functionality, highly disruptive

3. There are several dials and variables to help classify and determined which landscape and class one is dealing with.

This includes dials such as interdependencies, connectedness, diversity, and adaptive learning. These variables have measures to consider in quantity, quality, risk, maturity. For instance, diversity measures variation, entropy, and is very attribute-based. However, an overly diverse ‘dial’ is en route for collapse, where homogeneous means it is stubborn.

Given that, maybe there can be a cheat sheet after assessing the culture and business that helps select which consulting and design methods to apply?

Focusing on Data and IT Solutions for this example, lets take a look at the following table.

Taking this model into consideration, how are your design services are being applied?

• For example, did you move from an Enterprise MIS (Rugged, 3) to the web to offer self-service solutions (Dancing, 3)? Furthermore, did you take your MIS Operating model, and put a web front-end on? And furthermore, when did you start delivering data as a service?
• Did you move your major information product from using internal staff collection (Rugged, 2) to provided as a data generated product (Dancing, 3) and furthermore then provide as a service (Dancing, 3)?

In these scenarios, we have found our clients have circled back each time to the Operation Model Design. They revisit who they serve, their challenges and drivers, how funding and revenue changes, what the new value chain is, and how their technology and workforce strategy changes. This requires walking away from previous, long-term EA efforts to now taking chunks of the programs a segment at a time. This also involves considering what a new operating model design to utilize. All the while, changing their tactical development efforts to be more agile in the meantime in order to keep up with the new demand and inefficiencies of the existing model they are living in.

And if it Does Not Work?

But, if operating model redesign is just not in the cards, consider this one complexity theory principle: “He who has gets”. Ultimately, where ever the current operating model provides leverage, even if misaligned to the new landscape needs, they/he/she will continue to get the inertia, the funding, the scope, and leadership support to complete model implementation.