Monday, 27 May 2013
Wednesday, 22 May 2013
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.
Saturday, 18 May 2013
Many organizations are looking for ways to improve business agility and innovation enabled by information technology. Moreover, they are concerned about the increasing Cyber Threat, to core business systems, that comes with new technologies.
The need for 'Business Agility' in this area was demonstrated, when Cathay Pacific introduced new seats in the economy class cabin. They received overwhelming feedback that their new seats were uncomfortable and many passengers complained of back problems after long-haul flights. Passengers started to vote with their feet. While this was clearly and expensive lesson in 'User Experience' testing, commercial disaster was averted by their ability to react quickly. This was only possible because the sub-system in question had been specifically designed to be easily swapped-out - it is an inherently agile system that can be described as having a 'Safe-Fail' quality.
Going back to the organization as a Complex System, identifying the fundamental characteristics of the sub-systems of people interacting with technology within an organization is critical to understanding how the correct balance of agility, robustness and resilience is achieved across the whole the enterprise. As has been said many times before, one-size-doesn't-fit-all! (i.e. we're an 'SAP shop' so let's use their products wall-to-wall!). Understanding that starts with knowing the outcomes to be delivered by each sub-system and how they work together to deliver safe, secure, and at the same time, flexible systems.. In the context of Business-Technology, this understanding can only be gained through insightful and informed, whole-business design, that understands the behavior of the business as a combination of people, process and technology. This, in my opinion, should be a primary focus of Enterprise Architecture. Critical design patterns are often overlooked when the notion of Analysis and Design is limited to project-led solutions, that at best, describe the desired features and functions of a narrow 'User' community. This has not been helped by the IT industry's constant ability to misappropriate such terms as Agility, Service Orientation and spin-off into, often faddish, ill defined concepts like Cloud computing and BYOD.
Like Mr. Bloomberg, I believe it's now time to re-think what a Business-Technology Architecture needs to deliver. Many of the original concepts of the thought-leaders in Enterprise Architecture are still very relevant - Jason makes that point the the original idea behind SOA (Component-Based Architecture) are even more relevant today and he airs his frustration with IT software vendors' re-badging of middleware as 'SOA' - all but destroying the original concept. There are many other examples. However, he and are are not alone in our belief that understanding organization as a 'Complex System' is vital today. Others like Tom Graves, Richard Veryard, Chris Bird, Darrach Ennis, Simon Wardley and Sally Bean have been banging this drum for many years!
This is a big subject and I recognize that this is a very 'What' rather than 'How' focused post. I'd be happy to take the discussion further and share ideas on how I'm starting to make-sense of the Business-Technology challenges I'm facing in my day-job - ranging from core SCADA systems to Consumer-led IT and the 'Cloud'. As always, I'd be delighted to hear your views, builds and challenges to this post!
A much earlier related post here.
Thursday, 9 May 2013
In the process of developing a Business-Technology Strategy, I wanted to create Gamestorming-like approach to help position business drivers, technology trends and IT responses. I've been reading 'The Agile Architecture Revolution' by Jason Bloomberg (highly recommended!) - I particularly was inspired by the Zapthink Poster therein. But given the different audience, I need a more Business-focused that might eventually evolve into a info-gram poster ( I recognise it's more Mindmap than info-gram in this version!). The aim is to create a tool that will help frame and stimulate discussion with business people and technologists that becomes the core of a Business-Technology strategy. Subsequently, the developed artwork (or simplified versions) might become a commonly understood reference model for communicating the strategy - maybe even a piece of office wall-art!
Hopefully, the diagram I've developed is self explanatory, however, a few words of explanation might be helpful:
- The star at the centre should be the "headline" of CEO's strategic direction over the period (e.g. to 2018) or similar agreed at the C-level.
- The items in blue circle are the specific business drivers - the things C-level care most about!
- The six labelled outer sections are general technology trends that the CIO/IT team believe are most pertinent to the business.
- The items red circle are the IT responses to both the inner business direction & drivers in the context of the technology trends.
- In this example, the buff coloured encircling arrow represents the importance of "Big Data" overall and how data-driven decision-making will be fueled by other technology trends (I guess this might vary from business to business).
- The orange "explosions' are specific predicted events within a trend, the yellow "post-its" are aspects/observations and the green "scrolls' represent particular milestones or goals.
I'd welcome any thoughts, builds or alternative ideas - maybe you have a better approach or can offer something to augment?
Oh, and one more ask, if anyone knows of a low-cost way to make the poster less "PowerPointy" and more "Infogramy", please Tweet me (@taotwit) with suggestions - thanks!
You can download a more readable .pdf version below. Let me know if you'd like an editable .ppt version via email.