Rants are Useful

Are you annoyed when you stumble across yet another rant that appears to be full of emotion but is hardly presenting any insight in how it should bring any other relief than channeling the originator’s frustration? Or is simply hinting towards how ignorant the “others” are?

I am. And by experience I know I am hardly an exception.

Nevertheless a rant can be very useful, but on a condition, which is apparently quite counter-intuitive. A rant is an essential step in what should be a multi-step approach:

  1. Your frustration starts boiling. It is your moment of clarity for seeing the essence of the problem to its full extent! Keep your calm and interactive attitude, mitigate your frustration by thinking about and preparing for what you will do in step 2.The worst possible scenario at this moment is creating distance by becoming very outspoken. Preserve your frustration for the better. You are lacking the time for essential reflection at this point anyway. On the contrary, keep on challenging in a constructive way, listen well to what the others bring on and capture well what is going on, the positive and the negative. You need to go into learning mode. You will need a detailed understanding of the situation later.
  2. Write it down as soon as possible. It is your moment of clarity, right? Don’t let the clarity slip away. Writing it down is the ideal way of finding personal relief for your frustration and to avoid any premature sharing that you may regret later. There is your rant. Let it out.
  3. DO NOT SHARE/PUBLISH IT!!! You will annoy people! Resist the temptation!
  4. Let it sink. Reflection time! Add more detail and additional views when they come to you. At this point, you may also want to look for partners – not all likeminded! – with whom you can constructively and safely exchange views in order to better explore and understand the problem.
  5. If it is not worth gaining priority or you’re not willing to put any effort into doing something about what you are opposing, you can stop here and feel definitively relieved now.
  6. If it is and you are among the willing, you can continue:

    You will need to change your perspective towards the problem to a broader one, one that includes the people as part of the situation, yes also the so-called “ignorant others” that you will have to work with anyway!

    Only a solution approach that acknowledges that fact and addresses how to bring and keep people on board, can lead to real, long-term relief.

    Remember the situation. You will need the full understanding now. It will make clear where the real constraints are, and what can realistically be done. The solutions to our problems are inherently embedded in the problems themselves.

    If you are not yet familiar with the really magnificent classic book “Change: Principles of Problem Formation and Problem Resolution” by Paul Watzlawick, John H. Weakland and Richard Fisch, now is your opportunity to study it. It dates back to 1974 (and got a paperback reissue in 2011) but has not lost any of its relevance in getting a deep understanding of change as you intend to pursue.

  7. Form a better understanding of the problem in its entirety
  8. Build your problem resolution strategy

Unfortunately it often goes wrong in step 3.

Pragmatism as a Clincher

One recurring explosive argument in otherwise nicely going exploration debates is the word “pragmatism”. Architects love to explore, and know all about so-called “pragmatism”. They know all too well how disconcerting the word can be. It is not seldom the word that just prevents architects from doing what they actually need to do.

Pragmatism seems to resonate with everyone, but no one feels really happy when the word is thrown into a debate. The experience is as if a big boulder is thrown in the vivid little pond that a debate was, with no water left.

Why is that? Because the word is a clincher, a meaningless argument but with serious impeding effect.

Pragmatism is not an absolute but a relative measure. What is pragmatic in one context can be totally unreasonable in another one and vice versa. Moreover the measure seems to be very subjective. Pragmatism is what holds utopians from chasing illusions as well as visionaries from achieving astonishing results.

Of course, architects are not without blame.  They should take the usage of the word “pragmatism” as a signal: a signal for a lack of preparation; a signal for not having thought through, and gained the necessary support for the constraints of purpose, effectiveness , efficiency and timeliness in exploration.

Pragmatism is actually the word used to argue the shift from “exploration” to “exploitation” when sound reasoning in the form of formulation of constraints is absent.  The word makes the shift happen but not necessarily at the right moment. When used, the closure of exploration is likely to happen in an ad hoc, hasty, incoherent manner.

To avoid the argument from being used, prime concerns on the mind of the architect should be:

  1. What is the purpose of exploration?
  2. What is the fit-for-purpose to be reached? In terms of what is considered sufficiently effective?
  3. What is the (supported) capacity for exploration? In terms of resource usage that is still considered sufficiently efficient?
  4. What is the requirement of timeliness?

One should thereby keep in mind that one needs a necessary degree of inefficiency to be effective. Or as Einstein once declared, “Creativity is the residue of time wasted.” (Lehrer, Jonah. How To Be Creative.)

Especially the neglect of (supported) capacity and timeliness appears to be a key reason to call in “pragmatism”. And meeting timeliness might mean that what is considered effective, needs to be more relaxed at first, possibly through intermediate results to be further improved, so to reduce to results that are feasible in a timely manner, or simply to maintain the necessary support.

Really tackling the trap of pragmatism requires architects with an ability to explore with long-term, focused and coherent foresight as well as an ability to produce intermediate outcomes, ready for exploitation, that stand the test of longer-term validity for the significant part:

Wouldn’t capacity and time for exploration be used more optimally and the proper moment for intermediate closure be more clear without calling in “pragmatism”, if above 4 questions got answers first?

Let’s get rid of pragmatism as a clincher!

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:

structure dissected

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.