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.
 
 
 
 

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.

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:

  1. How do you define Business Architecture?
  2. What is the role of the business architect? What real world business problems does Business Architecture solve?
  3. How is the role of the business architect changing? What are the drivers of this change?
  4. How does Business Architecture differ from Enterprise Architecture?
  5. How can business architects and enterprise architects work together?
  6. 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:

BizArch 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.

EA domains

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.

Business Architecture

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.

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.

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.

 

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 Service-Oriented Enterprise: Enterprise Architecture and Viable Services

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.

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… ’

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 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.

Business Model Canvas

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:

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.

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.

describe the image

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

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.

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.

Jeanne W. Ross recently proposed the following.

“Let me propose the following hypothesis: Although EA was initially a function within the IT organization, we will soon find IT to be a function within EA. This is actually not a wild theory; it’s a trend.”

- Jeanne W. Ross, Foreword, The SIM Guide to Enterprise Architecture, CRC Press, 2010, p. xli.

 

This is a great proposal.

Making the IS/IT function part of the Enterprise Architecture (EA) function makes much more sense than having the Enterprise Architecture function as part of IT.

Unfortunately the latter situation is far too common as organisations make the mistake that EA is somehow a more specialised version of Solution Architecture and Technical Architecture.

From the business perspective, the IS and IT functions are often seen as part of the problem and if the Enterprise Architecture (EA) function reports to IS/IT then by association it can also seen as part of the problem.

Since EA is very close to the business by definition (i.e. the ‘Enterprise’) this make life for an Enterprise Architect very difficult. Their natural and main business stakeholders will be wary of sharing their discussions on strategy and business ideas with EA.

The EA function should ideally report to the executive board and be a peer with the business functions.

Often the EA function reports to the CIO.  If the CIO is the head of IS and IT functions, then this can be a problem.

Ideally the Chief Enterprise Architect (i.e. the CEA) should be a new ‘C’ level executive position and a peer of the CIO and not report to the CIO.

This would instantly give the Enterprise Architecture function the level of authority and position with the organisation hierarchy that it needs to do its job properly.

See also the discussion on this topics started by Birgitt Hartje

at http://www.linkedin.com/groups?home=&gid=48747&trk=anet_ug_hm

Enterprise Architecture does by definition include Business Architecture. Any other view is now rather out of date. 

Enterprise Architecture should include several domains: 

  •  Strategy 
  • Business Architecture 
  • Information/Data Architecture 
  • Application Architecture 
  • Infrastructure Architecture

In addition there are other sub-domains for Process Improvement, Governance, Audit, Security etc. 

All EA frameworks including Zachman, Archimate, IAF and TOGAF 9 recognise these distinct domains in some form. 

TOGAF 9 is increasing mature and the image at http://tinyurl.com/btxqga 
is a good baseline for understanding the various domains. 

Of course over the history of the maturing of the Enterprise Architecture discipline, it was nearly always the case that Architects came out of the IT function.

IT trained staff are more likely to be good modellers and think in rational formal ways necessary to produce good Architecture models.

Business staff on the other hand like to own their business models and have been less precise and formal about how they modelled what they do.

This is improving of late with BPMN and BMM models becoming more acceptable for business focused staff to use.

The Enterprise Architect is also increasingly becoming a Strategy & Architecture discipline and an Enterprise Architecture (as opposed to a Solution Architect) likely not to have an IT background. Many are from a Business Analysis, Programme Management, Portfolio Management background.

The ideal EA team today will have a mixture of all kinds off staff from different disciplines and will not report to the IT function.

EA is a corporate level function and not just a Business or IT function.

Follow

Get every new post delivered to your Inbox.

Join 699 other followers

%d bloggers like this: