FINDING THE RIGHT FELLOW TRAVELLERS

OK, so we have agreed that the quest metaphor is more apt. We need to create alliances with the enterprise communities where the knowledge lies and with those who will ultimately sign off our activities. To do this we need to identify our Data Stakeholders.

Data Stakeholder A Data Stakeholder is any person within or outside the organization who has a legitimate interest in the data migration outcomes.

This definition is important. Taking the definition in reverse:

• Projects are about outcomes (or ‘deliverables‘) more than processes. The physical coding process may belong to the techies but if, for example, an audit trail (see page 51) must be shown to satisfy a regulator then this must become one of the outputs and must be reflected in the project processes.

• A legitimate interest is harder to define and will vary from project to project. There are some mandatory Data Stakeholders that must be identified for each data source, but otherwise it is usually better to be inclusive rather than exclusive.

Hint We have all worked on projects where some well-thought-of employee takes an informal interest in all projects, dipping in and out almost at whim. These people can be quite disruptive. Get them to define their legitimate interest — possibly an architectural one. Usually it is better to have them inside rather than outside, but if you want to be rid of them, remember Golden Rule 1. Once you have got buy-in from your key Data Stakeholders, get the other stakeholders to assign them a role or reject them.

• Data Stakeholders, as we will see from some of the examples below, can be drawn from outside of the organization — external auditors are an obvious example.

• A Data Stakeholder, for our purposes, is a person not a group. They may represent a larger group but we need individuals we can contact, with phone numbers and email addresses, empowered to make judgements and decisions.

We will be expecting a lot from our trusted band of Data Stakeholders and we must bind them early into the success of the project. They must know their role and accept the responsibilities that come with it. Finding all your Data Stakeholders and getting buy-in is one of your first and most difficult tasks. Below are some of the common Data Stakeholders, starting with the two that are mandatory for every data source you find.

Data Store Owner

A Data Store Owner is the individual within the enterprise that has formal responsibility for the quality of the data in a system and for its use.

Hint An easy way of identifying a Data Store Owner is that they are the employees who have the power to sign off your decommissioning statement — they can sanction switching a system off.

However, finding Data Store Owners can be difficult. It may seem simple but in modern enterprises with their constantly changing structures and their wall-to-wall ERP systems, finding owners can be hard. Some systems seem to be used by everyone and owned by no one.

Anecdote I was working on a project in a heavily regulated national company and the project required that I make changes to one of their key infrastructural systems. Although each module could be identified with an enterprise function, and therefore ultimately with a director, the system as a whole seemed to be owned by no one. In the end I settled for the senior business manager of the function in which I was working as my Data Store Owner. One can persist up the chain of command until you reach the CEO but you may have to settle for a committee of senior managers. Remember the key question is: ‘Who can authorize that this system be switched off?‘

A Data Store Owner will also be needed for the new system once it is commissioned. Often it is one of the Data Store Owners from the more significant of the Legacy Data Stores (see page 46), but sometimes the new system implementation will be going hand in hand with enterprise structural change. Find the Data Store Owner and get them signed up to their role. They will need to be party to the Data Transitional Rules and possibly to the System Retirement Policies outlined in Chapter 4.

Business Domain Expert

Frequently the Data Store Owner is not the person in day-to-day contact with the data source. The Data Store Owner may be a senior manager who has moved into their position from elsewhere and never had hands-on contact with the system.

You may find, however, that the Data Store Owner, some time and a couple of promotions ago, worked with the Legacy Data Store. This can be more difficult. They may believe that they know what is going on but beware. System use evolves with time and with personnel. You need to know how the data source is used right now, what its idiosyncrasies are and what work-arounds are in place today, not how it used to work in the past.

Hint Just as they can be a challenge, Data Store Owners with a long association with the data source can also be an asset. They will have knowledge of the history of faults, fixes and enhancements that so often compromise data migration. Having a long association with the data source also, normally, leads to a natural commitment to its data quality. Tell these people about Golden Rules 1 and 2, with due humility, and you will be pushing at an open door. Treat them with insensitivity and you will alienate them all too easily.

You need a Business Domain Expert that is up to speed with the way the data source is used now. This does not mean that the Business Domain Expert and the Data Store Owner cannot be the same person — they often are on small local data sources — just be aware of the degree of up-to-date knowledge you are expecting of your expert.

Also be aware of the degree of commitment you are expecting of your Business Domain Expert. This is supposed to be a co-worker on the virtual team you are building. They must be available at the end of a phone for a quick call. They must be free to attend workshops at reasonable notice. A senior enterprise manager whose diary is booked for months in advance and who has a PA to answer email is unlikely to suit.

