Thursday, 7 July 2016

BREXIT - A story of unintended consequences

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:

Tuesday, 21 June 2016

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

EASIG of Hong Kong Computer Society Speaker Session: 
“Digital Transformation & Architectural Implications”
(12th July, 2016) To Be Confirmed

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

Friday, 3 June 2016

Evolution Architecture

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 they evolved a Microservices architecture at ITV. Note his comment about working with the "architect"...


This style seems consistent with Gunnar Menzel's recent post: "The New Role of the Architect". On reading his more detailed paper on this subject, I am, however, less convinced that TOGAF or IAF will be fit-for-purpose in the new world order.  

I'm seeing a trend towards a new breed of architect; one that delivers "Just Enough Architecture - Just In Time", as one client calls it, and another,  "Minimum Viable Architecture". It seems to me that the role of the "architect/design authority" has never been more important, and yet, so called "Best Practice" methods and frameworks seem unhelpful at best, and trust-destroyers, at worst.

Also, great stuff from ThoughtWorks on "Evolutionary Architecture", when you have 18 mins to listen: here 

Is the new EA and "Evolution Architect", and is she/he more a Systems Thinker than a TOGAF practitioner? Is the architect's toolset predominantly a whiteboard and a set of pens?

Post Post:

An upcoming session at IRM EAC/BPM conference in London on 13th June:

Outcome Driven Architecture

John Slater, Senior Manager Group Retail Strategy, Nationwide
Mike Clark, Business Designer and Digital Technologist, Cohesion 360 

"Historically organisations have struggled to strike the balance between delivering at pace and building a sustainable architecture. In most cases this results in either a solution that can't be scaled or one that goes over budget, delivers late and fails to meet the desired customer and business outcomes. Using a traceable outcome driven approach to connect the business goals to the machinery of the organisation and following MVP (minimal viable product) and MVA (minimal viable architecture) principles, enabled Nationwide to co-create new features with customers and colleagues, test their impact against a consistent group of value measures and iterate, pivot or scale & roll-out at pace, whilst still building a cohesive architecture".

Thursday, 24 March 2016

Designing Digital Change

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.

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 recognize 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 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 behaviors”.
" makes more sense for them to pay most attention to the real-world  ‘wiggliness’ of organization: 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? :)

Monday, 8 June 2015

Design Patterns for Event-driven Distributed Intelligence

Following discussions with   and , 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.