Business Architecture

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:

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.

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.

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.

Adrian Campbell

EA is Strategic Planning

Enterprise Architecture quite simply is all about Strategic Planning. It helps enterprises shape their future structure and dynamics in the face of the changing environment in which they do business. Its purpose is to understand the ends and means that form the strategies needed.

How does an enterprise react to events that do and will potentially occur and arrive at the strategies needed to remain robust, efficient and viable, to continue to deliver value and make profits for themselves?

Enterprise Architecture is the corporate discipline that helps us to understand the questions that need to be asked and get better at strategic thinking. The approach is based on asking the usual Why, What, How, When, Who and Where questions:

• Why does the enterprise need to change?
• What are the drivers for change?
• Are the drivers fully understood?
• What is the mission and purpose of the enterprise?
• What do enterprises need to do and need to understand? What do their customers and stakeholders want?
• What is possible to do?
• What are the strategies, goals and objectives?
• How will these be achieved?
• What business capabilities are needed?
• When should the enterprise react to new opportunities? What are the potential business scenarios that might occur? How will the enterprise react when they do occur? And how should it react?
• Who should be involved?
• Where is the enterprise?
• What environment or markets is it located in?
• How many different environments are there?
• What would success look like for strategic planning?

These should all be open questions. You should take care that the questions don’t upset those executives that are responsible for the current answers and are asked in an ego-less fashion.

All of these answers can be modelled and analysed with your favourite enterprise architecture tool.  I like to add a Strategy domain to the usual Business Architecture, Information Architecture, Application Architecture and Infrastructure Architecture domains.

Enterprise Architects should start to think like a strategist instead of just like a technologist.

In real life the answers from our questions are usually complex and enterprise architects will typically develop a number of different target enterprise architecture scenarios to explore all the options. These can be analysed and

What I find curious though is that I have never seen any mention of Enterprise Architecture approaches and techniques in any Strategic Planner job specifications. These job specifications may include requirements such as :

• Maintaining a clear picture of the external environment
• Development of vision, strategies, goals and objectives
• Identifying and assessing merger and acquisition opportunities
• Facilitating the on-going development of strategic and associated implementation plans (i.e. Roadmaps)
• Providing an ad hoc research and analysis capability
• Conducting market and competitor analysis
• Interacting with the board executives, and other senior internal and external  stakeholders
• Business and commercial awareness

TOGAF9 and ArchiMate already both include Motivation concepts, so now more and more Enterprise Architects are modelling Drivers, Goals, objectives, Measures, Values as well as Products and Business Services.

Isn’t it about time that Strategic Planning starts to make use of the value and benefits of the enterprise architecture capability?

The same point also applies to Enterprise Architecture and Business Transformation. In my view Enterprise Architecture is the glue that joins these approaches together.

Going from just good enough to being great

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.

The purpose of Enterprise Architecture

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.

 

Strategy Planning and Enterprise Architecture – dealing with the devil in the detail

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

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