Wednesday, 22 May 2013

Searching for Agility and Industrial Strength? - Part II

This is Part 2 of a discussion started in my last post. The discussion is around the need for Agile, Resilient and Robust systems within an Enterprise Architecture. This post is a detailed response to Adrian Apthorp's  comments and, more generally, comments from Chris Bird and Tom Graves (Thanks all).

Adrian said:  At the recent Integrated EA conference Tom Graves spoke about the notion of backbone and edge. The backbone being where the core robust and resilient elements sit and edge is the playground that enables agility. This division in itself implies / demands different 'engineering' practices to deliver backbone vs edge elements - may be one clue for the organisation of IT to deliver against these different demands.

I like Adrian's words: "edge is the playground that enables agility" and would add: "edge is also the playground that nurtures innovation". This is probably, in part, due to my frustration with trying to explain the true nature of innovation and to get people to understand that new IT gadgets do not bring about innovation on their own. Innovation is not something bought, it is something grown within the business by allowing people to experiment in a 'Safe-Fail' environment.

Adrian said:  The key question of course is how do you determine what sits in the edge and what in the backbone? This partitioning is of course down to architecture, but how do you go about it?

It's interesting that you should use the airplane example, certain aircraft (e.g. 747) are a good example of an architecture that has persisted over time, but virtually every part has changed. This illustrates the fact that even the robust and resilient elements change within the context of the whole. Don't forget the architecture of the aircraft goes beyond the airframe to include the design of airports etc.

Adrian also said:  The overall architecture of your system of systems provides the basis of the backbone and is populated by elements that don't change or have low rate of change. Chris Bird talks about shearing layers, I like to think about pivot points I.e. the stable parts of the architecture that change can be managed around. 

To put it in business terms these are the elements that define our business and if we change them we're in a different business or at least have major upheaval? 

In reply to Adrian's point that everything can change, even the more stable aspects of a system over time, I agree that entropy applies to everything but how we deal with change can differ significantly based on business needs: response to market, customer safety,  brand  et al. But, the context of 'the whole' in question must not be lost or confused. To this point, I wouldn't say that the architecture of the Complex System called  'aircraft' includes the design of airports, per se, rather, that the system 'aircraft' exists in a environments that include 'airports', 'weather', 'tourism' etc. Of course, one can see these as an infinite Russian-doll-like of Systems-of-Systems, but this rapidly becomes unhelpful. 

I believe the most fruitful to define the boundary between a 'System-of-the-Business' its environment by a current and planned view of the business. That is, the 'System-of-System' that is defined by the Business Operating Model, its Enduring Purpose (relates to the 'pivot-points' described by Adrian) and the current Centre-of-Gravity of the executive board (the strategic things they currently care about the most). This way, the boundary for the architecture can flex to encompass those aspects most germane - so if, in the analogy, understanding the deeper relationship between the system of 'aircraft' and the system of 'airport' is important to the future architecture, it's included.  Under different  circumstances, however,  it may be more important to understand the system of 'aircraft' in the context of the system of 'tourism', in which case, the system of 'airport' much just be recognized as a set of environmental constraints, with greater emphasis on the system of 'tourism'. End of analogy!

I find it useful to explore the Agility, Resilience and Robustness as potential 'Design Principles' for different aspects of the architecture. For example, it may be  that Agility is a core principle for mobile apps and SaaS. In contrast, however, Robustness might the most important characteristic of a system that has life-impacting consequences in the case of failure. 

It seems that the need to design Resilient systems rarely understood today but will become increasingly important. I believe that such systems require a meta-architecture (as described in Jason Bloomberg's book): an architecture that is specifically designed to cope with multiple business purposes that cannot be fully described at design time but should not be regarded as be designed/developed in a 'agile', experimental fashion.  An example of this was DHL's Track & Trace architecture designed in the1990s. This was designed as a set of simple services with flex and adaptability - this was the key to adoption through local adaption and extensibility and, ultimately gave way to local 'agile' innovation. While  a core set of 'Global' tracking checkpoints were defined the meta-architecture allowed for 'Local' extension without corrupting the core standards. This also had the effect of 'protecting' other core 'backbone' systems that produced, consumed and transported shipment status information.

Using Tom's definition of 'Edge vs Backbone', it seems to me that Resilient systems sit in the land between the two. They are the 'elastic surface' that allows for 'edge' agility and that acts as a membrane that helps protect the 'backbone'. The need for Resilience, in my opinion, was always a key objective of Service Oriented Architecture.




2 comments:

  1. "Architecture for resilience rather than robustness" and much more - video from Dave Snowden - worth the 40 min investment. Specific Resilience v Robustness points @ around 15:30.

    "Resilience: Early detection, fast recovery and fast exploitation. We must architect on the assumption of failure rather than success

    ReplyDelete