I had an interesting conversation recently about the use of Wardley maps as part of an Enterprise Architecture and Digital Transformation programme recently. I had looked at using Wardley maps some time ago but now I think it is a good time to incorporate their use into normal Enterprise Architecture/ Business Architecture work. They are a very useful addition to the bag of techniques and approaches that I recommend should be used by Enterprise Architects working on the Strategy and Business Architecture domains as well as for the IT architecture domains.

Wardley Maps are useful for understanding the dynamics of what is needed to support a user’s needs. The underlying dependencies between user needs are constantly evolving and many organisations do not recognise this when they come up with a dry list of Business Strategies, Goals and Objectives using a Business Motivation Model. A Wardley map makes strategies much clearer and contributes towards better situational awareness which is critical.

When asked about their strategy the CxOs often simply mention similar lists of ideas that they see other organisations talking about and copy. Often they don’t really understand the buzz words. For instance, what does ‘Digital’ really mean? Is doing Digital sufficient to claim an innovative advantage in the blue ocean? A situational Awareness map will help visualise the buzzwords and their relative importance. It will also allow the organisation to better understand where it can gain an advantage.

Wardley maps help to position the user needs and dependencies in a continuum from the genesis of an idea through to the commoditisation of the same idea, at the same time as creating a value chain as a directed graph and not just as a high level list of business functions.  The Wardley map combines the Value chain view with an Evolution and dependency view which helps to identify where the strategies (Both Business and IT) should attack to produce a competitive advantage.

Upstream of Wardley maps, User needs can be identified from modelling Business Scenarios and Customer Journeys. It will be very likely that multiple Wardley maps will be needed.

The dependencies between user needs is similar to the dependencies that can be identified between Business Capabilities. Also the provision of Value to a customer is also the outcome of a Business capability. I can easily see a mapping between a grouping of Business Capabilities or groupings of dependencies between Business Capabilities and a a set of Wardley Maps.

Capability Increments can map to groupings within a Wardley map and dependencies between User needs can be associated with dependencies between Capability Increments.

These complementary techniques will reinforce each other and ensure the resulting EA Roadmap of Initiatives and subsequent Project roadmaps will be well designed and stay meaningful and relevant.

Obviously it is important to remember that the evolutions of user needs identified in a Wardley map are dynamic and the resulting EA roadmaps also need to be constantly kept under review, as business and IT trends evolve.

The best strategy is one that can help identify where to attack when things change.

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.

When establishing (or indeed re-establishing) a brand new Enterprise Architecture function within an organisation there are perhaps two main approaches:

  • A big bang approach
  • A gradual iterative incremental approach

I favour the big bang approach. This is for several reasons:

1) a big bang send a clear and confident message to everyone in the organisation that things WILL be done differently

2) a big bang provides a clear mandate, mission, vision and positioning for the Enterprise Architects, sidetracking threats and challenges from others who feel threatened by the emergence of EA

3) a big bang ensures that the Enterprise Architecture function is given a solid budget and is established through a strategic change programme, complete with programme manager

4) a big bang has clear reporting to the CEO or appropriate C-level executive (since responsibilities vary from company to company) and clearly defined outcomes

5) a big bang needs clearly visible and continuous [sic] executive support

6) a big bang must have clear goals, objectives, measures, performance targets etc. Enterprise Architecture must be part of the business strategy to improve the organisation’s effectiveness and profitability.

7) a big bang ensures that proper effort is made choosing an appropriate EA framework, Meta Model, Process and EA tool

8) a big bang is JFDI on a large scale – get the whips and carrots out and get it done right first time ! Make it So !

Don’t get me wrong, iterative approaches do work well with established processes such as software development, but not for the introduction of new functions and processes that haven’t previously existed.

Establishing an EA function in small iterations is giving ammunition to challengers and doubters. There tends to be no mandate, no or limited budget, a quick and dirty mindset, limited access to experienced consultants, no EA tools, overall limited maturity.

It sends a message to the staff that the executive management is not sure, is not confident, and won’t invest in the success of Enterprise Architecture.

It’s a bit like changing governments, you don’t do that iteratively do you?

As Niccolo Machiavelli once said ‘Tardiness often robs us (of) opportunity, and the dispatch of our forces’.

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.

%d bloggers like this: