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?

Advertisements

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

Typically the focus of Enterprise Architecture is on:

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

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

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

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

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

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

 

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

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

 

Enterprise Architecture is all about supporting strategic planning and business transformation activities, although many organisations seem to almost wilfully forget that this is one of the main purposes of Enterprise Architecture if not the most important one.

A business strategy is a long-term plan of changes for the whole enterprise which will address things like offering new products an business services, dealing with new customer or market segments, opening up niche opportunities, growth via mergers & acquisitions, cost consolidations and increased efficiencies. See http://en.wikipedia.org/wiki/Strategic_planning  and http://en.wikipedia.org/wiki/Business_transformation

Enterprise Architecture primarily focuses on what an enterprise needs to do in order to stay viable, efficient and profitable in the future. In Viable System Model (VSM) terms, Enterprise Architecture is a System 4 type of system. See http://en.wikipedia.org/wiki/Viable_system_model

Enterprise Architecture bridges the gap between new strategy ideas and the execution of those ideas, in the same way that the intelligence corp in the military provide intelligence about current and future capabilities to the generals and ensure that the appropriate planning takes place in order to win the military campaigns.
Many organisations without an Enterprise Architecture function will risk failing to properly implement or deliver the on their business strategy.

It is frequently reported that many strategic ideas and initiatives identified by C-level executives are never properly implemented or seen through to full operation by the business units. That big picture of the business strategy on the white board in the CEO’s office or a high level presentation can look deceptively simple in a board meeting, but as they say ‘the devil is in the detail’. The C-level executives are responsible for seeing that the strategy is implemented, but it will be the Enterprise Architect that works out the detail.

Organisations need to know where they are now and create a baseline Enterprise Architecture model of their current state, then create a future target Enterprise Architecture model and do impact and gap analysis between them. The future state Enterprise Architecture model often needs to contain not just one single future target model but multiple complementary or competing models of  the many future scenarios that are likely to have  been developed using Scenario Planning techniques. See http://en.wikipedia.org/wiki/Scenario_planning

Strategic business transformation can be hard. Enterprise Architecture makes it far easier to answer questions such as:

  • What Strategic initiatives are needed to fill the gaps found and address risks and issues?
  • What new or changed business capabilities will be needed?
  • What needs to be done when?
  • How does one prioritise the different strategic business initiatives on an Enterprise Architecture roadmap?
  • When are these investments in change going to be delivered?
  • How will the initiatives be funded?
  • What are the dependencies between the strategic initiatives?
  • How will the business model be changed?
  • How will the target Business Operating Model be changed?
  • What organisation units and business functions need to be changed?
  • What value chain and value streams need to be changed?
  • What are the costs and potential revenues?
  • How feasible is the business strategy?
  • What feedback mechanisms between ‘systems’ will be needed?
  • How will change be governed and how will compliance be assured? (i.e. how do we overcome resistance from difficult stakeholders, and the ‘Not invented here’ anti pattern?)
  • What controls, KPI’s, CSF’s, incentives, bonus structures will be needed?
  • What changes to the principles and standards will be needed?
  • How do we align people, processes and technology?
  • What other things have we forgotten?

I recommend reading the books:

  • Making Strategy Work: Leading Effective Execution and Change’ by Lawrence Hrebiniak and
  • Enterprise Architecture As Strategy: Creating a Foundation for Business Execution’ by Jeanne Ross and Peter Weill.

