evolving your semantics: feedback between data projects ... · evolving your semantics: feedback...

Evolving your semantics:Feedback between data projectsand the corporate standard

John Jordanis a senior data analyst in the Siemens Business Services’ Media Data Consultancy. He is a senior member of the team

providing a data management service to the BBC and has just lead the media asset management strand of a project

implementing an end-to-end production, playout and archiving system in the BBC World Service.

Keywords: digital asset management (DAM), data analysis, data management,

corporate semantic standard, system development

Abstract Paradoxically, in the current rapidly changing business environment it has

never been more important to maintain a standard view of the meaning of the

business data within an organization. Only with a common corporate understanding of

the semantics of the data can the organization hope to develop the interoperating

systems environment which will maximize the value of their assets and minimize the

effort required to use them. Maintaining the shared semantics within an agile

organization in a rapidly changing business environment is complex and this paper

describes a method for doing just that. It will also outline the value of the corporate

model, how it is used, derived and maintained, and the value and role of projects in

this activity.

THE IMPORTANCE OF DATAUnless an organization knows what itsassets are, where they are, what they cando with them and how much that willcost, it cannot do business effectively.The metadata underlying thisinformation are, increasingly, beingshared across the organization —databases are no longer merely theprovince of the team that createdthem.As the data gain wider currency it

becomes crucial that we have acommon, pan-organizationunderstanding of what that data actuallymean — the organization needs asemantic standard.

THE VALUE OF A SEMANTICSTANDARDThis paper describes a general approachto the development and evolution of acorporate data standard. The methodsand processes described are informed bythe activities of an outsourced data teamworking for the British BroadcastingCorporation (BBC) to provide a datamanagement service known as the DataIntegration Service (DIS). One of thecomponent parts of the DIS is themaintenance of the BBC’s corporatesemantic model.The DIS data team takes an approach

which uses the existing business systemdevelopment projects to enhance and

JOURNAL OF DIGITAL ASSET MANAGEMENT Vol. 1, 6 386–398 # Henry Stewart Publications 1743–6559 (2005)386

John JordanSenior Data AnalystSiemens BusinessServicesG201 Stadium House68 Wood LaneLondon W12 7TAUKTel: +44 (0) 7739920023Fax: +44 (0) 20 85763029Email:[email protected]

renew the corporate standard. Thisproject-based approach ensures that thecorporate standard evolves in the samedirection and at the same rate as thebusiness: ensuring systeminteroperability and supporting thechosen commercial strategy.As, in general, these activities require

that an organization has both the will toimpose a corporate standard and theresource to develop and maintain thestandard, it is best to state clearly whythe organization is doing this.This can be done quite simply — the

goal is to gain business benefit byenabling media asset management:

. simplifying asset exchange and reuse;

. enabling information sharing by

breaking down data silos;

. informing the provision of systems

which are fit for purpose — no matter

whether they’re developed in-house,

purchased packages, or leased services.

WHAT FORMAT DOES THESTANDARD TAKE?The core of the data team’s activity isthe development and maintenanceof the corporate semantic data model(CSDM). This model represents anddefines the meaning of things ofinterest to the business and of thebusiness rules which link them.Examples of these things in abroadcasting environment wouldinclude programs, playlist items,transmissions, contributors, rights, etc.This model can be presented in a

variety of ways but, for ease ofmaintenance, it should be managed in acomputer aided software engineering(CASE) tool. The tool, in general, willlimit the presentation of the model toone or other of two styles — entity

relationship diagrams (ERD) and classmodels in unified modeling language(UML). More advanced tools will allowthe generation of XML schemas fromselected areas of the model.It is worth stressing that, for the

purposes of the corporate semanticmodel, the style of presentation (ERDvs UML) is one of mere preference. Thepoint is the clear and unambiguousrepresentation of the meaning to thebusiness of the data and of therelationships between the data.Figure 1 provides an example of one

of the ERDs used to represent theBBC’s corporate semantic model1 — theBBC Standard Media ExchangeFramework, SMEFTM. The blocks(entities) represent the objects of interestto the business and the lines betweenthem, the business relationships. Eachentity has a number of named dataattributes which represent those of theobject’s properties which are of interestto the business.The colored entities contain reference

data and are candidates for the datateam’s reference data managementactivities. We will mention referencedata later but, here, it is sufficient to notethat the CSDM can be used to bringtogether several strands of theorganization’s data managementactivities.The simplest way of representing the

data structures and relationships isgraphically, but the definitions arecommunicated in a data dictionary. Thedata dictionary is associated with thefigures and contains a detailed definitionof every data element — entities,attributes and, increasingly, relationships.Figure 2 is an example of a datadictionary entry for one of the SMEFTM

entities on the ERD. Each entity is

Evolving your semantics

# Henry Stewart Publications 1743–6559 (2005) Vol. 1, 6 386–398 JOURNAL OF DIGITAL ASSET MANAGEMENT 387

CO

MM

ISS

ION

ING

(E

ntity

Rel

atio

n S

ubje

ct A

rea)

SA

/200

1Fr

i May

14,

200

4 1

7:01

Com

men

t

SM

EF

Ver

sion

1.1

0

Dia

gram

5 o

f 8

Cop

yrig

ht 2

004:

Brit

ish

Bro

adca

stin

g C

orpo

ratio

n. A

ll rig

hts

rese

rved

.

Con

fiden

tial a

nd p

ropr

ieta

ry in

form

atio

n of

the

Brit

ish

Bro

adca

stin

g C

orpo

ratio

n.A

utho

rs:

BB

C T

echn

olog

y, M

edia

Dat

a G

roup

Con

tact

e-m

ail:

sm

ef@

bbc.

co.u

k

ED

ITO

RIA

L_O

BJE

CT

_VE

RS

ION

Prim

ary

Key

EO

V_I

dent

ifier

[P

K1]

Non

-Key

Attr

ibut

es

EO

V_C

reat

ion_

Dat

eE

OV

_Dur

atio

n

EO

V_C

olou

r_In

dica

tor

EO

V_T

itle

EO

V_W

orki

ng_T

itle

EO

V_L

ast_

Wor

ds_S

eque

nce_

Des

c

EO

V_F

irst_

Wor

ds_S

eque

nce_

Des

cE

OV

_Sus

pend

ed_D

ate

EO

V_N

CS

_Slu

g_Ty

pe

EO

V_N

CS

_Slu

g_N

ame

EO

V_S

ub_T

itle

EO

V_E

nd_o

f_S

peec

h_D

urat

ion

EO

V_I

n-V

isio

n_S

ubtit

les_

Indi

cato

r

EO

V_O

rigin

al_B

road

cast

_Des

crip

tion

EO

V_H

ired_

She

et_M

usic

_Ind

icat

or

EO

V_P

rodu

ctio

n_E

nd_D

ate

EO

V_P

rodu

ctio

n_S

tart

_Dat

e

BR

IEF

Prim

ary

Key

BR

I_N

umbe

r [

PK

1]

Non

-Key

Attr

ibut

es

BR

I_F

inan

cial

_Yea

r

BR

I_E

dito

rial_

Info

rmat

ion_

Des

crip

tion

BR

I_P

rogr

amm

e_Q

uant

ity

BR

I_C

ateg

ory_

Des

crip

tion

BR

I_R

equi

red_

Dur

atio

n

BR

I_S

lot_

Day

_Nam

eB

RI_

Slo

t_D

ay_C

ode

BR

I_S

lot_

Sta

rt_T

ime

BR

I_S

lot_

Cod

e

BR

I_Ta

rget

_Am

ount

BR

I_T

itle

BR

I_E

arlie

st_P

ossi

ble_

Pub

licat

ion_

Dat

e

RO

LE

Prim

ary

Key

RO

L_Id

entif

ier

[P

K1]

Non

-Key

Attr

ibut

es

RO

L_B

illin

g_N

ame

RO

L_B

illin

g_P

riorit

y_C

ount

RO

L_S

tar_

Indi

cato

r

RO

L_S

tart

_Dat

e

RO

L_E

nd_C

redi

t_In

dica

tor

RO

L_E

nd_D

ate

RO

L_E

xtra

ct_F

ee_I

ndic

ator

RO

L_N

ot_U

sed_

Indi

cato

r

RO

L_O

ut_O

f_V

isio

n_In

dica

tor

OF

FE

R

Prim

ary

Key

OF

F_I

dent

ifier

[P

K1]

Non

-Key

Attr

ibut

es

OF

F_A

mou

ntO

FF

_Ave

rage

_Dur

atio

n

OF

F_D

eliv

ery_

Dat

eO

FF

_Slo

t_C

ode

OF

F_S

lot_

Day

_Cod

eO

FF

_Slo

t_D

ay_N

ame

OF

F_S

lot_

Sta

rt_T

ime

OF

F_T

itle

ED

ITO

RIA

L_O

BJE

CT

_GR

OU

P

Prim

ary

Key

EO

G_I

dent

ifier

[P

K1]

Non

-Key

Attr

ibut

es

EO

G_T

itle

EO

G_S

ub_T

itle

EO

G_S

erie

s_N

umbe

r

EO

G_I

SA

N_R

oot_

Iden

tifie

rE

OG

_Des

crip

tion

EO

G_B

AR

B_P

AS

_Num

ber

EO

G_P

rogr

amm

e_N

umbe

r

EO

G_E

piso

de_Q

uant

ityE

OG

_Wor

king

_Titl

e

PR

OG

RA

MM

E_C

LAS

SIF

ICAT

ION

_TY

PE

Prim

ary

Key

PC

L_C

ode

[P

K1]

Non

-Key

Attr

ibut

es

PC

L_T

itle

PC

L_E

ffect

ive_

From

_Dat

eP

CL_

Effe

ctiv

e_To

_Dat

e

PE

RS

ON

Non

-Key

Attr

ibut

es

PE

R_F

irst_

Nam

eP

ER

_Mid

dle_

Nam

e

PE

R_L

ast_

Nam

eP

ER

_Sal

utat

ion_

Sho

rt_F

orm

PE

R_S

uffix

_Nam

eP

ER

_Des

crip

tion

PE

R_P

rese

nter

_Rea

d_R

ate

CO

MM

ISS

ION

ED

_PR

OJE

CT

Prim

ary

Key

PR

J_Id

entif

ier

[P

K1]

Non

-Key

Attr

ibut

es

PR

J_T

itle

PR

J_D

escr

iptio

nP

RJ_

Exp

ecte

d_E

nd_D

ate

PR

J_E

xpec

ted_

Sta

rt_D

ate

PR

J_W

orki

ng_T

itle

OF

FE

R_T

YP

E

Prim

ary

Key

OT

Y_C

ode

[P

K1]

Non

-Key

Attr

ibut

es

OT

Y_D

escr

iptio

n

OT

Y_N

ame

OT

Y_E

ffect

ive_

From

_Dat

e

OT

Y_E

ffect

ive_

To_D

ate

OU

TLE

T

Prim

ary

Key

OU

T_C

ode

[P

K1]

Non

-Key

Attr

ibut

es

OU

T_N

ame

OU

T_D

escr

iptio

nO

UT

_Effe

ctiv

e_Fr

om_D

ate

OU

T_E

ffect

ive_

To_D

ate

CU

RR

EN

CY

_TY

PE

Prim

ary

Key

CU

R_C

urre

ncy_

Cod

e [

PK

1]

Non

-Key

Attr

ibut

es

CU

R_D

escr

iptio

nC

UR

_Effe

ctiv

e_Fr

om_D

ate

CU

R_E

ffect

ive_

To_D

ate

RO

LE_T

YP

E

Prim

ary

Key

RO

T_C

ode

[P

K1]

Non

-Key

Attr

ibut

es

RO

T_T

itle

RO

T_E

ffect

ive_

From

_Dat

eR

OT

_Effe

ctiv

e_To

_Dat

e

ED

ITO

RIA

L_O

BJE

CT

_CO

NC

EP

T

Prim

ary

Key

EO

C_I

dent

ifier

[P

K1]

Non

-Key

Attr

ibut

es

EO

C_T

itle

OR

GA

NIS

ATIO

N

Non

-Key

Attr

ibut

es

OR

G_N

ame

BR

IEF

_LIN

K_E

OC

_EX

AM

PLE

BR

IEF

_LIN

K_E

OV

_EX

AM

PLE

PAR

TY

Prim

ary

Key

PAR

_Ide

ntifi

er

[PK

1]

OF

FE

R_L

INK

_OU

TLE

T

BR

IEF

_LIN

K_O

UT

LET

PC

L_LI

NK

_BR

IEF

PC

L_LI

NK

_OF

FE

R

OF

FE

R_L

INK

_OB

JEC

T

linke

d to

Out

lets

via

the

link

for

poin

ting

to e

xam

ple

Edi

toria

l Obj

ect G

roup

s vi

a

for

b

part

icip

ant i

n

assu

med

dire

ctly

by

afu

lfilli

ng

of

orig

inat

or o

f

the

resu

lt of

split

into

owne

d by

spec

ifier

of fo

r

spec

ified

as

exam

ples

in B

riefs

via

for

for

of

fulfi

lled

by

for

poin

ting

to e

xam

ples

via

for

a

asso

ciat

ed w

ith

asso

ciat

ed w

ith

a

asso

ciat

ed w

ith

asso

ciat

ed w

ith

a

asso

ciat

ed w

ith

asso

ciat

ed w

ith

a

asso

ciat

ed w

ithas

soci

ated

to

a

linke

d vi

a

asso

ciat

ed w

ith

a

subj

ect o

f

asso

ciat

ed w

ith

for

desc

ribed

by

a

fulfi

lling

of

afulfi

lling

of

auth

ority

for

for

for

of

spec

ifier

of

for

linke

d to

Brie

f via

the

link

for

linke

d to

Out

lets

via

the

link

for

resu

lting

in

resu

lt of

desc

riptio

n fo

ras

soci

ated

with

spec

ified

as

for

spec

ifier

of

for

for

reci

pien

t of

iden

tifyi

ng s

erie

s fo

r

iden

tifie

d by

cite

d in

for

Figure

1:Example

ofanERD


Jordan

described in terms that include businessexamples where possible.One of the strengths of the semantic

approach is that it allows the datamanagement team to remaintechnology-agnostic and for theindividual projects to select theimplementation technology which fitstheir situation best.A final point when considering the

representation of the model is that itshould be appropriate to the situation.It is sometimes forgotten, but everymodel can be expressed at differentlevels of precision2 and taking a highlydetailed model, intended for a technical

audience, into a general business user-group meeting can becounterproductive.

HOW THE STANDARDPROVIDES VALUEThe thinking behind the standard isquite simple — effective sharing ofinformation requires that we have acommon understanding of what dataitems mean. If different businesscommunities understand data to meandifferent things then the data are, at best,useless and, at worst, dangerous.Using a well accepted definition of an

asset as: Asset = Content + Metadata3 it

Figure 2: Example of a data dictionary entry



becomes clear that unreliable metadatatransform an asset into a liability.For the purposes of this paper, the

terms data and metadata will be usedinterchangeably to mean the same thing.The metadata to be managed willinclude the data structures of businesssystems, descriptive data (both editorialand physical) about media assets andcorporate reference data sets. Referencedata may be defined as any kind of dataused to categorize other data found in adatabase or for relating data in adatabase to information beyond theboundaries of a particular system or theenterprise.4 Examples of corporatereference data will include thedescriptive taxonomies used within anorganization to classify their assets:examples of taxonomies would includecatalog indexing terms and contentgenres.The development of a shared,

semantics-based data architecture willallow effective inter-systemcommunication, the development of acorporate approach to the

implementation of external datastandards such as television Anytime andP-Meta, and the adoption of a pan-systems approach to integration.This paper will concentrate on the

management of the business systems’data architecture rather than on themaintenance of taxonomies.

THE STANDARD AS ASEMANTIC BUSAn increasingly common example of apan-systems integration architecture isthe use of middleware-enabled webservices within organizations. Thedevelopment of shared exchangemessages is a prerequisite for theimplementation of a services orientedarchitecture (SOA).Within such an environment, the

corporate standard acts as a semantic bus— a common communication layer usedand understood by the systems withinthe organization. Thus, developers cando away with individually developedpoint to point interfaces and replacethem with agreed exchanges through the

Point to point

System 1 System 2

System 4System 3

Point to point

System 1 System 2

System 4System 3

System 1 System 2

System 4System 3

System 1 System 2

System 4System 3

Via a standard

System 1 System 2 System 3 System 4

Corporate Semantic Model

MAPPING

Via a standard



MAPPING



MAPPING

Figure 3: Point-to-point or standards enabled interfaces


Jordan

medium of the common data standard(Figure 3). This allows independentdevelopment of specific individualsystems within the organization bysimplifying system integration.

WHO MANAGESTHE STANDARD?The team that manages the standardneed not be large. Small organizations,with a relatively specialized business,don’t need a team as large as thatrequired by a national or internationalradio and television broadcaster with alarge web presence. A data team can beas small as a single person.Management of the corporate

semantic standard will be one of severalfunctions that the group provides.Other, related functions could include:

. Setting up the business organization and

processes to enable the organization to

manage its reference data efficiently: for

example, avoiding divergence of

meaning within the corporate reference

data and maintaining its integrity —

supporting data sharing.

. Defining and managing data stewardship

policies: data stewardship can be defined

as being accountable for the definition of

the quality of a set of data such that it

supports all required uses by the

organization. Data stewardship means

also being responsible for the delivered

level of data quality. It is about the

quality of corporate data and not, for

example, how or where it is stored.

. Managing the corporate exchange

model: providing a model and

supporting specifications of the actual

messages and interfaces used to exchange

data within the organization.

As can be seen from the examples of thetasks performed by the data

management team, the aim of theiractivities is to increase data sharing, dataquality and data reliability across theorganization. The team will becomposed of data analysts and architectsand can be provided internally from thecompany or can be an outsourcedservice working under a service levelagreement.An organization of the size and

complexity of the BBC would requireabout eight full-time staff to maintainthe entire DIS activity. Of this team,some two and a half are sufficient tomaintain the corporate semanticstandard and carry out the projectmapping and compliance activities. Thesame level of activity could be carriedout in a smaller organization by aproportionately smaller team.

BUSINESS DIRECTION:GOVERNANCE, TECHNICALSTRATEGY AND ADATA CHARTERFor any corporate data standard to besuccessful, it is critical that theorganization impose a system ofgovernance upon the design and use ofits data. No matter whether the datamanagement team are in-house oroutsourced, in order for their activitiesto be effective they must work to asenior technical strategy group withinthe client organization. The reasons forthis are related to the two organizationrequirements we mentioned at thebeginning of this paper — the will toimpose a corporate standard and theresource to maintain it.By taking the role of customer for the

data management service, theorganization’s technical strategy groupindicates that the service is a corporatepolicy with high-level support. The data



management team’s role should be statedand defined by the publication of a datacharter. This data charter, adopted byresolution of the management board,should establish the rationale and contextfor the development and delivery of thepan-organization approach to dataintegration. It should set out how this isto be delivered, who is involved, whatthey will produce and how it will bemanaged.The second main reason for working

to a senior technical strategy group isthat the data management team iscertain to be resource-limited and willbe unable to work with all the systemsunder development within theorganization. Because of this, it is crucialthat the business’ technical strategygroup should identify the high prioritydevelopments for the attentions of thedata management team.One method, commonly used to

impose governance upon anorganization’s data, is for all systemdevelopment projects over a specifiedsize to be referred to the technicalstrategy group for review and appraisal.When selecting projects for complianceto the corporate model, the groupwould have a clearly defined remit:

. to minimize technical investment costs

across the organization;

. to ensure the investment provides best

value for money;

. to ensure the investment is in line with

the organization’s published technical

strategy;

. to mandate that any development project

will comply with organizational

technical standards and policies.

In essence, the technical strategy groupensures that projects of strategic value to

the organization are delivered in aconsistent and cost effective manner.It must be stressed that this is not just

an academic technical exercise — itcannot be forgotten that the technicalstrategy group is, essentially,representing the business and the goal isthe procurement of technology to fitwith business strategy and to gainbusiness benefit.By giving the technical strategy group

the authority to mandate compliance tothe corporate data standard as aprerequisite for funding, we can ensurethat the corporate data standard will bepresent in all the major strategicdevelopments. It should also beremarked that compliance to thecorporate standard in selected strategicsystems has a noticeable cascade effect,moving compliance, informally, intoprojects not specifically selected forcompliance.

WHAT IS THE ROLEOF PROJECTS?At their best, projects represent themovement of the business in thedirection the business strategy haschosen. By working with projects, thedata management team has the ability toinfluence the development of the systemenvironment for the future. Settingmodeling directions to achievecompliance during the project analysisphase — avoiding re-work and retro-fitting — minimizes overhead to thebusiness.The project team should not slavishly

adopt the corporate model — they mustcarry out additional analysis. Thisadditional analysis will test the corporatemodel against reality — giving usincreased confidence in the corporatestandard.


Jordan

The project analysis is the primesource of accurate business definitionsfor the data structures and relationshipsas they are used within the scope of theproject.A point which shouldn’t be

underestimated is the political value ofworking with the business during theproject and using the business to enhanceand develop the corporate standard. Ifthis is handled well it can foster a senseof ‘‘ownership’’ within the business asthey see their understanding reflectedback into the standard.

HOW DOES THE DATA TEAMWORK WITH PROJECTS?It is hugely important that thecompliance process should have aminimal negative impact upon theproject. To this end, although theproject will fund its own projectanalysis, the compliance exercise can befunded centrally. A useful way tosimplify the compliance reviews is forthe project to employ one of the datateam as a project data analyst and for thesame data team member to carry out the

compliance mappings and reviews.After a project has been selected for

compliance a member of the data teamwill meet with the project manager toagree a modeling approach and thereview timetable. The selection of thecompliance sign-off points will betailored to the development methodused. Figure 4 illustrates a fairly standardproject lifecycle comprising four phases:inception, elaboration, construction andtransition. The middle row containsexamples of the sort of projectdocumentation we would expect to seegenerated at each stage. The bottomrow gives examples of the points atwhich it would be natural for the datateam to schedule compliance reviews.The scheduling of compliance reviews

at each of the points illustrated inFigure 4 would be severe overkill for allbut the largest and most complexprojects and would probably beconstrued as harassment. As a minimum,however, we would expect the project’sstatement of data requirements to becompliant with the corporate standardand then to have a further review stage

Data Management review

Metadata Management

review

PIR

Scope review Data Model reviewData Architecture reviewSystem Interfaces review

Design review

Data Management review

Metadata Management

review

PIR

Scope review Data Model reviewData Architecture reviewSystem Interfaces review

Design review

CONSTRUCTION TRANSITIONINCEPTION ELABORATION CONSTRUCTION TRANSITIONINCEPTION ELABORATION

Database DesignProgramme

DocumentationTesting products

Deployment Products

Live systemEnhancement requirements

Scope documentsProject strategy

Business CaseProcess Diagrams

Use CasesProject Data Model

Interface Statements

Database DesignProgram

DocumentationTesting products

Deployment Products

Live systemEnhancement requirements

Scope documentsProject strategy

Business CaseProcess Diagrams

Use CasesProject Data Model

Interface Statements

Figure 4: Example project lifecycle



at the end of the construction phase toensure that the delivered system meetsthe stated requirements.It is also recommended that, when the

project has been delivered, and thesystem moves into the maintenance andenhancement phase (not illustrated),further routine compliance meetings arescheduled in order to ensure that thesystem’s compliance to the corporatestandard is not threatened bymaintenance modifications. Thesecompliance meetings need not bescheduled in the sense of setting a datebut can be made part of the system’sconfiguration management approach.Although the example of the project

lifecycle in Figure 4 is for a softwaredevelopment project, it is possible toapply the principles to both packagepurchase schemes and leased services. Ineach of these cases the requirement neednot be for the internal system structureto comply with the standard but for thecompliance to apply to the suppliedsystem’s interfaces. The requirement forcompliant interfaces can be used as oneof the system selection criteria.It is extremely unlikely that any

system scope will encompass all of thedata areas represented on the corporatemodel. The next step after agreeing thereview points is, therefore, for the datateam to supply the project with therelevant subset of the corporate model.This provides the project with a rapidstart to their analysis phase and ensuresthat the project’s model starts with acompliant core. The value of this to theproject in terms of saving analysis timeshould not be underestimated.As the project carries out its own

analysis it will enhance and modify thesupplied data model to produce its owndata requirements’ definitions. These

requirements may be expressed in avariety of ways but one of the mostcommon is by the development of aproject logical data model (PLDM). ThePLDM expresses the proposed system’sdata requirements in a formal mannerand satisfying the PLDM can be one ofthe project’s deliverables. Anotheradvantage of the use of a standardmethod like the PLDM is that it makesit very easy to compare a project’s datadefinitions with the corporate standardand/or another project’s model.The rest of this paper will be based on

the used of a PLDM to express theproject’s data requirements, but as longas the project’s data requirements areexpressed clearly and unambiguously,the same principles apply to anyrepresentation.During the development of the

project’s data requirements the datastructures can diverge from thecorporate standard and this is where thevalue of having a data team member onthe project as an analyst or the data teambeing represented at design workshopscan be most obvious.

WHAT IS COMPLIANCE?There are two main types of criteria forthe assessment of compliance of aPLDM to the corporate standard:modeling quality criteria and semanticmapping criteria.The aim of the first group of criteria is

to ensure that the project’s datarequirements are expressed clearly andconsistently. These are presentationquality standards for the PLDM andthey include measures such as:

. Are the entities appropriate to the

business area?

. Are entities, attributes and relationships


Jordan

named clearly, unambiguously,

appropriately and in agreement with

corporate model naming conventions?

. Are business examples included?

. Are relationship names consistent with

the cardinality and optionality?

Other formal methods for stating thedata requirements will have functionallysimilar measures of quality.The second group — containing the

semantic criteria — is rather more fun.Here the measure is the degree to whichthe PLDM data structures and conceptsare semantically related to the structuresand concepts within the corporatemodel. To enable this judgment to bemade, one of the data team will producea document which attempts to map eachappropriate PLDM object (entity,attribute and relationship) to a similarobject on the corporate standard.The word ‘‘appropriate,’’ in the

previous sentence, is used to make aparticular point. Not all data elementsand structures on the PLDM need becompliant with the standard. If weremember that the point of the standardis to enable the reuse and exchange ofassets and of information about assets,we can see that any given system islikely to contain data which fall outsidethe standard’s remit: system specific dataand/or purely administrative data. Thecorporate standard need not concernitself with data of this sort and toattempt to map them would be a wasteof resources.The semantic criteria are quite

complex and form an intricatelyinterdependent rule set but some of thesimpler measures include:

. Can each PLDM entity/attribute/

relationship be mapped to an entity on

the standard? If not, should a new entity/

attribute/relationship be created on the

standard?

. Are the PLDM object descriptions

identical to the corporate standard? If

not, do they simply represent a more

constrained definition of a generic

corporate description with contradiction

of the standard?

. Are the cardinality, optionality and

exclusivity of the PLDM relationships

consistent with their representation on

the standard?

At the conclusion of the mapping therewill be two outcomes:

. A list of new project-related knowledge

of data structures and elements, not

currently present on the corporate

standard, will be available for

consideration for inclusion on the

standard.

. A decision as to whether the PLDM and,

by extension, the specified system can be

mapped successfully and unequivocally

to the corporate standard, enabling the

proposed system to use standard

interfaces with other systems in its

environment.

COMPLIANCE DECISIONIt is the responsibility of the data teamto report back to their client, thebusiness technical strategy group, thecompliance status of the selectedprojects. The decision as to whether ornot a system is compliant lies with thedata team but the actions following onfrom the report are the responsibility ofthe technical strategy group.The report back to the client can

include an analysis of the impact of anynon-compliant areas. This impact



analysis will allow the strategy group tomakes estimates of the cost-benefit ofany remedial work.

FEEDBACK FROM THEPROJECT TO THE STANDARDAs we have seen, one of the outcomes ofthe project compliance review will be alist of the new business knowledgeobtained from the project and notcurrently on the standard. Thisknowledge is then used to help developthe standard. Figure 5 illustrates thisproject-standard interaction.The feedback, from the projects into

the corporate standard, means that thestandard will change over time. Themodifications to the standard might beas minor as the enhancement of aparticular entity definition to include abusiness example specific to one area ofthe business. It might, on the otherhand, involve a major restructuring ofthe corporate standard to include

analysis from a completely new businessarea. To minimize the chance of such amajor revision it is critical that thebusiness is widely consulted on thecontent and meaning of the standard.The good news is that the more

mature the standard, the less likely thatmajor upheaval is to be expected.

CHANGE MANAGEMENT OFTHE STANDARDGiven that the standard is changing overtime it is important to have a changemanagement process in place. Theprocess need not be complex but itshould be formal and rigorous. Anoutline of the change control process forSMEFTM within the BBC is as follows:

1. As part of the project mapping andcompliance work, suggestedmodifications to SMEFTM are addedto a change log with supportingdocumentation.

SMEF v.X

Extracted subset

Extracted subset

Project Model

Additional project

analysis

Additional project

analysis

SMEF v.X+1

VersioningVersioning

New in-scope concepts

Project starting model

Mapping and change control

Figure 5: Project-standard interaction


Jordan

2. As part of a regular versionpublication cycle, existing change logentries are grouped into businessareas reflecting the data structuresinvolved and assigned to a memberof the data team for analysis,including impact analysis andrecommendation.

3. The analyst prepares theirrecommendations in consultationwith the business and theserecommendations are debated at aworkshop. Where possible, theworkshop should include bothmembers of the data managementteam and business representatives.The inclusion of the businessminimizes the chance of false analysisleading to a future majorrestructuring of the model and helpsthe model get business buy-in.

4. The decisions from the workshop arerecorded in the change log withadditional supportingdocumentation.

5. Successful recommendations are

incorporated into the next version ofSMEFTM which is then publishedwith a relevant change log extract.

6. The audit trails of the relevant datastructures in the SMEFTM modelwithin the CASE tool are modifiedto reflect the changes and to ensuretraceability. Confidence in themodel’s validity is increased byknowing the model’s derivation andthe reasons for any change.

VERSIONING AND MAPPINGTHE STANDARDIt is as vital to map between versions ofthe corporate standard as it is to mapbetween the standard and the PLDM.Only if we understand the directrelationships between the versions of thestandard can we make statements aboutthe indirect relationships betweenPLDM, which have been mapped todifferent versions of the standard(Figure 6).To facilitate this sort of analysis the

PLDM and the SMEFTM versions are

Repository

Project ModelA

Project ModelB

Project ModelC

…

Standard vX

Standard vX+1

Standard vX+2

Standard vX+3

Standard vX+4Direct mapping

Indirect mapping

Figure 6: Mappings across versions of the standard



held within a repository tool which alsocontains the mapping tables between thevarious PLDM and SMEFTM models. AsSMEFTM evolves, the tool allowsmappings to be maintained betweenpreviously mapped project models andthe current version of the standard. Thetool also enables impact analyses as thedata standard evolves and is versionedand/or modifications are proposed to thePLDM for an existing system during anenhancement program. These impactanalyses inform the cost-benefit decisionsmade by the business technical strategygroup.

CONCLUSIONSWe have seen that a corporate semanticstandard can simplify the reuse of assetsand information across an organization.The development of this standard iscomplex and requires both resolutionand resource — but it is achievable. Thestandard’s management process must bedesigned to take into account both thestrategic aims of the organization andthe business’ need for agility andflexibility. By doing this, we canensure that the corporate standardevolves in a controlled manner to takeaccount of business and organizationalchange. In the end, the simplification ofmedia asset management brings businessbenefit.Of course, the possession of a robust

corporate semantic standard isn’t

sufficient (on its own) to bring thisabout. The organization requires astrategic implementation strategy tomake use of this semantic standard.That, however, is another story

ACKNOWLEDGMENTSThe author would like to thank theBBC for allowing reference to, andillustration from, the SMEFTM model.Thanks are also due to colleagues withinboth the BBC and Siemens BusinessServices for help and support as thispaper was written and during the day-to-day activity of the Data IntegrationService. Finally, thanks are due to ‘‘thebusiness’’ for their input into thedevelopment of SMEFTM and the fun aswe’ve all worked to deliver it. SMEFTM

is a trademark of the BBC.

References1. BBC (2004) Standard Media Exchange

Framework — SMEFTM Data Model,v1.10.

2. Booch, G., Rumbaugh, J. and Jacobson,I. (1999) The Unified Modelling LanguageUser Guide. Addison Wesley, Reading,MA.

3. Marcus, I. (2005) ‘‘The DAM vendorlandscape: What the buyer shouldknow.’’ Journal of Digital AssetManagement, Vol. 1, No. 1, pp. 46–58.

4. Chisolm, M. (2001) Managing ReferenceData in Enterprise Databases, MorganKaufmann, San Francisco, CA.


Jordan

evolving your semantics: feedback between data projects ... · evolving your semantics: feedback...

Documents