Infosys Labs Briefings

VOL 10 NO 1
2012

Proactive Data Integrity

Management
By Priyanka Ahuja

Enterprises that have pro-actively embraced

DI leakage detection and prevention strategies
have always remained ahead of the curve

he term data integrity (DI) signifies the

to improve DI across the operating/business

correctness, coherence and accessibility

support system (OSS/BSS). However, what

of data. Lack of data integrity can have

needs to be understood first are the potential

adverse effects on data-intensive, sensitive

root causes that lead to a compromise on DI.

transaction oriented application(s) and

Some of them are discussed below [1, 2, 3].

customer authentication/ activations. This

can often result in crippling operations taking

Migration from Legacy to Strategic Systems

hours to detect, troubleshoot and indemnify

Until recently, enterprises used to deploy

the problem. Trend- tracking becomes an otiose

systems as per their convenience rather than in

effort if the underlying data has been periled.

a systematized way. This practice was followed

If data is unreliable, all stakeholders including

even when the same product/solution was being

customers, vendors, management and anyone

delivered across various locations. Due to lack

else who has a vested interest in the enterprise

of a standard framework or language, system

will question its credibility.

integration and business transformation became

Therefore, in order to maximize return on

a problematic task. This migration process

investment (ROI), it is important that enterprises

encompassed various systems across multiple

build DI prevention and detection strategies at

platforms to be moved to newer strategic

three levels - system, design and process.

systems. During this phase, data inconsistencies

were developed/ observed across these systems

INHIBITORS TO DI

that resulted in operational delays, revenue

As carriers try to derive the greatest value from

leakage and poor customer experience affecting

their networks and systems, they need a solution

the enterprises brand image.

29

Operational Issues and Outages

due to synchronization issue, this information

Untimely outages may lead to the order getting

may not reach the second system. This scenario

stuck on order provisioning or service system(s),

may occur in situations where same data is

thereby resulting in data inconsistency on various

maintained across two systems. For example,

retail systems. For example, customer asset

customer billing information may be stored on

information may be present on service and billing

both CRM as well as the billing system.

systems but may be missing on the CRM system.

Jeopardy Management Processes and
Architectural Issues or System Design Flaws

Procedures

Interface issues or flaws at the system design

Recovery mechanisms used for order correction

level often create situations that result in

may not exist or could be incomplete and

incorrect information flow across the stack. This

inaccurate thus resulting in DI fallouts.

has an adverse impact on customer experience.

For example, customer payment option is set to

PRESENCE OF DI SOFTWARE

Direct Debit on a CRM system but is categorized

DEVELOPMENT LIFE CYCLE (SDLC)

as Cash on Billing in the billing system. In such

To pursue DI prevention maturity model, it is

a situation, customers would get charged for

recommended that service providers engage

late payment or face loss of service.

DI in the early phases of SDLC, ideally at

the requirement gathering stage itself. DI

Distributed Data Model or Data Duplication

champions drive all DI prevention activities

Changes may get implemented on one system but

at each stage of the SDLC and ensure that

Study AS IS, Study TO BE

Evaluate the changes required
& the their impact on DI

Gathering

Feasibility
and Impact
Analysis

High Level
Solution
Design

Review test scenarios to

ensure negative test cases
are included which can have
DI impacts Review and sign
off test cases

Component
Design &
Development

Review & sign off designs

Review interface specifications
Validate the key parameters across systems

Testing

Source: Infosys Research

30

Launch

Post-Launch
Support

Product/ service goes live with the changes.

Support the launch. Follow up on any
failures

DI Prevention

Figure 1: DI Prevention Lifecycle

Provide prevention support to

all new change requests and
process fixes identified to
understand Di impacts (if any)

process, system and design fallouts are captured

Root Cause Analysis (RCA)

before the product is made available to the end

Budget allocations need to be made for this

customer. DI champions are in-sync throughout

activity along with team structure and strategy

the product lifecycle (PLC). Figure 1 highlights

so that root causes of all DI fallouts are

the presence of DI prevention team during

recognized and captured. Knowledge sharing

product delivery lifecycle.

and gaining activities should be initiated for

RCA resource(s) on board. This activity is

MATURITY MODEL FOR DI PREVENTION

performed in parallel to design, build and test

It is important that service providers identify

phase so that key DI issues are captured.

DI areas to address challenges like revenue

leakage, customer experience, right first time

DI Metrics

(RFT), etc. For addressing these challenges a

All high level metric requirements to measure

robust solution i.e., DI maturity model (DIMM)

DI fallouts should be ready before full volume

is developed that will run throughout the PLC

launch of the product.

from concept phase through launch [Fig. 2].

According to the DIMM, there are 6 dimensions

DI Rate

for any product launch in the DI prevention

Based on learning(s) and experience DI

space.

rate across various launch phases should

be base-lined. This would act as basis to

Manual Clearance

measure the percentage of DI fallouts over

DI prevention team needs to work out on

customer base.

logistics, resources and training requirements

for clearance activities that would need to be

Backlog

performed for known and unknown fallouts

Clearance team should be accountable for

that occur during product launch.

keeping backlog lower than x weeks growth.

Manual Clearance
Root Cause Analysis

Activity

Low
Volume

High
Volume
Low
Base

High
Volume
Medium
Base

High
Volume
Large
Base

Data Integrity Metrics

DI Rate

Clearance
Automation /
Reconciliation
Backlog: <x week growth

Figure 2: DI Maturity Model

Source: Infosys Research

31

Clearance Automation/Reconciliation

helps specify minimum DI requirements

One of the major tasks of team is to ensure

required for the launch of any product. This

all critical keys/services have automatic

is the key to comprehend DIMM. It helps

reconciliation (between 2 or more systems)

identify the potential system, process, design

in place so that DI fallouts can be prevented

as well as metric issues that can result in DI

in the first place. If this is not possible, then

fallouts. Proactive DI management also known

alternative methods of auto clearance should

as DI prevention is the new dimension where

be conceived which is based on zero touch, i.e.,

same product is analyzed through six different

with no manual intervention.

processes that act as building blocks of DI

While implementing this model, service

prevention.

providers should
END-TO-END DI PREVENTION STRATEGY
Define their strategies for each of the

This approach focuses on different set of

identified DI activities based on the

activities that need to be conducted to ensure

stage of prevention and customer

lower DI rate. It takes into consideration all

base achieved. This can be attained by

aspects of OSS product, process and system

designing matrix structure. For example,

requirements where product data managed

at high volume, large base clearance

is mostly order oriented and data needs to

activities should be performed by a small

be reconciled occasionally to bring systems

team with the help of mature clearance

in synchronization. Key activities conducted

tools.

under each of the identified processes are

detailed below.

Identify DI quality gates from support

to product launch (a) day 0 costing and

Design Assurance

planning of DI work-stream; (b) product

Early involvement of DI team during design

launch DI minimum criteria agreed;

phase helps identify DI issues/fallouts, thus

(c) sign off from operations and design

reducing cost of RCA, fixing and clearing

team.

resources at later stages. It minimizes the

risk of delayed launch due to DI issues that

SOLUTION APPROACH FOR DI

require code fix. It also enables sizing of DI

PREVENTION

impact beforehand and ensures that new

The manual processes that are traditionally

design(s) or change requests meet all DI

used to improve DI raise the total cost of

principles.

ownership (TCO) of the network and service

system clearance and are time consuming.

Process Assurance

Many service providers are now prioritizing

Process and procedures are reviewed and

DI in order to achieve a targeted low DI rate

signed off for all high risk and reject scenarios

over their customer base. In fact, the DI state

to ensure that there are no process fallouts that

of a carriers operations has a direct impact on

could potentially lead to DI issues. This is a

its ability to manage lower costs and enhance

dynamic activity which continues throughout

service profitability. DI prevention strategy

the PLC.

30

Launch and Trial Support

fixes. Metrics help drive clearance activities and

DI provides full support during pilot launch

monitor quality gates.

of Product to ensure that (a) all key DI issues

are addressed at the time of order placement/