I am currently involved with the EAST group (an outreach group of SCiO http://www.scio.org.uk/ ) which is looking at the overlap between Enterprise Architecture and System Thinking, and in particular the Viable System Model (VSM).

The Viable System Model has been around for many years, coming out of Stafford Beer’s work  http://en.wikipedia.org/wiki/Anthony_Stafford_Beer

This diagram looks complex at first but you can also read a very accessible description of the Viable System Model at http://www.scio.org.uk/resource/vsmg_3/screen.php?page=0cybeyes and at http://en.wikipedia.org/wiki/Viable_system_model

An excellent book to read is Patrick Hoverstadt’s book  ‘Fractal Organization: Creating Sustainable Organizations with the Viable System Model’  See http://amzn.to/mjHz6F

But what is the Viable System Model?

The Viable System Model is a recursive view of five main systems within an organisation.

The word ‘System’ here doesn’t mean an IT system or an information system but has the more generic meaning of the word ‘System’. See http://en.wikipedia.org/wiki/System

Those five systems are concerned with the following functions and capabilities:

System 5 Policy, ultimate authority, identity.
System 4 Adaptation, forward planning, strategy.
System 3 Internal regulation, optimisation, synergy.
System 2 Conflict resolution, stability.
System 1 Primary activities.

System 1 systems within an organisation are realised by those organisation units that actually make products, deliver business services and create value.

System 2 systems are those organisation units that provide the coordination functions.

System 3 systems are those that provide the audit and operational control functions.

System 4 systems are those that look forward to the future and the external environment.

System 5 systems provide the strategy and business direction.

The Viable System Model is recursive so that the same five systems appear at all levels within an organisation, but it’s easy to see equivalent VSM systems at various levels in an organisation.

At at the top level it is possible to see that the Executive Board is a level 5 system, the general management are mainly level 3 systems, the system 2’s are the programme managers, project managers and solution architects. The system 1’s are the operational service delivery units and project teams.

Where does that leave Enterprise Architects? Well the Enterprise Architect function is essential a system 4 system with it’s focus on strategic planning for the long terms view and creation of roadmaps of strategic initiatives.

The strategic Enterprise Architects (system 4) with their long term, external and strategic focus work in co-operation with the Solution Architects (system 3) with their immediate operational, internal, lean, design and delivery focus.

It’s clear to see with our Viable System Model lens that solution architects and enterprise architects are not doing the same job but a completely different job.

From an Architecture Continuum perspective (TOGAF9  http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap39.html) then the Viable System Model is an example of a generic Foundation Architecture. and a thus a key architecture to reuse when designing organisation specific target enterprise architectures.

The SCiO group has developed the SCiO Organisational Maturity Model http://www.scio.org.uk/OMM which is based on the Viable System Model.

This can be used for assessing the strengths and weaknesses in your enterprise, looking at how efficiently it is working today, both in the immediate operational perspective but aslo the log term viability of your enterprise in the face of changing external market and business environment.

The on-line questionnaire for the SCiO Organisational Maturity Model addresses six aspects of the Viable System Model:

  • Operations
  • Co-ordination
  • Resource and Performance Delivery
  • Monitoring
  • Development
  • Managing strategy

The outcomes are expressed in terms of  a measure of maturity across those six dimensions and a diagnosis of which Archetypes (i.e VSM anti-patterns) apply to your enterprise and which need to be addressed.

Unlike Lean manufacturing which only focuses on operational efficiencies in the the lowest level System 1, System 2 and System 3 systems within an organisation, the Viable System Model looks at the whole enterprise from a recursive perspective which is more sound and holistic.

In some ways it is surprising that it hasn’t yet reached a tipping point within organisations or their enterprise architects. Maybe this is because everyone is too focused on the day to day need for operational efficiency and approaches such as Lean Manufacturing (http://en.wikipedia.org/wiki/Lean_manufacturing) and forgets about planning for the future. This is the difference between being reactive and proactive.

Further reading at http://coherencyarchitect.com/2011/01/29/the-fractal-organization-in-an-enterprise-architecture-point-of-view/

and the excellent book: The Service-oriented Enterprise by Tom Graves,  http://amzn.to/kAzR7F

The Service-Oriented Enterprise: Enterprise Architecture and Viable Services

The next time you are challenged on the purpose and value of Enterprise Architecture, then answer that it’s the difference between the external and future oriented perspective of the VSM system 4 as opposed to the inside and now, operational efficiency perspective of system 3 and service delivery perspectives of  system 1 and 2.

As a system 4 system, the enterprise architecture function focuses on:

  • Supporting the business strategy developed by system 5
  • Analysing strategic change initiatives
  • Planning and creating strategic road-maps
  • Scenario analysis
  • Assessment of future risk, agility and viability of the enterprise
  • Coordinating with system 3 systems (i.e. portfolio and programme management, project management and solutions architecture)
  • Governing the realisation of those strategic changes and development of new business capabilities.

The more one looks at the Viable System Model, the more it looks like the unifying theory behind Enterprise Architecture.

We are used to the idea of a Programme/Project Management Office (PMO) but often organisations fail to understand (or perhaps deliberately misunderstand) what the Enterprise Architecture function does. I propose that the Enterprise Architecture function is, in effect, an Office of the CEO, or an Office of the CEO and Strategic Change Management.

The book ‘Enterprise Architect as Strategy’ (http://www.architectureasstrategy.com/book/eas/ ) gives us the right way of thinking and talking about what enterprise architecture is for – creating a foundation for the execution of the Business Strategy.

This book is an essential read for senior executives, business leaders and enterprise architects.

Many people within an organisation will understand the big picture view of the business strategy, such as the CEO of course, but perhaps only at a shallow level of detail.

Would the C-level executives understand all the potential nuances and wrinkles that come with that business strategy? Perhaps not unless they were a ‘details’ person.

What does the CEO do? They will spend time in evaluating ideas, formulating the mission and vision of their orgnaisation, innovating the business model to ensure the company remains competive in their market, looks for future opportunities for expansion and carving out a niche market.

It is the Enterprise Architect who has the job of maintaining the big picture on the behalf of the CEO, in sufficient detail to ensure that it becomes a knowledge base to support the executive’s decision making and help them to realise the business strategy and govern the implementation of that strategy.

In this way the Enterprise Architecture function is effectively the Office of the CEO,  providing strategic support to the CEO and the other C-level executives. It’s also worth stating here that effective companies focus on enterprise architecture and don’t jump straight into IT architecture. Enterprise Architecture is not the same discipline as IT Architecture.

We can look at the the Enterprise Architecture function in terms of Deming’s Plan-Act-Do-Check process improvement process:

PLAN

The CEO and other C-level executives will stablish the mission, vision, goals, objectives, principles and metrics to identify the main outcomes of the business strategy.

The Enterprise Architect will help executives, business leaders and strategic planners to develop the business model, operating model, and other enterprise architecture models supporting business model innovation

DO

The CEO and other C-level executives will evolve and innovate the Business Model.

The Enterprise Architect will take the business strategy and business model and support the development of the target operating model,  communicate the business strategy, model the target and interim enterprise architecture models, plan an EA roadmap of strategic initiatives, identify and define the required capabilities, define the mandates for the investment programmes and key projects, define standards and process improvements. They will usually define the IT strategy to ensure that it fits with the business strategy rather than being developed in isolation (as unfortunately often happens).

CHECK

The Enterprise Architect will perform EA governance, compliance and design assurance against those programes & projects implementing the strategic changes and new capabilities. They will perform gap analysis and impact analysis, measuring the performance and compare the results against the expected outcomes.

ACT

All the while the Enterprise Architect will report to the CEO and act as their trusted advisor. They will analyze the gaps, risks, costs, issues, assumptions and dynamics to determine their cause and determine where to apply further strategic changes in the next iteration of the cycle and improve the overall maturity level of the enterprise.

The mission of Enterprise Architecture is to improve the implementation and excecution of the business strategy, ensuring that the enterprise will survive, continue to develop and remain profitable in the future.

An interesting example to look at is the US Department of Health and Human Services which has established an Office of Enterprise Architecture as part of the Office of the CIO.  http://www.hhs.gov/ocio/ea/index.html

Activities of the Office of Enterprise Architecture

As the the book ‘Enterprise Architect as Strategy’ says – ‘When it comes to executing your Business Strategy your Enterprise Architecture may matter more than your strategy itself… ’

%d bloggers like this: