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

I’m reading a great new book called Intersection: How Enterprise Design Bridges the Gap Between Business, Technology, and People by Milan Guenther

The book discusses modern Enterprise Architecture perspectives like the Outside In approach and provides a holistic design lead approach that is focus more on the customer than on the underlying applications, technology and infrastructure.

The book also addresses the corporate branding of an enterprise. A successful brand is grounded in the strategic future vision of an enterprise. This strategic vision is also what drives the enterprise architecture initiatives, so it is clear that the enterprise architecture discipline must then provide the key support for understanding what contributes to the brand, what makes the brand successful and what must be done to sustain the brand.  This is a refreshing perspective that tends to get lost in most organisations.

The knowledge of messages, business events, interactions with stakeholders, outside in scenarios, business services and value streams that are defined and designed as part of the business architecture domain will all enable senior executive to understand and develop their brand. A brand is not just the value proposition, the set of products and services offered, but includes the development of the reputation of the enterprise, the customer experience it provides and the trust the customers develop. The book describes this in terms of the form, appearance, communication and behaviour of the enterprise and much more

Enterprise Architecture will have a profound impact on the brand and ultimately on the financial success of the business.

This book is a must read that should be on the bookshelf of every true Enterprise Architect.

See Enterprise Design Framework

Outside In

24 June 2013

How often do you see customer journeys, customer events and scenarios modelled in an Enterprise Architecture model? Not often, if at all I suspect.

In my opinion, the ‘Enterprise’ in Enterprise Architecture should include all those stakeholders that are engaged with an organisation. This include all those suppliers and service providers to the left hand end of the Value Chain, and the Customers at the right hand end. In this post I’ll be focusing on the Customers that are consuming the products and business services that are the outcomes of the Value Chain.

This is the view that the Customers have from the outside of an organisation looking in. This perspective should drive what a business does.

In most organisations however, the Enterprise Architecture is usually focused on the organisations internal workings, the inside out view of how an organisation can become more efficient, leaner and reduce cost, as a way of making more profits. The focus is on delivering better software faster, improved processes, commoditised infrastructure, reusable IT services, providing a self-service internet to replace face to face contact with the customer and so on.

The business strategy may look at the customer and market segments and the drivers for strategic change, but this is often as far as it goes. The rare organisation models the customers journey and the customers perspective and if they do then its rare to find the customer journey modelled in the Enterprise Architecture.

Organisations often try to reduce the direct interaction they have with their customers by removing phone numbers from their web sites, and providing limited set of services and FAQs. Customers are forced to waste many minutes on the telephone, selecting endless options in an attempt to get a human voice to speak to. Companies are afraid of this because of the costs of complaint handling.  To be fair, a number of organisations have implemented a live chat IM service on their web sites and high value customers do often get a live account manager to speak with. But what about the rest of us everyday customers?  It still seems like businesses are  lacking a good understanding of  their customers behaviour.

Digital Businesses and Digital Customers

Every business is now a digital business. It’s the same for customers (i.e. all the consumers, customers, potential customers and contacts) who are also increasingly digital using technologies like smartphones, social networks and broadband. They are using their own devices (such as iPads and other tablets) to research potential products and business services that they wish to purchase from businesses. They browse social networks and conduct searches to determine what product or business service best suits them. They have mass access to huge networks of information such as Google to help them.

Customer behaviours are changing, but does your enterprise architecture model know that? Does it model what the customers’ own processes are? Does it model the events that originate from a customer? Does it model what the various scenarios that there are in the customer journey? In my experience the answer is typically ‘No’ to all these questions. In my experience even when an organisation is modelling the customer journey then it is never included in the future state enterprise architecture.

What is the customers’ processes? Customers will conduct a search and discovery process, engage with the business to select, negotiate and make a purchase. If the business is lucky then the customer will re-engage to make future purchases, but if they screw up the customer will get annoyed and tell all their contacts on social media about why they are no longer buying. Companies are seeing the increasing power of customers but how many are trying to understand them and model their behaviours?

Enterprise Architecture, or more specifically, the Business Architecture within the Enterprise Architecture discipline should cover the customers’ interactions with a business, understand what they are saying on social media.

An initial approach is to speak with customers and use a thinking framework such as VPECT to determine their Values, Policies, Events, Content, Trust Relationships.

See http://en.wikipedia.org/wiki/VPEC-T

They can also use the less engaged PEST analysis for strategic market research.

See http://en.wikipedia.org/wiki/PEST_analysis

Results of conducting VPECT analysis and PEST analysis should be recorded in the enterprise architecture models and associated to a representation of the customers journey

How should we model the Customer Journey and the different customer scenarios?