DI Tool Development

provisioning, if any); (b) all complex scenarios

DI champions identify existing tools and

are tried and tested with zero percent DI issues;

service jobs that can be enhanced or developed

and (c) full analysis of all orders placed to

for reducing clearance resources required for

determine system/design/process fallout as

correcting data fallouts.

part of launch that lead to any DI issue is done.

CONCLUSION
DI Clearance

DI can inhibit efficiency of service providers

This is one of the most important activities to

by consuming time and resources to detect

be performed during product launch. Even

and fix fallouts. Data is susceptible to go out

with adequate DI prevention activities in place

of step both at rest or while in transit between

there are bound to be some DI fallouts due to

two or more systems. The causes for data

reasons like (a) known issues that cannot be

corruption might be different, but methods for

fixed immediately; (b) unknown issues that

overcoming these are similar. DIMM helps in

may occur when the project has gone live; (c)

early identification and remediation of both

system outages or failures; and (d) advisor

known and unknown DI issues thus benefiting

error/mistakes.

businesses. It looks at six dimensions as stated

Hence it is imperative that DI clearance

in the paper to ensure a proper remediation

teams are aware of the new product.

process. The key to comprehending DIMM is in

Therefore, training packages and DI clearance

religiously adhering to the processes to attain

procedures should be created. Also, DI resource

a low DI rate. Only then can one achieve zero

requirements are calculated based on volume

touch automation and ward off all the evils of

forecast, past learning and prior experience. DI

DI plaguing enterprises.

champions who drive the DI initiatives during

trial phase also generate DI issues to ensure

REFERENCES

that tools/processes and procedures work for

1. O S S / B S S r e f e r e n c e A r c h i t e c t u r e

these products. In case these tools/processes

and its Implementation Scenario for

or procedures are found to be inadequate, DI

Fulfillment (2005). Available at http://

champions raise new requirements for tool

www.nokia.com/NOKIA_COM_1/

enhancements.

About_Nokia/Press/White_Papers/
pdf_files/nokia_tietoenator_0605_net.
pdf.

Detection Metric Report Development

DI metrics is developed before the product

2. OSS/BSS Planning and Implementation.

launch to ensure that we have appropriate logic

Available

at

http://www.

and code developed to detect and report data

ltcinternational.com/brochures/

fallouts across systems. This also helps detect DI

LTC114_OSS_Services_v1.4.pdf.

issues during trials phase which is then taken as

3. Pressman R. (2010), Software engineering:

input to determine the root cause and suggest

a practitioners approach McGraw-Hill.

31

ISBN-13: 978-0073375977.

5. Preventive and Detective Data Integrity

4. T M F o r u m s B u s i n e s s P r o c e s s

Solutions- Case Study. Available at

Framework (eTOM), TM forum.

http://www.infosys.com/industries/

Available at http://www.tmforum.

communication-services/case-studies/

org/BusinessProcessFramework/1647/

Documents/data-integrity-solutions.

home.html.

pdf.

30

Authors Profile
PRIYANKA AHUJA is a Consultant for Data Integrity team in Communication, Media and Entertainment
Business Unit at Infosys. She can be contacted at priyanka_ahuja@infosys.com.

For information on obtaining additional copies, reprinting or translating articles, and all other correspondence,
please contact:
Email: InfosyslabsBriefings@infosys.com

Infosys Limited, 2012

Infosys acknowledges the proprietary rights of the trademarks and product names of the other
companies mentioned in this issue of Infosys Labs Briefings. The information provided in this
document is intended for the sole use of the recipient and for educational purposes only. Infosys
makes no express or implied warranties relating to the information contained in this document or to
any derived results obtained by the recipient from the use of the information in the document. Infosys
further does not guarantee the sequence, timeliness, accuracy or completeness of the information and
will not be liable in any way to the recipient for any delays, inaccuracies, errors in, or omissions of,
any of the information or in the transmission thereof, or for any damages arising there from. Opinions
and forecasts constitute our judgment at the time of release and are subject to change without notice.
This document does not contain information provided to us in confidence by our clients.