Business transformation involves significant changes to all areas of an enterprise. It focuses on the future strategies.

These includes strategies, business models, operating models, business processes, information & data, systems, products, business services and channels. These are exactly the deliverables developed by enterprise architecture to understand the current state of an enterprise, to envision and design the future state of the enterprise, to discover the gaps between them, to identify the opportunities for investment in change and to plan the enterprise architecture roadmap to achieve the change initiatives.

This sounds just like what Business Transformation approaches do, doesn’t it?

In fact Enterprise Architecture and Business Transformation disciplines have much more in common, than they have differences.

It’s clear that real Enterprise Architects play a critical role in business transformations. The Chief Enterprise Architect is the most important member of the senior management team leading a business transformation and ensuring that it is effective.

By the way Enterprise Architecture, by definition, should not be misunderstood as only being about IT Architecture or Technical architecture, used just to support IT solution development. This is not what real enterprise architecture is for. Business transformation is rarely limited just to IT projects.

The CxOs are the business leadership responsible for providing business direction, identifying the needs for the business transformation in the first place and making the investment decisions.  But the Enterprise Architects will work directly with the CxOs to drive out the devil in the details, planning the future transformation roadmap, developing future scenarios, making projections and forecasting future options. Acting without enterprise architects is equivalent to failing to make proper preparations and is asking for trouble. The enterprise architects perform the important task of analysis and evaluating the impact of strategies and proposed changes in detail, identifying risks and prioritising the transformation initiatives into a viable roadmap. They manage the complexity of transformations and are essential to achieving success and effective transformational changes. Enterprise architecture is about bridging the gap between the transformation vision and strategy and its realisation.

What approach should be taken for leading business transformation?

The recommend approach is based on the books by John Kotter, “Leading Change”, “A Sense of Urgency” and The Heart of Change Field Guide”, together with real enterprise architecture approaches to managing strategic change.

Creating the conditions for business transformation

1 Increasing urgency

For Business Transformation to be successful, then the whole enterprise needs to understand the need for it. The whole enterprise needs to have a view of the current state and the motivation for change.  Enterprise Architecture provides an understanding of the existing problems and the desired future vision. Avoid complacency and business as usual behaviours. Business transformation means new behaviours and new ways of working.

2 Building a joint Enterprise Architecture/Business Transformation team

A Business Transformation team should not be a group isolated from the enterprise architecture team, but completely integrated with it. Remember that a real enterprise architecture team is responsible for the future business change within the enterprise (and is not just an IT development function), typically up to between 2 and 5 years into the future. Seriously, how can they be kept separated from a business transformation programme?

Identify the members of the Enterprise Architecture/Business Transformation (EABT) team. Look for a mixture of strong management leaders and include a good influential people from a continuum of all job titles, levels of authority and statuses. Remember that enterprise architects are strong and effective change leaders and already cross cut the whole enterprise. Non-enterprise architects in the EABT team will probably have greater political and financial skills whereas Enterprise architects will have cross domain knowledge about the whole enterprise in detail, analytical skills and significantly greater modelling skills. All team members should have good vision and leadership skills.

Hold honest and convincing discussions, dialogues and workshops. Enterprise architects are often useful as facilitators at this stage.

Ask for emotional commitment from all EABT team members and commitment to work together for the common good of the enterprise.

3 Establishing the Target Transformation Vision models and Strategy

What does business transformation success look like?

Planning the strategies and confirm the business motivation. Enterprise Architects and C-level managers will use a Business Motivation Model for this, identifying Strategies, Goals, Objectives and performance measures.

Analyse the various ideas and options to develop an understanding the various Business Models for the target transformed enterprise. Alternative business models can be produced by the enterprise architects using a Business Model Canvas approach and these can be compared with multiple measures, including total cost of ownership and potential revenue.

Avoid thinking in terms of systems and IT solutions too early, after all this is the job of the enterprise architects later on and business transformation is a business problem.  Allow for unfettered innovations to emerge from discussions.

Identify stakeholders including customers, partners and suppliers.

Examining the Outside In views from the perspective of these customers and partners.

Creating detailed Business Scenarios, Customer Journeys and Partner Journeys using any suitable story telling approach. Remember that stories are powerful, especially if they come directly from your customers. The enterprise architects will capture and analyse these business stories, but remember that at this stage these are not detailed IT requirements or user stories/use cases from an Agile software development perspective. Those kinds of deliverables will be defined much further downstream.

Identify opportunities and innovations. The team should consider approaches such as a Blue Ocean Strategy (see the book).

Definition the transformation Vision, Values, Motivations.

Defining the transformed value propositions

Analyse and understand the risks, their probabilities of occurring and their potential mitigation.

Engaging and enabling the Enterprise

4 Communicating the Transformation Vision and strategy

Communication is essential for all business transformations if they are to be successful.

There will be detractors and strong opposition to some of the transformation vision. The enterprise architects in the EABT team will ensure that fact based decisions can be made.

Publish and communicate the business transformation models as widely as possible. This will help make the right decisions and solve problems. Don’t assume either the C level managers or the enterprise architects have a monopoly on good decisions. Challenges need to be addressed and responded to.

