Stakeholder Buy-in & Motivation Models Pt 5: A second worked example


The previous example post described one classic motivator to engage in an enterprise architecture initiative – the need to be more agile and more aligned with the business. In the second of our two examples, I explore another classic case: the need to streamline a chaos of systems that has just happened.

Summary: we explore how to use a motivation model to drive conversations with different stakeholders, for a second sample organization. This organization is a large insurer that has grown exponentially in the past few years via a series of acquisitions. Now they face the challenge of rationalizing a hotch-potch of systems and processes.

The second example is a familiar scenario; the need to rationalize a set of systems and the data that they access. Looking at COBIT 5’s list of 17 business drivers, we can immediately identify three that are impacted by this situation;

  • Optimization of service delivery costs
  • Customer-oriented service culture
  • Information-based strategic decision making

How are these three affected?

Well, the fact that each of these acquisitions now means that the insurer has effectively inherited a patchwork. They have different platforms, they need different skillsets, and so on. The insurer has the support costs of all its acquisitions put together; there is minimal economy of scale without changes being made. We can express this in the assessment ‘IT spending too much money on support’, further explained by the assessment ‘IT is supporting too many disparate systems’. This leads to a goal for the organization to aspire to – ‘IT needs to not have duplicated systems’. This leads to the need ‘Need to document and rationalize applications’.

The business driver ‘Customer- oriented service culture’ is affected in one glaring way; with no integration between systems, when a customer wants to move from one region to a different one served by a different subsidiary, transferring their data is a manual and painful process – which leads to a frustrating experience for the customer.

This fragmentation of systems also has a chilling effect on the other driver, ‘Information-based strategic decision making’; because it becomes a painful exercise to amalgamate data across the subsidiaries – expressed succinctly in the assessment ‘Limited overall picture of customers and market’.

Both these problems can be summarized more pithily however, in the assessment ‘Systems do not share data’ – which naturally implies the goal that ‘IT needs to remove data silos between systems’. There are two things that the insurer has identified as things that need to be done – our requirements –

  • Need to establish org-wide common data model
  • Need to reliable data sharing between systems

So we’ll conclude by looking at how we can use this model to derive a summary. Say we are talking to the COO.

“We’re having real problems providing the reports that the business needs because all the IT systems that we inherited aren’t sharing data – so IT needs to knock down these silos. There are two things we can do to accomplish this. First, we establish a common data model across the organization. At the same time, we need to implement a master data management initiative to rationalise data across these disparate systems.”

Catch up on previous instalments of Peter's series below:

1. Persuasion in Enterprise Architecture 

2. An Overview of the SPIN Methodology

3. The Link to Motivation Models

4. A First Worked Example