For a start, each scenario in a customer journey will be triggered by one of more of the Events discovered by VPECT analysis and be concluded by something of Value delivered back to the customer (Content).

What does the Event trigger? For me the best representation is a sequence of Business Services, in what might be called a Service Flow diagram.

This is much the same as a Process Flow diagram but from the external perspective. For a customer interacting over the internet, the Business Services might involve a Browse Service, A Product Detail Service, A Product Price Service, A Payment Service and a Fulfilment and Delivery Service. The Outside In service flow view is later mapped to the Inside Out process flow view

Customer Journey model

Customer Journey model

It’s easy to see that an organisation may not itself directly provide all these Business Services (for example the Payment Service may be provided by PayPal or similar, and the Fulfilment service may be provided by DHL or similar)

What also need to be modelled are the Customers own goals and objectives and how the scenario of service based interactions supports the customers goals.  Key measures should also include:

  • How much did the customers have to invest in the interaction (in time, and navigating complex interfaces, breaks in the interaction, confusion) to complete it?
  • How much they enjoyed the interaction (customer satisfaction feedback)?
  • How many customers abandoned the attempt early?
  • How many customers complained to their social media contacts afterwards?
  • How many customers complained directly to the business?

Multi-Channel

Another question that needs to be addressed is what channels and multiple channels do customers use? Customer these days are much more likely to use multiple channels at different times, rather than just a single one:

  • Search the internet with their iPad or smartphone at home
  • Switch to using their desktop PC at work
  • Use the telephone, email, IM message or SMS message for clarification on product details, prices and discounts
  • Hand off the desired purchase to their purchasing department to use corporate discounts to make the actual purchase
  • Expect an email or letter with their receipt, complemented by an SMS message to their mobile device and copy to the purchaser

Channel strategies don’t often allow for a customers’ use of multiple channels and for account information being passed around during an interaction with the customer. Businesses often manage different channels with different functions and organisation units. This results in confusing and frustrating transfers between departments. How often have you called a business, given your contact and customer account details, only to be handed off to another department who asks you all over again for that same information? It’s extremely annoying and it’s this kind of symptom that undermines the customers’ experience and sends them tweeting negative remarks.

One to One marketing

One-to-one marketing refers to marketing strategies that are designed as if they apply directly to an individual customer. Information is collected about customers’ needs, customer segments that they fall into, their preferred channel, their lifetime value to the business and which products and business services they are likely to purchase.

See the books by Don Pepper and Martha Rogers: The One to One Future and the One to One Field book.

http://www.amazon.co.uk/The-One-Future-Building-Relationships/dp/0385425287/ref=sr_1_1?ie=UTF8&qid=1372038361&sr=8-1&keywords=The+One+to+One+Future

http://www.amazon.co.uk/One-Field-Book-Don-Peppers/dp/1900961873/ref=la_B000AQ8U5Q_1_5?ie=UTF8&qid=1372038423&sr=1-5

What one-to-one marketing misses is more of an Outside In perspective, going much further in understanding the values that a customer needs and their own processes that customers follow (formally or informally).

The book I recommend is ‘Outside In: The Power of Putting Customers at the Center of Your Business’ by Harley Manning, Kerry Bodine et al.

http://www.amazon.co.uk/Outside-Putting-Customers-Center-Business/dp/1477800085/ref=sr_1_1?s=books&ie=UTF8&qid=1372038930&sr=1-1&keywords=outside+in

Total Unified Customer Communication

Typically organisations still tend to communicate with their customers in a disjointed and unconnected way. Invoices, statements, receipts, marketing literature, pricing deals, discounts, marketing campaigns, letters, emails, IM messages, data streams etc.. are all sent from many different departments who have no idea about the incoming or outgoing communications that have already been received or are being made by other departments. The result is customer confusion. To be fair, the situation is not so bleak for business customers, as it is for individual personal customers, but increasingly it’s difficult to tell the difference and negative social media discussion will also impact the business customers.

Instead of just silo based incoming communication with customers we need to get a total view of all the customers interactions both incoming and outgoing to the business, and within social media, centralising all interactions, via multi channels, with a Customer Communication Management (CCM) system. Curiously I’ve never seen a Customer Communication System in any future state Enterprise Architecture model and the recommendation to include one has fallen on deaf ears.  One to one marketing should become one to one multi-channel total customer communication.

Companies will want to differentiate their products and business services and to compete with other businesses and therefore they will need to innovate. Understanding their customers’ perspectives and their customer journey scenarios will be a key innovation for any business. This will require that the future target Enterprise Architecture model includes these views and connect them to the rest of the model.

%d bloggers like this: