Nigel Green

BREXIT – A story of unintended consequences

by
On Cameron’s performance: 

“Referenda are the nuclear weapons of democracy. In parliamentary systems they are redundant. Seeking a simplistic binary yes/no answer to complex questions, they succumb to emotion and run amok. Their destructive aftermath lasts for generations”

“In any referendum over separation, the “independence” side appeals to the patriotic heart. The thinking of the Leave side is magical. It plucks at a dimly remembered but glorified past (that was never as good as nostalgia makes it), and offers a future that is imaginary. The Brexiteers are the dog that caught the bus: they hadn’t thought what to do next. Coping with impending difficulties is for another day”.

“You needed to be candid that Britain would be at a disadvantage in a negotiation to leave the EU because the EU has the trump of being less dependent on the UK than vice-versa. You avoided saying so, perhaps because it could sound wimpy or “defeatist” about British stature and weight. You let the Leave side get away with claiming that the EU would negotiate as an equal partner with equal stakes as the UK because the volume of trade was roughly equal. The reality is that respective stakes are starkly unequal. On trade, the UK is dependent on the EU market for 45 percent of its exports. The EU is dependent on the UK for only 8 percent of EU exports. Foreign investment into the UK has stopped because of uncertainty that UK exports will still get to the EU market. The Confederation of British Industries therefore judged that Brexit will cost 4-5 percent of GDP. The Economist Intelligence Unit is even more harsh”.


Please read the whole article here:

https://www.opencanada.org/features/brexit-post-mortem-17-takeaways-fallen-david-cameron/

HK Computer Society Event: Microservices, Cloud, EDA and next practice architecture

by
EASIG of Hong Kong Computer Society Speaker Session: 


“Digital Transformation & Architectural Implications”


(12th July, 2016) 

Nigel Green: 5Di Ltd (UK) & CIO Connect Hong Kong Associate

In this session Mr. Nigel Green will share his experience of preparing organisations for the Digital World. He will introduce key concepts that help open-up the discussion of the implications, risks, 
and opportunities, of a digital strategy. He will also share some of the design patterns he uses in the transformation to “Digital”.

Topics covered in session: 

• How a major European Retailer is approaching their digital transformation and the tangible business benefits of their architectural approach. This will cover both business and technology architecture implications, and will include perspectives on the Micro-services pattern adopted by the “born digitals” (e.g. Netflix, Google, and Amazon).

• The dangers of “Big Design Up Front”, and perhaps paradoxically, why “Adaptive Design” is ever more crucial.

• Subject matter experts to track, follow-up research material, and next steps to take.
Event Details: 

Date:12th July, 2016 (Tuesday)

Time: 19:00-20:00

Venue: P304, Anita Chan Lai Ling Building, The Hong Kong Polytechnic University [Map]

Seats: 50

Fee: Free
HKCS (Fellow/Members) & AEA-HK members*: Free of charge
Non-members: HK$50
* Seat is subject to availability and priority will be given to HKCS member

Evolution Architecture

by

Caoilte O’Connor is a developer at ITV, the UK’s largest Commercial Terrestrial TV Network. Here’s a short  (~2 min) clip from Domain Service Aggregators: A Structured Approach to Microservice Composition . In this clip he describes how …

Designing Digital Change

by
Session Synopsis for Hong Kong, April 2016: 

In this session Mr. Nigel Green shares his experience of preparing organisations for the Digital World. He introduces key concepts that will help open-up the discussion of the implications, risks, and opportunities, of a digital strategy. Whilst the popular definition of “Going Digital” is often focused on digital channels for Marketing purposes, Mr. Green explains why it also impacts many areas of the organisation, and explains why it is not simply the CMO’s, CDO’s, or CIO’s challenge alone. He will also share tools and techniques used in the design & execution of the transformation to a digitally enabled business. In addition, he will discuss pragmatic next steps to take, and share ideas on how to contribute to a business-wide discussion on the subject.
This session should be of interest to anyone trying to get to grips with what “Going Digital” means to their organization, and how to start planning the change:
  • The components of a digitally-enabled Business Model
  • The implications & risks of adopting “Bi-modal IT”
  • How to design for the protection of existing core business systems whilst embracing the new
  • Dealing with an unknown future, and adaptive long-range planning
  • The dangers of “Big Design Up Front”, and perhaps paradoxically, why “Adaptive Design” is ever more crucial
  • The business and technology architecture implications – including a perspective on the applicability of a pattern adopted by the “born digitals” (e.g. Netflix, Google, and Amazon)
  • Suggested subject matter experts to track, follow-up research material, and next steps to take.

Designing Digital Change

by
Session Synopsis for Hong Kong, April 2016: 

In this session Mr. Nigel Green shares his experience of preparing organisations for the Digital World. He introduces key concepts that will help open-up the discussion of the implications, risks, and opportunities, of a digital strategy. Whilst the popular definition of “Going Digital” is often focused on digital channels for Marketing purposes, Mr. Green explains why it also impacts many areas of the organisation, and explains why it is not simply the CMO’s, CDO’s, or CIO’s challenge alone. He will also share tools and techniques used in the design & execution of the transformation to a digitally enabled business. In addition, he will discuss pragmatic next steps to take, and share ideas on how to contribute to a business-wide discussion on the subject.
This session should be of interest to anyone trying to get to grips with what “Going Digital” means to their organization, and how to start planning the change:
  • The components of a digitally-enabled Business Model
  • The implications & risks of adopting “Bi-modal IT”
  • How to design for the protection of existing core business systems whilst embracing the new
  • Dealing with an unknown future, and adaptive long-range planning
  • The dangers of “Big Design Up Front”, and perhaps paradoxically, why “Adaptive Design” is ever more crucial
  • The business and technology architecture implications – including a perspective on the applicability of a pattern adopted by the “born digitals” (e.g. Netflix, Google, and Amazon)
  • Suggested subject matter experts to track, follow-up research material, and next steps to take.

Going Digital & Agile Architecture

by

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.

Design Patterns for Event-driven Distributed Intelligence

by
Following discussions with @seabird20  and @darachennis, among others last year. I decided to publish a rough idea of the event-driven Distributed Intelligence architecture for Smart Grid (this could apply to the broader IoT). This is loosely-based on the microservices concepts & principles described here and builds on Duke Energy’s collaboration on interoperability and distributed intelligence initiative. The purpose of this post is to generate ideas and aid the ongoing dialogues. As far as I’m aware, the additional concepts I discuss here; SEDA, microservices and distributed agent patterns, are not  called out in the Duke Energy work (although the authors might reasonably claim they’re implied). My aim, however, is to make the ‘software and event data’ conceptual architecture much more explicit in this discussion.
Having said that,  the  first diagram looks pretty physical! It serves as a simple IoT-ish context: A metering sensor talks to an edge processor on a ‘Field Area Network’ and thereafter data is relayed back to the Data Centre for further processing.

In the 2nd diagram we open up the Edge Processor and to reveal a relatively simplistic view of the software architecture. This is based on the micoservices pattern described by Fred George, and my own experience as VP Product Development/Architect at VI Agents.




I found the concept of small, autonomous agents, work very well for us at VI. Moreover, I spotteda lot of parallels with Fred George’s description of microservices:

Publish anything of interest – don’t wait to be asked, if your microservice thinks it has some information that might be of use to the microservices ecosystem, then publish-and-be-damned.



Amplify success & attenuate failure – microservices that publish useful information thrive, while those that left unsubscribed, wither-on-the-vine. Information subscribers determine value, and value adjusts over time/changing circumstances.



Adaptive ecosystem – versions of microservices are encouraged –may-the-best-service-win mentality introduces variety which leads to evolution.



Asynchronous & encapsulated – everything is as asynchronous as possible – microservices manage their own data independently and then share it in event messages over an asynchronous publish-subscribe bus.



Think events not entities – no grand BDUF data model, just a cloud of ever-changing event messages – more like Twitter than a DBMS. Events have a “use-by-date” that indicates the freshness of data.



Events are immutable – time-series snapshots, no updates allowed.


Designed for failure – microservices must expect problems and tell the world when they encounter one and send out “I’m alive” heart-beats.



Self-organizing & self-monitoring – a self-organizing System-of-systems’ that needs no orchestration. Health monitoring and other administration features are established through a class of microservices.



Rapids, Rivers & Ponds
I also particularly liked Fred’s use of the labels Rapid and Rivers to describe two seperate instances of message brokers and Ponds to describe persisted data. Again very similar to the VI SixD architecture where we collected signals on a ‘Rapids’ bus and  business event & document messages flowed over a ‘Rivers’ bus, and Event Logs & Document Queues were our  ‘Ponds’. But that was back in 2002,  I do think the microservices pattern is much more elegant and more extensible.


Staged Event Driven Architecture
The 3rd diagram overlays what I see as the SEDA Stages in our Smart Grid architecture:

Stage1: Raw signal filtering, simple aggregation& correlation, negative-event detection etc.

Stage2: Goal and role based functionality via an ‘Edge Agent’ that does complex aggregation and correlation, sense-making and alerting. These might be implemented as microservices, or at least, share many of the attributes described by Fred.


Stage3: There will  be more aggregation & correlation, routing alerting and broadcasting done here. The junction of Information Technology (IT) and Operational Technology (OT)  is probably here. These are the the software components that sit back at the Data Centre, that receive and process the event messages produced by the ‘Edge Agents’. There’s also a nod to some sort of management console and the publishing of commands and requests to the ‘Edge Processing’ domain. This diagram is very sketchy right now, with loads of components missing.   I just want to keep things very simple at this stage. 

Stage4: This is where the  ‘Big Data’ heavy-lifting of historical data and predictive analytics stuff is done.

We used  the SEDA pattern to define an Events Network that was capable of processing 4bn events per day without having to invest in massive network bandwidth and huge back end processing capabilities for the Royal Mail – I believe the U.S. postal service didn’t implement a SEDA  and  throw a huge amount of cash at the problem. I love the elegance of a series of cascading queues that gradually whittle the tsunami of raw signals in real time, down to ‘right-time’ stream or tap of business-meaningful messages.



This is the early stage thinking and part of a much bigger Smart Grid, and ultimately Smart City architecture. Please feel free to tweet about. or better still, comment below. Thx.

What’s A Strategy?

by

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’).

Addendum:
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”.

What’s A Strategy?

by

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’).

Addendum:
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”.

A Wiggly Path To Transformation

by

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

And:

“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,