Anecdote Finding the stakeholders is not always simple. I was called in to consult on the struggling data migration aspects of an outsourcing programme for a large multinational financial institution. Unfortunately the project was running very late by the time I arrived on site and most of the Business Domain Experts had already been outsourced. Without them we had no way of judging if the proposed solution was fit for purpose. It took considerable effort to track down suitable Business Domain Experts. This is an illustration of the problems caused by failing to explicitly link the requirements of the data migration project with the wider programme.

Your Business Domain Expert may also not work directly for the Data Store Owner. You need the best person for the job that the enterprise can spare. This is another reason for taking a top-down approach. Get Data Store Owner buy-in at the outset and resourcing issues become that bit easier to resolve.

Finally, the Business Domain Expert should be just that — an expert. Do not be fobbed off with some junior that is the easiest person to spare. The Business Domain Expert will be your champion in their enterprise area. Their peers should respect them and accept that they can adequately represent the business domain—s interests.

Hint So I’ve just set you an impossible task ’ find perfect Business Domain Experts. In my experience these people are usually well known in their environment but are also often over tasked, dealing with every new initiative that comes their way. It is up to your negotiating skills and powers of persuasion to get the best you can. This is one of the reasons I recommend a top-down, enterprise-owned approach. Identify the Data Store Owner, make the situation real to them and then get them to select a Business Domain Expert after explaining the role. Never forget Golden Rule 1! If they do not prioritize your project over the others making a call on their staff then, after due warning, accept their view and get them to sign it off.

In large, complex, systems you will need more than one Business Domain Expert, each familiar with their own aspect of the data source and its use. One representative that everyone can trust, who has the internal network of contacts to get answers to questions and can select the correct invitees to meetings is better than a plethora of experts, but you may have to make a compromise between an army of experts and a lack of knowledge. Whoever is chosen, they need to be credible to the enterprise with recent, real, hands on, business domain experience.

Technical Data Experts

In anything other than a simple data source there are often aspects of the system that only the technically expert can know about. These may relate to file formats, access permissions, interfaces etc. It is usually easy to identify the Technical Data Experts. They may work for the IT department just like you do. They are often the system experts you are first pointed to when you get your initial job brief. These people are important, but not as important as the Business Domain Experts are and definitely not as important as the Data Store Owner. Do not allow yourself to be misled into thinking that the systems administrator is the same as a well-informed user of the system. They are not, but many a data migration founders on the confusion of the two roles. You will not need me to tell you that someone as closely associated with a data source and its uses as a systems administrator is a valuable source of information on who are the best candidates for Business Domain Expert. They will also be well informed on issues of data quality.

Finally, as I keep banging on, it is imperative that no matter how well informed the technical side is of the enterprise issues, a data migration project must be led by, and be seen to be led by, the enterprise. If the technical side take the lead then they will own any and all problems they find. Again, no matter how expedient it might seem to you (and to your programme manager) to use the skills of some business analyst who is the acknowledged expert in this business domain, hold out for a local Business Domain Expert.

Programme Experts

It is obvious that the programme, of which this data migration project is a part, has a legitimate interest in the data sources. It may be that you, the reader, are the Programme Expert as far as data migration is concerned. But just as the Business Domain Expert and the Business Data Store Owner are distinct roles that can be embodied by the same person, so the Programme Expert and the Data Migration Analyst are distinct roles. Do not confuse them. In any case, on a large data migration it is unlikely that one person will be an expert across the whole of the target system.

Second, confusing the legitimate interest of the programme with the interest of the enterprise causes more problems than any other single thing. As a data migration expert you are the mediator between what the programme needs and what the enterprise and other Data Stakeholders need. You must satisfy all your Data Stakeholders, not just the programme.

I cannot tell you how many data migration exercises I have been involved with that have started from the premise of programme not enterprise need — probably just about all of them! From the outset the focus is on staffing the project with people who know the target and not the data sources. We concentrate on getting the data that the target system needs over the data that the enterprise needs. Remember, data migration has (at least) two ends — a new system for sure but also a Legacy Data Store end as well.

I am not recommending here that you re-work the analysis that has gone into the target system. That has to be a given to the data migration project. It is the choice of source, of quality and of audit trails that is the decision area of the data migration project. This is a shared responsibility with the other Data Stakeholders (along with Data Transitional Rules, retirement policies and a heap of other things that we will cover later in the book).

Corporate Data Architect

Those organizations with a sophisticated approach to data management and administration will often have an information management function where corporate data models and data architectural models will be maintained.

Data Architect Terms like ‘Data Architect‘are bandied about a lot in IT and can mean subtly different things in different departments, from an extremely technical role related to the nuts and bolts of databases and servers to a more widely encompassing one. A good working definition is ‘The Data Architect is responsible for the design of how the data required for an organization, possibly held over multiple applications, is held‘ (from British Computer Society Careers Leaflet CWG13). Corporate Data Architects will have an overview of how the data is structured and where it is mastered in those common cases where the same data item is used in more than one place. They will also be responsible for producing, and often enforcing, institution wide definitions of key enterprise entities.

If the organization in which you are delivering a data migration project has such a function it is extremely unlikely that you will not be made aware of it at the inception of the project. Given that these people’s day job is reviewing data standards and maintaining data models, they make an extremely useful first port of call when you get onto the process of defining the Key Business Data Areas (see Chapter 4) and producing the legacy data models. They will be well informed of the data quality issues in existing legacy data, so make a good starting point for your first-cut Data Quality Rules straw men (see Chapter 5). They are the official corporate lead in best practice data design methods, so it makes sense to use their modelling standards, tools and methods. As you will see when we look at the example specimen project later (see Chapter 9) there is a section where choices of deliverables can be made. Use the advice of the local experts to choose the tools that are mandated or just work best in the environment in which you find yourself.

On a personal level, Data Architects are usually well informed as to who the best candidates for Business Domain Expert and the other key Data Stakeholders are.

However, once again there is a health warning. Corporate Data Architects do not have day-to-day, hands-on, use of their systems. They are not a substitute for Business Domain Experts. They are usually organizationally and culturally part of the IT function within the organization. And remember Golden Rule 1!

Sometimes, but rarely, they have Data Store Owner responsibilities, but again the key question of who has the final say in decommissioning a Legacy Data Store will normally resolve this issue.

The main area where there is a potential for conflict between the data migration project and the data architecture team lies in the contradiction between enforcing corporate policy with regard to private data stores and getting the best data available for the new system. Here we need to be clear about our role as data migration expert facilitators of change, not owners of the solution. I personally always push for a full amnesty over legacy data stores where these run counter to corporate policy, for the initial period of the migration exercise. However, it is often the legitimate role of the Corporate Data Architecture team to resist this. Once again it comes down to the wider business assessing the arguments in favour of the fullest possible set of data stores against the impact on corporate discipline. The worst case is to duck the issue. It has to be faced, a decision made that all parties can agree to (and possibly an entry made in the risk register).

Anecdote Each enterprise differs in the degree of latitude it allows its staff for local initiatives. Sometimes even within the same organization there are differences. When I was working for an emergency services organization the discipline against private data stores was absolute amongst the uniformed section. Amongst the civilian workers, however, there was a greater degree of flexibility.

Once again, though, we must stick to the rules. If there is to be a Corporate Data Architecture stakeholder, they must be named, with roles, responsibilities, email addresses and telephone numbers. It may be that the way the information resource function is organized there will be separate people responsible for data modelling and physical data storage design etc. I prefer a single contact with overarching responsibility to my project, even if they pass the work around within their own department, but however it is accomplished you should have an agreed series of deliverables and methods of communicating.

Hint In the first phase of engagement with Data Stakeholders it may be that the initial deliverable will be the definition of the subsequent deliverables. However, it is essential that the full list of products is nailed down before project work commences in earnest.

Audit and Regulatory Experts

Most organizations these days are subject to external auditory and regulatory requirements. The process of data migration, both in the process itself (or more appropriately the audit trail evidence left after the process has finished) and in its delivered data, may be subject to legitimate audit and regulatory inspection. If this is so in your case then you will need a contact for each of these requirements. These contacts can be external to the company for whom you are working, but are more likely to be fellow employees who have the contact responsibility on behalf of the company. Either way, identify them if needed.

Once again it may be that the same person is your Business Domain Expert and your >Audit and Regulatory Expert. This is not a problem. As long as you can sort out when they are speaking on behalf of the user community and when they are speaking on behalf of the regulator. This is important; regulatory requirements usually take precedence over user ergonomics but it is not unknown for the two to be conveniently confused for the benefit of the user population!

Data Customers

Alongside the regulatory and audit there are often internal recipients of data — quite often information is gathered that is needed elsewhere, outside the business domain of origin. It is sometimes necessary for these Data Stakeholders to be identified. Be careful how wide you cast your net, however. Analysis of data in Legacy Data Stores can often identify additional data items that need to be passed on. The choice of appropriate Technical Data Experts should inform the project of those interfaces to secondary systems invisible to the Data Store Owner or Business Domain Expert. Bringing too many parties into the project risks making your work unwieldy, bringing too few risks oversights. I—m afraid it is a matter of judgement and experience, but, hey, that—s what you are being paid big bucks for, right? Only invite those who clearly have something to add.

Other stakeholders

It is not unusual that in the environment in which you find yourself you may need additional Data Stakeholders. This is fine provided you can define their role and agree it with the other stakeholders. Beware of having too many people involved, and closely define all stakeholder roles so that their influence is not allowed to extend beyond their proper competence.