Making Sense of the Enterprise Continuum, Part I

There is that famous proverb by George E. P.Box:

All models are wrong but some are useful.

If there is one model that fits that criterion, it must be Cynefin.

Cynefin regularly receives criticism, grounded and ungrounded, for example by academics for its “oversimplification” as formulated in Key Issues in the New Knowledge Management.

But is’t that what models are? An oversimplification of reality? Anyhow the simplification proves to be awfully useful in conceivably explaining that not everything can be ordered upfront and maybe should be ordered at all.

In fact Cynefin creates the awareness that a perspective well beyond the oversimplification that today is predominantly being maintained, is key in better dealing with reality. Paradoxically enough, Cynefin is even a model that demonstrates when models aren’t useful!

Now, what is Cynefin?  Cynefin is in fact what is called a sense-making model, actually referred to as a framework rather than a model. Instead of explaining further details myself, I’ll leave that to the prime author, David J. Snowden (@snowded), as there is no way that I can equal David’s canny explanation.

Found that interesting? Unfortunately, understanding of Cynefin often ends here. A consequence is that many fail to grasp its full usefulness. Real understanding requires additional insight in the associated “dynamics”. And gaining familiarity with the dynamics will require an extra effort through the reading of a paper: The new dynamics of strategy: Sense-making in a complex and complicated world. Be aware that the paper predates the video and is still using “known” and “knowable” for what today is labeled as “simple” and “complicated” respectively.

Now, how can Cynefin be useful?  As the title suggests, I will shed light on how Cynefin is in making sense of the enterprise continuum. But before going there, some reviewing and rereading might be necessary to fully comprehend Cynefin.

Business Model and Business Architecture: Synonymous or Dissimilar?

When I read Tom Graves’ (@tetradian) post Who is the customer? published on July 14th, 2011, it was not the first time that I thought: “Hey, wait a minute. Using business model and business architecture interchangeably is not right.”  But did I expect Tom to do so?  No, not at all.

So when I noticed Chris Potts’ tweet (@chrisdpotts) the next Friday:

@chrisdpotts @tetradian Let’s not confuse business model with business architecture. Our business vs how we are structured to achieve it. #entarch

I could only join him in surprise.

I was even more surprised with what followed. Many reactions on twitter and blogs, most asking for further clarification.  What two characters, a ‘+’ and a ‘1’ can cause on a Friday…

Tom’s response with What do we mean by ‘business-architecture’? was one of disappointment, but also a lot of curiosity about what  –  the hell? :-)  –  we were thinking:

@tetradian @chrisdpotts @krismeukens to me it sounds like you’re mixing BA with EA? – expand/explain, please, perhaps with blog-post?

With that last tweet, Tom has brought a fundamental question to the surface, one that I believe is long overdue and that I am really excited about.  So I was not disappointed at all by his response to our criticism but a bit surprised by his thinking because he has been driving so much debate with regard to other fundamental questions.  For example, I just love the debate that he has set in motion about the distinction between the organization and the enterprise, and admire him for his persistence in defending his stance.  His thinking is far from mainstream yet. But with his passion for enterprise architecture, which is second to none, there is no doubt that his voice has become influential.  But I also believe that the distinction is far from fully clarified yet and that it is root to our ongoing “business model versus business architecture” disagreement.

Maybe I am missing details.  I am not fully aware of all that Tom has ever written. To be honest, I do not read all his posts and rarely completely.  Tom just writes way too much for the time I have available.  Sorry Tom.

Anyhow, whatever my following responses, I do not expect that Tom will have to say: “So that nailed it.  I was totally wrong.”  I am not seeking any truth but have developed a perspective that I think is worthwhile to share.

Of course, Tom is right.  A business model is business structure. Moreover it is significant structure, hence even by my own small attempt to more definition of architecture described in Architecture and the Remainder of Design, business architecture.  But does that make the terms interchangeable?  I believe it does not.  It are key nuances that get lost that way.

I was quick in starting to draft an answer but I quickly found out that a full response would take a very very long post. In fact the more I thought about it, the more I began to see as relevant for clarification of my perspective. The conclusion is that my answer will not arrive quickly. Instead I will explore answers to more fundamental questions first.

At the core of this dispute, I do consider the continuing fuzziness in what not only makes the enterprise and the organization distinct, but the business as well.

The opening sentence of the “business” entry Wikipedia says it all:

“A business (also known as enterprise or firm) is an organization engaged…”

If there is so much confusion between what is the business, the enterprise and the organisation, how then can we meaningfully distinguish between what are their respective architectures?

I cannot count the times that I have people heard trying to clarify the relationship between these concepts, also myself, each time different, not a single time without a lot of fuzziness.

So a first will be my attempt in exploring what I will call the enterprise continuum, in Making Sense of the Enterprise Continuum.  The post will kick off a renewed attempt to write more regularly.

Structural Agility Dissected

Last April Doug Newdick (@dougnewdick) made an interesting comment to Architecture and the Remainder of Design:

I think there is a distinction between “agility” and “agile” that we are both glossing over. Agile architecture (or more properly “agile architecting”) is architecture that takes the “Agile manifesto” seriously. Agile architecture is a (software development) process. Agility is a property of systems or enterprises. You can architect for agility without doing it in an agile fashion, and vice versa. So the process can be agile, and the resulting architecture have no agility. I take it that a key point of any system or enterprise architecture is designing in those points of flexibility that support desires for enterprise agility, and designing in points of inflexibility where the business does not desire agility.

I understand what Doug is hinting to. It is important and something I have not yet addressed. So I’ll give it a try.

I do not think the difference is in the words agile and agility.  What I actually notice is that we are confronted with two structures underlying two different systems:

1. structure
2. structure to structure

“Structure to structure” is the factory, the factory that produces the “structure” which is the product.  The factory represents the structuring competence.  That competence can be agile or not, independent of the characteristics of the product, as Doug is rightfully arguing.

The “structure to structure” has different facets as it is in fact always a social system, potentially making use of supporting systems.  When the product is a social system too, the factory is often part of the product in a recursive way:

For an enterprise, the factory is the competence that develops the enterprise structure, and indeed often part of the product itself.  When making this concrete with the example of an agile development competency, the factory structure is what has been institutionalized in a social system, contained within the enterprise, including all the support systems that have been installed for the purpose as well.  Nonetheless, the factory can be very unstructured, being the counterpart of craftsmanship that was applied in building the first automobiles more than a century ago.

The factory introduces another interesting question as to how it is positioned with regard to orders of agility. Clearly the factory can be very agile in producing an ineffective product, a fact often forgotten.

Architecture is Fractal in Nature

Let’s start a mental experiment, starting with the earth as it can be seen from space, with time come to a halt. For the purpose of experimentation, that is the initial design of interest.

Next let’s imagine having an instrument to observe.  What can be seen through the eyepiece determines the whole, at the start the whole earth. What can be subjectively considered the significant structure of the whole, is the architecture.

When zooming down, the “whole” boundary changes. What can be subjectively considered the significant structure relative to the newly determined whole, the architecture, changes too.

The instrument provides an infinite zoom capability. Zooming down can continue, down to continents, countries, cities, buildings, ultimately to the atomic level and even beyond. All in all, the overall design i.e. the whole of the earth down to its tiniest part wholes does not change at all. Architecture is thus the sum and the part because as one zooms in and out ultimately everything is covered, all design.

Architecture is design, design is architecture.

Orders of Agility

Two weeks ago, Ruth Malan (@ruthmalan) of Bredemeyer Consulting and contributing author to the Cutter Consortium commented in her online journal (being maintained since 2006 and recommended!) that between the metaphor used by Tom Graves (@tetradian) in Agility Needs a Backbone and what I covered in Architecture and the Remainder of Design, there is a great way to talk about architecture and agility.

I agree. And more there is, there is definitely more to talk about…

In Architecture and the Remainder of Design and further comments, I argued that architecture provides an agility distribution instrument; that architecture is inherently not agile but simultaneously an instrument to push desired variation points out, to the boundary with or into agile territory.

Likewise it is an instrument to inhibit non-differentiating change, by burying the opportunity. Actually, to quote Dana Bredemeyer (@DanaBredemeyer), one can “prune the opportunity tree”. In Enterprise Agility, an Attempt to Get to the Bone I shortly covered the apparent paradox that agility also increases by reducing change, albeit the non-differentiating change, thereby leading to “leaner” structure. Clearly I am using the word “lean” here only as an adjective, a marker, no decorated meanings intended! Leaner structure is more coherent, carries less weight or — using a better word — mass, thus eases coordination, and so enhances the ability to move quickly and easily.

