Tuesday, 1 September 2015

Going Digital & Agile Architecture

Recently, I've been reworking & tightening up some earlier ideas and putting them in a ‘Going Digital’ context. I’m posting them on LinkedIn to reach a slightly different audience.  
Here are the posts so far:

During the process, I’ve been reading/re-reading some great related articles that discuss agile architecture and the need recognise the business as a complex adaptive system. Here are the links with some favourite quotes:

Is Agile killing EA #1?  By Charles Betz "the EA team needs to match the cadence of the Agile teams. This is a central challenge".

Is Agile killing EA #2?  By Jason Bloomberg.

" ...if some company’s EA means nothing more than a lot of paperwork that gets in the way of basic goals like working software that keeps customers happy, then we can only hope Agile drives a nail into that coffin. On the other hand, sometimes the paperwork is a good thing. Only an overly dogmatic reading of the Agile Manifesto would lead one to conclude that we don’t need no stinkin’ documentation".

“Frameworks are cocaine for executives – they give them a huge rush, and then they move to the next framework”.

Enterprise Architecture Finally Crosses the Chasm by Jason Bloomberg including an interview with Adrian Cockcroft formally the Cloud Architect at Netflix. 

“The goal of architecture was to create the right emergent behaviours”.
"..it makes more sense for them to pay most attention to the real-world  ‘wiggliness’ of organisation: the hidden, messy and informal dynamics of everyday human interaction in which they and everyone else are continuously immersed".

With the 'Going Digital' series, my aim is talk about real-world experiences and emerging techniques for doing "agile architecture', or business change design, or whatever it gets called in the future. All I know is that it isn't framework-centric and that many who carry the title Enterprise Architect will have trouble giving up their particular drug of choice! I’m interested to hear what others are doing; what’s working for you - and what doesn’t.

I guess like many of have lived with the 'EA' label, I'm tending to avoid the term, so as not to confuse what I do with the framework-centric, heavy modelling, and 'certified' practices stuff.

Has anyone seen a good job description? :) 

Update Feb 27th, 2017: To see where these thoughts now are going, please take a look at the Found In Design un-book and  the Horses and Unicorns story.

Tuesday, 3 March 2015

What's A Strategy?

 Link to article
Recently, I was asked this simple question: What is a strategy?

According to this article a business strategy is: the result of choices executives make, on where to play and how to win, to maximize long-term value

Which seems reasonable enough definition, for the CEO, but doesn't really help those who need to think strategically about other initiatives,  like, for example,  business change programmes. 

Here's some thoughts on what a strategy is, and what it isn't:

A strategy:
- Tells a story
- Is future focused
- Can apply to short, medium on long term futures
- Provides focus on what is important (and what isn't)
- Is actionable
- Is a framework for decision-making
- Is holistic - considers changing environment & external events
- Examines alternatives
- Assesses risks
- Takes step back from Business As Usual - it is an abstraction from the current operation
- Can be emergent and living: will undergo revisions and course-corrections.
- Is a reference point for dealing with emergent change
- Is 'WHY', 'WHAT', 'WHEN' and 'HOW' focused. The 'HOW' in a strategy is a 'Meta-HOW':  often speaking to unknowns and unplanned (unknowable) events. The 'WHEN' is often more sequence focused than time-definite
- Is a choice

What a strategy isn't:
- A detailed plan of activities
- A grand design
- A set of desired aims/objectives ( although these might be the basis)
- A mission statement
- A budget plan
- A collection of pre-determined projects
- A list of possibilities (technology-based or otherwise)
- Only applicable to 'big' or 'long-term' change (things often labelled as 'strategic').

I recommend reading Roger Martin's wise words on the subject of Stategy.  A few quotes from his post:

"The problem with a lot of strategies is that they are full of non-choices. Probably most of us have read more than a few so-called strategies that say something like, "Our strategy is to be customer centric." But is that really a choice?"

"I would argue that 90 percent of the strategic plans I've seen in my life are really more accurately described as budgets with prose".

"If you're into destroying innovation, two words—"prove" and "it"—will do the trick".

Sunday, 1 March 2015

A Wiggly Path To Transformation

According to Sunday Times journalist, Carly Chynoweth, “Managers must learn how to adapt so they can solve problems they haven’t faced before.”


“The fundamental impression they give is that the future can be organised and managed to achieve what you set out to achieve, and as long as you do it right it will come out as planned. But the reality is much more complex. Organisations are wiggly. They don’t operate in the neat, straight-line way conventional management thinking assumes”.

“It is not possible to predict outcomes — they emerge from people’s actions. You might have plans about what you are doing, but so does everyone else.”

The culture and traditions of 100 year old Utility business make behavioual change hard. Power-plant Engineer's detailed and precise planning techniques don’t work for this sort of long-term change. In our case, over 70% of the business processes will change. The main hurdle for us was the lack of certainty and predictability over 5, 10 and 20 years. It was impossible to answer the basic questions; when, how and how much? There was discomfort over sanctioning any plans without the ‘details’. This resulted in a period of ‘decision-making-block’.

This is when we introduced ‘Transition State’ planning. This borrows ideas from Complexity Theory: Specifically, the characteristics of Complex Adaptive Systems. We started with the premise that we cannot predict the long range future.  We also accepted that outcomes will emerge at various points along the way.

Much like ’Scenario Planning’, we first developed a few hypothetical ideas. These were refined in workshops with subject experts until we reached a reasonable consensus of:
  • the principles we will apply to different aspects of the transformation ahead of us,
  • an initial guess of when certain outcomes are needed,
  • a list of the main influencing events/decisions assessed as ‘Known’, ‘Unknown’ or ‘Unknowable’ now – along with an assessment of risk.

Armed with this, we plotted-out a series of ‘Way-points’ over time. We call these ‘Transition States’. Each has a few goals (expected outcomes) that we estimate to complete.  At this stage, Transition States are not pinned to a hard date.  Rather they describe the sequence of outcomes, and roughly when we think they'll happen. Transition States are re-planning points; a time to reassess and re-estimate the next phase of work. The Transition State is an opportunity to amplify value-adding and extinguish value-detracting aspects.

After a few iterations, a more precise view emerged of the early Transition States and a traditional approach to planning and deliverables could be applied.

At first, we were quite concerned that this approach would be rejected by the culture; a plan must be very detailed and accurate before work can start. This, however, wasn’t the case, decision-makers could see the merits of a more agile and iterative approach to complex change. They liked the way ‘doable’ increments became clearer after a few iterations. They also liked the explicit opportunities for re-think and course-correction.


Is a Complex Adaptive approach the only way to manage large-scale, long-running, change? I’d like to hear how others approach designing and managing business transformations and whether they see the merits of Complexity Theory that we've seen,