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.

Architecture in Context [Revision 1]

Context carries tremendous importance in disambiguation of meanings as well as in understanding of the actual meaning of words.  The word “architecture” is exemplary in this regard.

So first I will focus on the contexts in which the word “architecture” is being used. Without understanding the different contexts,  there is no clear road to a defining story.  For the moment, I will just ignore the enterprise, the domain of prime interest. It is just about “architecture” in general as there must be a reason that the word is used across widely diverse domains.

So then, what are the different contexts? One fact is clear. Dictionaries offer only limited assistance as they show little formal recognition of those contexts.

The start is a quote from Grady Booch (@Grady_Booch) that intuitively feels right:

“All architecture is design but not all design is architecture.”

With a little further help of dictionaries, one can already discover different usages:

• design / architecture as a noun (state): a design / an architecture
• design / architecture as practice of doing design / architecture, thus a verb (action): to design / to architect

Without yet trying to determine the difference between architecture and the remainder of design, it feels right to state that, both design and architecture represent arrangement or structure.

With that in mind I have come up with a first revision of a model in an attempt to capture all arrangement- or structure-related concerns:

Centre piece is concrete structure (A), the actual state of structure (states are boxes) as it exists in the reality of a building, a city, a software-intensive system or a social system (for example an enterprise); any object or system really. Concrete structure is often not really static, thus not a state but in order to get to understanding it is conceived as an image being taken thereby capturing the moment and so turning it into something static (The same recipe is applied for the other states for which the notion of a baseline is common practice). Mostly, the dynamic aspects of especially architecture over a small period of time are of limited concern anyway.  There are reasons why, that I will tackle later.

An immediate question that arises from above notion, is how concrete structure comes into existence, an actual action to structure (actions are arrows). Another quote from Grady Booch provides some further clues here:

“Most architectures are accidental, some are intentional.”

In other words, concrete structure either emerges (1), is engineered, or is a mixture of both.  Engineering is a composite action; it consists out of several other.

A key means in an engineering effort of any concrete structure is a structure plan (E), either a mental plan or a material plan that, by addressing necessary action and targeted concrete structure, assists in the realization (3).

The conception (7, 2) of any structure plan seems to be either based on something that has been proven to be wrong, hence the negative outcome of structure assessment (C) or to be right, the structure template (D).

Structure templates are structure styles, patterns and/or tactics, or combinations of those in the form of reference models, with both structure as state and as action, that have been recognized (6) as proven to be right for specific purposes based on the positive outcome of structure assessment.  Typical examples of structure templates in building architecture, styles in fact, are Romanesque architecture, Gothic architecture, etc.

Of course there is the action of selecting proper and/or recognizing improper structure templates and properly (re-)combining for the now targeted concrete structure, the conception (2, 7) of the structure plan.  Hence it is in this action that the purpose of  the targeted concrete structure is to be taken in account.

Concrete structure is often difficult to understand, especially when it is at least in part result of emergence for which obviously no structure plan can be available.  Hence, it is appropriate to analyse (4) concrete structure in order to build an understanding through the creation of a structure model (B).  Structure plan and structure model can show similarity only when the concrete structure is highly engineered.  Anyhow, the structure model will only offer a representation based on specific concerns, a simplification for the further purpose of either single or comparative assessment (5).  Single assessment can lead to re-engineering so to better align structure with purpose.  Comparative assessment can lead to the recognition (6) of structure templates.

The words design and architecture are used as being all of the above, as the concrete structure, the structure plan, the structure model, the structure assessment and the structure template, as well as the practice of conceiving, realizing, analysing, assessing and recognizing.

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!