Using EA for Business Agility
11 January 2018
Taking Immediate Action with Enterprise Architecture initiatives
Introduction
Enterprise Architecture will enable Business Agility, increase flexibility and the long-term viability of an organisation.
However, don’t make the mistake of thinking that Business Agility is the same as Agile software development. Business Agility doesn’t come from using Agile for software development. They are two different concepts.
Business Agility is a mindset about business, not about software development or IT-Specific.
It is about the capability to deal with volatility and uncertainty and to react to unexpected business events that can occur at any time.
Business Strategy and Business Agility
Organisations need to Think about Business Agility in terms of the dynamics of Business Strategy.
Mapping their strategies, tactics and business capabilities.
Knowing:
- Where to defend
- Where to attack
Tactics for Business Agility
What are the tactical manoeuvres that an organisations will need to think about?
- Ability to do something different
- Preparing for various Business scenarios
- Consequences of alternatives
- Business Trends
- Strategies for gaining a competitive advantage
- Organisations have traditionally responded to change with strategic planning
- Change today can be fast
- Many strategies are 3 to 5 years
- Aim to be active and prepared to make quick decisions and not just reactive
- Gain fluidity to be able to adapt to new business models quickly
Business Agility with Enterprise Architecture
How does Enterprise Architecture (and Business Architecture) help? Firstly we can defined some principles.
Enterprise Architecture Principles for Business Agility
- Reducing bureaucracy
- Reduce constraints
- Avoiding blinkered approaches
- Freeing up power structures
- Put the customer first
- Keep up with the customers journey
- Lean Management
- Use EA for modelling people, process, policy, applications and technology
- EA provides a portfolio of initiatives and investments
- Avoid the pitfalls of automation
- Ad-hoc Business Processes
- Data Driven processes
- Faster decision making
- Deliver experiences instead of just products
- Better communications
- Omni channel communication
Purpose of Business Agility
What is the purpose of Business Agility?
Business Agility will increase the overall agility of an organisation to react to a changing market and customers environment.
This will:
- Enable more innovation
- Improve value propositions
- Reduce systemic risks
- Business Agility is the new key to success
- Is your organisation stuck in a rut?
The value of Business Agility
Greater Business Agility will give an organisation:
- Greater freedom of choice
- Knowledge of where to change
- Freedom of manoeuvre
- The capability of taking Immediate action
- Re-deployable capabilities
- Tailored value realisation
- Increased Business Value
- Faster responsiveness
- Increasing foresight
- Faster reacting to social media
- Reacting to customers journeys
- Moving fast in response to customers’ needs
- Gaining a critical advantage (Blue Ocean)
- Increased responsiveness to consumer needs is now more important to successful organizations than industrial efficiency and lower costs
- Better positioned to deal with ongoing and constant change
- Increased Responsiveness
- The capability to switch resources quickly and faster than competitors
- Being able to switch external partners quickly
- Capability to quickly react to external changes
Definition of Business Agility
Business Agility means having sufficient spare unallocated resources available in order to react to change quickly enough to be beneficial.
- Business Agility is the capability to quickly sense and respond to new events
- Ratio of available resources to uncommitted resources – planned redundancy
- Less constraints for implementing strategic change
- Increased Requisite variety
The law of requisite variety governs the capacity of a system to respond to changes in its environment.
- Business Agility requires a different philosophy for taking immediate action
- Balance between efficiency and flexibility
100% Standardisation does not provide required agility.
Automated versus manual processes.
- Business Agility is the capability to make rapid changes when required and not be constrained by static designs
- Having the capacity to deal with unexpected business events
Providing some slack or unexploited capacity.
A new Business Capability is needed.
This new Business Capability is called Business Agility Management.
This is not simply another name for:
- Risk Management
- Change management
Change management is a systematic approach to dealing with change both from the perspective of an organization and the individual.
Change management has at least three different aspects, including: adapting to change, controlling change, and effecting change.
It is a new and specialised Business Capability that is Business Event driven and continuous.
- It will continually adapt to business events
- It will require capable individuals from the relevant business, with supplier and customer collaboration
For an analogy think of a Cheetah.
- Cheetahs are perfectly adapted to rapidly accelerating to a great speed for capturing prey
- Chasing after prey that is dodging about and constantly changing direction
- A Cheetah is a stealthy high speed agile running machine
Process Models for Business Agility Management
What processes should be used for realising an Business Agility Management capability?
The two that I recommend are the Kotter’s 8 Step change process for developing a strategic overview process, and John Boyd’s OODA Loop for the continuous operational Business Agility process.
John Kotter’s 8-Step Process for Leading Change
https://www.kotterinc.com/8-steps-process-for-leading-change/
These 8 steps are the best approach for developing the strategic Business Agility Management capability:
- Establish a Sense of Urgency
- Create the Guiding Coalition
- Develop a Vision and Strategy
- Communicate the Change Vision
- Empower Employees for Broad-Based Action
- Generate Short-Term Wins
- Consolidate Gains and Produce More Change
- Anchor New Approaches in the Culture
Run these previous 8 steps continuously and concurrently.
OODA Loop
The OODA Loop (Observe – Orient – Decide – Action) process has been defined by John Boyd.
https://en.wikipedia.org/wiki/OODA_loop
OODA is the best approach to use for the operational aspects of Business Agility Management.
Observation (current enterprise architecture)
- Assess current business events
- Expect and watch out for the unexpected events and scenarios
- Determine how the current enterprise architecture model will support the new ad emerging events
Orientation (Analysis and insights)
- Analyse Business Events and current outcomes
- Identify what EA initiatives will be needed to fill the gaps
- Identify change and transformation opportunities decisively
- Focus on a clear future vision of customer value
Decision (Target Enterprise Architecture and alternatives)
- Identify alternative target enterprise architectures and different business scenarios
- Identify the target enterprise architecture
- Identify EA initiatives
- Evaluate investments in change that are needed (play or pass)
- Make decisions quickly
- Define the EA roadmap in terms of EA Initiatives and Investments on Change
Action (Execution of Target Enterprise Architecture)
- Take immediate action on investments in change
- Ensure resources and funding are already pre-allocated to immediate actions
- Start an immediate action task force to accomplish the changes without delay
- (for IT only teams this can be an Agile IT development team that is on hot standby, but don’t forget Immediate business changes needed)
- Respond flexibly to emerging circumstances
- designed to provide swift and positive reactions
- Quickly pivot on changes
- Execute the roadmap
- Implement the changes
Factors of successful Business Agility Management
How do we determine success for the Business Agility Management capability?
- Define measurable stakeholder aims and create a business case for their achievement (which should be continuously updated)
- Monitor assumptions, risks, dependencies, costs, return on investment, dis-benefits and cultural issues
- Effective communication that informs various stakeholders of the reasons for the change (why?), the benefits of successful implementation (what is in it for us, and you) as well as the details of the change (when? where? who is involved? how much will it cost? etc.)
- Devise an effective education, training and/or skills upgrading scheme for the organization
- Counter resistance from the employees of companies and align them to overall strategic direction of the organization
- Provide personal counselling (if required) to alleviate any change-related fears
- Monitoring of the implementation and fine-tuning as required
What will the Challenges be?
Business Agility Management will have plenty of challenges:
- Business Agility requires continuous adaptation
- Constantly changing context and variable Risks
- Understanding that people and business processes are resistant to change
- Avoiding fear, uncertainty, doubt, uncomfortable
- Designing a Business Model for Business Agility
- Creating the foundation for a viable business model which maximises opportunities for Business Agility in the enterprise architecture
- Determining the Readiness for Business Agility
- Encouraging the likelihood and support for business agility in existing business and IT systems
- Overcoming organisational inertia
- Planning and realising a new Business Agility Capability
- Requires a balance between decision making between speed and efficiency
- Requires high speed of decision making
- Requires enterprise architecture to ensure the alignment, integration and collaboration between strategic, social, business and technical components
- EA-enabled business investments
- Culture of Business Agility
- Create a culture that promotes fast decision making
- Make decisions and taking immediate actions using a rapid decision model
- Continual scanning of the market and customer environment
- CxOs understanding Business Agility
Some quotes to use
‘Sometimes I feel the need … the need for speed’ – Top Gun.
Ready, Fire, Aim!
More dreams die because we fail to seize the moment.
Immediate action means seizing the moment!
What keeps CEOs awake at night?
15 December 2017
Nightmare 1 – Competing with newer and nimble competition, who have better and more modern business models
New start up companies are generally more nimble that established companies, but are more fragile and prone to failure once the venture capital money runs out.
New start up companies may end up being very successful capturing customers without needing all the baggage of older more establish companies.
However when they are successful (which is not guaranteed) they can be very profitable and become a takeover target.
When is the best time to acquire them and gain value from them? Will they be worth it? Will they be a good cultural match with your company?
The answer is to use Enterprise Architecture for performing due diligence on them and determining value, business fit and technical fit.
Model the current state Architecture of each company in a merger, then define a single target architecture for the proposed new merged company.
Plan the business transformation with an EA Roadmap.
Nightmare 2 – Dealing with the Effect of Regulatory changes
What will be the impact on political change to the market and a new international trading environment with BREXIT?
How can we ensure the company remains profitable during the transition period, as well as afterwards?
Can we implement the new EU GDPR regulations in good time to avoid the heavy fines? Is your company already very late in starting a GDPR implementation?
The answer is to already be using Enterprise Architecture to understand your current baseline architecture, understanding all the various components in your business, all the connections between data and processes, and all the connections between processes and applications. This will enable you to design your target architecture to implement GDPR compliance.
It’s so much easier with enterprise architecture than starting from a blank model.
Nightmare 3 – Engaging more customers with digital architecture approaches
What is digital Architecture anyway? Its a nice buzz word and everyone will say that they are going digital, but few really understand it.
It is a very fuzzy term.
Is digital technology enough in itself, or is a culture change to the business also needed? The answer to that question will be yes.
It really represents an entirely new way of doing business, not simply new technology.
Digital is about getting closer to your customers, who are adept at using mobile devices, tablets and eCommerce websites to engage with you and your competitors.
Their customer journeys and scenarios are important to understand. An outside in approach is mandatory not optional.
The answer is to use enterprise architecture to understand the market environment, your competitors, your customers as well as your own company.
This needs to be from both business and technology perspective.
If you don’t understand what is happening then how will you be able to compete?
Nightmare 4 – Developing new Strategies and Innovations
Its hard and difficult to develop new strategies. Most CxOs are not really that confident in doing it.
Too often conventional strategy fails. A few one line strategic statements are not particularly actionable.
The dynamic dependencies and manoeuvres are all multidimensional. Companies need greater situational awareness.
How do we deal with dependencies between strategies? Are you being reactive or pro-active?
Is simply copying your competitors strategy a good plan? Or only a focus on mitigating Risks, Issues and Challenges?
The answer is to use enterprise architecture approaches to model your strategic situation, converting strategies into an actionable EA roadmap.
Using Business Models, Wardley Mapping, Business Capability models and Business Motivation Models is a good start for evaluating the pros and cons of strategies.
Nightmare 5 – Managing change – maintaining business agility and speed of change
Everyone wants Faster, Better, Cheaper but its still only possible to achieve 2 out of 3 of those! Is there a silver bullet? No, only in Vampire movies!
There is the lure of Agile, but does it work? Will business agility be achieved by developers using Agile methods for development? Probably not.
There is also the lure of DevOps, but is this just the latest fad? Does it work in all circumstances? How will these work with Lean and 6Sigma approaches?
In reality Agile and DevOps are not the silver bullet for organisations wanting things faster, cheaper and better. Think ‘Horses for courses’.
What about a roadmap for future changes and balancing out the needs of Digital Architecture and your business capabilities.
This will take enterprise architecture and planning, not just agile development. For true Business Agility, your organisation will need to properly plan its future using Enterprise Architecture.
Long term strategic planning, enterprise architecture and road-mapping are always needed.
Nightmare 6 – Growing new business, new Products and Business Services
Many businesses simply think of growth in terms of increased sales, but it’s also important to maintain profitability and viability.
It’s important to have the appropriate business models and think about your value propositions, not just for new customers but for existing customers.
Why not create a Business Model to explore how your customers and competitor work?
The answer is to use enterprise architecture to model your business with a Business Model Canvas and Business Scenarios. Business Scenarios are answering ‘what if’ questions about the future, and how you should prepare. There can be multiple business scenarios for after BREXIT for example, and companies must be prepared for any of them.
Nightmare 7 – Managing Costs and Risks
It’s always more expensive that you thought to improve things. Nothing is ever simple.
Aim for simpler but no simpler. Aim for low risk and low costs, but trade off the risks for market share and share of the customers wallet.
Think of the law of Requisite Variety. And of balancing your problems with your responses.
The answer is to use enterprise architecture for tracking costs, efficiencies, total cost of ownership, balancing the relationships between cost and revenue items, and between risks and mitigation activities. Enterprise Architecture is inherently a cross disciplinary and multi-dimensional approach and usually no single change will solve the issues.
And don’t forget that if you don’t measure anything, then you can’t manage it!
Ensure that you are taking an enterprise investment view of all your new initiatives and change portfolios. Is every initiative actually worth investing in?
Will everything make a profit for your company? When is the best time to invest in change? What are the dependencies between investments in change?
Conclusion
Working out your strategic direction, ensuring that the right initiatives are invested in and ensuring that these are executed properly is exactly what enterprise architecture is used for.
It’s not just about better IT, but about planning a better future for your business, keeping it viable in the long term, helping to make the appropriate fact based decisions.
An enterprise architecture repository is the knowledge base to provide you with answers to your questions.
Enterprise Architecture helps you get on top of business transformational nightmares, to avoid those feelings of anxiety, fear, uncertainty and doubt.
And helps the CEOs sleep better at night.
Do some enterprise architects become masters at their discipline without hours of practice, or does it really take 10,000 hours?
Of course 10,000 hours is a long time. 5 hours per day for 10 years? Its not a fast process, and most people are always looking for short cuts.
Is 10,000 hours the average or the minimum?
Do enterprise architects need some innate talent, or can this discipline be learnt?
How long does that take? What do you need to learn?
“If you can’t explain enterprise architecture to a six year old, you don’t understand it yourself.” – as Einstein would have said.
What is Enterprise Architecture?
Enterprise Architecture (EA) is the process of understanding the business model, the enterprise vision and both the business and IT strategies and then enabling the effective execution of the resulting change initiatives.
Enterprise architecture does this by modelling the current state of the enterprise and defines a number of enterprise’s future target states, defines the dependencies, identifies the best investment initiatives, identifies the change initiatives and then plans the required business transformations in the future.
Business transformations includes defining holistic models and road maps of the change initiatives, covering all domains from a strategic, business, organisation, information, services, application, technology and infrastructure perspectives. Usually that also includes modelling the market environment (what the competitors are doing) and customers own architectures (customer’s own processes and customer journeys).
The goal of Enterprise Architecture is essentially to successfully manage the process from Strategy to Execution.
Strategy execution is generally an enterprise’s most challenging issue, especially with the current attention on digital or customer focused transformations.
What is an Enterprise Architect?
Too often the enterprise architect role is misinterpreted and misapplied. It is not another name for the IT architect or solution architect roles at a project development level. It is definitely not another name for a solution architect who has achieved a certain level of seniority.
A solution architect can’t call themselves an enterprise architect, without first attaining an expert level of understanding and knowledge of the business as well as of IT.
An Enterprise Architect is a senior management executive leadership role concerned with how an Enterprise works from a business perspective, planning the future of how an enterprise needs to be transformed and changed over time and how it need to operate in its future environment. Inevitably IT is a large part of that change but in itself doesn’t define what Enterprise Architecture is all about.
Becoming a master : Gaining Skills and experience
Ignorance brings chaos and not knowledge, and diligent study and learning is essential.
No matter where you start from, it is necessary to learn from others and apply what you have learnt. Finding the right mentor is important.
Enterprise Architecture is a broad discipline and skills and experience in programming and development will not make you an Enterprise architect.
You have to learn about how a business works in terms of its business strategy and business capabilities, how it delivers value to its customers with its Business Model and its value proposition. You have to understand what Business Capabilities an enterprise has and how those capabilities are realised in the future with a mapping to the staff, organisation structure, business processes, information/data needed (and flowing), enabling applications and the services they provide, as well as the underlying technology and infrastructure. Technology & infrastructure isn’t simply IT by the way, but can includes factories, physical facilities and machinery. Remember the Internet of things includes smart machines, Internet enabled cars, integrated factories etc, not just IT stuff.
What does an enterprise architect needs to know?
- A clear understanding of what Enterprise Architecture is
- Abstract thinking
- Conceptualisation
- Visualisation
- Visioning
- Discussing strategy and planning
- Modelling the enterprise – to understand anything requires a mental model or an image of it.
- Modelling the future change options and alternatives
- Understanding Meta modelling and applying the important concepts
- Understanding different stakeholders viewpoints
- Identifying best practises
- Understanding the enterprise architecture processes
- Researching new topics
- Following business and IT trends
- Assessing opportunities
- Critically evaluating information gathered from multiple sources
- Evaluating investments
- Evaluating future business and IT trends
- Making recommendations
- Analysing the architectures
- Aligning business and IT
- System thinking
- Designing
- Road-mapping and business transformation
- Making decisions
- Teaching and mentoring
- Writing and communicating
- Persuasion and influencing
- Managing complexity
- Managing performance
- Providing value to the enterprise
Enterprise Architecture thinking and deliverables are often seen as purely to do with software delivery, solutions development, technology selection and specific implementation details. These are aspects of the work that is done, but only a fraction.
Its worth repeating that Enterprise Architecture covers changes to the whole business not only IT related changes.
What should an EA job specification look for?
- 10 + years of experience of Enterprise Architecture including Business Architecture
- An understanding between future strategy planning and running current operations and software development
- Understanding how businesses work
- An understanding the difference in scope and context between enterprise architecture and solution architecture
- An understanding of stakeholder engagement, analysis and design.
- A broad, enterprise-wide view of the enterprise and appreciation of strategy, business capabilities, business processes, services, information, data, enabling applications, technologies and infrastructure.
- An understanding of governance, risks and compliance
- A demonstrated ability to recognise structural issues within the enterprise, interdependencies, issues and challenges, influences, motivations
- The ability to apply enterprise architectural principles to business problems
- Experience using model-based representations that can be adjusted as required to collect, aggregate or disaggregate complex and multiple views about the enterprise
- Extensive experience modelling using a variety of tools and techniques
- Stakeholder analysis experience
- Experience in establishing an enterprise architecture capability within the organisation.
- Participating in strategy discussions and planning
- Understanding evolutions and system dynamics
- Balancing the requisite variety
- Guiding the impact of strategy on business capabilities
- Guiding business transformations
Open minded and challenging group think
What are the habits of successful Enterprise Architects?
- Use a business led Enterprise Architecture approach
- Use business models to understand the business environment
- Use business capability models to understand outcomes of value and planning of change with heat maps
- Use strategy maps, Wardley maps and system dynamics models to understand dependencies and evolution
- Use information models to understand underlying data, information and knowledge
- Use appropriate frameworks to apply consistent structure of key deliverables
- Use appropriate EA tool to accelerate modelling and analysis of investments and options
- Use appropriate approaches (Agile, Lean, Six Sigma, Iterative) at the right time (one size does not fit all)
Master Enterprise Architect
A master enterprise architect requires a unique blend of skills, which include keen awareness of the business, looking into the future, analysing trends, understanding the evolution of dependencies, dealing with various strategies, managing business transformations and change, dealing with stakeholders, understanding IT architectures.
Working closely with C level executives and senior management, master enterprise architects get into the detail of what makes a businesses successful by getting to the heart of their business strategies, goals and objectives, making better decisions and managing the complexity of strategy execution to enable the enterprise to gain maximum value from their investments in change.
How long does this all take? Roughly 10,000 hours, if not more…
Its worth reading the book ‘Outliers: The Story of Success’ by Malcolm Gladwell
Written by Adrian Campbell
A good analogy for an Enterprise Architecture capability is to think of it as the equivalence to an intelligence corps in the military.
Military Leaders and business decision makers will use this Strategic Intelligence capability to:
- Know what their current capabilities are
- Know the capabilities of the enemy (competitors) are
- Understand and gain awareness of the market situation
- Understand the nature of the environment (the market place)
- Understand the chances of success (costs and revenue)
- Help define their goals and objectives
- Help plan their strategies and tactics
- Help create plans of attack or defence (a roadmap for transformation ad change)
- Help to make new plans as the situation changes (a plan is always the first casualty of war)
The military intelligence corps is responsible for gathering, analysing and disseminating intelligence and knowledge about the military situation.
Enterprise Architecture is a business capability that collects information about the whole enterprise and uses various modelling and analysis approaches to create knowledge about the enterprise, provide advice and guidance to CxOs and heads of business units, and provide intelligence in support of their strategic decisions.
Most enterprises maintain some kind of business intelligence capability to collect information and analyse it, but this is not enough. An enterprise architecture capability is also needed.
For a long time the high level decisions made by executives and senior managers have often purely been based on intuition, personal experience and anecdotes.
Often their experience is 20+ years old and no longer relevant. Unfortunately most CxOs didn’t ever learn about enterprise architecture in their MBA courses, or were never taught about it in the first place. This is woeful ignorance in todays fast moving and complex business environment. Don’t let other players on the golf course make your decisions for you.
Often CxOs and senior decision makers are simply copying the decisions made by their competitors, for better or worse. If one of their competitors is playing with Blockchain, so that must be a good strategy right? Right? Another silver bullet or a waste of money? Does your enterprise architecture capability give you a competitive weapon?
Companies that want to succeed should put their trust in real strategic Enterprise Architecture.
Q. How many CxOs does it take to change a light bulb?
A. None.
– They get their Enterprise Architects to enable the strategic change.
Connections between components in an enterprise architecture model are the basis for identifying, creating and providing knowledge, analysis and intelligence.
In other words, Enterprise Architecture creates the Situational Awareness model for the organisation. The battle map on which the strategies and tactics can be plotted.
Enterprise Architecture models include the strategy, business architecture, information/data architecture, application architecture, infrastructure architecture domains etc.
EA Models also includes a study of the behaviour of their contacts, customers, competitors, vendors and suppliers, from both a strategic and tactical perspective. Both for the current state and future target state, or indeed multiple alternative future states based on alternative business scenarios. The target operating model is the same as the target enterprise architecture model.
The Enterprise Architecture capability provides valuable knowledge, intelligence and experience of the dynamic changes going on and not just as a static set of deliverables or inflexible process. When the strategic situation changes, then the Enterprise Architecture body of knowledge and intelligence needs to rapidly provide the answers. Keeping pace with today’s dynamic markets requires an Enterprise Architecture capability to enable and deliver a strong strategy and amplify it. A better way to change that light bulb.
Achieving a company’s full potential and stimulating creative needs, innovation and knowledge needs answers to lots of known and unknown questions.
Leaders focus on the most important decisions, answering questions such as:
- What if a competitor does this?
- What if the regulations change?
- What can we do to help?
- How to persuade the customer to buy more?
- How to increase profits?
- How to improve our service?
- How to stay competitive in a changing market?
- How can we innovate?
Achieving instant readiness with Enterprise Architecture is better than not being ready at all, or too late.
If you (the CEO) don’t act now to establish an Enterprise Architecture capability now then you will lose out on competitiveness and efficiency.
The most successful leaders in business already have a Strategic Enterprise Architecture capability established, providing the organisation with Intelligence and Knowledge.
Strategic Enterprise Architecture (Intelligence corp) capability includes the following sub-capabilities that enable the most successful leaders in business.
An Enterprise Architecture Capability:
- Provides the ability to envision and visualise an ideal future state based and create a roadmap in order to realise it (situational awareness and winning the war)
- Provides the ability to understand trends that present threats or opportunities for an organisation (countering the enemies threats)
- Provides the ability to identify, analyse, integrate components and connections required to achieve a business strategy (organising your forces)
- Enables and motivates people to work together to realise a strategic business transformation. (ensures success and keeps up morale)
- Enables governance and compliance of strategic relationships with vendors and suppliers, including for cloud services (maintains direction and momentum)
..I love the smell of Enterprise Architecture in the morning. Smells like victory…
Enterprise Architecture and Target Operating Models
6 October 2016
What is an Operating Model?
The term Operating Model is a fuzzy one. What does it really mean? What is in an Operating Model?
It appears that often some consultants totally go out of their way to avoid mentioning Enterprise Architecture and instead focus solely on the term Operating Model.
This may well be a side effect of the misunderstanding of Enterprise Architecture as only concerned with IT Architecture. Or may be because those consultants want to invent new terminology to make their services sound unique?
And by Enterprise Architecture of course I don’t mean just the IT Architecture domains, but all the EA domains which now include:
- Strategy & Motivation
- Business Architecture
- Information/Data Architecture
- Application and Application Service Architecture
- Technology & Infrastructure Architecture
- Physical Architecture (I.e. Archimate 3 Physical Elements)
Why do we need an Operating Model?
- Business Model (BMC)
- Business Motivation Model (BMM)
- Wardley Model
- Strategic Map/Balanced Score Card (SMBSC)
- Business Capability Models
– The business processes that needs to be performed
Organisation and people
– The people and roles performing the processes and how they are grouped into organisation units
Locations, buildings and other assets
– The places where the work is done and the technology, infrastructure and physical equipment in those places needed to support the work
Information
– The Information, data and applications needed to support the work
Sourcing and partners
– External entities, people and organisations outside the enterprise also performing the work
Management
– the management processes for planning and managing the work
A secondary question that I always ask myself is why don’t Business Masters (MBA) courses teach executives and management about Enterprise Architecture?
This may indeed be the source of the fuzziness and lack of preciseness of the term Target Operating Model?
Target Enterprise Architecture Model
Strategic Architecture Domain
Business Model (BMC)
Wardley Model
Business Motivation Model (BMM)
Strategy Map / Balanced Score Card Model
Value Chain Model
Influences Domain
Stakeholders model
Customer (Outside In) Domain
Business Scenario Model
Customer Journey Model
Business Services (value proposition) Model
Business Events Model
Business Service Flow Model
Risks Domain
Assessment Model
Business Capability Model
Capability Dependency Model
Component Business Model
Governance and Compliance Domain
Business Rules Model
Governance Model
Requirements Model
Organisation Domain
Organisation Structure Model
Business Locations Model
Business Roles Model
Business Process Domain
Business Process Flow (Value Streams) Model
Knowledge/ Information/ Data Domain
Business Information Flow Model
Business Information Object Model
Logical Data Object Model
Physical Message Model
Physical Data Storage Model
Applications Domain
Application Landscape Model
Application Integration Model
Infrastructure Domain
Infrastructure Model
Network Model
Physical Models
Roadmap Domain
EA Roadmap Model
Project Roadmap Model
Programmes and Project Portfolio Model
Summary
Dynamic Enterprise Architecture Models
4 September 2016
“Situation Normal, Everything must Change” as Simon Wardley says!
Wardley Maps
Scenario Analysis
Business Capability models and Capability Based Planning
Business Capability models are becoming much more common these days for planning change. A Business Capability is defined as the ability of an enterprise to do something.
A Business Capability identified from value based, business service based, outcome based and ‘Outside In’ based perspectives.
Business Capabilities are not another way of viewing the current organisation unit structure, the existing business functions, or the business processes.
Business Capabilities are instead realised by an aggregation of a subset of all the ‘Inside Out’ components, often simplified as people, processes, applications and technology.
http://pubs.opengroup.org/architecture/togaf9-doc/arch/Figures/32_dimensions.png
Business Capability Models provide value by for ensuring alignment to business strategies and for planning change (See the Open Group paper on Capability-based planning – The link between Strategy and Enterprise Architecture).
https://ingenia.wordpress.com/2013/06/16/business-capability-based-ea-roadmap/
Capability Model Dynamics
Business Capability Dependency models are used to map what business capabilities are dependent on other business capabilities.
http://pubs.opengroup.org/architecture/togaf9-doc/arch/Figures/32_relationships.png
Capability Increment Dependencies
Enterprise Investment Analysis
Enterprise Architecture models for the Business Environment
See http://blog.gardeviance.org/2016/09/finding-new-purpose.html
Capability Analysis
Dependencies between Capabilities can be connected to their multiple future versions to visualise their evolution and the choices possible. Often a future capability is only possible if another capability i.e. realised first, even if that one has little intrinsic value on its own, such as an infrastructure platform capability.
System Dynamics Models
Loops can be added to identifying Increasing loops, Decreasing loops and Balancing loops.
An example of a System Dynamics/System Thinking Influence diagram can be seen at:
Business Architecture Model
I have created this as a meta model for use with the Abacus EA Management tool.
Enterprise Architecture and Wardley Maps
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.
Enterprise Architecture and Digital Strategy
16 July 2016
Digital strategy is not simply about marketing. It is about a better engagement with potential and existing customers. It is about the perception of the brand created with customers though close interaction via social media and close communication leading to a value proposition that can better serve their actual and future needs.
As with any business strategy, the enterprise architecture discipline is there to support the business transformation to success with a design strategy. It is useful here to remind everyone that enterprise architecture is not just another name for an enterprise wide view of the IT Architecture and the underlying infrastructure architecture
The term ‘Enterprise’ in Enterprise Architecture refers to the greater scope of the organisation which includes the Customers, contacts, stakeholders in the wider market environment which is addressed by the Digital Strategy.
Enterprise Architecture will help organisations to drive innovations and new business capabilities across their entire value chain and to better understand the digital environment in which they will be operating.
Joe Tucci, Chairman and CEO, EMC Corp.– “To stay relevant in this new, always-connected digital universe, businesses in virtually every industry are reinventing their business models for unprecedented customer access, interaction, speed, and scale.”
Using Enterprise Architecture to provide a blueprint for digital strategy
Enterprise architecture consists of the following primary architecture domains.
- Strategy
- Performance Architecture
- Business Architecture
- Information/Data Architecture
- Service/Application Architecture
- Infrastructure/Technical Architecture
- Business Transformation/ EA Roadmap
In addition to these usual enterprise architecture domains, I propose that further Architecture Domains are required for supporting a Digital Strategy.
| Additional Architecture Domains | |
| Customer Architecture
|
Modelling the Customers’ own Environment, their processes, usage scenarios, customer journeys. Includes the communication channels used for communications directly to the customers and other external stakeholders. |
| Market Architecture | Modelling the outside-in view of what is happening outside the organisation boundaries in the Environment in which the enterprise does business, Social media, Competitors, Competitors Value propositions. |
| Brand Architecture
|
The branding, value proposition, projected identity that provides value to the customers for the lifecycle of the business. Includes generic communication to the customer and market, advertising the brand and value propositions. |
Figure 1 Enterprise Architecture for Digital Strategy
Strategy
Obtain clarity on the goals, objectives and principles guiding your digital strategy Business strategy /Digital strategy
- Mission
- Vision
- Business motivation model
- Business Model
- Goals and objectives
Market Architecture
Identify the environmental, industry and internal factors that are influencing the digital strategy.
- Communities
- Market environment
- Modelling what the competition is doing
- Assumptions
- Networks
- Competitors and their activities
- Who else is in your space?
- How do you differentiate?
- Market trends
- Topics
- Hashtags
- Media
- Threats and opportunities
- Gaps
- Blue ocean
- Search topics
Customer Architecture
As usual this means developing Business Scenarios and Customers Journeys, but also modelling the customers (potential and actual) own business processes.
These models will help to understand the customer touch points with the organisation and their desired brand and product experiences.
The Customer Architecture will also include a Connection Model to understand the relationships with customers, communities, to better understand the customers own information and process flows.
A current state Connection Model will capture the Communities, External online nodes, web sites, collaboration social networks (Facebook, Twitter), mobile platforms (IOS, Android) and cloud platforms (Evernote, Google Drive, DropBox, OneDrive) where content exists and customers will go to visit. This Connections model will also include Search sites (Google),
multimedia sites (Flickr), advertising (Ad-Words), entertainment and gaming sites eCommerce sites (Amazon, eBay ), Mobile applications (from Apple Store, Google Play), Smart TV applications etc.
This is similar to a Context Diagram showing interaction between the Organisation and its Stakeholders, but in this case the organisation is not in the centre of the diagram and may not be shown at all in a current state (as-is) Connection Model. The organisation will however be shown in a target state Connection Model.
In a target state Connection model, it will be important to model how the organisations internal models will be coordinated and aligned to the Customers connection Model.
- Outside-in perspectives
- Obtain clarity on who the customer, consumer, partners are, their roles and their values.
- VPECT.
- Business Scenarios
- Customers journeys
- Wardley Models
- Customers own processes
- Understand the customer touch points and the desired brand and product experiences
- Connect relationships with customers to better understand them over time
- Customers own information and process flow
- External online nodes, web sites, networks, platforms where content exists and customers visit
- Communications
- Obtain clarity on how the organisation means to listen and respond to consumers.
- Multi-channel / Omni channel communications
- Communications flows both ways via whatever channel the customer is comfortable with
- Customers’ ideas
- Many channels and many messages
- Understanding and analysis of those messages
- Gaining customers’ attention
- Earning their trust
- Customers motivation
- How customers share content
Brand Architecture
A brand’s look and feel and tone of voice is as important as its identity, experiences and value proposition.
- Creating brand experiences
- Brands
- Brand story
- Brand Strategy – Developing a creative brand strategy that is fit for purpose, up to date and distinctive is key to establishing all marketing communications.
- Who engages with your brand?
- Selling the Experience
- Understand the customer touch points and the intended brand and product experiences
- Insights about Customers – observations that trigger innovations
- Blue ocean strategies
The internal mode of the organisations Brand will need to be part of the Value Proposition model and show where the Brand messages will be projected.
- Modelling what the customers will love to buy
- Modelling how customers interact via social media
- Causal loop model (system dynamics)
- Modelling what customers are interested in.
- Mapping to the value proposition
- Minimum viable concept
- Behaviour change model
- Value and truth about the value propositions offered
- Value propositions
- Products
- Business Services
Business Architecture
Business model canvas
Create the structure required to understand the business model required to realise your digital strategy
Create transparency and traceability across the market model, products and business services model, and the target operating model
Business capability model
- Create a view of the organisational capabilities across people, process, information and technology required to deliver the brand and product experiences.
- Capability assessment against goals and objectives
- Business Capability based Requirements
- Improve the way you manage your digital requirements
- Business Capabilities can be informed by the user needs identified by using Wardley models
Manage information from data architecture and information security through to delivering key messages to the market environment
- Content management
- Understand the content management approach and how it is enabled.
- Value of each bit of content.
- Relationship of content to value proposition
- System dynamics model (stocks and flows / cause and effect)
- System thinking
Governance
Provide clarity over decision making across the digital architecture
Business Transformation / EA roadmap
Create an understanding of the extent at which your current capabilities are able to support your digital strategy
Create clarity of the EA roadmap required to support the digital strategy
Obtain consensus, commitment and support for your digital strategy and roadmap which we believe are critical to the success of your strategy
Performance architecture
Obtain clarity on your measures of success and identify plans to measure and monitor them
- Investment case
- Procurement
- Programme/Project Portfolio management
- Delivery plan
As usual if you don’t measure, then you can’t manage. However, it is surprising just how many enterprises fail to measure anything at all, including what they have done and what they plan to do.
- Define Metrics and create measures
- Critical Success factors
- Capability Maturity models
Vote leave again
2 June 2016
Churchill salute
14 April 2016
Use of Reason
12 April 2016
Need more bullets
12 April 2016
Need more good men, and women
12 April 2016
Enterprise Architecture is a young, immature discipline that produces models to guide the development of an enterprise. It is generally recognised to date back to the late 1980s or early 1990s and the work of Zachman, Spewak and others though it really took-off in the late 1990s and early years of the 21st Century.
But methodological disciplines do not emerge complete and well-formed from nowhere. Spewak’s Enterprise Architecture Planning, for example, builds on and incorporates some of Michael Porter’s thinking on the analysis of enterprises and industries. [Sadly, some more recent EA methodologies seem to have forgotten about this very solid foundation.]
Enterprise Architecture is not the only, nor even the first, discipline to take a model-based, methodological approach to the change and development of enterprises.
“Systems Thinking”
“Systems Thinking” may be considered Enterprise Architecture’s older, and perhaps somewhat wiser, big brother.
“Systems Thinking” as a very broad ‘tradition’ in analysis and model-building dates back to the 1960s although its origins lie in the focus on efficiency and effectiveness of post-WWII industrial enterprises made possible by new technologies. It is, I think, no coincidence that this was a time of great social, economic and technological change – that demanded new ways of looking at the world, and the linkages between changes happening in it, and the new possibilities opened up by the changes.
Today, several renowned enterprise architects would identify “Systems Thinking” as the proper theoretical basis for the practice of Enterprise Architecture.
For example, James LaPalme and Donald de Guerre identify Enterprise Architecture as “Open Socio-Technical Systems Design” – a particular application of Systems Thinking. [Lapalme, J. & de Guerre, D.W., (2013), “An Open Socio-Technical Systems Approach to Enterprise Architecture” in Gøtze, J & Jensen-Waud, “Beyond Alignment: Applying Systems Thinking in Architecting Enterprises” (http://www.amazon.com/Beyond-Alignment-Applying-Architecting-Enterprises/dp/184890116X/ref=sr_1_1?s=books&ie=UTF8&qid=1415365247&sr=1-1&keywords=Gotze+Beyond+Alignment)
With hindsight developed in recent years within the Systems Thinking tradition, it can be seen as comprising three distinct broad categories of methodology or theory: “
- Traditional Systems Engineering” (TSE) – also loosely known as “Hard Systems (Thinking)” (HST),
- “Soft Systems (Thinking)” (SST) and
- “Critical Systems Thinking” (CST).
Gerald Midgely identifies these categories as the first, second and third waves of “Systems Thinking” [ Midgley, G., (2000), “Systemic Intervention: Philosophy, Methodology, and Practice”, Kluwer Academic / Plenum Publishing – from the Contemporary Systems Thinking series. ] and very roughly they cover the periods 1965-1980, 1980-1995 and 1995-present respectively.
There are many variations and ‘subdisciplines’ within these broad categories – like Cybernetics, System Dynamics, and Critical Systems Heuristics and so on – but before outlining the key features of each category, we need a little more clarity about terms like “System”, “Methodology” and “Method” – as these words have been so mis-used in recent years as to lose their precise meanings.
What is a “System”?
A system is any identifiable collection of parts or components that interact with each other and with things that are not “in the system”.
This simple idea has some profound consequences. To be counted in or out of the system means the parts are defined by being an identifiable whole or unity in their own right. Thus a part can be anything – and it does not necessarily have to be a material thing.
So it makes sense to talk of “knowledge systems”, “learning systems”, “information systems”, “social systems” and “organisational systems”etc. – all of which may feature components that are not material objects. Even physical systems may feature elements that are not material objects – magnetic fields, energy, physical space or spacetime, other sorts of fields, information, and ‘causality’.
Since systems are themselves identifiable wholes, they may also be parts of ‘larger’ (in some sense) systems. This leads immediately to notions of relative systems hierarchy and strata, or layers, with subsystems and families of systems – and composition/decomposition, specialisation/generalisation and the ‘black-box’ and ‘white-box’ systems.
Since individual people and organised groups of people are identifiable as wholes they also may be components in systems – hence social systems.
As components may be counted in or out of “the system” there is an ‘analytical boundary’ between the system, as modelled, and the environment.
Since analysis, or observation, is the product of theory-based cognition and empirical perception there may be a ‘real-world’ boundary around the system components – or it may be the boundary is only in people’s thinking.
The pattern of interactions within the system, or between the system and its environment, may endure over time – which leads to ideas of structure in and between systems.
Or the interactions between components and systems may involve the fairly rapid movement of material, energy or information – which leads to ideas about system dynamics.
Hence the very simple, general notion of a “system”, with a proper definition, bootstraps or kickstarts a whole theoretical framework for looking at the world – or bits of the world labelled as “enterprises”.
One key observation from this way or looking at the world: the real-world is full of thousands or millions of different systems and individual parts may be components in many systems concurrently.
‘Natural Systems’ emerge from the plethora of interactions between components without any conscious intervention but artificial systems emerge when purpose and design are inscribed into the relationships between components by human agency – these are ‘Engineered Systems’.
So the general notion of “System” – that is the one underpinning Enterprise Architecture as a discipline that holistically models the components and relationships in enterprises – is very different from the narrow notion of “Computer System”, “Software System” or “IT System” – that underpins IT Engineering – though consistent with it.
What is/are “Method(s)”?
A method is a collection of related actions engineered to achieve a purpose.
The actions may be cognitive-theoretical actions – like identifying and labelling things, putting things in categories, identifying types of things, describing the relations between things, assigning purpose to things etc. or practical-physical actions like moving something from one place to another, changing the shape or configuration of some thing or system, initiating a chemical or physical reaction – like putting a match to the bonfire, or flipping an electrical switch – and so on.
The actions are related to each other in time and space – they may be in a simple linear sequence or an iterative loop – or maybe a set of contingent pattern-action ‘reactions’ – lists of “ if this pattern, event or perception should occur then take that action”.
Methods may be applied to any human purpose – and in Enterprise Architecture that purpose is to produce a relevant model to direct the change.
Methods comprising cognitive-theoretical actions are generally called “analytical methods” whereas those concerned with making change in the real world, including constructing shared, explicit models, are generally “methods of synthesis”.
Academics may confine themselves to ‘pure’ (uninformed-by-practice) analysis but in real-world practice analysis and synthesis are invariably mixed – and so are their methods.
We continually iterate and alternate between analysis and synthesis – or thinking and doing.
The key thing about methods is that they are tested and known to work (proven) – use the method and you get the result you want – assuming an appropriate level of skill and judgement is used in applying the methods.
Don’t use methods and you risk wasting your time, effort and resources and falling short of objectives and expectations.
Note also the significant relationship between “Method” and “Process” – each implies the other.
“Methodology”
As to “Methodology”, I agree with Midgley: “a methodology is the set of theoretical ideas that justifies the use of particular method or methods” – and it should be carefully distinguished from method or methods (see Chapter 5 of Midgley’s book.)
[In passing, it may be observed that many so-called methodologies available to the prospective practical interventionist or change agent (such as an Enterprise Architect) are somewhat weak in the theory that justifies their methods.]
“Systems Thinking”
Turning back to “Systems Thinking”, TSE or Hard Systems Thinking is founded in the philosophical ideas of reductive realism and positivism: that complex phenomena can be understood by being broken down into the behaviours of individual components and their relationships and interactions. TSE assumes that components obey a strict deterministic, linear causality – that if certain “initial conditions” occur, then the prescribed outcomes inevitably follow.
The traditional method of “Functional Decomposition”, widely used in Enterprise Architecture, is firmly in the TSE camp – it may even be at the heart of it – ironically since “function” is a human construction and non-material attribute imparted to components and systems (and not something derived from the teleology-free material world).
Traditional Systems Engineering may be thought of as mapping straightforwardly onto the technological systems analysis part of Enterprise Architecture.
The problem with TSE (alone) is that it does not apply to people intensive systems – which do not follow such a mechanistic causality.
This realisation led to the development of Soft Systems Thinking – which focuses its attention on the systemic and systematic way in which the ideas of different stakeholders in a “problem-situation” – i.e. a situation that at least some stakeholders want to change – are brought together (with the intention of achieving some consensus about change actions).
In this sense Soft Systems Thinking is more attuned to sociological, not technological systems and leans towards a “social constructivist” philosophy – like that underpinning the Social Construction Of Technology theory. [http://en.wikipedia.org/wiki/Social_construction_of_technology].
SST methods and methodologies include Strategic Assumption Surfacing and Testing (SAST), Ackoff’s Interactive Planning (IP) and Soft Systems Methodology (SSM).
Not only do SST methods map onto Enterprise Architecture’s methods and techniques for the analysis and synthesis of social systems in an enterprise, they also inform and illuminate EA methodology itself.
SSM provides a passable and somewhat justified model of social construction of enterprise models –that is of Enterprise Architecture.
One important methodology that may be counted as a part of the second wave of Systems Thinking is Socio-Technical Systems (STS) theory – which bridges the social and the technical aspects of enterprises.
Critical Systems Thinking (CST), the third wave, is about applying the right sorts of methods of systems analysis (and synthesis) in the right contexts (or change-situations).
It is “critical” in two senses: 1) it examines the assumptions and ideas behind the methods and 2) it involves critique and “critical thinking” about the situation and the methodologies that may be chosen from. CST is therefore inherently “multimethodological”.
“System of Systems”
Arguably the best-known of the CST methodologies is the System-of-Systems Methodology (SOSM) developed by Jackson, Keys, Flood and others.[http://www.bcs.org/upload/pdf/steve-clarke-paper.pdf ]
In essence it seeks to apply HST to hard systems problems and SST to soft ones while challenging the presumptions of powerful stakeholders.
However, the term “System-Of-Systems” (S-O-S) needs to be used carefully:
In one context it may refer to systems of systemic methods – as in Jackson et al.’s SOSM;
In another it may refer to the stratified and partitioned reality of many sociological and technological, natural and engineered systems with shared components interacting with each other.
Some enterprise architects hold the conviction that Enterprise Architecture is synonymous with Enterprise Systems Engineering (http://en.wikipedia.org/wiki/Enterprise_systems_engineering) – e.g.James Martin
[ See “Transforming the Enterprise Using a Systems Approach” in Gøtze, J & Jensen-Waud, “Beyond Alignment: Applying Systems Thinking in Architecting Enterprises” (http://www.amazon.com/Beyond-Alignment-Applying-Architecting-Enterprises/dp/184890116X/ref=sr_1_1?s=books&ie=UTF8&qid=1415365247&sr=1-1&keywords=Gotze+Beyond+Alignment).
In my view it depends what you mean by “Enterprise Systems Engineering”.
If you mean Traditional Systems Engineering applied at an enterprise scale and scope, then I’d have to disagree. That was tried before, it didn’t work then, it doesn’t work now and the world has moved on.
If, on the other hand, you mean something more like Enterprise System-Of-Systems Engineering (http://en.wikipedia.org/wiki/System_of_systems_engineering) – with both critical multimethodological and engineered enterprise senses of S-O-S – then I am in complete agreement.
For this reason, in my view a broad grasp of several strands and sub–disciplines of “Systems Thinking” is an essential and significant part of the Enterprise Architect’s armoury of methods and methodologies.
If your EA Team doesn’t have at least one person who has studied Systems Thinking, are you missing out on good, methodological practice?
© Ian Glossop, Glossop Mallard Consulting Ltd., 2014. (November)
Enterprise Architecture, as an activity in organisations and ‘discipline of praxis’, is about producing rigorous, explicit models of the enterprise to be used in the organisation’s decision-making processes. Its purpose is to enable the organisation to make better decisions about where to invest its precious resources to change the enterprise for the better. [Note: The “Enterprise” and the “Organisation” are different things – but the differences between them are unimportant for this article.]
That investment might be in new or improved IT systems, or new products and production processes – or in new or improved capabilities in the organisation.
An enterprise – any enterprise – has many facets or aspects to it – social and technical – and there are many ways of metaphorically looking at it. In academic jargon, there are several (cognitive, theoretical) ‘lenses’ that might be used to analyse an enterprise. If Enterprise Architecture is done well, several of those lenses will be used and each analysis will contribute something valuable to the models produced.
The job of the Enterprise Architecture team is to pull together these different analyses, through different lenses, into a coherent whole that can be used, by various people throughout the enterprise, to plot and plan the enterprise’s evolution.
The single most popular, and oldest, ‘lens’ through which people have analysed enterprises might be called “Functional Decomposition”. This is about examining the activities in the enterprise as “black boxes” – focussing only on what it is the enterprise, or some “Organisational Unit” within the enterprise, does – and deliberately ignoring the how of its doing. It is based on the very old tradition of “the Division of Labour” or “Functional Specialisation”, which many people trace back to the very early 20th Century and the management thinking of F.W.Taylor. Others, however, would trace it back even further – and there is no doubt Adam Smith presented a clear idea of it in his “Wealth of Nations” [Book 1, Chapter 1] in 1776 with his “pin-making” example. [Yes, Enterprise Architecture was being done over 200 years ago – but of course it wasn’t called “Enterprise Architecture” then.]
Functional decomposition – and the structuring an enterprise around the functional decomposition – remains popular with management teams and enterprise architects even today. Indeed, it has become so ubiquitous, so commonplace and habitual that managements may even do it unconsciously – without thinking. Nobody would even think to question the existence of a separate “Accounting Function” – and organisational division or unit dedicated to carrying out that function.
The traditional organisational structure – Operations, Marketing, Finance etc. – is a reflection of the high-level functional decomposition of the arbitrary (commercial) enterprise. [This is one reason why novice enterprise architects and inexperienced managers sometimes mistake ‘function’ for ‘organisation’ or vice versa – and sometimes don’t fully appreciate ‘function’ in abstract terms, or produce an organisational model when asked to produce a functional one.]
Almost every enterprise architecture description would necessarily include a functional (and organisational) perspective. There may even be a ‘view’ dedicated to just the functional decomposition hierarchy,depending on the methodology used. In the analysis of modern enterprises the functional view is often traced through into the technical architecture – in the functions of software components, or robots, or other machines – as well as the teams of people. The relationship between functions and organisational units may be described by an “interaction matrix” or “dependency matrix” – again depending on the methodology used. [ This is, of course, not possible if managers fail to distinguish properly between functions and organisations (units) – which is one reason for adopting the method. ]
However, most enterprise architecture teams would argue that a functional view alone, or even a functional and organisational view, is far from enough. A functional decomposition and an organisational decomposition are necessary parts of an enterprise analysis and model – but not sufficient to enable rational decision-making instead of unconscious conformity to an historic model. Others argue that “… executives need to re-think the concepts through which they have classically viewed the firm.
Describing the organization as a set of sequentially ordered parts no longer captures its essential properties. In its place they need to use a dynamic and integrated model …” [Laszlo, E & Laszlo, C. in “The Insight Edge – An Introduction to the Theory and Practice of Evolutionary Management”]. An enterprise architecture model?
A fuller and richer enterprise architecture model would include some other abstract aspects of the enterprise (than functions). An important, related lens would be the capabilities of the enterprise – things the enterprise, or parts of it, are able to do. TOGAF – The Open Group Architecture Framework – DODAF – the [US] Department of DefenseArchitecture Framework and MODAF – the [UK] Ministry of Defence Architecture Framework, among others, include notions of “Capability”, “Capability Architecture” and “Capability-based Planning”.
This capability ‘lens’ is also not new – though not quite as old as functional decomposition. About 20 years ago it developed from the “Resource-Based View of the Firm (RBVF)” – and saw firms, commercial enterprises, as distinguished by their portfolio of capabilities rather than the assets they happened to own or control.
Ironically this was about the same time that Enterprise Architecture as a separate, distinct discipline was also being developed. Spewak published his seminal book on “Enterprise Architecture Planning” in 1992.
Dorothy Leonard (later Leonard-Barton) in her book “Wellsprings of Knowledge” produced a taxonomy of capabilities, and what Enterprise Architects would now call a “Reference Model” for a capability that asserts it comprises Physical Systems, Managerial Systems, Skills and Knowledge and Values – and is surrounded by a ‘learning system’ that makes the capability dynamic – change over time. [Contrary to the common misconception, not all EA Reference Models are reference models for technological systems.] She also warned about “Core Capabilities” turning into “Core Rigidities”.
A couple of years later David Teece and colleagues developed the “Dynamic Capabilities Theory” – as a model of how enterprises innovate and adapt – and ensure their competitive survival. About the same time the Oxford economist John Kay developed his “Distinctive Capabilities Theory” published in his “Foundations of Corporate Success” book.
This theory argues that what sets an enterprise apart from would-be copy-cats, and makes it successful, is its “distinctive capabilities” – and these derive from three sources:
1) Architecture,
2) Reputation and
3) Innovation.
Kay’s Distinctive Capabilities Theory recommends itself as a method to formulate strategy – strategy that if successfully executed would lead to sustainable corporate success.
So it would seem that identifying the enterprises distinctive capabilities, its core capabilities, its enabling and supplemental capabilities and actively managing their development individually and as a portfolio is really important to successful execution of the strategy.
An explicit Enterprise Architecture model, featuring As-Is, To-Be and Transitional Capabilities Architecture – linked to and coherent with other architecture models like Functional and Organisational – is therefore an essential product of an Enterprise Architecture initiative.
If your Enterprise Architecture team is not producing those models, not doing those analyses, not using those lenses – are they doing something of less value to the enterprise? Why?
Ian Glossop, Enterprise Architect.
(Copyright – September 2014 – Ian Glossop, Glossop-Mallard Consulting Ltd.)
Elevator Speech for Enterprise Architecture
10 March 2015
What is a good elevator speech for Enterprise Architecture?
I usually say something like the following:
“Enterprise Architecture is a strategic business capability that provides benefits to a business for:
- Digital strategy exploitation
- Cloud strategy implementation
- Business and IT Consolidation
- Business Transformation
- Cost reduction
- Business Process Improvement and innovation
- Exploiting opportunities for value creation
- Facilitating Investment decisions
- Effective performance measurement & management
- New organisation structures
- Business Model changes
- Mergers & Acquisitions integration
- Achieving and facilitating business growth
- Improving the efficiency of existing operations
- Smarter systems
- Reuse of shared services
- New technology implementation
- Managing Regulatory changes”
If the building has a large number of floors then I might elaborate as follows:
- For most companies Enterprise Architecture is an essential business capability when embarking on a large scale strategic planning and business transformation, which is all about staying robust, viable and efficient, continuing to deliver good outcomes and value to its customers/consumers in the future.
- Enterprises want to stay competitive and efficient and beat the competition. EA makes the connections between Strategic Decisions and Business Outcomes and ultimately to deliver Value to their customers and stakeholders.
- If a company is to succeed, it must make strategic decisions and investments in change based on a thorough analysis that is only possible with enterprise architecture.
- All components of the Enterprise Architecture are traced back to the Business Strategy, Goals, objectives, Mission, Vision etc. This enables full traceability for changes.
- EA provides an overall framework and knowledge base for managing, designing and delivering strategic business and IT changes, aligning outcomes to strategies, ensuring successful business transformations.
- The Enterprise architecture model is a knowledge base for understanding, analysing, conducting impact and gap analysis, in order to evaluate various strategic scenarios.
- EA helps to inform critical issues such as cost reduction, identify problems, process improvement, identify innovations, technology selection, investigation of possibilities and opportunities, organisation design, performance management, mergers and acquisitions and new business models.
- EA guides, recommends and oversees the realisation of business strategy.
- EA supports the assessment of future investment decisions.
- EA supports Impact Analysis by identifying the boundaries and main components of an enterprise architecture and how they interrelate.
- EA identifies the high level factors that describe the ends and means for achieving the enterprise mission and the architecture vision.
- EA helps to aligning the IT Strategy with the Business Strategy, Business Model and Business Operating Model.
- EA provides value by governing and supporting IT enabled policy changes, major initiatives and change programmes.
- EA provides a knowledge base to directly support business and IT management leadership in understanding what makes the business work.
- EA provides governance and design assurance to service development and delivery projects.
Pick and Mix to suit your organisation !
Enterprise Architecture and Business Transformation
5 August 2014
Business transformation involves significant changes to all areas of an enterprise. It focuses on the future strategies.
These includes strategies, business models, operating models, business processes, information & data, systems, products, business services and channels. These are exactly the deliverables developed by enterprise architecture to understand the current state of an enterprise, to envision and design the future state of the enterprise, to discover the gaps between them, to identify the opportunities for investment in change and to plan the enterprise architecture roadmap to achieve the change initiatives.
This sounds just like what Business Transformation approaches do, doesn’t it?
In fact Enterprise Architecture and Business Transformation disciplines have much more in common, than they have differences.
It’s clear that real Enterprise Architects play a critical role in business transformations. The Chief Enterprise Architect is the most important member of the senior management team leading a business transformation and ensuring that it is effective.
By the way Enterprise Architecture, by definition, should not be misunderstood as only being about IT Architecture or Technical architecture, used just to support IT solution development. This is not what real enterprise architecture is for. Business transformation is rarely limited just to IT projects.
The CxOs are the business leadership responsible for providing business direction, identifying the needs for the business transformation in the first place and making the investment decisions. But the Enterprise Architects will work directly with the CxOs to drive out the devil in the details, planning the future transformation roadmap, developing future scenarios, making projections and forecasting future options. Acting without enterprise architects is equivalent to failing to make proper preparations and is asking for trouble. The enterprise architects perform the important task of analysis and evaluating the impact of strategies and proposed changes in detail, identifying risks and prioritising the transformation initiatives into a viable roadmap. They manage the complexity of transformations and are essential to achieving success and effective transformational changes. Enterprise architecture is about bridging the gap between the transformation vision and strategy and its realisation.
What approach should be taken for leading business transformation?
The recommend approach is based on the books by John Kotter, “Leading Change”, “A Sense of Urgency” and The Heart of Change Field Guide”, together with real enterprise architecture approaches to managing strategic change.
Creating the conditions for business transformation
1 Increasing urgency
For Business Transformation to be successful, then the whole enterprise needs to understand the need for it. The whole enterprise needs to have a view of the current state and the motivation for change. Enterprise Architecture provides an understanding of the existing problems and the desired future vision. Avoid complacency and business as usual behaviours. Business transformation means new behaviours and new ways of working.
2 Building a joint Enterprise Architecture/Business Transformation team
A Business Transformation team should not be a group isolated from the enterprise architecture team, but completely integrated with it. Remember that a real enterprise architecture team is responsible for the future business change within the enterprise (and is not just an IT development function), typically up to between 2 and 5 years into the future. Seriously, how can they be kept separated from a business transformation programme?
Identify the members of the Enterprise Architecture/Business Transformation (EABT) team. Look for a mixture of strong management leaders and include a good influential people from a continuum of all job titles, levels of authority and statuses. Remember that enterprise architects are strong and effective change leaders and already cross cut the whole enterprise. Non-enterprise architects in the EABT team will probably have greater political and financial skills whereas Enterprise architects will have cross domain knowledge about the whole enterprise in detail, analytical skills and significantly greater modelling skills. All team members should have good vision and leadership skills.
Hold honest and convincing discussions, dialogues and workshops. Enterprise architects are often useful as facilitators at this stage.
Ask for emotional commitment from all EABT team members and commitment to work together for the common good of the enterprise.
3 Establishing the Target Transformation Vision models and Strategy
What does business transformation success look like?
Planning the strategies and confirm the business motivation. Enterprise Architects and C-level managers will use a Business Motivation Model for this, identifying Strategies, Goals, Objectives and performance measures.
Analyse the various ideas and options to develop an understanding the various Business Models for the target transformed enterprise. Alternative business models can be produced by the enterprise architects using a Business Model Canvas approach and these can be compared with multiple measures, including total cost of ownership and potential revenue.
Avoid thinking in terms of systems and IT solutions too early, after all this is the job of the enterprise architects later on and business transformation is a business problem. Allow for unfettered innovations to emerge from discussions.
Identify stakeholders including customers, partners and suppliers.
Examining the Outside In views from the perspective of these customers and partners.
Creating detailed Business Scenarios, Customer Journeys and Partner Journeys using any suitable story telling approach. Remember that stories are powerful, especially if they come directly from your customers. The enterprise architects will capture and analyse these business stories, but remember that at this stage these are not detailed IT requirements or user stories/use cases from an Agile software development perspective. Those kinds of deliverables will be defined much further downstream.
Identify opportunities and innovations. The team should consider approaches such as a Blue Ocean Strategy (see the book).
Definition the transformation Vision, Values, Motivations.
Defining the transformed value propositions
Analyse and understand the risks, their probabilities of occurring and their potential mitigation.
Engaging and enabling the Enterprise
4 Communicating the Transformation Vision and strategy
Communication is essential for all business transformations if they are to be successful.
There will be detractors and strong opposition to some of the transformation vision. The enterprise architects in the EABT team will ensure that fact based decisions can be made.
Publish and communicate the business transformation models as widely as possible. This will help make the right decisions and solve problems. Don’t assume either the C level managers or the enterprise architects have a monopoly on good decisions. Challenges need to be addressed and responded to.
Obviously some aspects of the transformation vision and strategy will be commercially sensitive and should not be communicated to the competition without careful thought. However, ultimately remember that the enterprise will want support from all customers, internal stakeholders, outside stakeholders, partners and suppliers and this support and buy in cannot be won without communication. Talk often and modify the transformation visions as needed. The enterprise architects will keep track of alternatives and decisions in the transformation model. The Vision and strategies need to be tied back to all aspects of the transformation model. This becomes infinitely easier using a flexible EA management tool (such as ABACUS) and avoiding spreadsheets and Visio diagrams which rapidly become unmanageable.
Ensure that the joint Enterprise Architecture/Business Transformation (EABT) team is able to lead by example by speaking about the transformation vision at any time and to always evangelise about it.
5 Enabling Action
Enabling transformation change is about removing the barriers to change and empowering staff. It involves removing resistance. Often resistance to change from staff is tied to functional divisions and people who are not measured by enterprise’s transformation success but only by fulfilling their own their own personal goals. Paradoxically, it may be the way they are measured and rewarded by the C-level managers that causes people to resist and avoid supporting transformational change.
To enable the right actions, the authorities, responsibilities and rewards need to be re-aligned with the business transformation vision, goals and objectives.
It is the enterprise architect who takes the business strategies and business model and successfully realise them on behalf of the whole enterprise, so are often best placed to also identify the authorities and responsibilities needed to focus people on benefits to the enterprise.
Ensuring that the Enterprise Architecture /Business Transformation (EABT) team has the right authority is also essential, and is able to resolve competing priorities. This authority is also exercised in relation to the governance and compliance stage.
Establish the appropriate metrics and measures, and maintain a scorecard for the business transformation vision, goals and objectives. It is strange how often performance is ignored and enterprises do not know how to measure success, or align performance to desired outcomes. Costs and revenue need to be balanced with other measurement dimensions. Measures should be aligned to transformation changes in the EA management tool.
6 Define Investment Opportunities
Examine the investment opportunities and develop an investment case. The Enterprise Architects will be best placed to determine how realistic and feasible a specific investment opportunity will be, and determine the fine details. Whereas the C-level management will understand the balance of costs and revenue developed in the Business Model.
Enterprise Architects will use a Business Capability model to scope and plan which business capabilities will be modified by a transformational change.
Transformational changes will typically be classed as short term or long term changes. However by definition, transformational changes will tend to be large and disruptive rather than “low hanging fruit”. Short term transformational changes will however be useful for maintaining the transformation momentum across a number of iterations.
Changes to business capabilities are identified as a number of capability increments. The dependencies between these and their priorities will form the first draft enterprise architecture roadmap and provide the scope and context for subsequent change iterations.
Implementing and sustaining the business transformation
7 Keep up the momentum
It is important to keep up momentum for a business transformation. The EABT team must keep communicating and clarifying the business transformation changes.
The business transformation model must be regularly published and all opportunities taken to speak to all stakeholders about it and inform them on status and progress. Capture feedback and responses to continually validate the vision and measure its effectiveness.
Address the fear, uncertainty and doubt from detractors and sceptics and motivate supporters to evangelise about the transformation. Encourage desired culture and values that reinforce the transformation changes. Keep your eyes on the roadmap and don’t assume everything is done after the success of the first iteration and let performance and concentration levels drop. Don’t let the EABT team get diverted into other side projects. Perseverance is important. Remember that change is the only constant.
Develop communication material including web sites, brochures and posters. Posters can be very effective as information radiators.
8 Enterprise Architecture Governance and Compliance
C level managers will be making the investment decisions and providing funding for investments in change.
Establishing an enterprise architecture governance and compliance capability will ensure successful realisation of transformation changes, and help them become permanent business as usual.
Detractors will often try to derail changes but the formal governance and compliance approaches will enforce decisions made but will also provide a platform for challenges and objections to be discussed openly and objectively.
9 Realising Transformation Changes
Business transformation needs many kinds of potential future changes to occur, not least of which are the key cultural changes and organisational changes.
Business Process changes, Information changes, system changes and procurement changes are also important. However for these I recommend designing for flexibility and adaptability not going for a fixed solution which may be cheaper but will invariably be difficult to change the next time. Business transformation should be thought of as a continuous process, enabling an enterprise the rapidly respond to changing forces in the market environment.
Before changes are executed, it is a good idea to conduct a Change Readiness Assessment, if you have not already done this earlier in the Enabling Action stage. This will help find out how prepared the enterprise is for the transformational changes and identify the enterprise’s overall competence, knowledge, skills and capabilities. Any shortfalls will be addressed by planning suitable skills training, and addressing the shortfalls.
In conclusion
For maximum success in strategic business transformations, an enterprise needs to completely and fully use their enterprise architecture resources and enterprise architects. You have to work hard and plan carefully. Building the proper foundation with an enterprise architecture model for the scope of the business transformation will make everything very much easier.
There is no good reason why real Enterprise Architecture and Business Transformation should not be merged as a single discipline. The skills needed for each hugely overlap, especially the Business Architecture domain of enterprise Architecture.
A joint Enterprise Architecture Business Transformation team is essential to achieving successful and viable transformations.
Cognitive Dissonance
11 November 2013
I was reading this today:
Intersection and branding
8 August 2013
I’m reading a great new book called Intersection: How Enterprise Design Bridges the Gap Between Business, Technology, and People by Milan Guenther
The book discusses modern Enterprise Architecture perspectives like the Outside In approach and provides a holistic design lead approach that is focus more on the customer than on the underlying applications, technology and infrastructure.
The book also addresses the corporate branding of an enterprise. A successful brand is grounded in the strategic future vision of an enterprise. This strategic vision is also what drives the enterprise architecture initiatives, so it is clear that the enterprise architecture discipline must then provide the key support for understanding what contributes to the brand, what makes the brand successful and what must be done to sustain the brand. This is a refreshing perspective that tends to get lost in most organisations.
The knowledge of messages, business events, interactions with stakeholders, outside in scenarios, business services and value streams that are defined and designed as part of the business architecture domain will all enable senior executive to understand and develop their brand. A brand is not just the value proposition, the set of products and services offered, but includes the development of the reputation of the enterprise, the customer experience it provides and the trust the customers develop. The book describes this in terms of the form, appearance, communication and behaviour of the enterprise and much more
Enterprise Architecture will have a profound impact on the brand and ultimately on the financial success of the business.
This book is a must read that should be on the bookshelf of every true Enterprise Architect.
Brilliant new album
10 July 2013
Go buy this now!
http://lachlancampbell.bandcamp.com/album/6-month-winter
Enterprise Architecture Lifecycle
27 June 2013
The Enterprise Architecture team has a lifecycle of its own, but doesn’t operate in a vacuum. The Enterprise Architecture capability fails if it is seen too much as blue sky thinking in an ivory tower.
The Enterprise Architecture team will interact closely with all the other management processes in an organisation, especially the IT management processes. When all these processes work together effectively, an enterprise will be able to successfully manage strategic changes and drive business transformation effectively and efficiently. Often in organisations little thought has been given to the integration of the EA processes to the other management processes. This contributes to making the EA team into an ivory tower, seemingly unconnected with everything else. The aim of this post is to shine some light the EA lifecycle and its interactions.
One of the goals when establishing or maturing an enterprise architecture capability is to make sure that the enterprise architecture a fundamental and normal part of the business-as-usual decision making flow rather than considered as an afterthought.
Too often I have seen major changes apparently started directly at the project initiation phase before there has been any serious appraisal of the business fit, technical fit and feasibility of that change undertaken, not least by the enterprise architects.
The Enterprise Architecture capability is driven by understanding the business strategy and strategic scenarios which drive the business and IT enabled changes in an organisation. It is there to ensure that any strategic change is viable in the future, but it also identifies the dependencies, feasibility, risks, issues, costs, and informs the subsequent investment decisions that need to be made.
The current state and future state enterprise architecture models will be developed (typically using the TOGAF ADM).
In the EA roadmap, the strategic changes will be prioritised and arranged into a meaningful sequence to inform the decisions made by the programme and project portfolio management and before any projects are initiated.
The Enterprise Architecture capability will govern what parts of the future state enterprise architecture are developed and delivered by the projects, and thereafter ensure that the delivered solutions and services remain compliant with it. The compliance stage will also capture and approve any innovations that are identified as useful. The enterprise architecture team and/or a technical design authority will provide design assurance for the projects, to ensure that principles, standards, patterns, policies and guidelines are being followed.
It’s worth noting that the EA lifecycle is not a part of the project solution development lifecycle as many organisations seem to imagine it is, but is a separate lifecycle that operates in parallel at a strategic level. Neither is the EA lifecycle the same as the TOGAF Architecture Development Method.
After a solution has been delivered, the enterprise architecture team will harvest the results in order to update the current state enterprise architecture, to measure performance and to publish a dashboard for the senior management team.
The following diagram illustrates the major stages and processes that are undertaken by an Enterprise Architecture team, for each iteration they undertake.
Context
These Enterprise Architecture processes can be best understood in the wider scope and context of all the processes defined by the COBIT5 framework for the governance and management of enterprise IT. http://en.wikipedia.org/wiki/COBIT http://www.isaca.org/cobit/pages/default.aspx
I’m surprised that COBIT is not used more in UK based organisations, but it is more popular in Europe. I would recommend COBIT5 is used as a broad framework for assessing the risk and value of IT and the governance of all IT management processes.
The following view is broadly based on the COBIT processes, and illustrates the position of the Enterprise Architecture processes relative to the other IT management processes identified by COBIT.
Starting from the Strategy & Vision there is an overall clockwise cycle through all the processes. The Enterprise Architecture capability is responsible or accountable for the processes shown in red, and is consulted and informed about the other processes. The responsibilities will, of course, vary in each organisation and in many cases the enterprise architecture team will be additionally responsible with many more of the Solution Development processes (for example, Select, Acquire, and maintain COTS software products).
In a more mature enterprise Architecture environment, all these processes will be expected to consume and contribute to the knowledge, information and models held in the Enterprise Architecture repository (illustrated in the centre of the diagram). The management dashboard of performance metrics, charts and graphs will be generated from the EA repository.
COBIT
The above diagram is based on the COBIT processes. The latest version of COBIT5 is more explicit about enterprise architecture than earlier versions were. The following table shows the COBIT5 processes that directly relate to or are supported by an Enterprise Architecture team and an Enterprise Architecture Governance Board.
| COBIT5 reference | Process |
| APO03 | Managing Enterprise Architecture |
| APO02 | Define Strategy (in this context this usually means the IT strategy) |
| APO04 | Manage Innovation (via the Enterprise Architecture Governance Board) |
| BAI08 | Manage Knowledge (via the EA Repository) |
| BAI06 | Manage Changes (i.e. Strategic changes and IT enabled Business changes that drive the future state enterprise architecture) |
| MEA03 | Monitor and assess compliance with external requirements (via the Architecture Governance Board) |
| APO05 | Manage Portfolios (with EA Roadmap) |
| APO011 | Manage Quality (via EA Appraisals) |
| APO012 | Manage Risk (via EA Appraisals) |
| EDM01 | Set and Maintain Governance Framework |
| EDM02 | Ensure Value Optimisation |
| EDM03 | Ensure Risk Optimisation |
RACI
The following table shows who is Responsible, Accountable, Informed or Consulted in regard to the services provided by the Enterprise Architecture team and an Enterprise Architecture Governance Board.
Implementing the EA lifecycle and integrating it with the IT management processes in an organisation will help the Enterprise Architecture capability to avoid the challenges and misperceptions that it is some kind of ivory tower that can be wilfully ignored and disbanded when looking for budget cuts.
Senior management teams will instead come to appreciate the valuable contribution that Enterprise Architecture makes to strategic planning, appraising investments in change, driving business transformations, finding opportunities and innovations, and to understand the value EA has to the organisation as a whole.
Outside In
24 June 2013
How often do you see customer journeys, customer events and scenarios modelled in an Enterprise Architecture model? Not often, if at all I suspect.
In my opinion, the ‘Enterprise’ in Enterprise Architecture should include all those stakeholders that are engaged with an organisation. This include all those suppliers and service providers to the left hand end of the Value Chain, and the Customers at the right hand end. In this post I’ll be focusing on the Customers that are consuming the products and business services that are the outcomes of the Value Chain.
This is the view that the Customers have from the outside of an organisation looking in. This perspective should drive what a business does.
In most organisations however, the Enterprise Architecture is usually focused on the organisations internal workings, the inside out view of how an organisation can become more efficient, leaner and reduce cost, as a way of making more profits. The focus is on delivering better software faster, improved processes, commoditised infrastructure, reusable IT services, providing a self-service internet to replace face to face contact with the customer and so on.
The business strategy may look at the customer and market segments and the drivers for strategic change, but this is often as far as it goes. The rare organisation models the customers journey and the customers perspective and if they do then its rare to find the customer journey modelled in the Enterprise Architecture.
Organisations often try to reduce the direct interaction they have with their customers by removing phone numbers from their web sites, and providing limited set of services and FAQs. Customers are forced to waste many minutes on the telephone, selecting endless options in an attempt to get a human voice to speak to. Companies are afraid of this because of the costs of complaint handling. To be fair, a number of organisations have implemented a live chat IM service on their web sites and high value customers do often get a live account manager to speak with. But what about the rest of us everyday customers? It still seems like businesses are lacking a good understanding of their customers behaviour.
Digital Businesses and Digital Customers
Every business is now a digital business. It’s the same for customers (i.e. all the consumers, customers, potential customers and contacts) who are also increasingly digital using technologies like smartphones, social networks and broadband. They are using their own devices (such as iPads and other tablets) to research potential products and business services that they wish to purchase from businesses. They browse social networks and conduct searches to determine what product or business service best suits them. They have mass access to huge networks of information such as Google to help them.
Customer behaviours are changing, but does your enterprise architecture model know that? Does it model what the customers’ own processes are? Does it model the events that originate from a customer? Does it model what the various scenarios that there are in the customer journey? In my experience the answer is typically ‘No’ to all these questions. In my experience even when an organisation is modelling the customer journey then it is never included in the future state enterprise architecture.
What is the customers’ processes? Customers will conduct a search and discovery process, engage with the business to select, negotiate and make a purchase. If the business is lucky then the customer will re-engage to make future purchases, but if they screw up the customer will get annoyed and tell all their contacts on social media about why they are no longer buying. Companies are seeing the increasing power of customers but how many are trying to understand them and model their behaviours?
Enterprise Architecture, or more specifically, the Business Architecture within the Enterprise Architecture discipline should cover the customers’ interactions with a business, understand what they are saying on social media.
An initial approach is to speak with customers and use a thinking framework such as VPECT to determine their Values, Policies, Events, Content, Trust Relationships.
See http://en.wikipedia.org/wiki/VPEC-T
They can also use the less engaged PEST analysis for strategic market research.
See http://en.wikipedia.org/wiki/PEST_analysis
Results of conducting VPECT analysis and PEST analysis should be recorded in the enterprise architecture models and associated to a representation of the customers journey
How should we model the Customer Journey and the different customer scenarios?
For a start, each scenario in a customer journey will be triggered by one of more of the Events discovered by VPECT analysis and be concluded by something of Value delivered back to the customer (Content).
What does the Event trigger? For me the best representation is a sequence of Business Services, in what might be called a Service Flow diagram.
This is much the same as a Process Flow diagram but from the external perspective. For a customer interacting over the internet, the Business Services might involve a Browse Service, A Product Detail Service, A Product Price Service, A Payment Service and a Fulfilment and Delivery Service. The Outside In service flow view is later mapped to the Inside Out process flow view
Customer Journey model
It’s easy to see that an organisation may not itself directly provide all these Business Services (for example the Payment Service may be provided by PayPal or similar, and the Fulfilment service may be provided by DHL or similar)
What also need to be modelled are the Customers own goals and objectives and how the scenario of service based interactions supports the customers goals. Key measures should also include:
- How much did the customers have to invest in the interaction (in time, and navigating complex interfaces, breaks in the interaction, confusion) to complete it?
- How much they enjoyed the interaction (customer satisfaction feedback)?
- How many customers abandoned the attempt early?
- How many customers complained to their social media contacts afterwards?
- How many customers complained directly to the business?
Multi-Channel
Another question that needs to be addressed is what channels and multiple channels do customers use? Customer these days are much more likely to use multiple channels at different times, rather than just a single one:
- Search the internet with their iPad or smartphone at home
- Switch to using their desktop PC at work
- Use the telephone, email, IM message or SMS message for clarification on product details, prices and discounts
- Hand off the desired purchase to their purchasing department to use corporate discounts to make the actual purchase
- Expect an email or letter with their receipt, complemented by an SMS message to their mobile device and copy to the purchaser
Channel strategies don’t often allow for a customers’ use of multiple channels and for account information being passed around during an interaction with the customer. Businesses often manage different channels with different functions and organisation units. This results in confusing and frustrating transfers between departments. How often have you called a business, given your contact and customer account details, only to be handed off to another department who asks you all over again for that same information? It’s extremely annoying and it’s this kind of symptom that undermines the customers’ experience and sends them tweeting negative remarks.
One to One marketing
One-to-one marketing refers to marketing strategies that are designed as if they apply directly to an individual customer. Information is collected about customers’ needs, customer segments that they fall into, their preferred channel, their lifetime value to the business and which products and business services they are likely to purchase.
See the books by Don Pepper and Martha Rogers: The One to One Future and the One to One Field book.
What one-to-one marketing misses is more of an Outside In perspective, going much further in understanding the values that a customer needs and their own processes that customers follow (formally or informally).
The book I recommend is ‘Outside In: The Power of Putting Customers at the Center of Your Business’ by Harley Manning, Kerry Bodine et al.
Total Unified Customer Communication
Typically organisations still tend to communicate with their customers in a disjointed and unconnected way. Invoices, statements, receipts, marketing literature, pricing deals, discounts, marketing campaigns, letters, emails, IM messages, data streams etc.. are all sent from many different departments who have no idea about the incoming or outgoing communications that have already been received or are being made by other departments. The result is customer confusion. To be fair, the situation is not so bleak for business customers, as it is for individual personal customers, but increasingly it’s difficult to tell the difference and negative social media discussion will also impact the business customers.
Instead of just silo based incoming communication with customers we need to get a total view of all the customers interactions both incoming and outgoing to the business, and within social media, centralising all interactions, via multi channels, with a Customer Communication Management (CCM) system. Curiously I’ve never seen a Customer Communication System in any future state Enterprise Architecture model and the recommendation to include one has fallen on deaf ears. One to one marketing should become one to one multi-channel total customer communication.
Companies will want to differentiate their products and business services and to compete with other businesses and therefore they will need to innovate. Understanding their customers’ perspectives and their customer journey scenarios will be a key innovation for any business. This will require that the future target Enterprise Architecture model includes these views and connect them to the rest of the model.
Business Capability based EA Roadmap
16 June 2013
As Business Capabilities are directly derived from the corporate strategic plan and are designed to satisfy the enterprise’s business strategies, goals and objectives, so they provide an excellent basis for the creation of an Enterprise Architecture Roadmap.
What are Business Capabilities?
A Business Capability represents the ability of an organisation to perform an activity that results in an outcome of value. Business Capabilities are as far as possible expressed in terms of those business outcomes and value. As far as I know the concept originated from MODAF and was later adopted by TOGAF. See http://en.wikipedia.org/wiki/Capability_management_in_business
Many Enterprise Architects and organisations fail to really use them, but in fact they are slowly becoming a common EA deliverable and a way of developing a target operating model view.
The key to their increasing popularity is because the Business Capabilities are expressed in terms of business outcomes and value rather than in purely functional or IT terms (i.e. Not just in terms of business unit needs or in terms of IT Solutions) thereby ensuring IT alignment with the business. Being expressed in terms of outcomes and values also means that Business Capabilities are tied to the outside in perspective of the Customer Journey and Strategic Scenarios, rather than the inside out perspective.
A good book to read about the outside in perspective is “Outside In: The power of putting Customers at the Center of Your business” by Harley Manning et al. http://www.amazon.co.uk/Outside-In-Putting-Customers-Business/dp/1477800085/ref=sr_1_1?ie=UTF8&qid=1371351364&sr=8-1&keywords=outside+in.
In order for an organisation to perform an activity, many parts of the organisation need to be involved. Consequently a Business Capability is modelled as grouping of other EA concepts including the following:
- People
- Organisation Units
- Functions
- Processes
- Business Services
- Information & Data
- Application Services
- Applications
- Infrastructure Services
- Infrastructure
In this way a Business Capability can be seen as a cross cutting slice through a typical enterprise architecture model.
A Business Capability is used for managing units of strategic business change and providing the mandate for programmes and project portfolio. Subsequently, project will develop a solution that either creates a whole new Business Capability or updates a Business capability by implementing a Capability Increment.
Thus, Business Capabilities and Capability increments provide the basis for the development of the EA Roadmap.
Business Capability Model
Figure 1: Example Business Capability Model Source: UK Government Reference Architecture (UKRA) v1.0
This diagram illustrates the start point for a Business Capability Model. This is a static view based on the style of IBM’s Component Business Model. This is a style diagram that has become quite popular.
The whole matrix represents all the Business Capabilities that the organisation performs. Each cell is a Business Capability.
The Columns usually reflect the high level value chain for the organisation or are major groupings of Business Capabilities that are meaningful to the business.
The Rows reflect the fundamental purpose of a Business Capability and there are normally three rows:
| Row | Aligned to the Viable System Model (VSM) system type |
| Direct (or Strategy) | System 5 and system 4 |
| Control (or Management) | System 3, system 3* and system 2 |
| Execute (or Operate) | System 1 |
For details about VSM, the Viable system Model see http://en.wikipedia.org/wiki/Viable_System_Model and my earlier blog posts.
Business Capabilities also have dependencies between them. I.e. one Business Capability has to exist before another Business Capability can be achieved.
Implementing Business Strategies requires new or changed Business Capabilities, but for the most cases we are just changing some aspects of the Business Capability rather than introducing brand new ones. This is the Capability Increment.
Relationship between Business Capabilities, Enterprise Architecture and projects
Figure 2: Diagram showing Business Capabilities Source: TOGAF
The diagram above shows the relationships between Business Capabilities and Capability Increments, and also related the Enterprise Architecture development method phases and definition of work packages for the Programme and Project Portfolios.
Capability Increments document the changes to each Business Capability that are needed to implement the Business or IT Strategies.
Each Business Capability is decomposed into one or more Capability Increments that are typically implemented at different points in time and in different Transition Architectures. Each Capability Increment represents a unit of change.
Capability Increments also have dependencies between them. I.e. one Capability Increment has to be implemented before another Capability Increment can be achieved.
Figure 3: Capability Dependency Model
The diagram above shows the dependency relationships between the Business Capabilities and between the Capability Increments.
The Capability Increments can be rearranged to show the dependency order in which they need to be applied. This sequence forms the basis for the EA Roadmap.
Figure 4: EA Roadmap structure
Often it is may be useful (and politic) to represent several tracks in the EA Roadmap. For example tracks may be introduced for Strategic changes, Business changes and IT changes, since Capability increments may be identified in such a way that they can be implemented in parallel.
The Capability Increments can be grouped into Transition Architectures. A Transition Architecture is an intermediate Architecture model somewhere between the current state and the future (target) state Enterprise Architecture model being aimed for. A Transition Architecture will typically be aligned to intermediate and temporary stages in implementation.
Groups of one or more Capability Increments will provide the mandate for a solution or service to be developed in a project.
A Business Capability Model should be at the core of all Enterprise Architecture Models.
Often the Architecture Vision Model or Core Model is produced as a Business Capability Model to provide a strategic view that helps all stakeholders in an organisation to develop a common understanding of what needs to be done and what needs to be changed.
(With thanks to Lee Hepplewhite for some aspects of this approach)
EA Voices
16 June 2013
I have recently come across a web site EA Voices (eavoices.com/) produced by John Gøtze.
This is described as an Aggregated Enterprise Architecture Wisdom and I have found it to be a good collection of articles and recommend it to all Enterprise Architects out there.
How to measure Enterprise Architecture
16 June 2013
What is Enterprise Architecture
Enterprise Architecture is essentially a strategic planning discipline for ensuring that all the strategies of an enterprise are well executed. How should we measure it and how it is performing?
First it’s best to clearly understand what Enterprise Architecture is and who it is for.
Enterprise Architecture bridges the gap between those decision makers who come up with new strategies and objectives and those who are involved in enterprise transformation and investments in change. It is about what the enterprise can do now (baseline capabilities) and what it wants to be able to do in the future (target capabilities).
Enterprise Architecture is all about keeping an organisation robust, viable and continuing to satisfy all its stakeholders in the future, who are interested in the enterprise succeeding and continuing to succeed i.e. the CxOs, Shareholders, Customers, Partners, Suppliers etc.
The Enterprise Architecture deliverables are a conceptual blueprint or Target Operating Model that explicitly defines the mission, vision, strategies, objectives, principles, standards and business capabilities at the strategic level, as well as all the other elements (component types) in the enterprise that define how the business operates. These elements include business functions, business services, business processes, scenarios, value chains, value streams, products, application services, applications, technology and infrastructure and are defined within the following Architecture domains:
| Architecture Domain | Typical object types in the domain |
| Market/Environment | Supplier, Partner, Shareholder, Stakeholder, Regulator, Customer, Contact, Prospect etc. |
| Strategy and Motivation | Drivers, Mission, Vision, Strategy, Objective, Measure, Metrics, Principle, Standard etc. |
| Business | Business Capabilities, Business Functions (Value Chains), Business Process, Strategic Scenarios (Value Streams), Events, Products, Business Services, Organisation Units, Persons and Roles etc. |
| Information | Business Information, Application Data, Stored data (Databases, Files etc.) |
| Applications | Application Services, Applications (Suites, Packages, Components etc.) |
| Infrastructure | IT Infrastructure (Hardware, Nodes, Networks, Devices, Appliances, Servers etc.Physical Infrastructure (Buildings, Facilities, Vehicles, Machinery, etc.) |
Enterprise Architecture also provides several different views of how an enterprise operates and changes, by maintaining a baseline enterprise (operating) model, target enterprise (operating) model(s) and a roadmap of changes to the enterprise’s business capabilities and investments in change ordered within an enterprise transformation roadmap.
Measures and metrics
A large number of organizations use Enterprise Architecture approach in order to plan strategic changes and manage enterprise transformations. Enterprise Architecture is not directly linked to a direct outcome but is usually indirectly related.
One of the major concerns is the failure of many enterprises to actually measure the value of their current or baseline Enterprise Architecture. One is reminded of the old adage ‘What you don’t measure, you can’t manage’. When changes occur as a result of new strategies and target enterprise models, the subsequent enterprise transformation may well be many months or years into the future. Changes are delivered by other groups inside the enterprise or external solution delivery partners. If measures and metrics are not used and actively managed then it becomes rather difficult to compare the old baseline with the new baseline to see what value has been achieved.
Identify the Metrics
The measuring metrics will vary from one enterprise to another. As Enterprise Architecture exists to support the CxOs and decision makers within the enterprise then it is important to define the metrics from their perspective.
Metrics can be identified form a number of perspectives.
Broadly these can be grouped into:
| Categories | Description | examples |
| Internal (Inside Out) metrics | Metrics that measure the internal efficiency of the enterprise’s functions, processes, applications, infrastructure |
|
| External (Outside In) metrics | Metrics that measure the way the enterprise operates from the perspective of those stakeholders outside the enterprise. |
|
| Change related metrics | Metrics that measure how well the enterprise transformations are being achieved |
|
More detailed metrics can defined for each Architecture Domain. Here below is a discussion of some of some potential metrics used for measurement of their enterprise architecture’s value.
CxO’s Metrics
The Enterprise Architecture is by definition the architecture of the enterprise, so the metrics also need to be defined from the enterprise or business perspective. The CEO and other CxOs are responsible for managing the enterprise so the metrics need to be ones that they are interested in and keen to measure. These may include:
- Completed transactions
- Revenues
- Operating expenses
- Profit
- Revenue per dollar of operating cost
- Profit per completed transaction
- Productivity
- Profits per investment
The trends and rates of change in the numbers are often more important than the actual numbers.
If the enterprise strategies and therefore the target Enterprise Architecture are not having an effect (directly or indirectly) on the numbers that the CEO is interested in, then the Enterprise Architecture is not being effective.
Customer experience metrics
One of the biggest contributions to Enterprise success and profits is the overall customer experience and satisfaction. There are three categories of Customer experience metrics:
| Category | Description | Examples |
| Descriptive Metrics | About what happened when a contact, prospect or customer engages with the enterprise |
|
| Perception Metrics | What did the contact, prospect or customer think about what happened |
|
| Outcome Metrics | What will the customer do as a result of what happened |
|
These metrics measures how happy a customer or prospective customer is with the enterprise’s value proposition (their products and business services). What value is provided to the customer? This measure is becoming common with value based pricing approaches. How easy is it for the customers to do business with you? Do the enterprise business services provide for the needs of the customer’s own internal processes? Customer Satisfaction can be increased by better communication with them through their preferred channel, so a measure of Customer communications (messages and interactions, social media) can be useful.
Cost Benefit
Cost/Benefit ratio to measure the value of any new or changed business capability. This is used to compares the amount of money spent on the transformation (costs) to the amount of money that is being saved after the implementation of the changes (Benefits). These metrics are often measured in terms of money, but in fact the benefits may be non-monetary values such as increased sales, improved customer satisfaction, reduction of risks, increased flexibility, and improved platform for future change.
Productivity and Effectiveness
CEOs will be concerned with the effects of Enterprise Architecture and new investments on production, efficiency and effectiveness. Metrics in this area can focus on:
- Reducing time to market for new investments in change
- Integrating and improving business processes across the enterprise (including with partners)
- Improving the ability to integrate data and interfaces across the enterprise (including with external partners)
- Improving the ability to reuse business functions, business processes and application services
- Increasing agility, flexibility and ability to rapidly change in the event of new strategic scenarios occurring
- Increasing standardization
- Reducing the time taken to develop solutions by maximizing reuse of enterprise architecture models
Governance and compliance
Enterprise Architecture ensures that the strategies of the enterprise are realised.
How many business capabilities are being created, updated or removed? What capability increments are being turned into investment proposals and providing the mandates for new programmes and projects? How many capability increments are being delivered by the solutions that have been subsequently designed and developed? How well are the solutions in compliance with the target enterprise architecture model?
Knowledge
The Enterprise Architecture function will create a well-populated repository of knowledge about the current state of an enterprise and its planned future state vision. The enterprise Architecture models provide a knowledge base for CEOs, CxOs and other decision makers that provides answers to their questions. In essence an enterprise architecture model needs to be designed to answer all their potential questions. How well does it achieve that?
These questions can be about gaps, impacts, dependencies, probabilities of success and failure, risks, costs etc. One of the major concerns of Enterprise Architecture is to reuse the knowledge, information and data as required by various processes and applications throughout the enterprise. Metrics can include the percentage completeness of this knowledge base. How easily and readily available is this knowledge throughout the enterprise to those stakeholders who need it?
A Common Vision of the future state
The whole purpose of Enterprise Architecture is to align investments in change with the strategies for the future of the enterprise. The target Enterprise Architecture Model is the target operating model that provides a common vision for all parts of the enterprise, including internal business units and external partners. How complete is this model and all the associated diagrams and documentation? Is it readily available?
Enterprise Transformation
The target enterprise architecture model will reduce the time it takes to conduct a particular enterprise transformation, implement new and changed business capabilities and reduce solution design and delivery time and development costs by maximising reuse of the enterprise level models. It will provide standard components and ensure maximum reuse of them across the whole enterprise. Over time the enterprise architecture will ensure faster development, fewer failures and better alignment to strategic enterprise level requirements and continual improvement.
Qualities
The Enterprise Architecture is often focused on improving or enabling various characteristics and qualities in the future.
Metrics can be based on these qualities can include:
- Efficiency
- Robustness
- Reliability
- Viability (ability to remain viable in a changed environment)
- Flexibility (ability to automatically adapt when unexpected external changes occur)
- Complexity
- Agility (Ability to adapt to changing business needs)
- Adaptability
- Ease of integration
- Amount of reuse
- Support for innovation
- Service level
- Quality
- Accuracy
In conclusion
Enterprises need to measure Enterprise Architecture by how well it improves the performance of the whole enterprise, meets its business needs, and supports its strategies and investments in change.
Enterprise Architecture Survey
16 June 2013
A friend of mine Ian Glossop, is doing a survey of views on Enterprise Architecture, and as many of you are Enterprise Architects he would appreciate your views on the subject.
I know your time is precious, and the survey is a little long, but nevertheless may I urge you to take a little time to complete it.
The survey is implemented as a PDF form, with the ability to save the data you enter and so may be completed and emailed back to:
Ian Glossop ( ian.glossop@glomal.co.uk) at your convenience.
The form may be downloaded from here:
http://www.glomal.co.uk/EASurvey/EASurvey.pdf
Ian is doing this as part of an MSc course in Technology Management with the Open University, so he would very much appreciate your help.
The thesis that Ian is testing is twofold really:
- That there is a common core to the diversity of EA methods/methodologies and
- That it is a new-ish (if you can call 25 years old ‘new’) integrative discipline.
If you would like a copy of the results, simply let Ian know and he’ll send you something in September or October.
Thanks.
Business Architecture
23 March 2013
Tom Graves recently participated in an Open Group TweetJam on Business Architecture. You can read about the results of this at http://weblog.tetradian.com/2013/03/20/opengroup-on-bizarch/
Unfortunately I didn’t hear about this in time to participate but I thought I’d record my own thoughts here.
The questions were:
- How do you define Business Architecture?
- What is the role of the business architect? What real world business problems does Business Architecture solve?
- How is the role of the business architect changing? What are the drivers of this change?
- How does Business Architecture differ from Enterprise Architecture?
- How can business architects and enterprise architects work together?
- What’s in store for Business Architecture in the future?
How do you define Business Architecture?
Business Architecture is one of the primary domains within Enterprise Architecture. It deals with the architecture of the business, ideally from a business perspective and is expressed in business terminology.
It should not really be considered a separate discipline from Enterprise Architecture but often is by those who persist in misunderstanding that Enterprise Architecture is only about IT and not about the whole of the enterprise.
Business Architecture deals with the structure and design of how an enterprise operates, makes money or delivers value, how it organises itself in order to provide products and business services to its customers, clients and consumers. It should be expressed independently of how the business architecture will be mapped to the underlying application architecture and infrastructure architecture, but is more connected to the business/contextual view of the information/data architecture and will include the organisation architecture.
Business Architecture is centred on the business and the business strategy, not on IT or on the IT Strategy and should not be considered just a source of requirements for IT projects (which is the impression that TOGAF gives of Business Architecture).
In general Business Architecture includes the following deliverables:
A Business Architect is primarily concerned with supporting and advising the senior executives, providing advice and guidance, and influencing decision making for the Business Architecture domain.
What is the role of the business architect?
As a specialised type of Enterprise Architect, they are in a leadership role, close to business management working for the CxOs to evaluate and elaborate possible future strategic scenarios.
They have a responsibility to guide, recommend and oversee the realisation of the business strategies identified by the CxOs, but they don’t control the business strategy or make the actual investment and strategic change decisions.
What real world business problems does Business Architecture solve?
As a type of Enterprise Architect, a Business Architect deals with strategic change, business transformation activities concerning topics such as:
- Ecommerce changes
- Consolidation
- Cost reduction
- Process improvement and efficiency
- New organisation design
- Mergers & Acquisitions
- Reuse of shared services
- New markets
- Regulatory and legal changes
One should not forget that, by definition, an Enterprise Architecture model covers everything about the enterprise including the environment and market which it operates in, its Business Strategies, its Business Architecture as well as the rest of the Enterprise Architect domains.
How is the role of the business architect changing? What are the drivers of this change?
The role of a Business Architect is becoming much more distinct than it has been. many organisations are maturing their enterprise architecture functions that were previously just centred on IT architecture and are now specifically introducing a Business Architect role.
How the Business Architect role differs from other roles such as a Business Analyst, Business Change manager, Business Transformation Manager etc. is still playing out. I discussed this to some extent in a previous blog post – The difference between a Business Architect and a Business Analyst.
Another current difference is that a Business Architect is often closely associated with the Business units (and perhaps reports to a business line manager of sorts) and therefore is seen as being on the ‘Demand’ side of a business, whereas the rest of the Enterprise Architects (including IT Architects) are often lumped into the IT department and therefore are seen as being on the ‘Supply’ side. In theory, the Enterprise Architects, including Business Architects, should only ever be on the ‘Demand’side and not seen as part of IT. They should report to the CxOs, ideally seen as part of a CEO Office.
How does Business Architecture differ from Enterprise Architecture?
A Business Architect is a type of (a ‘real’) Enterprise Architect. Business Architecture is a sub domain of Enterprise Architecture.
How can business architects and enterprise architects work together?
Of course they can. The distinction in the question is artificial anyway, since a Business Architect is just a type of Enterprise Architect that specialises in the Business Architecture domain.
But in reality many organisations do have an unfortunate tendency to make up their own interpretation of what these roles actually are.
What’s in store for Business Architecture in the future?
We will see more and more Business Architecture roles in the future as organisations mature their enterprise architecture strategy and capabilities, and they realise that they need to get to grips with their business model and how it is realised. They will need Business Architects to help them do that.
For most enterprises embarking on large scale strategic planning and business transformation programmes it is all about staying robust, viable and efficient, continuing to deliver good outcomes and value to their customers/consumers/clients in the future. Enterprises should be wanting to stay competitive and efficient and beat the competition.
If the enterprise is to succeed, it must make strategic decisions and investments in change based on a thorough architectural gap analysis/impact analysis that is only possible with business architecture as a key part of their enterprise architecture function.
Adrian Campbell
21 January 2013
EA is Strategic Planning
20 January 2013
Enterprise Architecture quite simply is all about Strategic Planning. It helps enterprises shape their future structure and dynamics in the face of the changing environment in which they do business. Its purpose is to understand the ends and means that form the strategies needed.
How does an enterprise react to events that do and will potentially occur and arrive at the strategies needed to remain robust, efficient and viable, to continue to deliver value and make profits for themselves?
Enterprise Architecture is the corporate discipline that helps us to understand the questions that need to be asked and get better at strategic thinking. The approach is based on asking the usual Why, What, How, When, Who and Where questions:
- Why does the enterprise need to change?
- What are the drivers for change?
- Are the drivers fully understood?
- What is the mission and purpose of the enterprise?
- What do enterprises need to do and need to understand? What do their customers and stakeholders want?
- What is possible to do?
- What are the strategies, goals and objectives?
- How will these be achieved?
- What business capabilities are needed?
- When should the enterprise react to new opportunities? What are the potential business scenarios that might occur? How will the enterprise react when they do occur? And how should it react?
- Who should be involved?
- Where is the enterprise?
- What environment or markets is it located in?
- How many different environments are there?
- What would success look like for strategic planning?
These should all be open questions. You should take care that the questions don’t upset those executives that are responsible for the current answers and are asked in an ego-less fashion.
All of these answers can be modelled and analysed with your favourite enterprise architecture tool. I like to add a Strategy domain to the usual Business Architecture, Information Architecture, Application Architecture and Infrastructure Architecture domains.
Enterprise Architects should start to think like a strategist instead of just like a technologist.
In real life the answers from our questions are usually complex and enterprise architects will typically develop a number of different target enterprise architecture scenarios to explore all the options. These can be analysed and
What I find curious though is that I have never seen any mention of Enterprise Architecture approaches and techniques in any Strategic Planner job specifications. These job specifications may include requirements such as :
- Maintaining a clear picture of the external environment
- Development of vision, strategies, goals and objectives
- Identifying and assessing merger and acquisition opportunities
- Facilitating the on-going development of strategic and associated implementation plans (i.e. Roadmaps)
- Providing an ad hoc research and analysis capability
- Conducting market and competitor analysis
- Interacting with the board executives, and other senior internal and external stakeholders
- Business and commercial awareness
TOGAF9 and ArchiMate already both include Motivation concepts, so now more and more Enterprise Architects are modelling Drivers, Goals, objectives, Measures, Values as well as Products and Business Services.
Isn’t it about time that Strategic Planning starts to make use of the value and benefits of the enterprise architecture capability?
The same point also applies to Enterprise Architecture and Business Transformation. In my view Enterprise Architecture is the glue that joins these approaches together.
Going from just good enough to being great
4 September 2012
I recently saw a Forrester blog entry from George Colony at: http://blogs.forrester.com/george_colony/12-08-27-enterprise_architects_for_dummies_ceos
And recently I’ve been reading an interesting book called Good to Great by James Collins. See http://en.wikipedia.org/wiki/Good_to_Great
The Forrester blog talks about succeeding with realizing the business strategy by involving enterprise architects, whereas the Good to Great book doesn’t mention enterprise architects but just talks about needing the best people to achieve great things.
It raises the question ‘Does an organisation need enterprise architects to achieve greatness?’, and ‘What does an enterprise architect need to do to be great themselves?’.
An Enterprise architect will certainly bring a logical enterprise-wide view of strategic change, usually cutting across organisation boundaries. They will look at the strategic design of the enterprise vision in terms of interconnecting business capabilities, where a business capability is a similar concept to a ‘system’ as described in system thinking and the viable system model. They will help with the business thinking.
But is this how senior executives see strategic change?
I’ve experienced organisation restructuring close up at a large number of organisations over recent years and in all cases, the enterprise architects were not involved at all. The re-structuring tends to be done along business functional lines. Nothing wrong with that perhaps, but it does tend to bake in the old silo boundaries and restrict cross functional reuse of business capabilities.
Is this good or great, or merely good enough?
How do senior executives see enterprise architects?
Enterprise architects work with the executives, senior business stakeholders and heads of all the business functions to build a holistic enterprise architecture vision model that links the enterprise’s mission, business strategies and priorities to the current and future needs in an efficient and viable fashion.
For enterprise architects it’s typically not sufficient to merely produce a good vision and good roadmap, but the focus should be on producing a great one that is robust and viable way into the future.
Quick and dirty is not a great approach and is often a waste of money from a long term enterprise perspective.
There will inevitably be a sort of creative tension between the various lines of business and enterprise architecture. Part of the reason for this this is that the lines of business invariably take a top down view and the enterprise architects are naturally working across functional silos. There is often a sort of conflict of overlapping RACIs, a clash of who appears to be responsible for making a decision. Generally that is easy, it’s the business strategy owned by the business that makes the decisions.
But as George Colony observes in his blog, it’s the enterprise architects that span both the business and technical domains and act as ‘an internal trusted advisor who marries the best interests of the business with long-term technology strategy’.
An analogy is within the realm of politics, where the politicians take the decisions helped and supported by their advisors. Also like politics, the lines of business are often challenging each other and pandering to popularity polls.
This raises another thought, should an enterprise architect be popular or be professional? Can they be both at the same time? Should an enterprise architect indeed be a kind of politician following the whims of the time, or should they be seen to be standing up for doing the right things for the future?
Tactical short term changes are invariably much easier to build a business case and obtain investment for than multi-year long term strategic changes will ever be. Should an enterprise architect just focus on short term fixes, or do their job and focus on strategic change. Like a politician, should an enterprise architect aim to be liked and popular, or respected for their work furthering the best interests of the enterprise?
It’s rather like a politician who can only achieve changes within a single parliament, and therefore shies away from embarking on initiatives that will take a long time and multiple parliaments to achieve. Should an enterprise architect just be popular and play politics? Does this make an enterprise architect great? In fact, what does make a great enterprise architect? Ideally 40% of our job is communication. Maybe communication really means playing to the populous crowds? Does promising bread and circuses make things great?
James Collins says that good to great companies follow the principle of “First Who, Then What” and hire good people. Collins talks about good CEO’s typically have much humility. So maybe a great enterprise architect should also be humble? Perhaps a great enterprise architect is one who makes great decisions? But then if it is only the lines of business who make the decisions, what then? Often the enterprise architect is not in the position to make enterprise level decisions, only recommendations.
To be great enterprise architects should be focused on being neutral and not taking sides, working faithfully for the enterprise as a trusted advisor, taking the enterprise in whatever direction it chooses to go at whatever speed it wants to go, realizing the collective enterprise vision. In turn, the enterprise needs to treat enterprise architects as true trusted advisors and not just delivery agents. Enterprise architects should follow a set of principles, be honourable, forthright and avoid compromise, keeping the organisation honest. Maybe in doing that they won’t always be popular but they will be doing their job.
It has been said that ‘business leaders rarely succeed in marrying empirical rigor and creative thinking’, so it is the enterprise architects task to help them do this better and achieve a great enterprise and not just one that is just good enough. Just good enough is never good enough.
In my opinion, without enterprise architects, an enterprise cannot easily become great and may only achieve greatness through simple luck.
The purpose of Enterprise Architecture
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.
Strategy Planning and Enterprise Architecture – dealing with the devil in the detail
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.
Demand and Supply
12 June 2011
Further to my last post, it occurred to me that another major difference between a Business Architect and a Business Analyst is that the Business Architect is a role on the demand side and the Business Analyst is on the supply side.
The Business Architect identifies the future demand for changes to the enterprise business model and associated business operating model and plans the change initiatives on the business part of the enterprise architecture roadmap.
The Business Analyst works in the here and now on how to satisfy the current business requirements for a single change project, where the project realises part of the supply schedule whereas the EA roadmap represents the future demand schedule of strategic changes.
The demand /supply distinction is clearer if the Business Analyst works in the IS/IT division since IS/IT often represents itself as a business (‘IT as a business’).
Interestingly the very concept of ‘running IT as a Business’ is counter productive and creates an unnatural barrier within an organisation. The IS/IT division is part of the business after all. Several commentators see this concept as a train wreck waiting to happen.
See http://www.infoworld.com/d/adventures-in-it/run-it-business-why-thats-train-wreck-waiting-happen-477 and http://www.itskeptic.org/dont-run-it-business-run-it-part-business
One could argue I suppose that if IS/IT is run as a business then the so called ‘Business’ will appreciate what IS/IT does for them.
But the problem with that (as seen in Chris Potts excellent story ‘FruITion’) is that IS/IT will not be invited to the top table where strategic decisions are made. See – http://www.amazon.co.uk/fruITion-Creating-Corporate-Information-Technology/dp/0977140032
I was recently asked what I thought was the difference between a Business Architect and a Business Analyst.
Broadly speaking I see the difference as being similar to the difference between an Enterprise Architect and a Solution Architect. i.e. one works at a Strategic level across the whole enterprise and the other works at a project level on a specific business domain or capability area in detail.
However the distinctions for Business Architects and Business Analysts are often far less clear.
This is because the terminology used by different organisations to describe a Business Analyst ‘s roles and responsibilities varies considerably from one organisation to another, and even fewer organisations have fully defined the role of a Business Architect.
Very often someone called a Business Analyst may in fact be working either as a Business Strategist, or as a Business Architect or as a Systems Analyst or as all three roles.
The following table illustrates the generic differences as I see them.
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:
- Operations
- Co-ordination
- Resource and Performance Delivery
- Monitoring
- Development
- 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.
Further reading at http://coherencyarchitect.com/2011/01/29/the-fractal-organization-in-an-enterprise-architecture-point-of-view/
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.
Establishing an Enterprise Architecture function
3 January 2011
When establishing (or indeed re-establishing) a brand new Enterprise Architecture function within an organisation there are perhaps two main approaches:
- A big bang approach
- A gradual iterative incremental approach
I favour the big bang approach. This is for several reasons:
1) a big bang send a clear and confident message to everyone in the organisation that things WILL be done differently
2) a big bang provides a clear mandate, mission, vision and positioning for the Enterprise Architects, sidetracking threats and challenges from others who feel threatened by the emergence of EA
3) a big bang ensures that the Enterprise Architecture function is given a solid budget and is established through a strategic change programme, complete with programme manager
4) a big bang has clear reporting to the CEO or appropriate C-level executive (since responsibilities vary from company to company) and clearly defined outcomes
5) a big bang needs clearly visible and continuous [sic] executive support
6) a big bang must have clear goals, objectives, measures, performance targets etc. Enterprise Architecture must be part of the business strategy to improve the organisation’s effectiveness and profitability.
7) a big bang ensures that proper effort is made choosing an appropriate EA framework, Meta Model, Process and EA tool
8) a big bang is JFDI on a large scale – get the whips and carrots out and get it done right first time ! Make it So !
Don’t get me wrong, iterative approaches do work well with established processes such as software development, but not for the introduction of new functions and processes that haven’t previously existed.
Establishing an EA function in small iterations is giving ammunition to challengers and doubters. There tends to be no mandate, no or limited budget, a quick and dirty mindset, limited access to experienced consultants, no EA tools, overall limited maturity.
It sends a message to the staff that the executive management is not sure, is not confident, and won’t invest in the success of Enterprise Architecture.
It’s a bit like changing governments, you don’t do that iteratively do you?
As Niccolo Machiavelli once said ‘Tardiness often robs us (of) opportunity, and the dispatch of our forces’.
Enterprise Architecture as the Office of the CEO
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:
PLAN
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
DO
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).
CHECK
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.
ACT
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
Activities of the Office of Enterprise Architecture
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… ’
Making Strategy Work with Enterprise Architecture
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?
No?
Me neither – I think you need some glue.
by Ian Glossop, Enterprise Architect.
How to elaborate a Business Model with Enterprise Architecture?
8 December 2010
How does an Enterprise Architecture and a Business Model work together?
Successful organisations are those that improve and innovate their Business Models to find a profitable niche against their competitors.
But a new Business Model alone is not enough. It needs to be implemented and executed. This is where an Enterprise Architecture comes in.
If organisations do not align their Business Model and their Enterprise Architecture then how can they be certain of making it work?
The first step is integrating the Business Model with the Business Architecture part of the Enterprise Architecture. This is described below.
Business Model Canvas
Business Model innovation is rapidly becoming a hot topic and especially with the release of the book ‘Business Model Generation’ by Dr Alexander Oesterwalder. http://www.businessmodelgeneration.com/
This book introduces a standard way of developing a Business Model called the Business Model Canvas. If you are an Enterprise Architect highly recommend you read it.
Up to now most organisations had their own informal and idiosyncratic way of defining a business model that was unique just to themselves. This is the first time a standard for developing a business model has been defined and published.
The Business Model Canvas is a powerful approach for business model design and innovation.
It captures the 9 most essential elements of a business model in a simple way, enabling the design of a ‘business model on a page’.
The 9 different segments are
- Customer Segments
- Customer Relationships
- Channels
- Value Proposition
- Key Activities
- Key Resources
- Key Partners
- Cost Structures
- Revenue Streams
You can see some example Business Models developed with the business Model Canvas at http://www.businessmodelalchemist.com/ and on an associate web site where you can view a variety of example Business Models and try creating your own can be found at http://bmdesigner.com/ .
So what does all this have to do with Enterprise Architecture?
Enterprise Architecture exists to provide a path between strategy and execution, identifying the current state and the desired future state and plot a roadmap of strategic changes between them.
See book ‘Enterprise Architecture as Strategy’ – http://www.architectureasstrategy.com/book/eas/
Enterprise Architecture provides the organising logic and architectural thinking needed to design the appropriate business capabilities need to implement a Business Model. To get the right outcomes, organisations must focus on Enterprise Architecture and Business Architecture not try and jump straight to IT architecture and solution design.
After setting the overall mission and enterprise vision, the first Enterprise Architecture domain that we need to model and align with the Business Model is the Business Architecture.
Business Architecture Model
A Business Architecture model is used further elaborates the 9 high level concepts segments that have been populated with conceptual themes and business strategies in the Business Model Canvas. A number of techniques and approaches, views and artifacts are used to explore the themes and strategies in each Business model canvas segment.
Customer Segments
Create a Porter’s Five Forces model to explore the market and the general business environment in which the organisation exists. Also conduct a SWOT analysis.
Create a VPECT model to explore the Values, Policies, Events, Content (outcomes) and Trust relationships from the perspective of each different customer segment.
For details of VPECT read the book ‘Lost in Translaton’ by Nigel Green and Carl bate – http://www.lithandbook.com/
Customer Relationships
Create a Business Event model, further elaborating the Business Events identified with the VPECT model.
For each current and especially the future Events, create a Business Scenario. This should explore he what if questions that will effect the business model in the future.
Channels
Create a model of the various channels that exist between the organisation and its customer segments as well as between the organisation and its partners and suppliers.
Don’t forget those new social media channels, such as iPhone or Android phones and other devices and applications such as Twitter and Facebook. Partners can also be channels as well.
Create a model of the flow of business information between the organisation and its customers and between the organisation and its partners and suppliers (use the Actor Co-operation Viewpoint in Archimate).
Value Proposition
Use VPECT to explore what Value you provide to each customer segment and what problems you solve for them.
Create a Value Proposition Model of the Products, Business Services and associated Values (using the Product Viewpoint in Archimate).
Value Propositions drive Business Strategy, so create a Business Motivation Model to understand all the relationships between Vision, Goals, Objectives, Strategies and Tactics associated with the Value Proposition.
See http://www.businessrulesgroup.org/second_paper/BRG-BMM.pdf for details of the Business Rules Group’s Business Motivation Model.
Key Activities
Key activities includes any model of behaviour,
This should include both internal Business (organisational) Services, Business Functions, Business Processes and Activities as well as the external behaviour of your customers, partners and suppliers.
In some cases it is useful to think about behaviour in terms of external services (the what) and the internal behaviour (the how).
Create a Business Function Model (using the Business Function Viewpoint in ArchiMate). A useful approach to use here is the Component Business Model approach from IBM. See http://www-935.ibm.com/services/uk/igs/html/cbm-bizmodel.html
IBM’s Component Business Model provides a good basis for visualising the Target Operating Model in terms of Business Functions or in terms of Business Capabilities (they’re not the same thing…).
Create a Business Process Model (using the Business Process Viewpoint in ArchiMate). Business Process Models are not just Process Hierarchy Models but include Value Chains and Value Streams.
Create Value Stream models for each Event/Outcome pair (use the Business Process Viewpoint in Archimate) identified in the customer relationship segment above.
Create a Value Chain model at a high level for each customer segment (also using the Business Process Viewpoint in Archimate).
See http://www.opengroup.org/archimate/doc/ts_archimate/ for details of modelling the Business Architecture Layer in Archimate.
As they are high level abstract views, Value Chains are often specified more in terms of Business Functions than the more specific Business processes or Activities.
Key Resources
Resources in this segment can be further elaborated by the other Enterprise Architecture domains or Information Architecture, Application Architecture (and Application Service Architecture) and Infrastructure Architecture.
However before jumping to the IT Architecture it is better to start more conceptually and create an Enterprise Vision Model and a Business Capability model.
Enterprise Vision models are those high level one page models described as ‘core’ models in the book ‘Enterprise Architecture as Strategy’ (http://www.architectureasstrategy.com/book/eas/) and also in TOGAF Phase A.
You can also use the Layered Viewpoint in ArchiMate to produce Enterprise Vision Models.
Create a Business Capability model. This is usually a hierarchy model similar to a Business Function Model but remember that a Business Function and a Business Capability are two different concepts.
A Business Function is a high level view of existing internal behaviour from an organisational perspective, where the business functions are closely associated with the organisation units.
A Business Capability is defined by TOGAF9 as ‘A business-focused outcome that is delivered by the completion of one or more work packages’. A Business Capability is defined as the ability to execute a specified course of action, to achieve specific strategic goals and objectives. A Capability is defined in terms of the outcome of the course of action, one that has a business value. The concept of Capability is used in the military context and the MODAF framework where it is described in the abstract. See http://en.wikipedia.org/wiki/Capability_management and http://tinyurl.com/2vge39e
See also my previous post on Modelling Behaviour.
Create an Organisation model (using the Organisation Viewpoint in ArchiMate) to capture the human resources and their roles and responsibilities.
Create a Business Information Model (using the Information Structure Viewpoint in ArchiMate) to understand the knowledge, information and data resources within the organisation. Outcomes identified as Content in the VPECT model and in the Value Stream models are also modelled here as Business Information (represented by Business Object, Meaning and Representation object types in ArchiMate).
Key Partners
Identify your key partners, suppliers as carefully as you do your customer segments and customer relationships.
Don’t forget that Enterprise Architecture includes the extended environment as well as the organisation itself. This extended environment includes the Suppliers and Partners (use the Actor Co-operation Viewpoint in Archimate).
Cost Structures
Explore the costs with a Total Cost of Ownership (TCO) model. This can be a spreadsheet.
Create a System Dynamics Models to fully explore and understand the cause and effect relationships between different stocks and flows, and run simulations.
See http://en.wikipedia.org/wiki/System_dynamics
Revenue Streams
Also explore revenues with a TCO model as with the Cost Structures
Remember that revenue doesn’t always mean profits in terms of money, but can be other non-monetary outcomes of value, (especially relevant for Government departments, non-profit and charity organisations who seek outcomes in terms of benefits to citizens and indirectly, votes).
It is again very useful to produce System Dynamics Models to understand the cause and effect relationships between different stocks and flows.
I think it’s surprising that more organisations don’t use System Dynamics as part of their enterprise architecture modelling. More on that subject in a future post…
Other Enterprise Architecture models
Starting from the Business Model Canvas, the Business Architecture views described above are used to further elaborate the details of the business model and to understand what needs to be realised from a business perspective.
After that the Business Architecture model is aligned to the Information/Data Architecture model, the Application Architecture model and finally the Infrastructure Architecture model pretty much as usual. I mostly develop these models using Archimate combined with other concepts from TOGAF 9 as needed, using tool such as Avolution Abacus and BiZZdesign Architect.
Note that other variations of Oesterwalder’s Business Model Canvas are starting to emerge. This is a sure sign that the concept is an important one that is reaching a tipping point.
These other business model approaches include:
- The Enterprise Canvas described in the book ‘Mapping the enterprise: modelling the enterprise as services with the Enterprise Canvas’ by Tom Graves. See http://tetradianbooks.com/2010/11/ecanvas/
- The Startup Canvas. See http://thestartuptoolkit.com/Nfd68Us5EnDa/
Modelling Behaviour
19 October 2010
I frequently find that there is much confusion about the modelling of Behaviour in an Enterprise Architecture model, specifically between the concepts of Business Capability, Business Function and Business Process. The various enterprise architecture glossaries all differ in their definition of these.
For example the TOGAF ADM or ISEB definitions don’t help as much as they could.
TOGAF quite reasonably defines Capability as ‘A business-focused outcome that is delivered by the completion of one or more work packages. Using a capability-based planning approach, change activities can be sequenced and grouped in order to provide continuous and incremental business value’.
However elsewhere TOGAF says that ‘The term “function” is used to describe a unit of Business Capability at all levels of granularity, encapsulating terms such as value chain, process area, capability, business function, etc.’. This confuses Business Capability with a Business Function.
ISEB says that a Business Function is ‘An idealised or logical subdivision an enterprise’s capability.’ and also that a Business Capability is ‘A business function whose performance is the subject of management attention … It is usually a high level and cross-organisational business function.’ Other methods I have encountered confuse Business Functions with Activities and have Business Processes decomposing into Business Functions.
ArchiMate has the most clarity about Business Functions and Business Processes but doesn’t as yet define a Business Capability.
One of the first artifacts to be produced as part of a Business Architecture model is a Target Operating Model. This is where definition issues are often first seen.
A Target Operating Model is usually a view of the organisation structure showing the Business Functions that each organisation unit is responsible for, but often these are also rather casually referred to as Capabilities.
Even more casually, it’s not uncommon to find the Target Operating Model actually contains a mixture of Business Processes, Business Functions and Business Capabilities with some Business Services thrown in for good measure.
It’s time for a bit more preciseness, less fuzziness and better standard definitions. ArchiMate has helped enormously by providing a standard enterprise architecture language but it still allows some fuzziness. See http://www.opengroup.org/archimate/doc/ts_archimate/
Below I’ve described the definitions I encourage the use of.
Behaviour concepts
Business Capability
A Business Capability is defined as the ability to execute a specified course of action, to achieve specific strategic goals and objectives. A Capability is defined in terms of the outcome of the course of action, one that has a business value. The concept of Capability is used in the military context and the MODAF framework where it is described in the abstract. See http://en.wikipedia.org/wiki/Capability_management and http://tinyurl.com/2vge39e
A Business Capability is not a Business Function, but is a concept that encapsulates other objects, in particular Actors (organisation units), Roles, Policies, Standards, Skills, Business Functions, Business Processes, Products, Business Services, Application Services, Application Components and Infrastructure. A Business Capability is therefore used for managing units of strategic business change.
A military example of a capability might be ‘2000 air freight sorties’, ‘1 Tonne heavy lifting’ or ‘Personnel Recovery under fire’ (but not ‘Helicopter’ or ‘Flight Management’). A business example might be ‘eBusiness’ (or the ability to sell new or existing products and business services to customers via the internet).
Business Capabilities can be decomposed into component business capabilities creating a capability hierarchy. A Business Capability is named after the desired outcome.
Business Function
Business Function is an organisational perspective on behaviour. It is not the same as a Business Capability. A Business Function defines the ‘what’ behaviour that is associated with an organisational unit and modelled in a target operating model. In many ways the Business Function is equivalent to all the behaviour that is modelled in an organisational specific swim lane in a Business Process Flow view (i.e. a BPMN diagram). A Business Function is typically named with a suffix of ‘management’ (i.e. ‘Customer Relationship Management’), but could also be a single noun (i.e. ‘Billing’). Business Functions can be decomposed into component business functions, resulting in a business function hierarchy. A Business Function does not decompose into a Business Process or an Activity.
A useful example of a Business Function model is IBM’s Component Business Model, where the ‘components’ are (usually) Business Functions. See http://www-935.ibm.com/services/us/imc/pdf/g510-6163-component-business-models.pdf
Business Process
A Business Process is another perspective on behaviour and defines the behaviour from the ‘How’ (how work is done) perspective. It represents both a complete Business Process Flow and the elements in a Business Process Flow. A Business Process Flow view (i.e. a BPMN diagram) is a view that shows a sequence of sub-Business Processes or Activities that are triggered by a Business Event. See http://en.wikipedia.org/wiki/BPMN
The sequence of Business Processes can represent a Value Chain at a macro level or the detail elements in a Value Stream that is triggered by a Business Event and results in an outcome of value to the source of the Business Event, usually a customer. See http://en.wikipedia.org/wiki/Value_chain and http://en.wikipedia.org/wiki/Value_stream_mapping
A Value Stream is a more detailed version of a Business Scenario (TOGAF). Business Processes are named with a Verb + Noun phrase.
A Business Processes representing a Value Stream is named after the Trigger + Outcome i.e. ‘Order to Cash’ or ‘Prospect to Customer’
The Enterprise Business Architecture book is highly recommended as a source of examples of a Business Process Model with Business Processes representing Value Streams. See http://www.enterprisebusinessarchitecture.com/
High level Business processes are typically aggregations of more specific Business Processes (sub-processes) or Activities.
Business Processes can be decomposed into component business processes, i.e. into a business process hierarchy. At the lowest level of sensible decomposition (i.e. at one place, at one time, by one person or system) the elementary business process is usually called an Activity. Activities are what are modelled in a BPMN diagram and are realised by a person (providing an organisation service) or by an application service or application. An Activity doesn’t decompose into a Business Process or into a Business Function.
A macro level Business Process (i.e. representing a Value Chain, or a column in a Component Business Model) may be used to group a number of Business Functions. Note that there is a many to many relationship between Business Functions and Business Processes. One Business Function may group many Business Processes and one Business Process may be used by many Business Functions.
An example of this can be seen in the eTOM (Enhanced Telecom Operations Map) where Business Functions and Business Processes are orthogonal to each other. See http://en.wikipedia.org/wiki/ETOM
Business Service
A Business Service represents an external view of the services an organisation provides or sells to its customers alongside the sale of a Product. A Business Service may be realised by a Business Function or directly by an Application Service, but is more usually modelled as being realised by a Business Process.
Business Services can be decomposed into component business services i.e. into a business service hierarchy. I’ve also found it useful occasionally to create a Business Service Flow view, which is similar to a Business Process Flow view but seen from an external customer’s perspective instead of the internal ‘How’ perspective of a Business Process Flow view.
Clarification of all these Behaviour concepts is an important step towards improving and evolving a common understanding of the business architecture layer within all enterprise architecture models.
Adoption of ArchiMate in the UK
14 October 2010
- BiZZdesign Architect
- Avolution Abacus
- Sparxsystems Enterprise Architect
- IDS Scheer Aris,
- Casewise
- System Architect
- Salamander MOOD
- Archi
Smart Enterprise Architecture
5 September 2010
Organisations need a new paradigm. In order to survive, old dogs are going to have to learn new tricks. They need to start fundamentally thinking about how to change the way in which they innovate, think and make decisions. To allow future operations to be more efficient, c-level executives and senior managers will need more accurate and real time information for better decision making and to optimise business strategy execution.
At a strategic level they need to leverage existing expertise and technology to deliver the capabilities they desire. Organisations will need to provide their decision makers with access to enterprise knowledge, allowing them to gain the insights that will enable the best alignment of operational performance with business strategy and objectives.
For effective knowledge management and information sharing they will not only need Enterprise Architecture, but will need Smart Enterprise Architecture.
The vision of Smart Enterprise Architecture is an approach that will enable information to be captured in real time, analyzed and proactively used to enhance business performance through predictive risk-based decision-making.
Sign up to Download the Diagram
See also IBM on predictive Analysis at http://tinyurl.com/39sdn3p
In the past, the technologies used in organisations have been relatively simple, now organisations will need to become ‘smart’.
What can make Enterprise Architecture smart is not new technology in itself, but rather innovative ways of combining existing state-of-the-art measurement and feedback mechanisms that can respond to changing conditions and allow an organisation to be agile and adaptable.
This vision is similar to that of Stafford Beer in his Viable System Model which he first described back in 1972. A Viable System is any system organised in such a way as to meet the demands of surviving in a changing environment, primarily by being adaptable. See http://en.wikipedia.org/wiki/Viable_System_Model
If he was still around today Stafford Beer would probably have been an enterprise architect.
To make Enterprise Architecture smart we have to gain value from examining the approach to process optimisation in other industries, such as the car industry.
In the not too distant past when a car was serviced, the diagnostics and fine-tuning of its systems were performed manually, with simple tools, skills & experience and heavy lifting. By contrast, the modern car engine is simply plugged into a computer diagnostic system which interfaces with the car’s onboard computers. The computer is linked to dozens of digital sensors that instantly monitor all the car’s systems and informs the mechanic what adjustments are needed. The car’s computer continuously controls its engine management system in real time as you drive along, optimally adjusting the engine parameters to adapt to the driving conditions and your driving style to maximise economy and minimise emissions.
So for Smart Enterprise Architecture we need the same kind of continuous state-of-the-art measurement and feedback value stream to control and adapt the organisation in real time. The following diagram illustrates the use of Enterprise Architecture in a continuous value stream or ‘value loop’.
See paper http://tinyurl.com/2em3k3m and also Deming’s Plan, Do, Check & Act cycle and Six Sigma’s Define, Measure, Analyze, Improve & Control cycle.
Once the Enterprise Architecture models are established it will be possible to make them the centre of predictive analysis, enabling the generation of strategic options in response to the real time changing behaviour of the enterprise.
Those strategic options can be kept in compliance with the business strategy, goals and objectives to continuously provide the best way to optimise value.
Organisations will need to look outside themselves and their traditional partners to find new skill sets and capabilities in order to develop a Smart Enterprise Architecture.
Join the Enterprise Architect community
This post is also available at http://tinyurl.com/29qunfd
A good decision is based on Enterprise Architecture
28 August 2010
There are still organisations that have not yet established an Enterprise Architecture function.
A simplistic and immature view of the Enterprise Architecture function is that it is only used to create a target architecture model for the IS/IT architectures that enable the IS/IT Strategies, create IS/IT roadmaps, and generally act as a Technical Design Authority for solution development projects.
But is this all that the Enterprise Architecture function is used for?
No, Enterprise Architecture also is a key enabler for decision making, what if analysis, gap analysis and answering the question “What business problem are we solving?”.
For the C-level executives in an organisation there just is not enough detail available to answer their questions, so they often appear to look for simple and quick answers to difficult and complex problems. This is not usually good decision making.
Business users frequently think of their business strategy in terms of decisions about technical solutions.
Are business users best placed to make these technical decisions?
They need to think about what their needs are how and think in terms of what business capabilities they need before rushing to ‘solutioning’.
There is a need for thinking and decision frameworks to help c-level executives and business leaders make their decisions.
What then, is a thinking and decision framework?
Decisions are made at every level across an organisation about:
- New Investments or business as usual changes
- Formal or Informal changes
- Tactical or Strategic changes
- Secret or well known changes
- Business or IS/IT changes
But does anyone actually know all the decisions that are being made in an organisation?
Questions are often asked within organisations at all levels:
- What decisions are IS/IT making?
- What decisions Business are making?
- Who should make decisions anyway?
- What decisions have been made?
- What if I don’t like the decision?
- Are the decisions still valid?
- Do I need to comply with the decision anyway?
Is the right decision being made – How would we know?
Are decisions being made without thinking, evaluation, pilot studies, use of facts etc?
Frequently this appears to be the case!
What makes better decision making?
- Business intelligence
- System thinking / System Dynamics
- Management models such as Porter’s Five Forces
- Thinking frameworks such as VPEC-T
What about using Enterprise Architecture helping to improve decision making?
Do you remember the mantra of ‘IT Enabled Business Change’ often used by government departments?
Shouldn’t this now be a new mantra of ‘EA Enabled Strategic Change’?
Remember, ‘When technology leads, it’s not enterprise architecture’!
Enterprise Architects are strategic assets, organisations should use them as such, at a corporate level, to support better decision making and for creating a solid foundation for the execution of the business strategies?
Existing policy making or decision making processes need to be adapted to make use of the Enterprise Architecture function, and most business change should be viewed as EA-enabled strategic change.
We are used to the idea that Enterprise Architecture function establishes an EA Governance process, an Enterprise Architecture Review Board and an EA Compliance process to guide the activities and deliverables of solution architects.
With the introduction of an Enterprise Architecture function there needs to be changes in the decision making roles and responsibilities at all levels.
The top business managers and executives will still make the strategic decisions for the enterprise and guide and plan the business structuring, but will now make decisions with a different level of abstraction and in a different way supported by the Enterprise Architecture function.
The Enterprise Architecture function will help with business decisions such as:
- Business strategy decisions on transformations, mergers/acquisitions etc.
- Business model decisions on customer segments, new products and business services
- Target operating model decisions on business capabilities
- Strategic changes and initiatives.
The Enterprise Architecture function can directly make independent decisions about:
- IS/IT Strategy (supporting the CIO)
- Target Enterprise Architecture model and Enterprise building blocks
The Enterprise Architecture function also supports and guides IS decisions about Solution building blocks, IT decisions about Technology and Operational decisions about Infrastructure upgrades etc.
As well as developing and maintaining the Enterprise Architecture models, the Enterprise Architecture function can keep track of the RACI for decisions, and maintain a decision log (typically owned by the Enterprise Architecture Review Board) and publish these on the Enterprise Architecture web site and other deliverables.
As Plato said, ‘A good decision is based on knowledge not [just] numbers’, and the Enterprise Architecture provides just that knowledge base.
This changes the way business strategy and strategic change are approached and increases their benefits.
As Jay Forrester said in his paper, Designing the Future, “Organizations built by committee and intuition perform no better than would an airplane built by the same methods… As in a bad airplane design, which no pilot can fly successfully, such badly designed corporations lie beyond the capability of real-life managers.”
Organisations without a real strategic Enterprise Architecture function are just like those ‘organisations build by committee and intuition’.
EnterpriseArchitects.com helps those involved in strategic change to truly understand the issues and concerns and become more successful in building a better ‘enterprise’.
Join the Enterprise Architect community
This post is also available at http://tinyurl.com/253zsth
Real Enterprise Architecture or IT Architecture?
28 August 2010
Organisations always have an implicit architecture, but not always an explicit architecture.
If they do have an explicit architecture, the chances are that it is an IT Architecture that has evolved over the course of hundreds of little decisions made by developers and project managers over the years.
Perhaps these decisions have been made by the CIO in consultation with the IT department and the business who ultimately have to pay for them.
The question is this IT Architecture the right architecture for the organisation?
Many of the business leaders certainly don’t think that they have the architecture they need or deserve.
Increasingly I hear business leaders talk of IT as part of the problem and not part of the solution.
The move to outsourcing and cloud computing is a knee jerk reaction by the business to bypass that slow, constraining old IT department they don’t like and think is too expensive.
The IT Architecture then represents what has happened in the past.
In many cases it’s not quite the fault of the IT department.
They’ve tried their hardest over the years and have done away with business and systems analysis in favour of Agile (the new quick and dirty) approaches in blinkered projects.
This has meant that many IT systems and processes have ended up as string and sealing wax solutions, each in their own silo, as one bank told me last year.
It’s easier for the business to hack together an end user computing (EUC) solution (i.e. Access or a Spreadsheet) or buy a cloud based solution outside the control of IT.
These are unstructured and dangerous, but within limits have given the business the control and responsiveness they wanted.
However ultimately these non-IT solutions hinder an organisations ability to execute its latest business strategy.
So the concept of Architecture is brought back to sort out the mess. But the IT Architecture has not had the impact at the right levels to have the right effect and be the right architecture, so we need something else.
To get the right architecture, organisations should focus on ‘real’ enterprise architecture, not IT architecture, and certainly not IT Architecture just renamed as Enterprise IT Architecture.
Top performing organisations use Enterprise Architecture, with it’s business and strategy driven approach, to help them mould their business strategies, identify the goals and objectives, guide the development of their Business Models and Business Operating Models, establishing the new set of Business Capabilities they require, provide advice and help shape the strategic initiatives that are plotted on an enterprise architecture roadmap in order to drive the execution of their strategies.
The outcome of Enterprise Architecture doesn’t necessarily involve IS or IT changes, it all about the business needs.
Smart organisations have found that using ‘real’ Enterprise Architecture, instead of just a focus on IT Architecture, has helped the business plan and manage mergers & acquisitions, major e-Business transformations & consolidations, grab hold of new business opportunities and introduce new offerings faster better and cheaper.
EnterpriseArchitects.com can help your organisation use ‘real’ enterprise architecture to achieve greatness.
This post is also available at http://hub.am/c4uN
Using VPEC-T and ArchiMate
10 July 2010
I have recently finished reading the book ‘Lost on Translation’ by Nigel Green and Carl Bate and found it a very useful and insightful. I recommend it for the shelf of any Enterprise Architect. See http://www.lithandbook.com/
The book describes the VPEC-T ‘thinking framework’ and a focus on understanding the Values, Policies, Events, Content and Trust perspectives and provides a useful language to use when speaking with the business about any strategic change.
Being keen advocate of using Archimate (http://tinyurl.com/cf3z25) for developing Enterprise Architecture models, it struck me the next step after a VPEC-T based conversation would be to write up the outcomes in an Archimate model.
So what is there in Archimate that would be useful?
The first thing I noticed is that more or less all of the Business Layer meta model concepts in ArchiMate are in scope for VPEC-T and the Application Layer and Technology Layer are not.
ArchiMate Business Layer Meta Model
That’s not to say that VPEC-T wouldn’t be useful for the application and technology layers, but it seems to be naturally focused on the Business Architecture side of things to me at the moment.
So how does VPEC-T map to ArchiMate concepts?
V = Values
The obvious first Archimate concept to use here is ‘Value‘.
ArchiMate users don’t use Value as much as they should in their models in my opinion. Using VPEC-T will correct that.
ArchiMate defines Value as that which makes some party (represented by Business Actor, Business Role) appreciate a Business Product and/or associated Business Services that they are buying, using or acquiring.
Value in this sense is also associated with a value chain (which is modelled in terms of a sequence of Business Processes and Business Activities that provide a Value).
I would also use the ArchiMate concept of Meaning.
Archimate defines Meaning as knowledge or expertise present in the representation of a Business Object, given a particular context. I would use Meaning to represent the inherent shared knowledge or value system that users have as their mental model.
P = Policies
There is no ArchiMate concept for Policy as such in the 1.0 specification but a number of EA tools that support ArchiMate do support it.
I would generally use the ArchiMate concepts of Business Function, Business Process to represent aspects of Policy. These should be used with care though, such as more in the sense of Business Rules, Guidelines, Policies, than with the normal meanings of Business Function and Business Process.
I would also use the ArchiMate concept Business Object, to represent Strategies, Goals, Objectives, Business Decisions,
In the conversation about Policies would be a focus on the Target Business [Operating] Model, in terms of what Business Product and Business Services would be sold or provided to what customer segments, i.e. Business Roles. This overlaps a bit with how one would represent a Business Model in ArchiMate which will be the subject of a future blog entry.
E = Events
The obvious Archimate concept to use here is a Business Event.
This is a key concept, and it seems especially obvious to use it in a message and service driven architectures, but it’s curious how infrequently it is actually used in most of the BPMN style models I have seen people develop.
I first started modelling with Events using IDS Scheer’s ARIS tool in 1998 and the power of an event driven approach has stayed with me ever since.
Business Events are used to trigger a value chain that results in an outcome that has Value.
Value chains are modelled using s sequence of Business Process and Business Activity and outcome of a value chain is represented with a Business Object, Business Product, Business Service associated with a Value.
Since Business Events occur via various channels, it might also be useful use the ArchiMate concept of Business Interface (representing a Channel) in your VPEC-T model, but that is a bit like solution design so is optional.
C = Content
Archimate can be used to model Content at several different levels of knowledge, information and data.
The Meaning object is used to represent knowledge, the Business Object for business information, the Data Object for data, the Representation object for the physical representation of information and the Artifact object for the physical storage of data.
In a VPEC-T model created with ArchiMate, I would mainly use the Meaning, Representation and Business Object concepts.
T= Trust
To me Trust is all about relationships, interactions and collaborations between people.
I would use the ArchiMate concept of Business Actor, representing an organisation, organisation unit or a person, and the concept of Business Role, representing the roles played by those organisations, organisation units or persons in relation to others.
For the trust relationships I would use the ArchiMate concept of Business Collaboration and Business Interaction. These don’t get used in many Archimate models but I think they are useful for representing aspects of Trust relationships.
A Business Collaboration is defined in ArchiMate as a (temporary) configuration of two or more business roles resulting in specific collective behaviour in a particular context.
A Business Interaction is defined as a unit of behaviour performed as a collaboration of two or more business roles.
I would also use the Archimate concept Contract to represent a Trust agreement (such as a Service Level Agreement) between parties.
ArchiMate concepts for VPEC-T models
Overall for doing Enterprise Architecture, I recommend using a ‘thinking framework’ such as VPEC-T first and then an Enterprise Architecture framework and modelling language such as ArchiMate second.
Enterprise Architecture Strategies
8 July 2010
I recommend you read Chris Curran’s excellent blog entry on 16 Enterprise Architecture Strategies Learned The Hard Way
I’ve included his list below with my views and comments following that.
1. An exhaustive enterprise level blueprint is virtually impossible to build – it’s too big and no one will buy-in
2. The best strategy blends a direction-setting enterprise blueprint and business unit and domain blueprints
3. Centralized accountability for the EA function is a predictor of success
4. A centralized team of architects is critical in driving EA standards and approaches
5. Architects must be assigned to projects as core team members (60%+ of total EA FTEs) rather than “advisors”
6. EA should be measured in 2 ways: business capabilities delivered and costs of core services
7. Measure EA as an asset – what does it cost to provide the service and what return does the business get from the business capabilities delivered?
8. Architecture leadership requires strong management, business operations and technology skills, most likely in 3 different types of people; don’t expect your chief architect to run the EA function
9. Methods and governance must be integrated into existing work processes (eg, project approvals, SDLC) rather than a new overlay
10. Enterprise Architecture is not always the best name for communicating; maybe Strategy & Planning or Enterprise Transformation is better
11. The best large companies have “business architecture” teams reporting to the business (or dual reporting to business and IT)
12. Leading companies have reference architectures in place for 90% of the technical domains
13. Your senior enterprise architects must have the right cultural skills and awareness to integrate well with upstream business partners and downstream technical users
14. High performance groups maintain consistent, formalized EA involvement in the SDLC to translate blueprints into sufficiently detailed starting architectures for each project as well as accurate cost and resource estimates
15. Mature organizations target 40% EA resource time for strategic planning and 60% on SDLC tasks, and typically err on spending more time on SDLC tasks
16. Strong credibility and trust amongst Business and IT partners is a predictor of EA success. Credibility has typically been gained via joint strategic planning efforts, one project at a time.
My Views
These are my comments on Chris’s list.
1. The enterprise architecture blueprint (i.e. the enterprise architecture content) needs to be developed in iterations, and treated as a living document/model that will never be complete. Aim for each iteration to provide value in it’s own right, to both the business and the rest of the organisation.
2. I agree that there needs to be different aspects to the business and IS strategies that address different segments of the enterprise. They shouldn’t conflict with each other though. Enterprise Architecture is all about aligning the IS strategy to the Business strategy and target business [operating] model.
3. The EA function needs an executive sponsor such as the COO that is accountable for the success of EA. I’m increasingly of the opinion that the EA function should not report to a CIO that is only focused on IT. This sends out the wrong message to the organisation as a whole. The COO should be focused on the success of the business and how it operates as a whole and not just the success of IT. In some cases success for the business may mean less IT as business capabilities in the cloud are used instead of local IT capabilities.
I’ve seen some suggestions that a new C-level post is needed to manage Strategic Change and Enterprise Architecture , that of a Chief Strategic Officer (CSO). This new role makes sense if the COO is only responsible for service delivery operations & support activities.
4. I agree – A centralized team of enterprise architects is critical in driving EA standards and approaches. There is also room for federated EA teams in large global organisations where centralised control is not feasible or even possible with local regional and country based regulatory environments.
5. Its the Solution Architects that should be assigned to projects as core team members. Enterprise Architects will be involved from a governance, compliance and design assurance perspective in quality gates/steering group meetings, and as an advisor. There are usually not that many enterprise architects and too many projects for them to be core members of every project.
Being a ‘Core’ member of a project team implies that they are managed by the project manager, whereas the relationship should be the other way around – the project manager needs to heed the advise and direction coming from the enterprise architects who have a governance sign off at the end of each project phase in project steering group meetings.
6. I agree that EA should be measured in terms of business capabilities delivered, but also in terms of value delivered. Cost of services is just one of many ways of measuring value. The value of EA is indirect though and value is only realised by solutions that deliver the business capabilities in the future many months away. To measure EA properly though means that there need to be a good record of decisions that are made by EA and the eventual outcome of these decisions in the future. This doesn’t happen much in my experience at the moment.
7. EA is a core business function in the same way that Finance Management or Sales & Marketing are core business functions. We should treat the Enterprise Architecture content as a knowledge management asset. The value is the return on knowledge (ROK) that is used in supporting decision making.
8. The EA function does need strong leadership. Doesn’t always get it though. In all the EA teams I have encountered, the Chief Enterprise Architect does also run the EA function. Within a larger EA team, there are often specific managers for the Business Architecture, Information Architecture, Application Architecture, Infrastructure Architecture aspects.
9. I partially agree. Aspects of EA Governance, Compliance and Design Assurance processes should be integrated into existing Strategic Planning, Portfolio Management, Programme and Project Management, Software Development and Service Delivery processes, but the Enterprise Architecture Development process (i.e. TOGAF ADM) will be a new overlay.
10. The name ‘Enterprise Architecture’ is all too easily confused with ‘Solution Architecture’, ‘IT Architecture’ which is a source of confusion so there are often suggestions for new names for ‘real’ Enterprise Architecture. I’ve not yet found a new name I like though it is becoming common to include Enterprise Architecture within a Strategic Change Management team.
11. Business Architecture is just one of the domains of Enterprise Architecture. All of Enterprise Architecture should be reporting to the business (i.e. the COO) rather than to IT (i.e. the CIO).
12. A Reference Architecture is a key component of the target Enterprise Architecture as a whole. In some cases these are provided by industry reference architectures.
13. I agree in general although I’d say that Enterprise Architects probably need to be much more business focused than IT focused. IT is often seen as part of the ‘problem’ and EA needs to be in alignment with the business.
14. This is more the responsibility of the Solution Architects who need to liaise with the Enterprise Architects to translate the Enterprise Building blocks into Solution Building Blocks. The Solution Architects should ideally form part of a ‘virtual’ EA team.
15. The 40% EA resource time on strategic planning and 60% on SDLC tasks mainly reflects the current overemphasis on IT Architecture being done by Enterprise Architects. I think the ideal percentages should be the other way around i.e. 60% strategic planning and 40% project related work.
16. I agree that the credibility of the Enterprise Architects and their trust relationships is critical. Building that credibility and trust starts with working closely with the business on strategic change programmes
Dealing with Complexity and Chaos
27 June 2010
I was thinking about System Thinking and how very few organisations that I have worked with have made use of this approach and associated System Thing tool such as iThink.
The same applies to Enterprise Architecture modelling and associated EA tools.
There is often a cry from some people that the resulting models are too complex.
‘Can’t I simplify it ‘ they cry. ‘It’s too difficult to understand’.
In one case the diagram in question was a relatively straightforward Application Architecture diagram showing 180+ Applications and a simplified view of the interfaces between them. At the time it made me smile since I’d previously worked with an Application Landscape that contained over 3000 applications!
However there is a real problem here of a general resistance to the use of Enterprise Architecture modelling (and also of the use of system thinking) revealing the underlying complexity of systems, and a wider problem of aversion to getting to grips with complexity.
Many people I think are afraid of complexity in general and are afraid of any model that reveals the underlying complexity. These people would like the world to be simple and straightforward (perhaps due to their limited education?).
It’s important to understand that the world is not at all simple, and simplistic solutions will not be sufficient for all problems.
The application of the right modelling tools, expertise and approaches will need to vary depending on the type of problem that needs to be solved.
The Cynefin model is useful for helping people understanding that different approaches are needed for different classes of problem.
See http://en.wikipedia.org/wiki/Cynefin
The Cynefin framework defines five context spaces: Simple, Complicated, Complex, Chaotic and Disorder.
For problems that fall into the Simple context space, the relationship between cause and effect is obvious to all, and the approach is to Sense – Categorise – Respond and we can apply best practice.
For problems that fall into the Complicated context space, the relationship between cause and effect requires analysis & investigation with good models and/or the application of expert knowledge, and the approach is to Sense – Analyze – Respond and we can apply good practice.
For problems that fall into the Complex context space, the relationship between cause and effect can not be instantly perceived without testing and simulation, including using System Thinking / System Dynamics modelling and simulation approaches. The approach to use is to Probe – Sense – Respond and look for emergent meaning.
For problems in the Chaotic context space, there is no obvious or intuitive relationship between cause and effect at systems level, the approach is usually known as JFDI (Just Effing Do It) and consists of trying something out and seeing what the hell happens – an Act – Sense – Respond approach.
The Disorder context space is the state of not knowing what the problem is in the first place and doing nothing and hoping for the best.
Unfortunately ‘Hope is not a Strategy’.
Complex models can only be made as simple as possible but no simpler. Ultimately you’ll have to live with complexity.
Knowing when to use the right modelling tool to manage complexity is the best strategy.
Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses handle it.
Enterprise Architecture and Zombies
2 June 2010
There has been much discussion about the ten Enterprise Architecture pitfalls that Gartner published at http://www.gartner.com/it/page.jsp?id=1159617
For example see http://tinyurl.com/2wfod8q and http://tinyurl.com/3ayz6a8
In the meantime, Jane Austen and Seth Grahame-Smith have also published a great book: Pride, and Prejudice and Zombies: The Classic Regency Romance-now with Ultraviolent Zombie Mayhem!
In a spark (fit?) of imagination, the title of this blog was raised up from the depths of Mordor and just wouldn’t die…
This is a light hearted, tongue firmly in cheek, look at Gartners 10 EA pitfalls written as a story just ripe for gore and senseless violence…
A world where Enterprise Architecture exists in an alternative universe where Zombies roam the corporate landscape. The denizens of this doomed land are the “stricken”, the “sorry stricken”, the “undead”, the “unmentionables”, or just simply “zombies”. The Zombies are those in an organisation who wittingly or unwittingly subvert the best intentions of those valiant enterprise architects envangelising about the benefits of Enterprise Architecture.
The Gartner 10 EA pitfalls are an excellent set of EA anti-patterns and avoiding them will result in a better Enterprise Architecture function within an organisation.
If you can’t avoid these pitfalls then it’ll seem as if you’re suddenly transported into the world of Zombies.
1. The Wrong Lead Architect: This is a classic and common anti pattern where the Chief Enterprise Architect turns out to be a zombie (an ineffective leader). He or she may not really understand Enterprise Architecture at all but has been put into the role by senior management because they were the only one available (dead man’s shoes?). This Dark Lord “He-Who-Must-Not-Be-Named” (ok, his name is Lord Voldemort) is making decisions with a forked tongue, for seemingly no reason whatsoever, other than to spy out opportunities and jobs for other zombies perhaps. Devoid of real interest in Enterprise Architecture he actively campaigns against its introduction.
Best thing to do is chop their head off, but as Harry Potter knows, this is easier said than done. Expect an uphill battle.
2. Insufficient Stakeholder Understanding and Support: This happens when the hordes of living dead outside the Enterprise Architecture team ignore what the EA team is doing, continually questioning the value of anything not related to their immediate problems, usually project related. This is because they are undead vampires who do not live in the real world. Get sharpening those stakes and hang up the garlic to keep them away. A huge problem occurs when the Enterprise Architecture team loses its executive sponsor. As with the volcano, Eyjafjallajökull, ash clouds of Fear Uncertainty and Doubt will start filling the air. Who is going to pay attention to the Enterprise Architects when they don’t have a sponsor?
Best thing to do is get a new sponsor as soon as possible, or start dusting off your old CV.
3. Not Engaging the Business People: Zombies don’t understand the living. They only talk to other zombies and don’t communicate much anyway. They think that Enterprise Architects are just another species of Solution Architect or Technical Architect. To overcome this make sure you get involved with the business and with real business decision making. This is not easy if the business are used to making decisions without the support and involvement of the Enterprise Architects (I’ll cover decision making in a future blog). Communications with the business units are frequently lost when the messengers are captured. Zombies that don’t like the enterprise architecture message will kill and eat the messenger. Yum.
Best thing to do is create a great communication plan and be clear about the messages, be sure to engage with the living at all times to create value and ROI and to placate the Zombies.
4. Doing Only Technical Domain-Level Architecture: Some people think that an Enterprise Architect is just another name for a Solution Architect who deals with applications used at the corporate level by all business units. These people look alive but are really undead.
Best thing to do is to clearly distinguish between the roles and responsibilities of Technical focused Solution Architects and business strategy focused Enterprise Architects. Wearing a garlic necklace should also help…
5. Doing Current-State EA First: Successful Enterprise Architecture is about the future, about strategy and governance. Zombies live in the present and worry about the current state and short term gains and don’t care about the business strategy and why they are there. They do lots of howling. Enterprise Architects are there to help the business make money in the future, faster, better cheaper.
Best thing to do is to focus on the future target business model and how to realise it.
6. The EA Group Does Most of the Architecting: The Zombies are not informed by those alive on the business side. There is consequently no buy-in for developing the Enterprise Architecture content. Zombies just want to kill people and make more zombies. They are dead anyway so don’t care about the future. The primary job of real enterprise architects is to wear silver crosses, kill zombies, vampires and werewolves.
Best thing to do is to lead the Enterprise Architecture process to develop the future architecture rather than live in an ivory tower and impose their favourite ideas.
7. Not Measuring and Not Communicating the Impact: The value of real EA is often indirect, so it won’t be obvious to the Zombies in the organisation. This then exposes the Enterprise Architecture function to the risk of failure and being beheaded. If you don’t measure what EA does then how can you manage it?
Best thing to do is to build an EA scorecard, plan the EA roadmap, concentrate on continually providing and communicating the value of EA to the living, kill zombies, sharpen your axe, and grow garlic.
8. Architecting the ‘Boxes’ Only: Enabling better business agility is frequently a key EA goal, but Zombies only care for their projects or business unit and generally won’t be rewarded for providing corporate benefits. Enterprise Architects work for the whole organisation. Where is the one true ring to help to defeat a rampaging horde of Zombies and fight the ever-present threat of a Zombie apocalypse?
One (EA) Ring to rule them all, One (EA) Ring to find them,
One (EA) Ring to bring them all and in the darkness bind them..?
Best thing to do is focus more on business strategy and the business capabilities that cut cross the business silos to provide value, polish your stakes and silver crosses and look for the one true ring.
9. Not Establishing Effective EA Governance Early: Zombies live without any governance. The quick and dirty rule, and regard the living Enterprise Architects as a troublesome, albeit deadly, nuisances. Enterprise Architects must resist the temptation to wait for more enterprise architecture content before establishing credible Enterprise Architecture governance and compliance processes.
Best thing to do is develop EA content and EA governance in parallel and constantly cry “I have a cunning plan”…
10. Not Spending Enough Time on Communications: Zombies will ignore Enterprise Architects unless they are hungry for blood. Key messages about Enterprise Architecture will not be intuitively obvious to Zombies, if at all. Enterprise architects must constantly work to educate the living business and kill all zombies.
Best thing to do is keep sharpening the EA axe and evangelise with tailored messages to your audience.
With apologies to Harry Potter, Lord of the Rings, Black Adder and the book – ‘Pride and Prejudice with Zombies’ (http://tinyurl.com/al6gvx ) which originally inspired this blog entry…
This blog bears absolutely no relation to any organisation either living, dead or undead. Comments and Lawsuits to Harry.Potter@Azkaban.org.uk
on Enterprise Architecture 