Obviously some aspects of the transformation vision and strategy will be commercially sensitive and should not be communicated to the competition without careful thought. However, ultimately remember that the enterprise will want support from all customers, internal stakeholders, outside stakeholders, partners and suppliers and this support and buy in cannot be won without communication. Talk often and modify the transformation visions as needed. The enterprise architects will keep track of alternatives and decisions in the transformation model. The Vision and strategies need to be tied back to all aspects of the transformation model. This becomes infinitely easier using a flexible EA management tool (such as ABACUS) and avoiding spreadsheets and Visio diagrams which rapidly become unmanageable.

Ensure that the joint Enterprise Architecture/Business Transformation (EABT) team is able to lead by example by speaking about the transformation vision at any time and to always evangelise about it.

5 Enabling Action

Enabling transformation change is about removing the barriers to change and empowering staff. It involves removing resistance. Often resistance to change from staff is tied to functional divisions and people who are not measured by enterprise’s transformation success but only by fulfilling their own their own personal goals. Paradoxically, it may be the way they are measured and rewarded by the C-level managers that causes people to resist and avoid supporting transformational change.

To enable the right actions, the authorities, responsibilities and rewards need to be re-aligned with the business transformation vision, goals and objectives.

It is the enterprise architect who takes the business strategies and business model and successfully realise them on behalf of the whole enterprise, so are often best placed to also identify the authorities and responsibilities needed to focus people on benefits to the enterprise.

Ensuring that the Enterprise Architecture /Business Transformation (EABT) team has the right authority is also essential, and is able to resolve competing priorities. This authority is also exercised in relation to the governance and compliance stage.

Establish the appropriate metrics and measures, and maintain a scorecard for the business transformation vision, goals and objectives. It is strange how often performance is ignored and enterprises do not know how to measure success, or align performance to desired outcomes. Costs and revenue need to be balanced with other measurement dimensions. Measures should be aligned to transformation changes in the EA management tool.

6 Define Investment Opportunities

Examine the investment opportunities and develop an investment case. The Enterprise Architects will be best placed to determine how realistic and feasible a specific investment opportunity will be, and determine the fine details. Whereas the C-level management will understand the balance of costs and revenue developed in the Business Model.

Enterprise Architects will use a Business Capability model to scope and plan which business capabilities will be modified by a transformational change.

Transformational changes will typically be classed as short term or long term changes. However by definition, transformational changes will tend to be large and disruptive rather than “low hanging fruit”. Short term transformational changes will however be useful for maintaining the transformation momentum across a number of iterations.

Changes to business capabilities are identified as a number of capability increments. The dependencies between these and their priorities will form the first draft enterprise architecture roadmap and provide the scope and context for subsequent change iterations.

Implementing and sustaining the business transformation

7 Keep up the momentum

It is important to keep up momentum for a business transformation. The EABT team must keep communicating and clarifying the business transformation changes.

The business transformation model must be regularly published and all opportunities taken to speak to all stakeholders about it and inform them on status and progress. Capture feedback and responses to continually validate the vision and measure its effectiveness.

Address the fear, uncertainty and doubt from detractors and sceptics and motivate supporters to evangelise about the transformation. Encourage desired culture and values that reinforce the transformation changes.  Keep your eyes on the roadmap and don’t assume everything is done after the success of the first iteration and let performance and concentration levels drop. Don’t let the EABT team get diverted into other side projects. Perseverance is important. Remember that change is the only constant.

Develop communication material including web sites, brochures and posters. Posters can be very effective as information radiators.

8 Enterprise Architecture Governance and Compliance

C level managers will be making the investment decisions and providing funding for investments in change.

Establishing an enterprise architecture governance and compliance capability will ensure successful realisation of transformation changes, and help them become permanent business as usual.

Detractors will often try to derail changes but the formal governance and compliance approaches will enforce decisions made but will also provide a platform for challenges and objections to be discussed openly and objectively.

9 Realising Transformation Changes

Business transformation needs many kinds of potential future changes to occur, not least of which are the key cultural changes and organisational changes.

Business Process changes, Information changes, system changes and procurement changes are also important. However for these I recommend designing for flexibility and adaptability not going for a fixed solution which may be cheaper but will invariably be difficult to change the next time. Business transformation should be thought of as a continuous process, enabling an enterprise the rapidly respond to changing forces in the market environment.

Before changes are executed, it is a good idea to conduct a Change Readiness Assessment, if you have not already done this earlier in the Enabling Action stage. This will help find out how prepared the enterprise is for the transformational changes and identify the enterprise’s overall competence, knowledge, skills and capabilities. Any shortfalls will be addressed by planning suitable skills training, and addressing the shortfalls.

In conclusion

For maximum success in strategic business transformations, an enterprise needs to completely and fully use their enterprise architecture resources and enterprise architects. You have to work hard and plan carefully. Building the proper foundation with an enterprise architecture model for the scope of the business transformation will make everything very much easier.

EABT

There is no good reason why real Enterprise Architecture and Business Transformation should not be merged as a single discipline. The skills needed for each hugely overlap, especially the Business Architecture domain of enterprise Architecture.

A joint Enterprise Architecture Business Transformation team is essential to achieving successful and viable transformations.

Cognitive Dissonance

11 November 2013

I was reading this today:

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.

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

Get every new post delivered to your Inbox.

Join 871 other followers

%d bloggers like this: