Cognitive Dissonance

11 November 2013

I was reading this today:

http://it.toolbox.com/blogs/ea-matters/is-there-an-enterprise-architect-paradox-surely-is-57728?rss=1

It is a good analysis of the cognitive dissonance between what Enterprise Architects should be doing and the role and situation they often actually find themselves in. The term Enterprise Architect has been hijacked for far too long.
An Enterprise Architect should indeed be a senior leadership role, ideally reporting to the CEO.
 
The trouble I’ve often seen is that mid level executives often think that because they have been promoted into that role that their job title automatically gives them the skills and experience of a real enterprise architect.
 
News Flash: It doesn’t!
 
They do have the skills to set business strategy and provide direction of course (This is a Viable System Model System 5 role). But are they capable of plotting the effect on the enterprise architecture and planning an Business transformation roadmap? Often not so much. They understand the market realities and their customers. The Roadmappping and Busienss Transformation is more the domain of expertise of the enterprise architect (This is a Viabale system Model System 4 role).
 
Subsequently the mid level executives tend to think that real Enterprise Architects who engage with them are somehow after their job (instead of being there to help them) and spend their political capital to push them back to IT where they think they belong.
 
News Flash: Enterprise Architects don’t belong in IT!
 
There should be a Chief Enterprise Architecture Officer with a EA Management Office (or better still called the Office of the CEO) to support them, in the same way that a PMO supports Programme Managers. 
 
My advice is to educate the employers and teach them what an Enterprise Architect really does, and not let them employ other skills and erroneously call them Enterprise Achitects.
 
Its time Enterprise Architecture was taught properly in University MBA courses to the next generation of business leaders. Maybe then the cognitive dissonance will be avoided.
 
 
 
 

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.

See Enterprise Design Framework

Brilliant new album

10 July 2013

Go buy this now!

http://lachlancampbell.bandcamp.com/album/6-month-winter

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.

EA lifecycle

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.

EA processes

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.

RACI

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

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.

http://www.amazon.co.uk/The-One-Future-Building-Relationships/dp/0385425287/ref=sr_1_1?ie=UTF8&qid=1372038361&sr=8-1&keywords=The+One+to+One+Future

http://www.amazon.co.uk/One-Field-Book-Don-Peppers/dp/1900961873/ref=la_B000AQ8U5Q_1_5?ie=UTF8&qid=1372038423&sr=1-5

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.

http://www.amazon.co.uk/Outside-Putting-Customers-Center-Business/dp/1477800085/ref=sr_1_1?s=books&ie=UTF8&qid=1372038930&sr=1-1&keywords=outside+in

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.

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

UKRA BCM

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.

BC and CI

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.

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.

 

Follow

Get every new post delivered to your Inbox.

Join 697 other followers

%d bloggers like this: