By now most companies should have heard about the new EU General Data Protection Regulations (GDPR).  https://en.wikipedia.org/wiki/General_Data_Protection_Regulation

The deadline is looming ever closer, and there are some hefty fines for companies that fail to implement it. The penalties for not complying with the legislation are potentially going to put a huge dent in your profits and viability. These include fines of up to €20 million or 4% of annual global revenue. This is then a huge reason for your company to be using Enterprise Architecture to deal with the GDPR changes.

And GDPR does not just have to be affecting European based companies, it applies to any company dealing with European citizens. And what’s more, even BREXIT won’t help. The UK government is already committed to GDPR after BREXIT. Sorry!

Companies that already have a healthy and strategic Enterprise Architecture Capability will be in a much stronger position. I don’t just mean EITA here of course, but real Enterprise Architecture.
GDPR is not just about IT change, but also about business change. Your existing Enterprise Architecture models will make it very much easier to identify the impact of the EU GDPR regulations, using new attributes and heat maps on existing catalogues, matrices and diagrams.

Purpose of GDPR

The purpose of GDPR is to improve on the previous data protection rules. In this digital eCommerce world, this is absolutely essential. This is no longer a so called box ticking exercise but a cultural change in mindset and levels of trust and integrity.
Companies, such as UBER, can no longer be blase and hide being hacked for months and losing huge amounts of customers personal data, without coming clean about it, and consequentially stopping it happen again.

See http://ec.europa.eu/justice/data-protection/reform/index_en.htm

The aim of the General Data Protection Regulations is to ensure that personal data is stored with customers informed consent, where the customer knows for what purpose data about them will be used and for how long it will be kept. Customers will want to know how their personal data is being used afterwards, especially after a merger or acquisition. What, for example does Facebook plan to do with WhatsApp data now that it has acquired Facebook?
It is certainly not transparent, is it? A customer might have trusted WhatsApp, but do they still trust the new owners Facebook? Facebook seems to be increasingly pushing fake news and becoming more political, which is troubling. Don’t just worry about SkyNet but also about Big Brother.

GDPR has been introduced to help companies be honest and increase their data security and their overall integrity. Luckily Enterprise Architects are already skilled at providing details about party data, data models, data flows and data security to support information security audits and personal impact assessments, and other regulatory requirements.

Something like GDPR is exactly the kind of strategic change scenario that Enterprise Architecture is designed to support.
What are the requirements? How do they affect the various EA domains? Strategy, Business Architecture, Information and Data Architecture of course, Services and Application Architecture and also the technology and infrastructure Architecture, where the personal data will be stored.
The same considerations apply whether the data is stored on premises or in the cloud. Enterprise Architects now need to build privacy by design.

Organisations will need to know why the data is needed? Is it always really needed, or is it just for future cross selling and data analytics?
Is that personal data compliant with GDPR? Probably its not longer compliant. Who uses the personal data? What business processes are involve? Too many process models that I’ve seen fail to show access to read and update data objects in their process models, let alone the business events that re related to customers data. What data services are involved? What applications need to be upgraded or replaced? I expect many package applications are being updated to ensure their compliance with GDPR. How do we ensure visibility of data to the customers, in the background of continual changes?
How do companies prove that they are being honest with customers data and especially how do they keep customers informed? If customer data increasingly has a value, then how will customers gain value from how companies use their data without their informed consent?

The Enterprise Architecture repository should already be able to answer all of these questions.
If not then why not? If not now, then when?

Companies without any credible Enterprise Architecture will be in a huge disadvantage and have to rapidly catch up. It’s never too late.
And once again, this is not simply about IT Architecture or just Data Architecture, it’s about the whole enterprise. The enterprise will include partners and suppliers as well. You will need to know what your contractors are doing with customers personal data.

In many organisations, the application architecture is only about so called Business Applications, that are approved and managed by the IT department. You also have to model the End User Computing (EUC) applications like those Excel spreadsheets, Access Databases, Sharepoint tables and Cloud databases (like Box, DropBox, Google Drive etc) that business users have created (unbeknown to IT) in order to do their job outside the main business applications. These EUC applications and databases must also be considered.

EA Governance and Compliance

Enterprise Architects, Business Architects, Risk Managers and Compliance Managers are in a strong position to assist the business to review their existing data flows and applications against the GDPR requirements.

See http://ec.europa.eu/justice/data-protection/reform/index_en.htm

Companies with an Enterprise Architecture capability will also normally have set up an EA Governance and Compliance capability. For GDPR, the Strategies, Goals, Objectives, Measures, Policies, Business Rules and Governance organisation structure need to all be reviewed and enhanced.
The Enterprise Architecture team should already be playing a key role in these EA governance bodies, the Architecture Governance Board of strategic changes and in ensuring compliance with policies, rules, patterns and standards in a Technical Design Authority.

Risk management and Audit processes also need to be reviewed and updated. Enterprise Architects are usually involved as key stakeholders for these. Are there adequate controls and monitoring of events? Is the data secure against hacking and accidental loss?

Enterprise Architecture Modelling

As per any enterprise architecture work, you need to identify the current and target architectures, identify gaps and change initiatives and then plan a roadmap of those changes. Heatmaps for GDPR related changes are an essential way to identify and prioritise GDPR changes needed.

After Enterprise Architecture changes for GDPR, then it is important to maintain continual operation, monitoring and reporting, so that the target Enterprise Architecture will need to include new end to end processes, roles and responsibilities for the business, to ensure continual compliance. Is data being captured with consent and a clear purpose, fully communicated to customers? ‘Security by Design’ is the new normal. This requires enterprise architects, compliance managers and C level executives to build compliance into the design of all current and future Enterprise Architecture models.

Enterprise Architecture models need at minimum, to review the following deliverables:

  • Data Catalogue
  • Data Model diagram
  • Process model
  • Process flow diagrams (Event-driven Value streams)
  • Application Service models (Catalogues and Diagrams)
  • Application model (Catalogues and Diagrams)
  • Application Integration/Flow diagrams
  • Data storage models (Databases, Data stores, Messages)
  • Data flow Diagrams
  • Infrastructure Service Catalogues
  • Infrastructure Component Catalogues
  • Infrastructure Diagrams

What are the key Changes for GDPR?

Compared to the current data protection framework under the Data Protection Act 1998, the GDPR will bring a number of important changes and enhancements including:

  • Increased accountability and greater level of responsibility within organisations to ensure that personal data is fully protected and processed according to the regulations
  • More data will be classified as customers personal data, not just in normal databases but also in EUC component and in Cloud data storage
  • New internal role of a Data Protection Officer
  • External Roles outside the company will also be regulated, such as contractors, partners and service providers
  • Eye-wateringly high cost of non-compliance
  • New requirements for notification of data losses through hacking and lack of compliance
  • Greater rights for customers to understand how their data is to be used, to give their informed consent, and to make future requests to change their consent
  • Risk Assessments
  • Privacy Impact Assessments

See also https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/

Benefits of GDPR

What are people expecting your company to do with their data? It’s about re-establishing your customers’ trust, and that you won’t change your mind and do something different or evil with their data. This trust will provide an increased business advantage for companies that get it right.

If a company cannot demonstrate that they are using Enterprise Architecture to achieve compliance with GDPR, then they are risking their reputation, which ultimate means less business and less profits.

With Digital Architecture, companies are designing their business with an Outside -In approach, designing their value proposition around what customers really want in their customer journeys.

GDPR is essentially designing the Outside-In approach for the protection of customers private data.

Enterprise Architecture perspectives

From an Enterprise Architecture perspective you need to ensure that:

  • Decision makers and C level executives are aware that the law is changing to the GDPR and time is running out to plan the changes
  • They use Enterprise Architecture to drive this as a strategic change, with new initiatives to be designed in the target Enterprise Architecture model and managed in the EA Roadmap
  • There is full knowledge of how information and data is managed, flows around the company and is changed by processes, services and applications
  • New business processes are created to handle customers new rights
  • Enterprise Architecture is used to managed and rapidly create an EA roadmap for strategic changes needed
  • A new meta model is designed to include customers consents, breach events and other change events
  • New business processes are created to handle data breaches and GDPR reporting requirements
  • Risks, issues and mitigations are well modelled
  • New Application Services are created
  • New package Applications are procured, which have updated support for GDPR data and processes

Conclusion

Yes, it’s a big strategic piece of work to do, with a May 2018 deadline that is getting ever closer, but luckily Enterprise Architecture is designed for managing just this kind of strategic change scenario.

So to avoid GDPR fines in 2018, start using Enterprise Architecture now, to plan and execute the strategic changes needed.

It makes sense!

How can you not already be using Enterprise Architecture?

Do some enterprise architects become masters at their discipline without hours of practice, or does it really take 10,000 hours?
Of course 10,000 hours is a long time. 5 hours per day for 10 years? Its not a fast process, and most people are always looking for short cuts.
Is 10,000 hours the average or the minimum?

Do enterprise architects need some innate talent, or can this discipline be learnt?
How long does that take? What do you need to learn?

“If you can’t explain enterprise architecture to a six year old, you don’t understand it yourself.” – as Einstein would have said.

What is Enterprise Architecture?

Enterprise Architecture (EA) is the process of understanding the business model, the enterprise vision and both the business and IT strategies and then enabling the effective execution of the resulting change initiatives.

Enterprise architecture does this by modelling the current state of the enterprise and defines a number of enterprise’s future target states, defines the dependencies, identifies the best investment initiatives, identifies the change initiatives and then plans the required business transformations in the future.

Business transformations includes defining holistic models and road maps of the change initiatives, covering all domains from a strategic, business, organisation, information, services, application, technology and infrastructure perspectives. Usually that also includes modelling the market environment (what the competitors are doing) and customers own architectures (customer’s own processes and customer journeys).

The goal of Enterprise Architecture is essentially to successfully manage the process from Strategy to Execution.
Strategy execution is generally an enterprise’s most challenging issue, especially with the current attention on digital or customer focused transformations.

What is an Enterprise Architect?

Too often the enterprise architect role is misinterpreted and misapplied. It is not another name for the IT architect or solution architect roles at a project development level. It is definitely not another name for a solution architect who has achieved a certain level of seniority.
A solution architect can’t call themselves an enterprise architect, without first attaining an expert level of understanding and knowledge of the business as well as of IT.

An Enterprise Architect is a senior management executive leadership role concerned with how an Enterprise works from a business perspective, planning the future of how an enterprise needs to be transformed and changed over time and how it need to operate in its future environment. Inevitably IT is a large part of that change but in itself doesn’t define what Enterprise Architecture is all about.

Becoming a master : Gaining Skills and experience

Ignorance brings chaos and not knowledge, and diligent study and learning is essential.

No matter where you start from, it is necessary to learn from others and apply what you have learnt. Finding the right mentor is important.

Enterprise Architecture is a broad discipline and skills and experience in programming and development will not make you an Enterprise architect.
You have to learn about how a business works in terms of its business strategy and business capabilities, how it delivers value to its customers with its Business Model and its value proposition. You have to understand what Business Capabilities an enterprise has and how those capabilities are realised in the future with a mapping to the staff, organisation structure, business processes, information/data needed (and flowing), enabling applications and the services they provide, as well as the underlying technology and infrastructure. Technology & infrastructure isn’t simply IT by the way, but can includes factories, physical facilities and machinery. Remember the Internet of things includes smart machines, Internet enabled cars, integrated factories etc, not just IT stuff.

What does an enterprise architect needs to know?

  • A clear understanding of what Enterprise Architecture is
  • Abstract thinking
  • Conceptualisation
  • Visualisation
  • Visioning
  • Discussing strategy and planning
  • Modelling the enterprise – to understand anything requires a mental model or an image of it.
  • Modelling the future change options and alternatives
  • Understanding Meta modelling and applying the important concepts
  • Understanding different stakeholders viewpoints
  • Identifying best practises
  • Understanding the enterprise architecture processes
  • Researching new topics
  • Following business and IT trends
  • Assessing opportunities
  • Critically evaluating information gathered from multiple sources
  • Evaluating investments
  • Evaluating future business and IT trends
  • Making recommendations
  • Analysing the architectures
  • Aligning business and IT
  • System thinking
  • Designing
  • Road-mapping and business transformation
  • Making decisions
  • Teaching and mentoring
  • Writing and communicating
  • Persuasion and influencing
  • Managing complexity
  • Managing performance
  • Providing value to the enterprise

Enterprise Architecture thinking and deliverables are often seen as purely to do with software delivery, solutions development, technology selection and specific implementation details. These are aspects of the work that is done, but only a fraction.

Its worth repeating that Enterprise Architecture covers changes to the whole business not only IT related changes.

What should an EA job specification look for?

  • 10 + years of experience of Enterprise Architecture including Business Architecture
  • An understanding between future strategy planning and running current operations and software development
  • Understanding how businesses work
  • An understanding the difference in scope and context between enterprise architecture and solution architecture
  • An understanding of stakeholder engagement, analysis and design.
  • A broad, enterprise-wide view of the enterprise and appreciation of strategy, business capabilities, business processes, services, information, data, enabling applications, technologies and infrastructure.
  • An understanding of governance, risks and compliance
  • A demonstrated ability to recognise structural issues within the enterprise, interdependencies, issues and challenges, influences, motivations
  • The ability to apply enterprise architectural principles to business problems
  • Experience using model-based representations that can be adjusted as required to collect, aggregate or disaggregate complex and multiple views about the enterprise
  • Extensive experience modelling using a variety of tools and techniques
  • Stakeholder analysis experience
  • Experience in establishing an enterprise architecture capability within the organisation.
  • Participating in strategy discussions and planning
  • Understanding evolutions and system dynamics
  • Balancing the requisite variety
  • Guiding the impact of strategy on business capabilities
  • Guiding business transformations
    Open minded and challenging group think

What are the habits of successful Enterprise Architects?

  • Use a business led Enterprise Architecture approach
  • Use business models to understand the business environment
  • Use business capability models to understand outcomes of value and planning of change with heat maps
  • Use strategy maps, Wardley maps and system dynamics models to understand  dependencies and evolution
  • Use information models to understand underlying data, information and knowledge
  • Use appropriate frameworks to apply consistent structure of key deliverables
  • Use appropriate EA tool to accelerate modelling and analysis of investments and options
  • Use appropriate approaches (Agile, Lean, Six Sigma, Iterative) at the right time (one size does not fit all)

Master Enterprise Architect

A master enterprise architect requires a unique blend of skills, which include keen awareness of the business, looking into the future, analysing trends, understanding the evolution of dependencies, dealing with various strategies, managing business transformations and change, dealing with stakeholders, understanding IT architectures.

Working closely with C level executives and senior management, master enterprise architects get into the detail of what makes a businesses successful by getting to the heart of their business strategies, goals and objectives, making better decisions and managing the complexity of strategy execution to enable the enterprise to gain maximum value from their investments in change.

How long does this all take? Roughly 10,000 hours, if not more…
Its worth reading the book ‘Outliers: The Story of Success’ by Malcolm Gladwell

 

Enterprise Architecture is much more than a list of components. Too often one sees diagrams in slide decks that are either simple lists, a layered view of domains, or a graphical hierarchy. And these are supposed to represent the ‘Architecture’?

These visualisations are good to use to inform on the scope and context, but they really only tell us half the story.

The various components (building blocks in TOGAF) will all have a large variety of connections between them to other components. It is these connections that in fact provide the value of an enterprise architecture model, and cement everything together.
An Enterprise Architecture model is a graph of connections. The information and knowledge created in the enterprise architecture model can be viewed from many perspectives and needs to satisfy many stakeholders. Everything is dependent on everything else, and everything is connected in multiple ways. Components never exist in isolation.

An enterprise architecture model is holistic and models the whole enterprise as a sum of the parts, from a variety of different perspectives and stakeholder viewpoints. All enterprises are essentially multi-dimensional, and the connections are the way we can understand all the dimensions.

The connection types can include connections such as:

  • Traceability
  • Impact
  • Association
  • Responsible
  • Affinity
  • Correlation
  • Dependency
  • Interaction
  • Cost
  • Accesses
  • Motivation
  • Evolution
  • Need
  • Enables
  • Assignment
  • Realisation
  • Uses
  • Requires

The name, definitions and set of all possible connection types will be specified in your favourite EA Framework/Meta Model (I.e. TOGAF, ArchiMate, FEAF, MODAF etc.). It’s more common to customise a meta model by adding new connections between existing components that it is to add new component types themselves

Using a well developed EA model, CxOs will be able to look at all the connections help to understand the way the enterprise works as a whole, as a holistic enterprise. The connection provide the cohesion in the model. CxOs can understand all the connections internally between business units, their business model, their business motivation model and externally with their customers and suppliers. And to gain an understanding of how the company fits within the market environment and compares with its competitors. The connections provide knowledge and dynamics.

To get the right answers you need to ask the right questions. The connections between components will provide the answers and support decision making.

Here are some questions that might be asked:

  • How are the Business Capabilities realised?
  • How do the Business Processes access Data and Information?
  • What Knowledge is available to my staff?
  • What Business Services are associated with my Value Proposition in my Business Model?
  • How does the Product Lifecycle change over time?
  • What are the dependencies between Business Capabilities?
  • How are my User Needs and Customer Journeys satisfied?
  • What components are expected to evolve in the future?
  • How do my Business Capabilities compare to those of my Competitors?
  • How does my enterprise compare to the Market Offerings?
  • When are the Capability Increments realised with Initiatives in the Roadmap?
  • Which Initiatives are planned as Programmes and Projects?
  • What Resources are assigned to each Initiative or Project?
  • What are the Risks associated with my potential Investments?
  • What are the dependencies in the Project?

More connections in an EA model will make that model richer and more useful. Connections provide the behaviour in a model.
Connections are not just static but are dynamic and may be changed far more often that the components they link. Modelling dynamic behaviour in an EA model is something that is often overlooked.

An Enterprise Architect is thus someone who makes vital use of “the fundamental interconnectedness of all things”, in order to understand complexity and to find the right answers for the whole enterprise; and who thereby becomes the master of changes, transformations and evolution of the enterprise over time.

Increased interconnectedness in an enterprise architecture model can stimulate innovation and the emergence of new ideas and possibilities.

Written by Adrian Campbell

A good analogy for an Enterprise Architecture capability is to think of it as the equivalence to an intelligence corps in the military.
Military Leaders and business decision makers will use this Strategic Intelligence capability to:

  • Know what their current capabilities are
  • Know the capabilities of the enemy (competitors) are
  • Understand and gain awareness of the market situation
  • Understand the nature of the environment (the market place)
  • Understand the chances of success (costs and revenue)
  • Help define their goals and objectives
  • Help plan their strategies and tactics
  • Help create plans of attack or defence (a roadmap for transformation ad change)
  • Help to make new plans as the situation changes (a plan is always the first casualty of war)

The military intelligence corps is responsible for gathering, analysing and disseminating intelligence and knowledge about the military situation.

Enterprise Architecture is a business capability that collects information about the whole enterprise and uses various modelling and analysis approaches to create knowledge about the enterprise, provide advice and guidance to CxOs and heads of business units, and provide intelligence in support of their strategic decisions.

Most enterprises maintain some kind of business intelligence capability to collect information and analyse it, but this is not enough. An enterprise architecture capability is also needed.

For a long time the high level decisions made by executives and senior managers have often purely been based on intuition, personal experience and anecdotes.
Often their experience is 20+ years old and no longer relevant. Unfortunately most CxOs didn’t ever learn about enterprise architecture in their MBA courses, or were never taught about it in the first place. This is woeful ignorance in todays fast moving and complex business environment. Don’t let other players on the golf course make your decisions for you.

Often CxOs and senior decision makers are simply copying the decisions made by their competitors, for better or worse. If one of their competitors is playing with Blockchain, so that must be a good strategy right? Right? Another silver bullet or a waste of money? Does your enterprise architecture capability give you a competitive weapon?

Companies that want to succeed should put their trust in real strategic Enterprise Architecture.

Q. How many CxOs does it take to change a light bulb?
A. None.
– They get their Enterprise Architects to enable the strategic change.

Connections between components in an enterprise architecture model are the basis for identifying, creating and providing knowledge, analysis and intelligence.
In other words, Enterprise Architecture creates the Situational Awareness model for the organisation. The battle map on which the strategies and tactics can be plotted.

Enterprise Architecture models include the strategy, business architecture, information/data architecture, application architecture, infrastructure architecture domains etc.
EA Models also includes a study of the  behaviour of their contacts, customers, competitors, vendors and suppliers, from both a strategic and tactical perspective. Both for the current state and future target state, or indeed multiple alternative future states based on alternative business scenarios. The target operating model is the same as the target enterprise architecture model.

The Enterprise Architecture capability provides valuable knowledge, intelligence and experience of the dynamic changes going on and not just as a static set of deliverables or inflexible process. When the strategic situation changes, then the Enterprise Architecture body of knowledge and intelligence needs to rapidly provide the answers. Keeping pace with today’s dynamic markets requires an Enterprise Architecture capability to enable and deliver a strong strategy and amplify it. A better way to change that light bulb.

Achieving a company’s full potential and stimulating creative needs, innovation and knowledge needs answers to lots of known and unknown questions.
Leaders focus on the most important decisions, answering questions such as:

  • What if a competitor does this?
  • What if the regulations change?
  • What can we do to help?
  • How to persuade the customer to buy more?
  • How to increase profits?
  • How to improve our service?
  • How to stay competitive in a changing market?
  • How can we innovate?

 

Achieving instant readiness with Enterprise Architecture is better than not being ready at all, or too late.
If you (the CEO) don’t act now to establish an Enterprise Architecture capability now then you will lose out on competitiveness and efficiency.

The most successful leaders in business already have a Strategic Enterprise Architecture capability established, providing the organisation with Intelligence and Knowledge.

Strategic Enterprise Architecture (Intelligence corp) capability includes the following sub-capabilities that enable the most successful leaders in business.

An Enterprise Architecture Capability:

  • Provides the ability to envision and visualise an ideal future state based and create a roadmap in order to realise it (situational awareness and winning the war)
  • Provides the ability to understand trends that present threats or opportunities for an organisation (countering the enemies threats)
  • Provides the ability to identify, analyse, integrate components and connections required to achieve a business strategy (organising your forces)
  • Enables and motivates people to work together to realise a strategic business transformation. (ensures success and keeps up morale)
  • Enables governance and compliance of strategic relationships with vendors and suppliers, including for cloud services (maintains direction and momentum)

..I love the smell of Enterprise Architecture in the morning. Smells like victory…

 

How often is an established Enterprise Architecture approach used to create a Target Operating Model?
If the answer is not often, then why not?
If the answer is yes all the time, then how should we go about creating one ?
Are traditional consultancy approaches to target operating models good enough?

What is an Operating Model?

The term Operating Model is a fuzzy one. What does it really mean? What is in an Operating Model?
It appears that often some consultants totally go out of their way to avoid mentioning Enterprise Architecture and instead focus solely on the term Operating Model.
This may well be a side effect of the misunderstanding of Enterprise Architecture as only concerned with IT Architecture. Or may be because those consultants want to invent new terminology to make their services sound unique?

Is a Target Operating Model just another name for the Target Enterprise Architecture?
And by Enterprise Architecture of course I don’t mean just the IT Architecture domains, but all the EA domains which now include:
  • Strategy & Motivation
  • Business Architecture
  • Information/Data Architecture
  • Application and Application Service Architecture
  • Technology & Infrastructure Architecture
  • Physical Architecture (I.e. Archimate 3 Physical Elements)
It seems to me that a target operating model is fundamentally just another name for the full target Enterprise Architecture model and in particular primarily represents the mapping between the Strategy and Business Architecture domains and the other EA domains.

Why do we need an Operating Model?

An Operating model at the very least represents the mapping between the strategic views and components, such as :
  • Business Model (BMC)
  • Business Motivation Model (BMM)
  • Wardley Model
  • Strategic Map/Balanced Score Card (SMBSC)
  • Business Capability Models
and the rest of the enterprise architecture models, views and components in the other remaining EA domains.
If we update the strategies then we will need to update how those strategies will be realised.
A strategic change / business transformation programme will be used to realise the new strategic changes and essentially change resulting operating model.
Many refer to a Target Operating Model in a simplistic fashion as consisting of People, Processes and Technology, but there is more to it than that.
According to POLISM, a definition that comes from Ashridge Business School, an operating model covers six component areas:
Processes
– The business processes that needs to be performed
Organisation and people
– The people and roles performing the processes and how they are grouped into organisation units
Locations, buildings and other assets
– The places where the work is done and the technology, infrastructure and physical equipment in those places needed to support the work
Information
– The Information, data and applications needed to support the work
Sourcing and partners
– External entities, people and organisations outside the enterprise also performing the work
Management
– the management processes for planning and managing the work
Missing from this list is an analysis and understanding of Customers, Risks, Assessments, Performance metrics and measures, and other influences.
A secondary question that I always ask myself is why don’t Business Masters (MBA) courses teach executives and management about Enterprise Architecture?
This may indeed be the source of the fuzziness and lack of preciseness of the term Target Operating Model?

Target Enterprise Architecture Model

For me a better approach is to use a complete Target Enterprise Architecture Model as the Target Operating Model.
The Target Enterprise Architecture Model will consist of a number of more specific models (viewpoints) grouped into a number of EA domains.
Each of the EA domains will typically address the needs of different stakeholders and
visualises their concerns. This is a bit like for the POLISM stakeholders above but in better detail.
Each of the specific models listed within an EA Domain below may well evolve and change over time independently. The specific models can be updated when necessary as the enterprise itself evolves and changes in reaction to changing business and customer environments.
There is traceability connection between each specific model, so creating or updating one model will inform and influence other models. The primary traceability connection are see in the diagram below.
As with any target enterprise architecture models, there can be a number of alternative future versions often aligned to different strategic themes,  business scenarios or intermediate transition architectures. There need not be a single view of the future.
The complete set of the following specific models makes up the whole target Enterprise Architecture model, grouped into the following EA Domains:

Strategic Architecture Domain

Business Model (BMC)
Wardley Model
Business Motivation Model (BMM)
Strategy Map / Balanced Score Card Model
Value Chain Model

Influences Domain

Influences model
Stakeholders model

Customer (Outside In) Domain

Business Value Network Model
Business Scenario Model
Customer Journey Model
Business Services  (value proposition) Model
Business Events Model
Business Service Flow Model

Risks Domain

Risks (RAID) Model
Assessment Model
Business Capability Domain
Business Capability Model
Capability Dependency Model
Component Business Model

Governance and Compliance Domain

Business Policy Model
Business Rules Model
Governance Model
Requirements Model

Organisation Domain

Business Context Model
Organisation Structure Model
Business Locations Model
Business Roles Model

Business Process Domain

Business Process Hierarchy Model
Business Process Flow (Value Streams) Model

Knowledge/ Information/ Data Domain

Knowledge Model
Business Information Flow Model
Business Information Object Model
Logical Data Object Model
Physical Message Model
Physical Data Storage Model

Applications Domain

Application Services Model
Application Landscape Model
Application Integration Model

Infrastructure Domain

Infrastructure Services Model
Infrastructure Model
Network Model
Physical Models

Roadmap Domain

Initiatives Model
EA Roadmap Model
Project Roadmap Model
Programmes and Project Portfolio Model
fullsizerender

Summary

In summary we should not be defining target operating models with yesterday’s approaches, but must instead use today’s better Enterprise Architecture techniques and models for defining the next Target Operating Model.
The models identified above are all fully defined and available in an Abacus model. Anyone who wants to follow this approach can contact me for more details.

Digital strategy is not simply about marketing. It is about a better engagement with potential and existing customers. It is about the perception of the brand created with customers though close interaction via social media and close communication leading to a value proposition that can better serve their actual and future needs.

As with any business strategy, the enterprise architecture discipline is there to support the business transformation to success with a design strategy. It is useful here to remind everyone that enterprise architecture is not just another name for an enterprise wide view of the IT Architecture and the underlying infrastructure architecture

The term ‘Enterprise’ in Enterprise Architecture refers to the greater scope of the organisation which includes the Customers, contacts, stakeholders in the wider market environment which is addressed by the Digital Strategy.

Enterprise Architecture will help organisations to drive innovations and new business capabilities across their entire value chain and to better understand the digital environment in which they will be operating.

Joe Tucci, Chairman and CEO, EMC Corp.– “To stay relevant in this new, always-connected digital universe, businesses in virtually every industry are reinventing their business models for unprecedented customer access, interaction, speed, and scale.”

Using Enterprise Architecture to provide a blueprint for digital strategy

Enterprise architecture consists of the following primary architecture domains.

  • Strategy
  • Performance Architecture
  • Business Architecture
  • Information/Data Architecture
  • Service/Application Architecture
  • Infrastructure/Technical Architecture
  • Business Transformation/ EA Roadmap

In addition to these usual enterprise architecture domains, I propose that further Architecture Domains are required for supporting a Digital Strategy.

Additional Architecture Domains  
Customer Architecture

 

Modelling the Customers’ own Environment, their processes, usage scenarios, customer journeys. Includes the communication channels used for communications directly to the customers and other external stakeholders.
Market Architecture Modelling the outside-in view of what is happening outside the organisation boundaries in the Environment in which the enterprise does business, Social media, Competitors, Competitors Value propositions.
Brand Architecture

 

The branding, value proposition, projected identity that provides value to the customers for the lifecycle of the business. Includes generic communication to the customer and market, advertising the brand and value propositions.

Figure 1 Enterprise Architecture for Digital Strategy

EA for Digital Strategy

Strategy

Obtain clarity on the goals, objectives and principles guiding your digital strategy Business strategy /Digital strategy

  • Mission
  • Vision
  • Business motivation model
  • Business Model
  • Goals and objectives

Market Architecture

Identify the environmental, industry and internal factors that are influencing the digital strategy.

  • Communities
  • Market environment
  • Modelling what the competition is doing
  • Assumptions
  • Networks
  • Competitors and their activities
  • Who else is in your space?
  • How do you differentiate?
  • Market trends
  • Topics
  • Hashtags
  • Media
  • Threats and opportunities
  • Gaps
  • Blue ocean
  • Search topics

Customer Architecture

As usual this means developing Business Scenarios and Customers Journeys, but also modelling the customers (potential and actual) own business processes.

These models will help to understand the customer touch points with the organisation and their desired brand and product experiences.

The Customer Architecture will also include a Connection Model to understand the relationships with customers, communities, to better understand the customers own information and process flows.

A current state Connection Model will capture the Communities, External online nodes, web sites, collaboration social networks (Facebook, Twitter), mobile platforms (IOS, Android) and cloud platforms (Evernote, Google Drive, DropBox, OneDrive) where content exists and customers will go to visit. This Connections model will also include Search sites (Google),

multimedia sites (Flickr), advertising (Ad-Words), entertainment and gaming sites eCommerce sites (Amazon, eBay ), Mobile applications (from Apple Store,  Google Play), Smart TV applications etc.

This is similar to a Context Diagram showing interaction between the Organisation and its Stakeholders, but in this case the organisation is not in the centre of the diagram and may not be shown at all in a current state (as-is) Connection Model. The organisation will however be shown in a target state Connection Model.

In a target state Connection model, it will be important to model how the organisations internal models will be coordinated and aligned to the Customers connection Model.

  • Outside-in perspectives
  • Obtain clarity on who the customer, consumer, partners are, their roles and their values.
  • VPECT.
  • Business Scenarios
  • Customers journeys
  • Wardley Models
  • Customers own processes
  • Understand the customer touch points and the desired brand and product experiences
  • Connect relationships with customers to better understand them over time
  • Customers own information and process flow
  • External online nodes, web sites, networks, platforms where content exists and customers visit
  • Communications
  • Obtain clarity on how the organisation means to listen and respond to consumers.
  • Multi-channel / Omni channel communications
  • Communications flows both ways via whatever channel the customer is comfortable with
  • Customers’ ideas
  • Many channels and many messages
  • Understanding and analysis of those messages
  • Gaining customers’ attention
  • Earning their trust
  • Customers motivation
  • How customers share content

Brand Architecture

A brand’s look and feel and tone of voice is as important as its identity, experiences and value proposition.

  • Creating brand experiences
  • Brands
  • Brand story
  • Brand Strategy – Developing a creative brand strategy that is fit for purpose, up to date and distinctive is key to establishing all marketing communications.
  • Who engages with your brand?
  • Selling the Experience
  • Understand the customer touch points and the intended brand and product experiences
  • Insights about Customers – observations that trigger innovations
  • Blue ocean strategies

The internal mode of the organisations Brand will need to be part of the Value Proposition model and show where the Brand messages will be projected.

  • Modelling what the customers will love to buy
  • Modelling how customers interact via social media
  • Causal loop model (system dynamics)
  • Modelling what customers are interested in.
  • Mapping to the value proposition
  • Minimum viable concept
  • Behaviour change model
  • Value and truth about the value propositions offered
  • Value propositions
  • Products
  • Business Services

Business Architecture

Business model canvas

Create the structure required to understand the business model required to realise your digital strategy

Create transparency and traceability across the market model, products and business services model, and the target operating model

Business capability model

  • Create a view of the organisational capabilities across people, process, information and technology required to deliver the brand and product experiences.
  • Capability assessment against goals and objectives
  • Business Capability based Requirements
  • Improve the way you manage your digital requirements
  • Business Capabilities can be informed by the user needs identified by using Wardley models

Manage information from data architecture and information security through to delivering key messages to the market environment

  • Content management
  • Understand the content management approach and how it is enabled.
  • Value of each bit of content.
  • Relationship of content to value proposition
  • System dynamics model (stocks and flows / cause and effect)
  • System thinking

Governance

Provide clarity over decision making across the digital architecture

Business Transformation / EA roadmap

Create an understanding of the extent at which your current capabilities are able to support your digital strategy

Create clarity of the EA roadmap required to support the digital strategy

Obtain consensus, commitment and support for your digital strategy and roadmap which we believe are critical to the success of your strategy

Performance architecture

Obtain clarity on your measures of success and identify plans to measure and monitor them

  • Investment case
  • Procurement
  • Programme/Project Portfolio management
  • Delivery plan

As usual if you don’t measure, then you can’t manage. However, it is surprising just how many enterprises fail to measure anything at all, including what they have done and what they plan to do.

  • Define Metrics and create measures
  • Critical Success factors
  • Capability Maturity models

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.

As Business Capabilities are directly derived from the corporate strategic plan and are designed to satisfy the enterprise’s business strategies, goals and objectives, so they provide an excellent basis for the creation of an Enterprise Architecture Roadmap.

What are Business Capabilities?

A Business Capability represents the ability of an organisation to perform an activity that results in an outcome of value. Business Capabilities are as far as possible expressed in terms of those business outcomes and value. As far as I know the concept originated from MODAF and was later adopted by TOGAF. See http://en.wikipedia.org/wiki/Capability_management_in_business

Many Enterprise Architects and organisations fail to really use them, but in fact they are slowly becoming a common EA deliverable and a way of developing a target operating model view.

The key to their increasing popularity is because the Business Capabilities are expressed in terms of business outcomes and value rather than in purely functional or IT terms (i.e. Not just in terms of business unit needs or in terms of IT Solutions) thereby ensuring IT alignment with the business. Being expressed in terms of outcomes and values also means that Business Capabilities are tied to the outside in perspective of the Customer Journey and Strategic Scenarios, rather than the inside out perspective.

A good book to read about the outside in perspective is “Outside In: The power of putting Customers at the Center of Your business” by Harley Manning et al. http://www.amazon.co.uk/Outside-In-Putting-Customers-Business/dp/1477800085/ref=sr_1_1?ie=UTF8&qid=1371351364&sr=8-1&keywords=outside+in.

In order for an organisation to perform an activity, many parts of the organisation need to be involved. Consequently a Business Capability is modelled as grouping of other EA concepts including the following:

  • People
  • Organisation Units
  • Functions
  • Processes
  • Business Services
  • Information & Data
  • Application Services
  • Applications
  • Infrastructure Services
  • Infrastructure

In this way a Business Capability can be seen as a cross cutting slice through a typical enterprise architecture model.

A Business Capability is used for managing units of strategic business change and providing the mandate for programmes and project portfolio. Subsequently, project will develop a solution that either creates a whole new Business Capability or updates a Business capability by implementing a Capability Increment.

Thus, Business Capabilities and Capability increments provide the basis for the development of the EA Roadmap.

Business Capability Model

UKRA BCM

Figure 1: Example Business Capability Model Source: UK Government Reference Architecture (UKRA) v1.0

This diagram illustrates the start point for a Business Capability Model. This is a static view based on the style of IBM’s Component Business Model. This is a style diagram that has become quite popular.

The whole matrix represents all the Business Capabilities that the organisation performs. Each cell is a Business Capability.

The Columns usually reflect the high level value chain for the organisation or are major groupings of Business Capabilities that are meaningful to the business.

The Rows reflect the fundamental purpose of a Business Capability and there are normally three rows:

Row Aligned to the Viable System Model (VSM) system type
Direct (or Strategy) System 5 and system 4
Control (or Management) System 3, system 3* and system 2
Execute (or Operate) System 1

For details about VSM, the Viable system Model see http://en.wikipedia.org/wiki/Viable_System_Model and my earlier blog posts.

Business Capabilities also have dependencies between them. I.e. one Business Capability has to exist before another Business Capability can be achieved.

Implementing Business Strategies requires new or changed Business Capabilities, but for the most cases we are just changing some aspects of the Business Capability rather than introducing brand new ones. This is the Capability Increment.

Relationship between Business Capabilities, Enterprise Architecture and projects

Figure 2: Diagram showing Business Capabilities Source: TOGAF

The diagram above shows the relationships between Business Capabilities and Capability Increments, and also related the Enterprise Architecture development method phases and definition of work packages for the Programme and Project Portfolios.

Capability Increments document the changes to each Business Capability that are needed to implement the Business or IT Strategies.

Each Business Capability is decomposed into one or more Capability Increments that are typically implemented at different points in time and in different Transition Architectures. Each Capability Increment represents a unit of change.

Capability Increments also have dependencies between them. I.e. one Capability Increment has to be implemented before another Capability Increment can be achieved.

BC and CI

Figure 3: Capability Dependency Model

The diagram above shows the dependency relationships between the Business Capabilities and between the Capability Increments.

The Capability Increments can be rearranged to show the dependency order in which they need to be applied. This sequence forms the basis for the EA Roadmap.

EA roadmap

Figure 4: EA Roadmap structure

Often it is may be useful (and politic) to represent several tracks in the EA Roadmap. For example tracks may be introduced for Strategic changes, Business changes and IT changes, since Capability increments may be identified in such a way that they can be implemented in parallel.

The Capability Increments can be grouped into Transition Architectures. A Transition Architecture is an intermediate Architecture model somewhere between the current state and the future (target) state Enterprise Architecture model being aimed for. A Transition Architecture will typically be aligned to intermediate and temporary stages in implementation.