In fact, both “desired” and “non-differentiating” change options need to be addressed and to be brought in balance and that is what agility distribution is about. One could think that a start-up, with a small team and hardly any structure, with a lot of things happening by self-organisation (which in fact turns into structure too), is the summit of enterprise agility. But without much rigid structure, it is missing “non-differentiating” change being addressed, more often than not painfully experienced as soon as the start-up grows bigger and has to start fending off contenders. Simply put, there is hardly anything to balance the variability with. There is hardly any distribution that can be done. Thus no or little structure does not make agile! It offers plenty of room for change but hardly any quick and easy amplification of coordinated, directed change.

Indeed, Agility Needs a Backbone and it is architecture that can provide that, in fact architecture is that backbone! Of course, not withstanding all engineering (attempts), structure and the distribution thereof can be (partly) emergent. It may be what we simply find and often is. It may not be readily apparent, (partly) hidden in its complexity, something one can never be fully aware of, and not necessarily be well aligned with what is desired. But it will have specific quality characteristics nevertheless!

Much of the confusion about agility originates however from the unawareness of different orders of agility. All the above is not presenting the whole picture. What I tackled in Architecture and the Remainder of Design is about 2nd order agility, agility as a quality or state, the distribution of structure as it is that defines the rigid backbone and the set of variation points. The praises that for example the cloud receives is about 2nd order agility. But 2nd order agility in itself is useless if it is not aligned with and for a higher purpose: 1st order agility! If it is not, it simply adds to the non-differentiating change options and is counter-productive.

In explaining to the full extent what I mean with 1st and 2nd order agility, I would like to start with the framework described in the paper An Integrative Perspective on Information Management by Prof. Rik Maes (@hoogleerling), and which can be seen as an elaboration of the Strategic Alignment framework by Henderson & Venkatraman:

I have a particular interest in the structure layer that Prof. Rik Maes positions rightfully between strategy and operations.

The picture that I presented in Architecture and the Remainder of Design actually maps to these layers:

2nd order agility is represented by architecture and the remainder of, secondary, design. 2nd order agility determines the configuration set in support of 1st order agility.

1st order agility is change that can be performed abruptly while leaving competence intact. It represents the ready ability. It is agility that is embedded into the genes of the whole. There is no way to get outside the set that is provided. Even different combinations will bring no relief. But if the set does not suffice, there is still the choice of re-framing by changing structure so to change the set, hence by falling back on 2nd order agility. But doing so will come with a latency price tag, it will not happen abruptly and worse, will disrupt competence. If however structural agility distribution is handled well, it can still mean a world of difference: secondary design instead of architecture, with definitely superior latency. In fact regarding latency one could reasonably expect the following for an “enterprise” whole:

configuration → abrupt → seconds to months

secondary design → quick → months to years

architecture → slow → years to …

Many organisations neglect “real” enterprise architecture because it takes so long before benefits start to arrive — and thus much doubt exists if they will ever arrive — but surely miss grand opportunities: configuration and secondary design can never generate the abrupt or quick effect that they could potentially have. The backbone is lacking.

What is 1st order agility ultimately offering? Hopefully both strategic and operational agility. In a next round it determines the territory that can be explored for doing “right” things as well as the territory that can be exploited for doing things “right”. These round-trips ultimately determine how wholes, e.g. enterprises, are able to grow, improve and adapt over time, or collapse.

In effect:

Architecture has the potential to be the instrument to fixate the principles, either the aspiration for reliability in maintaining specific constants, or in maintaining specific variables, in a coherent manner.

So in conclusion: agility = structural agility (2nd order) + strategic agility (1st order) + operational agility (1st order). And architecture is the backbone.

Agility and Agile are Brand Names!

In Enterprise Agility, an Attempt to Get to the Bone, I mentioned that agility and agile are not brand names although vendors would like the idea.  Apparently, I was wrong.  I admit the mistake!

When reading all that is being written about agility and agile I can only conclude that I was terribly wrong.  Seemingly the tsunami of marketing indoctrination by vendors and consultants has done its work: Agile and agility have become brand names!

Why am I writing all of this? Just a few (contradictory) statements that I have found:

• Agile is a method, a production method in fact, of course delivering agility.
• Agility is an attribute of an organisation or a business unit.
• Organizations don’t simply become agile. They’re either agile or not.

Once again,  for just a small moment, let’s return to the original meaning of both words:

Agility noun the ability of moving quickly and easily

Agile adjective marked by the ability of moving quickly and easily

As an act of freedom, I broaden “moving” by replacing “moving” with “changing”, as moving is changing and changing is moving, and that word is better suited for what I am interested in:

Agility noun the ability of changing quickly and easily

Agile adjective marked by the ability of changing quickly and easily

First of all,  agile is a marker, or better an attribute, in fact a “quality” attribute associated with and exhibited by “something”, the object being marked.

Agility is neither a binary “present” or “absent”, and agile neither “true” or “false”. It is however better or worse, and that only with a specific purpose in mind.

I don’t read anything of a method, neither a production method.  Consultants have seemingly made many believe that everything agile is about, is their method.  And seemingly that has worked.  Agile is about methods, isn’t it?

No, it isn’t!  Or better, not necessarily. If “something” is the method, or better the method is the object, agile can be an attribute associated with the method.  Can that method be agile?  It depends what the purpose is. For one purpose the method can be agile, for an other it may be not at all.  Enterprise agility is yet an other matter, it is about an other object, and probably an other purpose as well.

I’ll illustrate further with an example:

If someone – a human as object – is wandering across the savanna, to be suddenly surprised by leopards approaching and that someone is able to move quickly and easily so to escape and survive, that someone is agile (marked by the ability) for the purpose of escaping and surviving. The ability could be better or worse. There is a tipping point when worse becomes too bad. With a Land Rover nearby that (s)he could drive, having foreseen the future purpose, (s)he would have been in a superior state of agility than with no means at all.  But there may be even less risky states to be in.  What if (s)he could be beamed up? Wouldn’t that be even a better state to be in? Because, what if the leopards would be able to run faster as the Land Rover could progress?

The state of agility may be good or better aligned with the purpose of escaping leopards. If however the area is abruptly and majorly flooded, the Land Rover may not help at all, and (s)he may drown.  The state of agility may not be aligned with an other purpose, surviving a flood. The more advanced technology solution would still help. Technology doesn’t matter?

Object and purpose!  All that matters is object and purpose!  In fact agility is about the ready ability of an object to timely arrive at a purpose legitimate in a suddenly changing context, here the ability to survive.

With the enterprise as the object that enterprise architects apparently care about:  What is the purpose of the enterprise?

In Re-Creating the Corporation and in even greater detail in On purposeful Systems, Russell L. Ackoff has offered great explanation that systems – and for the purpose of illustration I just accept the abstraction of the enterprise as a system – come in 4 flavors:

System	Parts	Whole
Deterministic	Not purposeful	Not Purposeful
Animated	Not purposeful	Purposeful
Social	Purposeful	Purposeful
Ecological	Purposeful	Not purposeful

An IT system is deterministic, having no purpose of its own, neither its parts. A human is animated, having a purpose of his/her own, but for example his/her stomach, being a part, hasn’t. An enterprise is social, having a purpose of its own, and humans, being parts, having as well.

So what is an enterprise’s primary purpose?  Russel L. Ackoff goes to great lengths to explain that social systems have one  primary purpose and that is surprisingly enough survival.  Hence:

If for an enterprise survival matters, in an ever changing context, the ability of changing quickly and easily is essential because, one day, its state of agility may be too bad.

So next question is:  what are events that the enterprise wants to survive?  One cannot have it all.  Choices will need to be made. Next, getting the enterprise in an aligned state to survive, is what increasing enterprise agility is about.

I admit: the prime purpose of surviving may sound abstract in relation with the enterprise. Therefore I really recommend Russell L. Ackoff’s work.

What about this one?

• It solves world hunger too.

In fact, it may.  If that is the purpose!  Let’s think about the object!

Architecture and the Remainder of Design

In the one comment made to the earlier post Architecture in Context [Revision 1], different aspects are put forward that I also see as key elements in a defining story but in quite different ways as proposed.

One, on which I fundamentally differ in opinion, is about the interpretation of a quote by Grady Booch (@Grady_Booch), a well-known and widely accepted truth about architecture:

All architecture is design but not all design is architecture.

The deduction that I make is that architecture is a part of a whole called design which leaves another part, the remainder of design, resulting in following questions:

• Is there any primacy in these parts?
• Where does architecture end and the remainder of design begin?

In the comment referred to above, is stated that Grady Booch meant to differentiate otherwise, between objective/subjective aspects.   No doubt the objective versus subjective stand towards fit-for-purpose is an important element in a defining story – one that I will later come back to  – but I disagree that the concern is what differentiates design from architecture.  It plays a role but in an other way.

In fact, I cannot find any proof of Grady stating so. Moreover, there is a well-known addition to the quote by Grady Booch (original reference) that points in quite a different direction.

What followed is:

Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

That more or less has always been my understanding and has a consequence.  It means that the part representing architecture is a relative notion.  Significant means “significant when compared to the cost of change of the whole”.

I’ll present an example taken from the tangible world, to clarify.  If urban architecture is your perspective, the architecture of one specific building is usually not significant. It is therefore part of the remainder of design, at least from that perspective.  If only the building is your perspective, architecture is made up by a part of a whole that in the former perspective completely ended up in the remainder of design.

Grady Booch refers to significant “cost of change” which seems to point to financial measure.  I believe that such an understanding is too restrictive.
Therefore I refer to significant “barriers to change” instead, thereby generalizing more specific barriers like:

• significant number of dependencies. In fact the remainder of design is secondary design as it depends on the architecture and thus will be seriously impacted by change to the architecture
• significant reach, level and/or period of non-operation due to change in progress
• the need for significant transition architecture(s) to overcome the previous
• significant financial cost to change in comparison with the financial cost of the whole, for sure
• significantly hard to gain empowerment needed to enact the change

The latter specific barrier is a reason why most cities have retained old structures over centuries but Paris is an exception.  Napoleon III had not only a considerable amount of power at his disposal but was also a good communicator, hence he succeeded in acquiring the necessary empowerment, to have realized what has been referred to as Haussmann’s renovation.

Hence significant in this context also means that such a change when started abruptly and incautiously is likely to cause anything close to destruction and subsequent recreation with the newly desired fundamental structure. In between old and new, the action would cause the whole to be significantly non-operational.

This all leads to following observation:

Architecture itself is that what is inherently not agile.

The remainder of design is on the other side of the barrier, thus:

The remainder of design is that what is inherently agile.

Thus this makes architecture about agility distribution, structures that can be changed easily and others that cannot:

That distribution may be a reality that we simply find or it may be something that can be influenced through the act of designing thereby turning architecture into an agility distribution instrument, in fact:

Although architecture is “the” prime enabler of agility, architecture itself is that what is inherently not agile.

The Road to a Defining Story of Enterprise Architecture

In my previous post, The Quest for All-Embracing Succinct Definition, I expressed the intention to build a defining story for enterprise architecture. The post received several encouraging comments that were most positive, constructive and challenging. Thank you! One (I am not referring to one of the comments @ drisec.com) was skeptical, straight cynical even, but with a hint why, which helps too.

I am not going to react to any of those comments now however. It is too easy to lose myself in doing so. Instead I opt to start a structured build-up over a number of posts and all comments received will be food for thought, to continue, or to go back and reconsider. So don’t stop commenting!

In creating the structured build-up I will take following approach:

• Initially I will draw from existing definition assertions made by others and will consider them being rightful only based on my own intuition although some might not be widely accepted yet.  Later on, I may come back to those so to secure the foundations or to reconsider.
• In the build-up I will leave lots of loose ends, by intention or just by initial oversight, that I will pick up again in later posts.  Any reader looking for “enterprise architecture” clarity in one post is headed to disappointment.  Please consider this when commenting.
• I will create models to support the reasoning, with the quote that “all models are wrong but some are useful” (George E. P.Box) in mind.

For the curious ones, on the reasons why I am doing all of this… I am proceeding with this, firstly out of intellectual curiosity whether it can be done, secondly to find better means to clarify the value of enterprise architecture to the unaware, but primarily in support of writing the master dissertation that I need to deliver and for which I have already done quite some research.  Is the defining story of enterprise architecture the subject of my dissertation?  Partly, it will form the underpinnings of something larger…

The Quest for All-Embracing Succinct Definition

Funny to observe how much effort has been spend lately in counter-arguing the arguments for having an all-embracing succinct definition of enterprise architecture.  The message is that it is “not worth the effort” as there is no succinct definition capturing the essence to find, and that one shouldn’t care because a definition does not really matter anyway.

One of the arguments being put forward to support that position is that one does not have an all-embracing succinct definition of “accounting” or “engineering” either and no one really seems to care or to be hindered.  A lot of accountants and engineers just do what they do and the value delivered is widely recognized.

It is however exactly that assertion that points to the heart of the matter.  It is not a definition that is essential, it is broadly shared, sufficient tacit knowledge.  That’s what is different for “accounting” or “engineering”. People hiring an accountant or an engineer almost never ask for a definition although they themselves may not be able to come even close to an all-embracing succinct one.

Question is: how does one get to broadly shared, sufficient tacit knowledge?  One may wonder whether sufficient tacit knowledge of what is “accounting” or “engineering” was always broadly shared.  The answer is: of course not!

It is debate, in order to synthesize a story, even if that is an attempt to get to better definition, that advances tacit knowledge transfer and eventually installs broadly shared, sufficient tacit knowledge.

Fact is that I agree with above mentioned position that there is not one succinct definition capturing the essence to find.  But a defining story is definitely within reach.  Next posts will shed more light on what I mean with that apparent contradiction.

Enterprise Agility, an Attempt to Get to the Bone

A while ago I got involved in following little Twitter conversation:

@pauljansen: RT @umairh the more unpredictable the world gets, the less valuable your cleverest strategy becomes < unless you go for agility

@krismeukens: @pauljansen agility requires predictability, agility comes through choices for longer term, hence one needs to foresee needed flexibilities.

@krismeukens:@pauljansen agility is about getting rid of flexibilities one does not require, which flexibilities?

@pauljansen: @krismeukens agility is ability 2 move quickly when change requires swift fundamental adaptation, it’s a competence, not a specific action.

Not only did this little discussion show me the limits of Twitter conversation in making a point, it also provoked some further reflection and an effort to write a post …

Agility

Ask a bunch of people what ‘agility’ means and how to get increased agility, and you are likely to find as many explanations as people.

The troubling consequence is that the concept of ‘agility’ is often turned down as being valuable or even worth discussing, and classified under “just another hype”. That is unfortunate as agility is really a fundamental ‘enterprise’ concept that deserves serious attention. But before that can be accomplished, its meaning and the path leading towards ‘increased’ agility should be clear.

In getting to the bone, I am in favor of returning to the original meaning. After all, it is an English word that can be looked up in the dictionary; not a brand name, although some, if it would be theirs, would like the idea.

A look-up in Oxford English Dictionary reveals the following:

agile
able to move quickly and easily

A look-up in Merriam-Webster Dictionary brings forth:

agility
the quality or state of being agile

agile
1. marked by ready ability to move with quick easy grace
2. having a quick resourceful and adaptable character

Agility as a ready ability

The words ‘able’ and  ‘ability’ hint, indeed, to competence; the competence to swiftly change even when change is fundamental, with hardly any ripple effects so to speak. Whether that competence is either high or low can eventually mean the difference between succeeding or failing.

The paradox is however that competence naturally is enemy of change. How can that be, you ask?

Ten years ago Seth Godin wrote a classic article “In the Face of Change the Competent are Helpless” about that disturbing fact. I urge anyone to read it.

The reason is that competence is built by factoring out variance, by casting in stone how things should be done over and over, to reach the same quality standards over and over. Once a competence is in place, high impact or abrupt change will destroy it. Naturally, sustained competence can only cope with slow-paced change.

The bitter consequence is that the options for abrupt change in competent enterprises are usually very limited.  Any of possible efforts to realize high impact change without destroying competence will simply take too long, will come too late to yield relief:

Agility as a quality or state

Luckily Merriam Webster mentions other words that provide further clues. Agility is the quality or state to be agile, hence indeed not an action.

But the path towards ‘increased’ agility is inevitably full of it. Increased agility asks for reaching a better ‘fit-for-future-purpose’ state by resolving above paradox, thus action. Without action, no reaching.

Resolving the paradox is about transforming the enterprise, moving it into a state in which minimal enterprise structure change, hence non-disturbing change, can result in abrupt high-impact enterprise operation change. In fact configuration options, realizing the quick resourceful and adaptable character, are to be embedded into competences, competences which inevitably become less specific. Once in place, competences can be reconfigured to realign with an evolving environment with the desired results. Let it be clear that the inclusion of the capability of configuration has a profound effect on Architecture and the Remainder of Design:

The action should also be focussed on working on what seems yet another paradox: Agility increases by reducing change options.

In fact much of found change options in enterprises are non-differentiating. It are options that lead to variance and personal judgement and that do not contribute to a well-shaped ‘lean’ enterprise.

The imperative is to determine what change options do not really matter and are in effect counterproductive, to identify inconsistencies between current and possible future states, and with that knowledge in mind, build core competences with embedded configuration options where necessary. Next one can drive efficiency to the extreme after which natural slow-paced non-disturbing evolution is considered sufficient for any of the desired future states.  That way possible future states are brought closer in line with current state, even when, being observed from the operational side, they appear fundamentally different.

Outcome

Fortunately being the easier part, reducing change options is a good start.

From there, strategic choices regarding alternative future states are to be made and needed configuration options to be derived.  As those choices are about the future, the act of prediction is never far away. So does agility require predictability? My answer is: Preparation for any change is preparation for no change.

However do not forget about velocity as Seth remarks!