16 July 2016
I had an interesting conversation recently about the use of Wardley maps as part of an Enterprise Architecture and Digital Transformation programme recently. I had looked at using Wardley maps some time ago but now I think it is a good time to incorporate their use into normal Enterprise Architecture/ Business Architecture work. They are a very useful addition to the bag of techniques and approaches that I recommend should be used by Enterprise Architects working on the Strategy and Business Architecture domains as well as for the IT architecture domains.
Wardley Maps are useful for understanding the dynamics of what is needed to support a user’s needs. The underlying dependencies between user needs are constantly evolving and many organisations do not recognise this when they come up with a dry list of Business Strategies, Goals and Objectives using a Business Motivation Model. A Wardley map makes strategies much clearer and contributes towards better situational awareness which is critical.
When asked about their strategy the CxOs often simply mention similar lists of ideas that they see other organisations talking about and copy. Often they don’t really understand the buzz words. For instance, what does ‘Digital’ really mean? Is doing Digital sufficient to claim an innovative advantage in the blue ocean? A situational Awareness map will help visualise the buzzwords and their relative importance. It will also allow the organisation to better understand where it can gain an advantage.
Wardley maps help to position the user needs and dependencies in a continuum from the genesis of an idea through to the commoditisation of the same idea, at the same time as creating a value chain as a directed graph and not just as a high level list of business functions. The Wardley map combines the Value chain view with an Evolution and dependency view which helps to identify where the strategies (Both Business and IT) should attack to produce a competitive advantage.
Upstream of Wardley maps, User needs can be identified from modelling Business Scenarios and Customer Journeys. It will be very likely that multiple Wardley maps will be needed.
The dependencies between user needs is similar to the dependencies that can be identified between Business Capabilities. Also the provision of Value to a customer is also the outcome of a Business capability. I can easily see a mapping between a grouping of Business Capabilities or groupings of dependencies between Business Capabilities and a a set of Wardley Maps.
Capability Increments can map to groupings within a Wardley map and dependencies between User needs can be associated with dependencies between Capability Increments.
These complementary techniques will reinforce each other and ensure the resulting EA Roadmap of Initiatives and subsequent Project roadmaps will be well designed and stay meaningful and relevant.
Obviously it is important to remember that the evolutions of user needs identified in a Wardley map are dynamic and the resulting EA roadmaps also need to be constantly kept under review, as business and IT trends evolve.
The best strategy is one that can help identify where to attack when things change.
10 January 2012
I’m often confronted by solution architects, IT and technical architects who don’t understand what Enterprise Architecture is all about. They usually misinterpret enterprise architecture from their own perspective as some kind of system design of ‘enterprise’ scale IS/IT systems and become frustrated when they discover that it is really something else. It often turns out that they are not usually working at the right level or with the right stakeholders in their organisation to be true enterprise architects. They are not working with the leadership team but within the scope of a small development project.
They can’t therefore see the wood (the ‘Enterprise’) for the trees (a project), let alone the helicopter view…
Enterprise architecture is in reality one of the most powerful management approaches that can be used by an organisation. It is not intended to be used (only) at a solution or project level but for the big decisions that an organisation’s leadership team have to make. The leadership (i.e. the C-level executives, and heads of divisions etc.) have to make the decisions based on the facts and knowledge base (the Enterprise Architecture repository) delivered by the enterprise architecture function. Those decisions are supported by the enterprise architecture function planning their execution in the EA roadmap. Each initiative in the EA roadmap is typically a new or changed Capability or Capability Increment (see MODAF and http://www.mod.uk/NR/rdonlyres/E43D93F6-6F43-4382-86BD-4C3B203F4AC6/0/20090217_CreatingCapabilityArchitectures_V1_0_U.pdf).
Typically the focus of Enterprise Architecture is on:
- Increasing the return on business and IT investments by more closely aligning them with business needs.
- Identifying areas for consolidating and reducing costs
- Improving executive decision making
- Increasing the benefits from innovation
- Delivering strategic change initiatives
- Managing business transformation activities
The Enterprise Architecture is also characterised across the following multiple dimensions:
- Direction: Enterprise Architecture is focused on strategic planning (i.e. business transformation, strategic change programmes) and not on operational change (i.e. run the business, six sigma, lean processes)
- Scope: Enterprise Architecture is focused on the whole of the business (i.e. the Business Model and Business Operating Model) for all business and IS/IT functions, and not just on the IS/IT components.
- Timeline: Enterprise Architecture is focused on the long term view of the future scenarios (up to 3/5 years in the future) and not just on a short term view of current state. Enterprise Architecture is focused on a roadmap of changes to an organisation’s capabilities.
- Value Chain: Enterprise Architecture is focused on the whole of the enterprise (i.e. the extended organization and value chain) and not just on the scope of a delivery project
- Stakeholders: Enterprise Architecture is focused on the needs and concerns of the C-level executives (CEO, CIO, COO etc.), business executives, corporate and business strategists, investors, strategic planners.
(ps. I tried to draw a diagram to illustrate where Enterprise Architecture lies on these dimensions but couldn’t visualise a multi-dimensional space…)
So overall, the primary purpose of Enterprise Architecture is to support strategic change such as :
- The introduction of new customer and supplier channels such as eCommerce
- The consolidation of the existing portfolio of people, processes, application and infrastructure etc.
- The reduction of costs and risks, ensuring the enterprise will remain viable and profitable
- The design of a new organisation, business model and business operating model.
- The due diligence for mergers and acquisitions and management of the resulting integration programme.
- The development of smarter and more effective systems (not just IT systems).
- The introduction of shared services and applications.
- The introduction of new technology, platforms and infrastructure such as SaaS, Cloud etc.
- The introduction of regulatory and legal changes such as Basel 3
In my future blog entries I will explore how Enterprise Architecture supports some of these areas.
The first one will be about how Enterprise Architecture is used to support Due Diligence activities prior to mergers and acquisitions.
11 November 2011
Enterprise Architecture is all about supporting strategic planning and business transformation activities, although many organisations seem to almost wilfully forget that this is one of the main purposes of Enterprise Architecture if not the most important one.
A business strategy is a long-term plan of changes for the whole enterprise which will address things like offering new products an business services, dealing with new customer or market segments, opening up niche opportunities, growth via mergers & acquisitions, cost consolidations and increased efficiencies. See http://en.wikipedia.org/wiki/Strategic_planning and http://en.wikipedia.org/wiki/Business_transformation
Enterprise Architecture primarily focuses on what an enterprise needs to do in order to stay viable, efficient and profitable in the future. In Viable System Model (VSM) terms, Enterprise Architecture is a System 4 type of system. See http://en.wikipedia.org/wiki/Viable_system_model
Enterprise Architecture bridges the gap between new strategy ideas and the execution of those ideas, in the same way that the intelligence corp in the military provide intelligence about current and future capabilities to the generals and ensure that the appropriate planning takes place in order to win the military campaigns.
Many organisations without an Enterprise Architecture function will risk failing to properly implement or deliver the on their business strategy.
It is frequently reported that many strategic ideas and initiatives identified by C-level executives are never properly implemented or seen through to full operation by the business units. That big picture of the business strategy on the white board in the CEO’s office or a high level presentation can look deceptively simple in a board meeting, but as they say ‘the devil is in the detail’. The C-level executives are responsible for seeing that the strategy is implemented, but it will be the Enterprise Architect that works out the detail.
Organisations need to know where they are now and create a baseline Enterprise Architecture model of their current state, then create a future target Enterprise Architecture model and do impact and gap analysis between them. The future state Enterprise Architecture model often needs to contain not just one single future target model but multiple complementary or competing models of the many future scenarios that are likely to have been developed using Scenario Planning techniques. See http://en.wikipedia.org/wiki/Scenario_planning
Strategic business transformation can be hard. Enterprise Architecture makes it far easier to answer questions such as:
- What Strategic initiatives are needed to fill the gaps found and address risks and issues?
- What new or changed business capabilities will be needed?
- What needs to be done when?
- How does one prioritise the different strategic business initiatives on an Enterprise Architecture roadmap?
- When are these investments in change going to be delivered?
- How will the initiatives be funded?
- What are the dependencies between the strategic initiatives?
- How will the business model be changed?
- How will the target Business Operating Model be changed?
- What organisation units and business functions need to be changed?
- What value chain and value streams need to be changed?
- What are the costs and potential revenues?
- How feasible is the business strategy?
- What feedback mechanisms between ‘systems’ will be needed?
- How will change be governed and how will compliance be assured? (i.e. how do we overcome resistance from difficult stakeholders, and the ‘Not invented here’ anti pattern?)
- What controls, KPI’s, CSF’s, incentives, bonus structures will be needed?
- What changes to the principles and standards will be needed?
- How do we align people, processes and technology?
- What other things have we forgotten?
I recommend reading the books:
- ‘Making Strategy Work: Leading Effective Execution and Change’ by Lawrence Hrebiniak and
- ‘Enterprise Architecture As Strategy: Creating a Foundation for Business Execution’ by Jeanne Ross and Peter Weill.
I am currently involved with the EAST group (an outreach group of SCiO http://www.scio.org.uk/ ) which is looking at the overlap between Enterprise Architecture and System Thinking, and in particular the Viable System Model (VSM).
The Viable System Model has been around for many years, coming out of Stafford Beer’s work http://en.wikipedia.org/wiki/Anthony_Stafford_Beer
This diagram looks complex at first but you can also read a very accessible description of the Viable System Model at http://www.scio.org.uk/resource/vsmg_3/screen.php?page=0cybeyes and at http://en.wikipedia.org/wiki/Viable_system_model
An excellent book to read is Patrick Hoverstadt’s book ‘Fractal Organization: Creating Sustainable Organizations with the Viable System Model’ See http://amzn.to/mjHz6F
But what is the Viable System Model?
The Viable System Model is a recursive view of five main systems within an organisation.
The word ‘System’ here doesn’t mean an IT system or an information system but has the more generic meaning of the word ‘System’. See http://en.wikipedia.org/wiki/System
Those five systems are concerned with the following functions and capabilities:
|System 5||Policy, ultimate authority, identity.|
|System 4||Adaptation, forward planning, strategy.|
|System 3||Internal regulation, optimisation, synergy.|
|System 2||Conflict resolution, stability.|
|System 1||Primary activities.|
System 1 systems within an organisation are realised by those organisation units that actually make products, deliver business services and create value.
System 2 systems are those organisation units that provide the coordination functions.
System 3 systems are those that provide the audit and operational control functions.
System 4 systems are those that look forward to the future and the external environment.
System 5 systems provide the strategy and business direction.
The Viable System Model is recursive so that the same five systems appear at all levels within an organisation, but it’s easy to see equivalent VSM systems at various levels in an organisation.
At at the top level it is possible to see that the Executive Board is a level 5 system, the general management are mainly level 3 systems, the system 2’s are the programme managers, project managers and solution architects. The system 1’s are the operational service delivery units and project teams.
Where does that leave Enterprise Architects? Well the Enterprise Architect function is essential a system 4 system with it’s focus on strategic planning for the long terms view and creation of roadmaps of strategic initiatives.
The strategic Enterprise Architects (system 4) with their long term, external and strategic focus work in co-operation with the Solution Architects (system 3) with their immediate operational, internal, lean, design and delivery focus.
It’s clear to see with our Viable System Model lens that solution architects and enterprise architects are not doing the same job but a completely different job.
From an Architecture Continuum perspective (TOGAF9 http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap39.html) then the Viable System Model is an example of a generic Foundation Architecture. and a thus a key architecture to reuse when designing organisation specific target enterprise architectures.
The SCiO group has developed the SCiO Organisational Maturity Model http://www.scio.org.uk/OMM which is based on the Viable System Model.
This can be used for assessing the strengths and weaknesses in your enterprise, looking at how efficiently it is working today, both in the immediate operational perspective but aslo the log term viability of your enterprise in the face of changing external market and business environment.
The on-line questionnaire for the SCiO Organisational Maturity Model addresses six aspects of the Viable System Model:
- Resource and Performance Delivery
- Managing strategy
The outcomes are expressed in terms of a measure of maturity across those six dimensions and a diagnosis of which Archetypes (i.e VSM anti-patterns) apply to your enterprise and which need to be addressed.
Unlike Lean manufacturing which only focuses on operational efficiencies in the the lowest level System 1, System 2 and System 3 systems within an organisation, the Viable System Model looks at the whole enterprise from a recursive perspective which is more sound and holistic.
In some ways it is surprising that it hasn’t yet reached a tipping point within organisations or their enterprise architects. Maybe this is because everyone is too focused on the day to day need for operational efficiency and approaches such as Lean Manufacturing (http://en.wikipedia.org/wiki/Lean_manufacturing) and forgets about planning for the future. This is the difference between being reactive and proactive.
and the excellent book: The Service-oriented Enterprise by Tom Graves, http://amzn.to/kAzR7F
The next time you are challenged on the purpose and value of Enterprise Architecture, then answer that it’s the difference between the external and future oriented perspective of the VSM system 4 as opposed to the inside and now, operational efficiency perspective of system 3 and service delivery perspectives of system 1 and 2.
As a system 4 system, the enterprise architecture function focuses on:
- Supporting the business strategy developed by system 5
- Analysing strategic change initiatives
- Planning and creating strategic road-maps
- Scenario analysis
- Assessment of future risk, agility and viability of the enterprise
- Coordinating with system 3 systems (i.e. portfolio and programme management, project management and solutions architecture)
- Governing the realisation of those strategic changes and development of new business capabilities.
The more one looks at the Viable System Model, the more it looks like the unifying theory behind Enterprise Architecture.
30 December 2010
We are used to the idea of a Programme/Project Management Office (PMO) but often organisations fail to understand (or perhaps deliberately misunderstand) what the Enterprise Architecture function does. I propose that the Enterprise Architecture function is, in effect, an Office of the CEO, or an Office of the CEO and Strategic Change Management.
The book ‘Enterprise Architect as Strategy’ (http://www.architectureasstrategy.com/book/eas/ ) gives us the right way of thinking and talking about what enterprise architecture is for – creating a foundation for the execution of the Business Strategy.
This book is an essential read for senior executives, business leaders and enterprise architects.
Many people within an organisation will understand the big picture view of the business strategy, such as the CEO of course, but perhaps only at a shallow level of detail.
Would the C-level executives understand all the potential nuances and wrinkles that come with that business strategy? Perhaps not unless they were a ‘details’ person.
What does the CEO do? They will spend time in evaluating ideas, formulating the mission and vision of their orgnaisation, innovating the business model to ensure the company remains competive in their market, looks for future opportunities for expansion and carving out a niche market.
It is the Enterprise Architect who has the job of maintaining the big picture on the behalf of the CEO, in sufficient detail to ensure that it becomes a knowledge base to support the executive’s decision making and help them to realise the business strategy and govern the implementation of that strategy.
In this way the Enterprise Architecture function is effectively the Office of the CEO, providing strategic support to the CEO and the other C-level executives. It’s also worth stating here that effective companies focus on enterprise architecture and don’t jump straight into IT architecture. Enterprise Architecture is not the same discipline as IT Architecture.
We can look at the the Enterprise Architecture function in terms of Deming’s Plan-Act-Do-Check process improvement process:
The CEO and other C-level executives will stablish the mission, vision, goals, objectives, principles and metrics to identify the main outcomes of the business strategy.
The Enterprise Architect will help executives, business leaders and strategic planners to develop the business model, operating model, and other enterprise architecture models supporting business model innovation
The CEO and other C-level executives will evolve and innovate the Business Model.
The Enterprise Architect will take the business strategy and business model and support the development of the target operating model, communicate the business strategy, model the target and interim enterprise architecture models, plan an EA roadmap of strategic initiatives, identify and define the required capabilities, define the mandates for the investment programmes and key projects, define standards and process improvements. They will usually define the IT strategy to ensure that it fits with the business strategy rather than being developed in isolation (as unfortunately often happens).
The Enterprise Architect will perform EA governance, compliance and design assurance against those programes & projects implementing the strategic changes and new capabilities. They will perform gap analysis and impact analysis, measuring the performance and compare the results against the expected outcomes.
All the while the Enterprise Architect will report to the CEO and act as their trusted advisor. They will analyze the gaps, risks, costs, issues, assumptions and dynamics to determine their cause and determine where to apply further strategic changes in the next iteration of the cycle and improve the overall maturity level of the enterprise.
The mission of Enterprise Architecture is to improve the implementation and excecution of the business strategy, ensuring that the enterprise will survive, continue to develop and remain profitable in the future.
An interesting example to look at is the US Department of Health and Human Services which has established an Office of Enterprise Architecture as part of the Office of the CIO. http://www.hhs.gov/ocio/ea/index.html
As the the book ‘Enterprise Architect as Strategy’ says – ‘When it comes to executing your Business Strategy your Enterprise Architecture may matter more than your strategy itself… ’
23 December 2010
If you want to execute a business strategy then you’ll need an Enterprise Architecture function.
Enterprise architecture (EA) is about change – strategic change in an enterprise.
But not exogenous change – reactive change forced on the enterprise by outside exigencies – although that sort of change and those external forces may be taken into account. No, enterprise architecture is about endogenous change – directed, planned, strategy-driven change within the enterprise.
Enterprise architecture is about describing the desired future state of the enterprise and plotting a course towards that position in enterprise ‘state space’ known as the Target Architecture.
Recently there was a long and fruitful discussion on LinkedIn, between practitioners, of the proposition that “EA is not the glue between IT and “The Business”. EA is the glue between Strategy and Execution.”. Aside from the questions of whether “glue” is the right metaphor and the possible mereological fallacy of considering IT and “The Business” as separate entities in need of glueing, the proposition is also something of a false dichotomy.
The two aspects – Business-IT Alignment and Strategy Formulation-Strategy Execution are neither mutually exclusive nor independent from each other. So, as with many false dichotomies, the ‘correct’ answer is “both and neither”. But in terms of importance to the business or enterprise, being the glue between strategy formulation and its (presumably) successful execution is critical whereas getting IT aligned to the business needs is only a very useful and desirable outcome.
But the question this immediately raises is what exactly it means to be the glue between strategy formulation and strategy execution – which despite the lengthy discussion was not really answered.
How exactly does EA help strategies get executed – and executed well?
The standard ‘authorities’ [like “Enterprise Architecture as Strategy” by Ross, Weill and Robertson] actually don’t help all that much – offering general aphorisms like “First build your foundation for execution” and “Define your operating model”. Well, yes – but what does that mean and how does that get your strategy off the drawing board and put into effect?
In recent weeks I’ve been reading a somewhat ‘non-standard’ EA textbook, by a professor at Wharton Business School which addresses exactly this problem.
That book is “Making Strategy Work – Leading Effective Execution and Change” – and even though Dr. Hrebiniak never mentions the term, I would contend it is a book about Enterprise Architecture because it is about change, strategic change, in an enterprise.
Towards the end of chapter six he provides a very plausible answer to the question of how strategy execution is glued to strategy formulation in the form of a “Strategy Review Process – Planning, Execution, and Controls” [Figure 6.2]. See http://www.amazon.com/Making-Strategy-Work-Effective-Execution/dp/013146745X
In essence the process is an adaptive closed-loop feedback control (socio-technical) system that seeks to bring actual business performance towards that demanded by the ‘control’ input of strategic objectives through the following six steps:
1) Strategy Formulation – including resource capabilities and constraints, strategy and goals, industry forces and competitor analysis
2) Strategy Planning and Execution – including meeting the demands of strategy, [changing] organisational structure, Integration Requirements and Methods, Information Requirements, Hiring and Training People [Developing organisational skills and knowledge] and Appropriate Incentives
3) Review of Actual Business Performance – including emergent deviations from the planned strategy
4) Cause-Effect Analysis and Learning
5) Feedback / Change – including changes in strategy and changes in the capabilities of the organisation
6) Continuation and Follow-Through – including integration and review of strategy changes, resource (re)allocations and agreement on business performance objectives and measures
Where step 6 feeds back and leads back into step 1, closing the loop. Dr. Hrebiniak asserts “Every organisation must fashion its own strategy review process. It’s not a luxury but a necessity. It’s that important. …It supports execution”. I’m not sure how much the professor is hyping his own process – but if the strategy review process is the enterprise’s only formal link between formulation and execution, I‘d say there is little hyperbole – it really is that important. Execution is delivery, formulation is just structured aspiration.
So what has this to do with Enterprise Architecture?
Step 1 is strategy formulation – and it is the usual process of matching internal and external analyses of the enterprise for the future. Enterprise Architecture is *the* key contributor to the internal analysis – the resource capabilities and constraints are (should be) described by the EA model, the strategy and goals are the EA (model) Motivation Decomposition.
Step 2 is essentially the strategic planning of change – including people, processes and technology wrapped up as organisational ‘capabilities’, or business architecture, information architecture, functionality (or ‘applications’) architecture and technology architecture. Many would regard this as definitively Enterprise Architecture. Not only that, the changes are described by the Target and Current Enterprise Architectures (models) and a number of intermediate Transitional Architectures and the differences between them. The planning process is the EA gap analysis process.
This is EA as a strategic planning for change function for the enterprise.
In step 3 – the intended target or transitional enterprise architecture (model) provides the baseline against which actual achievement can be objectively measured.
In step 4 – well, correlation is not causation; it is actually remarkably difficult to determine the contributory causative factors to any particular outcome or effect. EA has a role in assessing how much of the (change in) business performance achieved is down to what changes in the enterprise.
This is EA as the basis for impact analysis of change. Did investing in that software development really cause the increase in sales of snow-shovels or was it that the weather was more inclement than most people anticipated this year?
Step 5 brings in capabilities again. EA should describe the relationship between the organisational capabilities and the resulting business performance. EA is there to help assess what returns investing in particular capabilities is likely to achieve – and therefore find the optimum investment pattern.
And step 6 is again into describing the architecture of the enterprise as it is now and how we want it to be – and how we are going to measure the progress towards the ‘to-be’.
From this perspective, Enterprise Architecture can be seen to suffuse the entire Strategy Review Process, making it systematic, rigorous and cohesive – like a resin glue.
So if you are the CEO of a company that does not have an Enterprise Architecture function or a Strategy Review Process, presumably you think all you need do is formulate and promulgate a strategy and the execution will take care of itself?
Me neither – I think you need some glue.
by Ian Glossop, Enterprise Architect.