Data Management and the Service Lifecycle
It is recommended that a lifecycle approach be adopted in understanding the use of data in business processes. General issues include:
- What data is currently held and how can it be classified?
- What data needs to be collected or created by the business processes?
- How will the data be stored and maintained?
- How will the data be accessed, by whom and in what ways?
- How will the data be disposed of, and under whose authority?
- How will the quality of the data be maintained (accuracy, consistency, currency, etc.)?
- How can the data be made more accessible/available?
Supporting the Service Lifecycle
During requirements and initial design, Data Management can assist design and development teams with service-specific data modelling and give advice on the use of various techniques to model data.
During detailed (‘physical’) design and development, the Data Management function can provide technical expertise on database management systems and on how to convert initial ‘logical’ models of data into physical, product specific, implementations.
Many new services have failed because poor data quality has not been addressed during the development of the service, or because a particular development created its own data and metadata, without consultation with other service owners, or with Data Management.
Data is an asset and has value. Clearly in some organizations this is more obvious than in others. Organizations that are providers of data to other organizations – Yell, Dun and Bradstreet, and Reuters – can value data as an ‘output’ in terms of the price that they are charging external organizations to receive it. It’s also possible to think of value in terms of what the internal data would be worth to another organization.
It’s more common to value data in terms of what it’s worth to the owner organization. There are a number of suggested ways of doing this:
- Valuing data by availability: one approach often used is to consider which business processes would not be possible if a particular piece of data were unavailable, and how much that non-availability of data would cost the business.
- Valuing lost data: another approach that’s often used is to think about the costs of obtaining some data if it were to be destroyed.
- Valuing data by considering the datalifecycle: this involves thinking about how data is created or obtained in the first place, how it is made available to people to use, and how data is retired, either through archiving or physical destruction. It may be that some data is provided from an external source and then held internally, or it may be that data has to be created by the organization’s internal systems. In these two cases, the lifecycle is different and the processes that take place for data capture will be entirely separate. In both cases the costs of redoing these stages can be evaluated. The more highly valued the data, the more the effort that needs to be expended on ensuring its integrity, availability and confidentiality.
Data can be initially classified as operational, tactical or strategic:
- Operational data: necessary for the ongoing functioning of an organization and can be regarded as the lowest, most specific, level.
- Tactical data: usually needed by second-line management – or higher – and typically concerned with summarized data and historical data, typically year-to-year data or quarterly data. Often the data that’s used here appears in management information systems that require summary data from a number of operational systems in order to deal with an accounting requirement, for example.
- Strategic data: often concerned with longer-term trends and with comparison with the outside world, so providing the necessary data for a strategic support system involves bringing together the operational and tactical data from many different areas with relevant external data. Much more data is required from external sources.
An alternative method is to use a security classification of data and documents. This is normally adopted as a corporate policy within an organization.
An orthogonal classification distinguishes between organization-wide data, functional-area data and service-specific data.