Lars Hansen asked a question about my last post, Are agility and chaos two sides of the same coin? He asked whether I really meant "chaos", or perhaps I meant "complexity".
I definitely meant chaos. Complexity and agility are most definitely opposites. However, the thesis of my last post was that perhaps you need chaos to get agility - that chaos and agility are closely related (and in fact inseparable).
To be a word-weenie for a moment, here's specifically the definition of chaos I used:
"The behavior of systems that follow deterministic laws but appear random and unpredictable. Chaotic systems are very sensitive to initial conditions; small changes in those conditions can lead to quite different outcomes. One example of chaotic behavior is the flow of air in conditions of turbulence."
So, what makes the chaotic nature of dynamically unstable aircraft desirable? When the fly-by-wire system detects a random movement that's in the right direction, the plane takes advantage of it (and even lets it amplify itself). But, when the system detects a random movement that's undesirable it quickly compensates.
So, the key factors that make dynamically unstable aircraft possible are:
- Complete visibility into what's happening at any moment;
- Knowledge of the desired outcome (what the pilot wants the plane to do);
- Extremely fast control that ties the visibility to achieving the desired outcome.
Notice that I didn't say "Control of all the possible outcomes." The plane can't do this (because it's inherently unstable). The control systems of dynamically unstable planes are "going with the flow" or performing "dive and catch" response to what they observe... all many thousands of times per second. These planes are only possible because they can sense and respond extremely quickly, not because they can control what happens next.
SOA What?
Clearly the actions of project teams, to a SOA governance body or enterprise architect, will appear random - you will rarely be able to anticipate what they are going to do at any given point (no matter how much you tell them what they should be doing!).
But, perhaps if you can "sense and respond" in a tight loop, you can "go with the flow" of the seemingly-random behaviors that you determine will further your desired outcome, and "dive and catch" to change the ones that don't.
This is very different than traditional governance which seeks to control the possible outcomes in advance. In fact, this approach is almost entirely the opposite of traditional governance approaches! Traditional governance relies on many pre-defined controls, i.e. policies, with very little visibility into what really goes on. With limited visibility, obviously, limited on-the-fly response is a given - if you can't see it, you can't change it. In essence you assume the pre-defined controls achieve the desired outcome for you.
Agile governance (to coin a phrase) relies on very good visibility, few pre-defined controls, and the ability to respond quickly. Is enterprise architecture ready for agile SOA governance?