Groups of one or more Capability Increments will provide the mandate for a solution or service to be developed in a project.

A Business Capability Model should be at the core of all Enterprise Architecture Models.

Often the Architecture Vision Model or Core Model is produced as a Business Capability Model to provide a strategic view that helps all stakeholders in an organisation to develop a common understanding of what needs to be done and what needs to be changed.

(With thanks to Lee Hepplewhite for some aspects of this approach)

Business Architecture

23 March 2013

Tom Graves recently participated in an Open Group TweetJam on Business Architecture. You can read about the results of this at http://weblog.tetradian.com/2013/03/20/opengroup-on-bizarch/

Unfortunately I didn’t hear about this in time to participate but I thought I’d record my own thoughts here.

The questions were:

  1. How do you define Business Architecture?
  2. What is the role of the business architect? What real world business problems does Business Architecture solve?
  3. How is the role of the business architect changing? What are the drivers of this change?
  4. How does Business Architecture differ from Enterprise Architecture?
  5. How can business architects and enterprise architects work together?
  6. What’s in store for Business Architecture in the future?

How do you define Business Architecture?

Business Architecture is one of the primary domains within Enterprise Architecture. It deals with the architecture of the business, ideally from a business perspective and is expressed in business terminology.

It should not really be considered a separate discipline from Enterprise Architecture but often is by those who persist in misunderstanding that Enterprise Architecture is only about IT and not about the whole of the enterprise.

Business Architecture deals with the structure and design of how an enterprise operates, makes money or delivers value, how it organises itself in order to provide products and business services to its customers, clients and consumers. It should be expressed independently of how the business architecture will be mapped to the underlying application architecture and infrastructure architecture, but is more connected to the business/contextual view of the information/data architecture and will include the organisation architecture.

Business Architecture is centred on the business and the business strategy, not on IT or on the IT Strategy and should not be considered just a source of requirements for IT projects (which is the impression that TOGAF gives of Business Architecture).

In general Business Architecture includes the following deliverables:

BizArch deliverables
A Business Architect is primarily concerned with supporting and advising the senior executives, providing advice and guidance, and influencing decision making for the Business Architecture domain.

 

What is the role of the business architect? 

As a specialised type of Enterprise Architect, they are in a leadership role, close to business management working for the CxOs to evaluate and elaborate possible future strategic scenarios.

They have a responsibility to guide, recommend and oversee the realisation of the business strategies identified by the CxOs, but they don’t control the business strategy or make the actual investment and strategic change decisions.

What real world business problems does Business Architecture solve?

As a type of Enterprise Architect, a Business Architect deals with strategic change, business transformation activities concerning topics such as:

  • Ecommerce changes
  • Consolidation
  • Cost reduction
  • Process improvement and efficiency
  • New organisation design
  • Mergers & Acquisitions
  • Reuse of shared services
  • New markets
  • Regulatory and legal changes

One should not forget that, by definition, an Enterprise Architecture model covers everything about the enterprise including the environment and market which it operates in, its Business Strategies, its Business Architecture as well as the rest of the Enterprise Architect domains.

How is the role of the business architect changing? What are the drivers of this change?

The role of a Business Architect is becoming much more distinct than it has been. many organisations are maturing their enterprise architecture functions that were previously just centred on IT architecture and are now specifically introducing a Business Architect role.

How the Business Architect role differs from other roles such as a Business Analyst, Business Change manager, Business Transformation Manager etc. is still playing out. I discussed this to some extent in a previous blog post – The difference between a Business Architect and a Business Analyst.

Another current difference is that a Business Architect is often closely associated with the Business units (and perhaps reports to a business line manager of sorts) and therefore is seen as being on the ‘Demand’ side of a business, whereas the rest of the Enterprise Architects (including IT Architects) are often lumped into the IT department and therefore are seen as being on the ‘Supply’ side. In theory, the Enterprise Architects, including Business Architects, should only ever be on the ‘Demand’side and not seen as part of IT. They should report to the CxOs, ideally seen as part of a CEO Office.

How does Business Architecture differ from Enterprise Architecture?

A Business Architect is a type of (a ‘real’) Enterprise Architect. Business Architecture is a sub domain of Enterprise Architecture.

EA domains

How can business architects and enterprise architects work together?

Of course they can. The distinction in the question is artificial anyway, since a Business Architect is just a type of Enterprise Architect that specialises in the Business Architecture domain.

But in reality many organisations do have an unfortunate  tendency to make up their own interpretation of what these roles actually are.

What’s in store for Business Architecture in the future?

We will see more and more Business Architecture roles in the future as organisations mature their enterprise architecture strategy and capabilities, and they realise that they need to get to grips with their business model and how it is realised. They will need Business Architects to help them do that.

Business Architecture

For most enterprises embarking on large scale strategic planning and business transformation programmes it is all about staying robust, viable and efficient, continuing to deliver good outcomes and value to their customers/consumers/clients in the future. Enterprises should be wanting to stay competitive and efficient and beat the competition.
If the enterprise is to succeed, it must make strategic decisions and investments in change based on a thorough architectural gap analysis/impact analysis that is only possible with business architecture as a key part of their enterprise architecture function.

I recently saw a Forrester blog entry from George Colony at: http://blogs.forrester.com/george_colony/12-08-27-enterprise_architects_for_dummies_ceos

And recently I’ve been reading an interesting book called Good to Great by James Collins. See http://en.wikipedia.org/wiki/Good_to_Great

The Forrester blog talks about succeeding with realizing the business strategy by involving enterprise architects, whereas the Good to Great book doesn’t mention enterprise architects but just talks about needing the best people to achieve great things.

It raises the question ‘Does an organisation need enterprise architects to achieve greatness?’, and ‘What does an enterprise architect need to do to be great themselves?’.

An Enterprise architect will certainly bring a logical enterprise-wide view of strategic change, usually cutting across organisation boundaries. They will look at the strategic design of the enterprise vision in terms of interconnecting business capabilities, where a business capability is a similar concept to a ‘system’ as described in system thinking and the viable system model. They will help with the business thinking.

But is this how senior executives see strategic change?

I’ve experienced organisation restructuring close up at a large number of organisations over recent years and in all cases, the enterprise architects were not involved at all. The re-structuring tends to be done along business functional lines. Nothing wrong with that perhaps, but it does tend to bake in the old silo boundaries and restrict cross functional reuse of business capabilities.

Is this good or great, or merely good enough?

How do senior executives see enterprise architects?

Enterprise architects work with the executives, senior business stakeholders and heads of all the business functions to build a holistic enterprise architecture vision model that links the enterprise’s mission, business strategies and priorities to the current and future needs in an efficient and viable fashion.

For enterprise architects it’s typically not sufficient to merely produce a good vision and good roadmap, but the focus should be on producing a great one that is robust and viable way into the future.

Quick and dirty is not a great approach and is often a waste of money from a long term enterprise perspective.

There will inevitably be a sort of creative tension between the various lines of business and enterprise architecture. Part of the reason for this this is that the lines of business invariably take a top down view and the enterprise architects are naturally working across functional silos. There is often a sort of conflict of overlapping RACIs, a clash of who appears to be responsible for making a decision. Generally that is easy, it’s the business strategy owned by the business that makes the decisions.

But as George Colony observes in his blog, it’s the enterprise architects that span both the business and technical domains and act as ‘an internal trusted advisor who marries the best interests of the business with long-term technology strategy’.

An analogy is within the realm of politics, where the politicians take the decisions helped and supported by their advisors. Also like politics, the lines of business are often challenging each other and pandering to popularity polls.

This raises another thought, should an enterprise architect be popular or be professional? Can they be both at the same time? Should an enterprise architect indeed be a kind of politician following the whims of the time, or should they be seen to be standing up for doing the right things for the future?

Tactical short term changes are invariably much easier to build a business case and obtain investment for than multi-year long term strategic changes will ever be. Should an enterprise architect just focus on short term fixes, or do their job and focus on strategic change. Like a politician, should an enterprise architect aim to be liked and popular, or respected for their work furthering the best interests of the enterprise?

It’s rather like a politician who can only achieve changes within a single parliament, and therefore shies away from embarking on initiatives that will take a long time and multiple parliaments to achieve. Should an enterprise architect just be popular and play politics? Does this make an enterprise architect great? In fact, what does make a great enterprise architect? Ideally 40% of our job is communication. Maybe communication really means playing to the populous crowds? Does promising bread and circuses make things great?

James Collins says that good to great companies follow the principle of “First Who, Then What” and hire good people. Collins talks about good CEO’s typically have much humility. So maybe a great enterprise architect should also be humble? Perhaps a great enterprise architect is one who makes great decisions? But then if it is only the lines of business who make the decisions, what then? Often the enterprise architect is not in the position to make enterprise level decisions, only recommendations.

To be great enterprise architects should be focused on being neutral and not taking sides, working faithfully for the enterprise as a trusted advisor, taking the enterprise in whatever direction it chooses to go at whatever speed it wants to go, realizing the collective enterprise vision. In turn, the enterprise needs to treat enterprise architects as true trusted advisors and not just delivery agents. Enterprise architects should follow a set of principles, be honourable, forthright and avoid compromise, keeping the organisation honest. Maybe in doing that they won’t always be popular but they will be doing their job.

It has been said that ‘business leaders rarely succeed in marrying empirical rigor and creative thinking’, so it is the enterprise architects task to help them do this better and achieve a great enterprise and not just one that is just good enough. Just good enough is never good enough.

In my opinion, without enterprise architects, an enterprise cannot easily become great and may only achieve greatness through simple luck.

I’m often confronted by solution architects, IT and technical architects who don’t understand what Enterprise Architecture is all about. They usually misinterpret enterprise architecture from their own perspective as some kind of system design of ‘enterprise’ scale IS/IT systems and become frustrated when they discover that it is really something else. It often turns out that they are not usually working at the right level or with the right stakeholders in their organisation to be true enterprise architects. They are not working with the leadership team but within the scope of a small development project.

They can’t therefore see the wood (the ‘Enterprise’) for the trees (a project), let alone the helicopter view…

Enterprise architecture is in reality one of the most powerful management approaches that can be used by an organisation. It is not intended to be used (only) at a solution or project level but for the big decisions that an organisation’s leadership team have to make. The leadership (i.e. the C-level executives, and heads of divisions etc.) have to make the decisions based on the facts and knowledge base (the Enterprise Architecture repository) delivered by the enterprise architecture function. Those decisions are supported by the enterprise architecture function planning their execution in the EA roadmap. Each initiative in the EA roadmap is typically a new or changed Capability or Capability Increment (see MODAF and http://www.mod.uk/NR/rdonlyres/E43D93F6-6F43-4382-86BD-4C3B203F4AC6/0/20090217_CreatingCapabilityArchitectures_V1_0_U.pdf).

Typically the focus of Enterprise Architecture is on:

  • Increasing the return on business and IT investments by more closely aligning them with business needs.
  • Identifying areas for consolidating and reducing costs
  • Improving executive decision making
  • Increasing the benefits from innovation
  • Delivering strategic change initiatives
  • Managing business transformation activities

The Enterprise Architecture is also characterised across the following multiple dimensions:

  • Direction: Enterprise Architecture is focused on strategic planning (i.e. business transformation, strategic change programmes) and not on operational change (i.e. run the business, six sigma, lean processes)
  • Scope:  Enterprise Architecture is focused on the whole of the business (i.e. the Business Model and Business Operating Model) for all business and IS/IT functions, and not just on the IS/IT components.
  • Timeline: Enterprise Architecture is focused on the long term view of the future scenarios (up to 3/5 years in the future) and not just on a short term view of current state. Enterprise Architecture is focused on a roadmap of changes to an organisation’s capabilities.
  • Value Chain: Enterprise Architecture is focused on the whole of the enterprise (i.e. the extended organization and value chain) and not just on the scope of a delivery project
  • Stakeholders: Enterprise Architecture is focused on the needs and concerns of the C-level executives (CEO, CIO, COO etc.), business executives, corporate and business strategists, investors, strategic planners.

(ps. I tried to draw a diagram to illustrate where Enterprise Architecture lies on these dimensions but couldn’t visualise a multi-dimensional space…)

So overall, the primary purpose of Enterprise Architecture is to support strategic change such as :

  • The introduction of new customer and supplier channels such as  eCommerce
  • The consolidation of the existing portfolio of people, processes, application and infrastructure etc.
  • The reduction of costs and risks, ensuring the enterprise will remain viable and profitable
  • The design of a new organisation, business model and business operating model.
  • The due diligence for mergers and acquisitions and management of the resulting integration programme.
  • The development of smarter and more effective systems (not just IT systems).
  • The introduction of shared services and applications.
  • The introduction of new technology, platforms and infrastructure such as SaaS, Cloud etc.
  • The introduction of regulatory and legal changes such as Basel 3

 

In my future blog entries I will explore how Enterprise Architecture supports some of these areas.

The first one will be about how Enterprise Architecture is used to support Due Diligence activities prior to mergers and acquisitions.

 

%d bloggers like this: