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.
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.
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.
|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|
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.
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.
They can also use the less engaged PEST analysis for strategic market research.
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
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?
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.
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:
- Organisation Units
- Business Services
- Information & Data
- Application Services
- Infrastructure Services
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.
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)
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.
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.
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.
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’.