International Journal of Information Management

ContentslistsavailableatSciVerseScienceDirect

International

Journal

of

Information

Management

jo u rn a l h om epa g e :w w w . e l s e v i e r . c o m / l o c a t e / i j i n f o m g t

How

to

design

the

master

data

architecture:

Findings

from

a

case

study

at

Bosch

Boris

Otto

UniversityofSt.Gallen,9000St.Gallen,Switzerland

a

r

t

i

c

l

e

i

n

f

o

Articlehistory:

Available online 29 December 2011 Keywords:

Masterdatamanagement Masterdataarchitecture Casestudy

Architecturalpatterns Dataarchitecture

a

b

s

t

r

a

c

t

Masterdatamanagement(MDM)isatopicofincreasingprominencebothinthescientificandinthe practitioners’informationsystems(IS)community.Asaprerequisiteformeetingstrategicbusiness requirements,suchascompliancewithregulations,businessintegration,orintegratedcustomer man-agement,MDMcomprisesnumerousactivities.Oneofthecentralactivitiesisdesigningandmaintaining themasterdataarchitecture.Interestingly,though,thescientificcommunityhasremainedalmostsilent withregardtothequestionastohowcompaniesshouldproceedwhendesigningthemasterdata archi-tecture.Inordertoshedlightonthisunexploredtopic,thepaperathandpresentsthefindingsofacase studyatBoschGroup.Thecasestudyshowsthatdesigningthemasterdataarchitectureisa multidimen-sionaltaskwhichrequiresbalancingtheinterestsofvariousorganizationalstakeholders,managingan arrayoftechnicalopportunities,andmeetingrequirementsofnumerousmasterdataclasses.Also,the casestudysuggeststhattakingadvantageofarchitecturaldesignpatternsmaybeanappropriatewayto adequatelyaddressthecomplexityofthetask.

© 2011 Elsevier Ltd. All rights reserved.

1. Introduction 1.1. Motivation

Masterdatarepresentsacompany’skeybusinessobjects.These keybusinessobjectsformthefoundationofthecompany’s busi-nesspurposeandmustthereforebeusedunambiguouslyacrossthe entireorganization.Typicalmasterdataclassesaresupplier, cus-tomer,material,andproductdata,aswellasemployeeandasset data(Dreibelbisetal.,2008;Loshin,2008;Smith&McKeen,2008). Forquitesometimenow,themanagementofmasterdatahas beenreceivingincreasedattentionbothinthepractitioners’and thescientificIScommunity.Areasonforthatistherolemaster dataplaysinmeetinganumberofstrategicbusinessrequirements, suchasthe“360-degree-view”onthecustomer(Pula,Stone,&Foss, 2003),compliancewithagrowingnumberofregulations(Delbaere &Ferreira,2007),orgloballyintegratedandharmonizedbusiness processes(Loshin,2008).

In 2009,leading automotivesupplier ZF Friedrichshafen, for example,establishedanewservicebusinessunit,integratingits formerlyseparated aftermarket,spare parts,and service opera-tionsonacorporatelevel(ZF,2010).Thisstrategicreorganization presupposedhighlyintegratedandharmonizedmasterdataabout customers,ownproducts, andcustomers’products(modelsand makesofcarsZFsuppliespartsandcomponentsfor).

E-mailaddress:Boris.Otto@unisg.ch

SmithandMcKeen(2008,pp.65–66)definemasterdata man-agement (MDM) as“an application-independent process which describes,owns,andmanagescorebusinessdataentities.Itensures consistencyandaccuracyofthisdatabyprovidingasinglesetof guidelinesfortheirmanagementandtherebycreatesacommon viewonkeycompanydata,whichmayormaynotbeheldina commondatasource”.Thisdefinitioncomprises—asothers also do(Loshin,2008;Oberhofer&Dreibelbis,2008;White&Radcliffe, 2008)—threecentralconcepts:

•MDMisnotanapplicationsystem,butratheranorganizational functionwhichinvolvesownershipofmasterdata.

•PerformancemeasureforMDMisthedata’squality.

•Therearedifferentarchitecturalapproachesforstoringand dis-tributingmasterdata.

The firsttwo conceptsare currentlybeing discussed vividly in the IS community. Contributions regarding the organization of MDM have been made by Loshin(2008), Otto and Reichert (2010),Sarsfield(2009),andSwanton(2005).Studiesonmaster dataqualityhavetheirrootsinresearchondataquality manage-ment(Wang,1998),andaremainlyconductedintheformofcase studies(Knolmayer&Röthlin,2006;Kokemüller,2010;Otto,Ebner, &Hüner,2010).

Interestingly,though,thethird concept,namelymasterdata architecture,hasnotbeentakenuplargelysofar.Amongthefew scientificcontributionsonthissubjectaretwocasestudies(Hasan, Hyland,Dodds,&Veeraraghavan,2000;Legner&Schemm,2008), aninvestigationof ERP-centric approaches forMDM (Maedche, 0268-4012/$–seefrontmatter© 2011 Elsevier Ltd. All rights reserved.

2010),andananalysisbyAllemang(2010)focusingonlinkeddata usein companies.All three contributions tackle thetopic only superficially.Acomprehensivemorphological analysiswas con-ductedbyOttoandSchmidt(2010).Theiranalysis,however,does notallowforin-depthinsightastohowcompaniesshouldapproach themultipledecisionsrelatedtothedesignoftheirmasterdata architectures.

1.2. Researchproblemandcontribution

Thepaperathand hasbeen motivatedby thelackof scien-tificknowledgeregardingacontemporaryphenomenon.It aims atsheddinglightontheunexploredquestionastohow compa-niesshouldproceedwhendesigningtheirmasterdataarchitecture. Inparticular,thepaperwantstoillustratewhatdesigndecisions companiesneedtomakeandwhatoptionscompanieshave.

Casestudyresearchwaschosenasaresearchmethodbecause thephenomenontobestudiedcannotbeseparatedfromits con-text,and becauseonlylittleknowledge aboutthephenomenon existssofar(Benbasat,Goldstein,&Mead,1987;Yin,2002).The studyusesasingle-casedesign,investigatingthemasterdata archi-tecturedesign at BoschGroup (in the following referred to as Bosch),amultinationalandmultidivisionalengineeringcompany headquarteredinStuttgart,Germany.Single-casestudydesignsare frequentlyusedinIStostudyuniqueorextremecases.Examples aretheworkonITGovernancepresentedbyBrown(1997)and theinvestigationofindustry-wideISstandardizationbyMarkus, Steinfield,Wigand,andGabe(2006).

Thepaperisstructuredasfollows:Section2presentsareview oftheliteraturerelatedtomasterdataarchitecturedesign.Section

3outlinestheresearchdesign,beforeSection4presentsthecase studyatBosch.Section5analyzesthefindingsofthecase.Thepaper concludeswithasummaryofthemajorresultsandanoutlookon furtherresearch.

2. Literaturereview

2.1. Masterdataandmasterdatamanagement

Masterdataidentifiesanddescribescentralbusinessobjectsin acompany.Frequentlycitedexamplesarecustomermasterdata, suppliermasterdata,productmasterdata,and materialmaster data(Dreibelbisetal.,2008;Loshin,2008).Butmasterdatamay alsocompriseasharedchartofaccounts,employeedata,and orga-nizationaldata(e.g.costcenterinformation).

Manyattemptshavebeenmadetodefinemasterdataby dis-tinguishingitfromothertypesofdata,suchastransactionaldata, contractualdata,orinventorydata(Knolmayer&Röthlin,2006; Wieczorek,Stefanescu,&Schieferdecker,2008).However,this dis-tinction,duetoitsambiguity,doesnotseemtobehelpfulifone looksbeyondindividualcases.Contractualdata,forexample,might beconsideredmasterdataintheutilityindustry,becauseofits stabilityovertime,butmightbetreatedastransactionaldatain thetelecommunicationsindustry,duetocontractsbeingfrequently updatedorcancelledbyonline-servicecustomers.

Despitethelackof acommonunderstandingofmasterdata bothinthescientificandinthepractitioners’communitythispaper definesthetermforthefurthercourseoftheinvestigationas fol-lows:Masterdataisdataaboutthecharacteristicsofkeybusiness objectsin a companyand isunambiguously definedas wellas uniquelyidentifiedacrosstheorganization.

InrecentyearsMDMhasreceivedmuchattentioninthe practi-tioners’community.Toacertainextent,thisdevelopmenthasbeen fosteredbylargesoftwarevendors,whodevelopeddedicatedMDM systems.ExamplesareIBMInfoSphereMasterDataManagement

(IBM,2011),SAPNetWeaverMDM(SAP,2008),andTIBCO Collab-orativeInformationManager (TIBCO,2008).Thereis consensus, however,thatMDMdoesnotsimplyrefertoaclassof informa-tionsystems,butratherconstitutesan“application-independent” (Smith &McKeen, 2008)businessfunction. AccordingtoDAMA International(DAMA,2009),MDMwantstoachievethreegoals, namelyproviding an authoritative source of high-quality mas-terdata(“goldenrecord”),loweringcostandcomplexitythrough standards,andsupportingbusinessintelligenceandinformation integration.Activitiestoaccomplishthesegoalsinclude,among others,understandingmasterdataintegrationneeds,identifying masterdatasourcesandcontributors,definingandmaintainingthe masterdataarchitecture,andmanagingchangesinmasterdata.

Thenatureofmasterdataasreferringtobusinessobjectswhich areusedacrossthecompanyrequiresMDMtobeorganizedasa centralorcorporatefunction(Otto&Reichert,2010).Rolessuchas “datastewards”and“dataowners”havebeenintroducedtoensure “DataGovernance”withintheorganization(Khatri&Brown,2010; Loshin,2008;Weber,Otto,&Österle,2009).Whiledatastewards areconcernedwithensuringthequalityofacertainmasterdata class,dataownershavedecisionmakingrightswithregardto busi-nessrequirements,useanddefinitionofmasterdata(DAMA,2008; Loshin,2008).BittererandNewman(2007)useametaphorto dif-ferentiatebetweenthetworoles,comparingthedataownerto“a kingwhoownstheland,butdoesnotdoanythingwithit,apart fromridinghorsesontheland”,whereasthedatastewardis com-paredto“afarmerwhotakescareofthelandbygrowingcrops, wateringplants,ploughingfieldsandsoon.”

2.2. Masterdataarchitecture

Designandmaintenanceofthemasterdataarchitectureisoneof theactivitiesofMDM.Themasterdataarchitecturecontrolsshared access,replication,andflowofdatainordertoensuredataquality (DAMA,2009,p.181).

Thescientificbodyofknowledgeregardingthetopicofthe mas-terdataarchitectureisnotverycomprehensive.Earlycontributions canbefoundinthefieldofDataWarehousing,whichconsidersthe masterdataarchitecturetobeaprerequisiteforstandardizedand accuratereportingdimensions (Inmon, 1992).Inthemid-1990s researchersdiscussedintensivelytheconcept of“StrategicData Planning”, resulting,among otherthings,in a data architecture (Goodhue,Kirsch,Quillard,&Wybo,1992;Shanks,1997).Albeit notusingtheterm“masterdata”explicitly,StrategicData Plan-ningreferstodatathatis usedona company-widelevel.More recentstudiesaddressingthetopicofthemasterdata architec-turehavebeenacasestudyonmultidimensionaldatabases(Hasan etal.,2000)andaninvestigationoftheproductinformationsupply chainintheconsumergoodsindustry(Legner&Schemm,2008). Furthermore,Allemangmadethedistinctionbetweenlinkeddata enterprisearchitectureandmasterdataarchitecture(Allemang, 2010)—withoutspecifyingthelatteranyfurther.

Themostcomprehensivescientificcontributiontothetopichas beenmadebyOttoandSchmidt(2010).Theyrefertomasterdata architecturesasinformationarchitecturesthescopeof whichis restrictedtomasterdata.Theseauthorsusethenotionof “infor-mationarchitecture”notonlytoincludeshareddatasourcesand dataflowsbetweendatabasesintotheconcept,butalsoto empha-sizethedemandfor“authoritative”datastandardsanddefinitions (requiringa business perspective onthetopic). In their under-standing,themasterdataarchitecturecomprisesbothaconceptual masterdatamodelandtheapplicationarchitectureformasterdata. Theapplicationarchitectureformasterdatacanbefurtherdivided intosourceandtargetsystemsofmasterdataontheonehandand dataflowsontheotherhand.Moreover,theauthorsidentifyaset ofdesigndecisionsrelatedtothemasterdataarchitecture.

Ofcourse,manycontributionscanbefoundintheresearch com-munityaddressingthegeneral“dataarchitecture”topic(Brackett, 1994).Numerousarchitectureframeworks—theZachman Frame-work(Zachman,1987),TheOpenGroupArchitectureFramework (TOGAF) (Open Group, 2007), Enterprise Architecture Planning (EAP)(Spewak&Hill,1993),andtheEnterpriseArchitectureCube (Bernard,2005),justtonameafew—considerthedataarchitecture tobepartoftheoverallenterprisearchitecture.OttoandSchmidt (2010),however,showthattheseframeworksbydefinition(due totheiroverarchingapproach)arenotusefulinprovidingboththe conceptualbreadthanddepthrequiredtoinvestigate,analyzeand designamasterdataarchitectureindetail.

Asmentionedearlier,masterdataarchitectureisatopicof dis-cussionalsointhepractitioners’community.Aprominentaspect in this regard is the question for the right architectural style (Dreibelbis etal.,2008;Oberhofer&Dreibelbis,2008; Radcliffe, White, &Newman,2006).AnalystcompanyGartner, for exam-ple,distinguishesbetweenthreestyles(White&Radcliffe,2007). Design/construct MDM (1) is needed if a new business is cre-ated,operationalMDM(2)supportsregularoperationsofexisting businesses,andanalyticalMDM(3)ismainlyusedforreporting purposes.OberhoferandDreibelbis(2008)proposeasimilar cate-gorization,describingalsooperationalandanalyticalapproaches, butidentifyinga“collaborativemethoduse”in addition. Differ-encesbetweenthesearchitecturalstylesrelatetotheflowofdata betweena“goldenrecord”anddatasourcesystems.Ananalytical architecture,forexample,usesaunidirectionalflowofdatafrom thesourcesystemstothe“goldenrecord”,usingextract,transform andload(ETL)processesbeforeimportingthedata.Unlikethe oper-ationalapproach,nodataisfedbacktothesourcesystemsinthe analyticalapproach.

3. Researchapproach 3.1. Researchdesign

The paper uses case study research as a methodological approachtoexamine thecontemporary phenomenonofmaster dataarchitecturedesign.Theresearchdesignorientsitselfatthe fiveguidingpointsproposedbyYin(2002,pp.21–28).Theresearch question(1) is derived from theresearchproblem, namelythe limitedunderstandingofmasterdataarchitecturedesignin com-panies.Therefore, thecentralresearchquestionis:Howshould companiesproceedwhendesigningthemasterdataarchitecture? Duetothelimitedamountofscientificknowledgewithregardto thisquestion,thestudyisofexploratorynature.Yinconcedesthat insuchcasesitisunlikelytobaseone’sresearchonclear propo-sitions(2).However,hestipulatesthatcasestudyresearchshould havesomepurpose(Yin,2002,p.22)aswellasanumberof cri-teriaguidingtheinvestigation.Thepaperathandusesa simple conceptualframework(asshowninFig.1)asaguideforthe inves-tigation.Thisframeworkisbasedonfindingsfrompractitioners andresearchers(seeSection2.2),suggestingthatdesigninga mas-terdataarchitecturecomprisesdecisionsonatechnicallevel(e.g. architecturalstyles) and cannotbeisolated fromorganizational aspects(e.g.allocationofdecision-making rightsregardingdata standards).

Theunitofanalysis(3)setstheboundariesforthecasewith regardtogeneralizabilityofitsresults.Thepaperathandusesa single-casedesign, studyinghowBoschapproachestheissueof findingtherightmasterdataarchitecturedesign.Theconceptual frameworkshowninFig.1functionsalsoasthelogicwhichlinks thedatatothepropositions(4),anditrepresentsthecriteriato interpretthefindings(5).Hence,theconceptualframeworkserves asalensthroughwhichtheevidencefromthecaseisstudiedand analyzed.

3.2. Caseselectionanddatacollection

Single-casedesignshavelimitationswithregardto replicabil-ityoffindings,becausetheydonotsupporttheoreticalsampling (Benbasatetal.,1987;Eisenhardt,1989;Yin,2002).However,the uniquenessofthecase(Yin,2002,pp.40–41)justifiesthedesignof thestudy.

Incontrasttomanyothercompanies,Boschlooksbackona rel-ativelylonghistory ofhavingMDMasacorporatefunctionand designingthemasterdataarchitectureonacompany-widelevel. In2006,Boschintroducedagroupguidelinesettingoutbinding principlesforMDM.Thegroupguidelineincludesanorganizational andatechnicalpart.Thisinformationtogetherwithaccessto var-iouscarriersofknowledgeintheorganizationwereavailableto theauthoroveraperiodofmorethanthreeyears.Also,Boschwas invitedasareferencetopresentthebasicprinciplesoftheirmaster dataarchitecturedesignatameetingoftheMDMWorkingGroup oftheGerman-speakingSAPUserGroup(DSAG),whichtookplace onJune17,2010,inSt.Leon-Rot,Germany.ThecaseofBoschcan thereforebeconsideredashighlyexplorativeandsuitableforlaying thefoundationsforfurther,multiple-caseresearch.

Datawascollectedfromdifferentsources,asshowninTable1. Themaindatasource,however,wereinterviewswithexpertsof Bosch.Transcriptsoftheinterviewswerecreatedbasedonthefield notesfromtheresearchersinvolved.Thefinalcasestudyreportwas senttoBoschforapproval.

4. MasterdataarchitectureatBosch 4.1. Companyoverview

Boschis a leadingtechnology andservice companywithan overall revenueof 47.3billionEurosand 283,500employeesin 2010. Headquartered in Stuttgart, Germany, Bosch operates in threebusinesssectors,namely“AutomotiveTechnology”, “Indus-trialTechnology”,and“ConsumerGoodsandBuildingTechnology”. Thebusinesssectorsspan17divisionswithoperationsinmorethan onehundredcountriesaroundtheworld.

4.2. MDMatBosch

Boschhasmanyyearsofexperienceinmanagingmasterdataon adivisionallevel.In2006,though,thecompanymadeafirststepto organizeMDMonacorporatelevelbyintroducingagroup guide-line,aimingatthespecificationofacompany-widesetofgoalsof MDMinsteadofgoingondealingwithMDMbymeansofrather uncoordinatedactivities.Thegroupguidelineconstitutesa bind-ingframeworkforthemanagementofgroupmasterdata.Group masterdatafollowsthedefinitioninSection2.1.Itisallmaster datawhichisusedonagrouplevel,i.e.bymorethanonedivision. Thegroupguidelinedoesnotapplyformasterdatausedbysingle divisionsonly.

Thegroupguidelineintroducestworoles,namelyMasterData Owner(MDO)andMasterDataOfficer(MDF).Theresponsibilities oftheMDOarethesameasoutlinedinSection2.1.TheMDFrole correspondswiththegeneralunderstandingofthedatasteward role.

Thegroupguidelineidentifiesa setofMDMactivitieswhich aredividedintoorganizational/functionalactivitiesandtechnical activities(seeFig.2).Whereastheformerareunderthe respon-sibilityoftheMDO,thelatterareundertheresponsibilityofthe corporate information technologydepartment.Fig.2 shows the MDMreferenceframeworkatBosch.Itconsistsoffourcomponents, namely“GovernanceSystem”,“MDProvisioning”,“MDUtilization”, and“MDConcepts&Projects”.

Organizational Design Decisions Technical Design Decisions Master Data Architecture Design

Fig.1.Conceptualframework.

Table1 Datasources.

Datasource Description

Interviews 2010-07-19:9.00amto4.00pm,Stuttgart,Germany.Boschparticipants:

•Director(CorporateUserdepartment),responsibleforgroupmasterdata;

•Director(IT),ResponsibleforBusinessSupportTimetoMarket;

•ExpertsandSolutionArchitectMDM(CorporateUserdepartment/IT). 2010-07-19:5.30pmto7.30pm.Stuttgart,Germany.Boschparticipants:

•HeadofCorporateUserdepartment,responsibleforgroupmasterdata;

•Director(CorporateUserdepartment),responsibleforgroupmasterdata. 2011-03-14:3.00pmto3.30pm,conferencecall.Boschparticipants:

•SeniorExpert,SolutionArchitectMasterDataManagement(IT). 2011-03-29:4.00pmto5.00pm,conferencecall.Boschparticipants:

•ExpertsandSolutionArchitectMDM(CorporateUserdepartment/IT).

Presentation •PresentationofBoschattheDSAGMDMworkinggroupmeetingon2010-06-17inSt.Leon-Rot,Germany(availabletoworkinggroup membersonly).

Internaldocuments •GroupguidelineonMDMatBosch,ofNovember2006;

•InternalBoschpresentationonarchitecturalapproachesonMDM,dated2010-12-14.

Observations •2008-02-13:08:30amto6:00pm,Sindelfingen,Germany,WorkshopofWorkingGroupMDMatBoschwithover15participants discussingfourfocustopics,namelyMDMroadmap,MDMorganization,MDMplatforms,MDMmaturity;authorofthepaperparticipated asamoderator.

The“GovernanceSystem”containstheMDStrategyforeach masterdataclassaswellasMDControllingactivities,whichassess thematurityofMDMforeachmasterdataclassandmeasurethe qualityofthemasterdata.

“MDProvisioning”includesthedesignandmaintenanceofan organization for MDM(including MDOsand MDFs), thedesign andmaintenanceofmasterdataprocesses(e.g.creationorupdate of master data), the design and maintenance of a master data model,and thedesignand guidanceoftheapplication systems usedtostoreanddistributemasterdata.Themasterdatamodel hasaconceptualview(MDOresponsibility)andaphysicalview(IT responsibility).

“MDUtilization”includestheuseofmasterdatainbusiness processes and the business application systems supportingthe businessprocessesatBosch.

Finally,theframeworkcomponent“MDConcepts&Projects” takesalifecycleperspectiveonthedifferentmasterdataclasses. Relatedactivities include themanagement of business require-mentsregardingmasterdata,thedesignoffunctionalandtechnical specifications,andtheorganizationalandtechnical implementa-tionofthespecificationsthroughprojects.Table2summarizesthe organizational/functionalandtechnicalactivities.

In2006,sevenmasterdataclasseswerewithintheinitialscope oftheimplementationbasedonthegroupguideline,namelychart

MD Provisioning

MD Utilizatio

n

MD

Concepts &

Projects

Governance System

MD Strategy

MD

Controllin

g

MD Org

.

MD

Processes

MD Ap

plications

Systems

MD Model

Business Processes

Business Applicat

ion

Systems

Implementation

Projects

MD Concep

t

Requirements

Management

Legend: org./f unctional responsibility; technical responsibility; MD – master data. Fig.2.MDMreferenceframeworkatBosch.

Table2

OrganizationalandtechnicalMDMactivities.

Organizationalactivities Technicalactivities

•Definitionofmasterdataclasses •Designandmaintenanceofphysicaldatamodels

•Specificationofareaoforganizationalvalidity •Designofdatastorageanddatadistributionarchitecture

•DesignandmaintenanceofanorganizationforMDM •SupportofMDOs

•Designandmaintenanceofdatamaintenanceprocesses

•Designandmaintenanceofconceptualdatamodels(attributesandvaluesallowed)

•Designandmaintenanceofdatadistributionprocesses(functionalperspective)

ofaccounts,customerhierarchy,customermasterdata,supplier masterdata,certainmaterialmasterdataincludingproduct hier-archies,andasubsetofso-calledgroupelements,whichcomprise referencedata,suchascountryandlanguagecodes.

4.3. Masterdataarchitecturecontextandgoals

Masterdatahadbeenmanaged,ofcourse,bythedifferent busi-nesssectorsanddivisionslongbeforeMDMwasestablishedon acorporatelevelatBosch.Hence,forthemanagementofmaster dataavarietyofbusinessprocessesandapplicationsystemshad emerged.Intheprocessofimplementingmasterdataarchitectures forthedifferentdataclassesaccordingtothegroupguideline,MDM atBoschencountereddifficultieswhendiscussingthe introduc-tionofastandardarchitecture.Astandardapproachwouldhave meanteithermigratingalldatafromexistingapplicationsystems toanewlyinstalledsystem(whichisnotafeasibleoptioninthe majorityofcasesduetocostandorganizationalconstraints),or liv-ingwiththeheterogeneityandnotfollowingthepoliciesspecified bythegroupguideline.Moreover,therequirementsonthe mas-terdataarchitecture,whicharederivedfromthedemandfromthe businessunits,differsignificantlyacrossthevariousmasterdata classes.

Summarizing,threefactorspreventa“onesizefitsall” archi-tectural design at Bosch. First, there are different business requirements across different divisions and functional depart-ments. Unique supplier master data, for example, is mainly requiredforreportingpurposesinpurchasingandcompliancewith regulations—suchasbeingabletoblocksuppliersforpurchasing thatallowchildlabor—whereasconsistentandcompletematerial masterdataisneededfromanoperationalperspectiveinsales, manufacturinganddistribution.

Asecondfactoristhevarietyofexistingapplicationsin differ-entdivisionsandfunctionaldepartments.Theapplicationsystem landscapefollowsagroup-wideframework,but,ofcourse,shows differenceswhenitcomestodetails.Examplesaretheuseof dif-ferentsoftwarevendorsforthesameclassofapplicationsystems anddifferentreleasesofthesamesystem.Thesedifferencesleadto technicalbarriersregardingtheuseofa“onesizefitsall” architec-turaldesign.

Third,therearedifferentlevelsoforganizationalmaturitywith regardtoMDMindifferentdivisionsandfunctionaldepartments. Somefunctional departmentshaveaclearunderstandingofthe requirementswithregardtomasterdataqualityandthemaster datalifecycle,whileothersareinearlyanalysisstages.

Asa consequence,the idea wasdeveloped tooffer a set of referencemasterdataarchitecturestheMDOsandotherpersons responsiblecouldchoosefromonacase-wisebasis.Thereference architecturesaresupposedtosupportthefollowingobjectives: •Vendor-neutral representation of master data architecture

approachesatBosch.

•Accelerated “time to market” from business requirementsto implementedsolutions.

•Supportofinternal(betweencentralunitsanduserdepartments) andexternal(withsoftwarevendors)communication.

4.4. Technicalperspective

Ingeneral,masterdataarchitecturedesignatBoschmustbe alignedwiththreeparameters,namelythegroup-wideapplication systemarchitectureframework,thedatagovernanceframework, and the product strategy of the preferred application system vendor. Taking into accountthese parameters, Boschidentified fourbasicapproachesfor masterdataarchitectures (seeFig.3). ApproachAisreferredtoastheanalytical approach.Itassumes thatallmasterdatamaintenanceactivities,i.e.creation,update, anddeletionofmasterdata,areperformedbylocalsourcesystems. Incaseofcreationofnewmasterdata,theprimarykeyattributeis alsoassignedbythelocalsystem.Dataisthenperiodicallyimported intoacentralMasterDataServer(MDS),whichassignsa“global”, i.e.company-wideunique,identificationnumbertoallimported masterdatarecords,andoptionallyholdsreferencestolocalkey attributes.DuplicaterecordsareidentifiedbytheMDS.Approach Aisusedtosupportbusinessscenarioswhichrequireongoingdata qualityassuranceandageneraloverviewofdistributedand hetero-geneousmasterdatainacertaindomain.Itisusedinpost-merger situationsandinpreparationofdatamigrationprojects.

Approach B is referred to as the transactional approach. It assumesthatmaintenanceofglobalmasterdataattributesis per-formed by the MDS. Also, the MDS provides functionality for assigningglobalidentificationnumbers,workflowsupportfordata maintenance,duplicate checksupon dataentry,andexportand distributiontolocaltargetsystems.Globalmasterdatacanonly beread by thetargetsystems;updating or changing,however, is not allowed. Approach Bis used in business scenarios with highliabilityrequirementsondata.AnexampleofApproachBis thecompany-widechartofaccountsfollowingtheInternational FinancialReportingStandards(IFRS),wheredatamaintenanceis performedbyalimitednumberofsubjectmatterexperts.

ApproachC(coexistence)isacombinationoftheanalyticaland thetransactionalapproach.Masterdataismaintainedbylocal sys-tems,whichalsoassignprimarykeystomasterdatarecords.The data is then imported into a centralMDS and assigned witha globallyuniqueidentificationnumber.Inanextstepthedatais consolidatedbyasmallnumberofsubjectmatterexperts,handed backtothesourcesystems,and(onrequest)furtherdistributed toothertargetsystems.ApproachCisusedinbusinessscenarios which arecharacterizedbyhighlyheterogeneouslocalbusiness requirementsand/oraneedforcompany-widedataintegration. AnexampleofApproachCishumanresourcesmasterdata,which needstocomplywithlocalstandardsbutmustalsobeconsolidated centrallyforidentitymanagementaswellasforcorporatehuman resourcesfunctions,suchascompetencemanagementandtraining management.

ApproachD,theparallelapproach, ischaracterizedby divid-ing up central master data maintenance functionality between a central MDS and local application systems. Users of local systems are supported by workflow management in creating, updating and deleting master data. However, all transactions

MDS

Analytical Approac

h

A

Source

System 1

Source

System

2

Source

System n

MDS

Transactional Approach

B

Target

System

1

Target

System

2

Target

System n

MDS

Coexistence

C

Source

System 1

Source

System

2

Source

System n

MDS

Parallel Approach

D

Target

System

1

Target

System

2

Target

System n

Target

System 1

Target

System

2

Target

System n

Source

System

1

Source

System n

MDS

MD

S

Legend: local system; “global”, i.e. corporate-wide system (“golden record”)

Fig.3. ArchitecturalapproachesatBosch.

requiringcompliancewiththeACIDprinciple,definingthe atom-icity,conistency,isolation,anddurabilityofdatabasetransactions (Haerder&Reuter,1983),aresynchronizedwiththecentralMDS, whichalsoassignsgloballyuniqueidentificationnumbersto mas-terdatarecords,checksforduplicate records,andvalidatesthe data.IncontrasttoApproachC,whichusescorporatesubject mat-terexperts,theparallelapproachusestheexpertiseoflocalusersto consolidatethemasterdata.Theparallelapproachisthereforeused inbusinessscenarioswhicharecharacterizedbymany heteroge-neousbusinessrulestobecheckedduringdatamaintenanceand/or ademandforhighmasterdataquality.AnexampleofApproachDis masterdataformachineryspareparts,asthisdatacombineslocal (e.g.localmanufacturerpartnumbers)withglobalrequirements (e.g.company-wideinventorylevelvisibility).

4.5. Organizationalperspective

Besidesthetechnicalperspectiveonthemasterdata architec-ture,the groupguideline at Boschalso includes organizational design activities, namely a common definition of master data classes,adefinitionoftheirorganizationalvalidity,andthe concep-tualdatamodel.Apartfromthat,thegroupguidelinealsoidentifies theneedforfurtherorganizationaldesign activities,namelythe definitionofmaintenanceprocesses(relatedtotheMDS),thedata distributionanddeploymentprocesses(relatedtothetarget pro-cessesandsystems),andtheassignmentoforganizationalroles.

Boschidentified three general organizational approaches, as showninTable3.ApproachI(centralapproach)ischaracterized bya centralresponsibility for allfunctional and organizational design decisions related to a certain master data class and also—partially—bycentralexecutionofmasterdatamaintenance. ApproachII(hybridapproach)combinescentralandlocal respon-sibility,i.e.businessunit responsibilityfordesignactivities.The

executionofmasterdatamaintenanceactivitiesisassigned com-pletely tothebusiness units.AndApproach III(local approach) is characterized by almost complete local responsibility for all functionalandorganizationaldesigndecisionsrelatedtoacertain masterdataclass.Onlythedefinitionofguidelinesformaintenance activitiesisassignedtothecentralMDOrole.

Boschalwaysallocatestheownership ofmasterdataclasses andthedesignoftheconceptualdatamodeltoacentralrole,i.e. theMDO,evenunderthehybridandthelocalapproach.Thisisa consequenceofthepoliciesoutlinedinthegroupguideline,which understandsMDMasacentralfunction.Therefore,local owner-shipandlocalconceptualdatamodelswouldbecontradictoryto theobjectivesofMDMforgroupmasterdataatBosch.

4.6. Integratedassessment

Basedontheidentificationofbothtechnicalandorganizational approachestothemasterdataarchitecture,Boschidentifieda num-berof“feasible” architecturepatterns,i.e.combinationsof both perspectives.

AsTable4shows,Boschconsiders fivecombinations(outof twelvetheoreticallypossible)asfeasible.ApproachA(analytical approach),forexample,isdeemedfeasibleonlyin combination withApproachIII(localapproach).Therationalebehindthisisthat thereisnoneedto“dictate”businessunitsthedesignofthedata maintenanceprocesswhenthemasterdataisusedonacorporate levelforreportingpurposesonly.Instead,itjustmustbeensured thatmasterdatacanbeconsolidatedbyacentralMDS.

Allothertechnicalapproachesmaybecombinedwiththehybrid organizationalapproach,ensuringabalancebetweenlocaland cen-tralbusiness requirements.While thetransactionalapproach is preferablebecauseofitsrelativelylimitedtechnicalcomplexity, itisoftenapplicableonlyinorganizationalenvironmentssimilar

Table3

OrganizationalapproachesatBosch.

Designparameters I (Centralapproach) II (Hybridapproach) III (Localapproach) Organizationalallocationof

responsibilityformaster dataclass

MDO,togetherwithbusinessunitrepresentativesandMDF

Designofdatamaintenance process

MDOdefinescompany-wide maintenanceprocess (standard)

MDOdefinesprinciplesfor company-widemaintenance processes,detaileddefinition donebybusinessunits

NocentralprinciplesbyMDO; maintenanceprocesses designedbybusinessunits Executionofdatamaintenance

process

CentralMDOorganization, togetherwithbusinessunits

Businessunits Businessunits Designofconceptualdata

model

MDO Examples Customerhierarchydata Customermasterdata,

machineryspareparts,human resourcesmasterdata

Producthierarchy

MDO—MasterDataOwnerandMDF—MasterDataOfficer.

toApproachI.In general,thetechnicalapproachfor thehybrid organizational approach(II) dependsonthe followingfour fac-tors:

•Diversityofbusinessprocessesandsystemstobeconnected. •Heterogeneityofdataanddatamodels.

•Timelinesofprioritizedbusinessrequirements(“customers”of masterdata).

•Feasibilityandcostofimplementation(asaresultofthethree factorsabove).

In general,Boschprefers the parallel approach tothe coex-istence approach. The latter may be followed, however, when businessprocesses and applicationsystems relatedtoa certain master data class are too heterogeneous, making the parallel approachbecomeeconomicallyunreasonable.

Anexample ofthecoexistenceapproach ishumanresources masterdata.Mainreasonsforusingthisapproachare:

•Varianceofbusinessprocesses(includingmasterdata mainte-nance)incombinationwithcountryspecificlegalrequirements: whilethefactthatmosthumanresourcedepartmentsatBosch areusingSAPsystemsbasicallysupportstheimplementationof almostallapproaches,theobstacleofdiversebusinessprocesses remains.Masterdatacouldonlybecleansedin“downstream” activities(whichpreventstheuseofsynchronousdataprocesses approachessuchastheparallelapproach).

•Timelineconstraints: usersofglobal humanresourcesmaster datacouldnotwaitfortheimplementationofthetransactionalor parallelapproach.Inthisregard,thecoexistenceapproachwas usedtomeetprioritizedbusinessrequirementswhenneeded, servingasafirststeptowardthefinalmasterdataarchitecture.

Forothermasterdataclasses(customerandsupplierdata,for example),thefactorsmentionedabovearedifferent(strictcentral masterdatamaintenance,forexample),leadingtothepreference

ofthetransactionalapproachfromtheverybeginningofthe imple-mentation.

Moreover,theparallelapproachispreferredtothetransactional approachformasterdataclasseswhichrequireintensive knowl-edgefromthelocalbusinessunits.Anexampleismaterialmaster data,whichoftenrequirestheknowledgeoflocalplantmanagers andwhichismanagedthroughavarietyofdifferentbusiness pro-cesses.Incaseslikethis,theparallelapproachoffersmoreflexibility tothebusinessunitsthanthetransactionalapproach.

Boschusesthesefivemasterdataarchitecturepatternsasa ref-erenceforthevariousmasterdataclasses.Boschconsidersthese approachesasameanstobalancetheneedforflexibilityinthe businessontheonehandandthedemandforreducedtechnical complexityontheotherhand.Atpresent,Boschisintheprocess ofsuccessivelyapplyingtheconcepttothemasterdataclasses.

5. Caseanalysis

5.1. Thenatureofmasterdataarchitecturedesignpatterns

ThecaseofBoschshowsthatpatternscanbeveryusefulwhenit comestodesigningthemasterdataarchitecture.Ingeneral, archi-tecturaldesignpatternsareverycommoninsoftwareengineering as theyrepresent a problem-solution pair not onlyfor specific butforclassesofarchitecturaldesignproblems(Avgeriou&Zdun, 2005;Buschmann,Meunier,Rohnert,Sommerlad,&Stal,1996,p. 3).Furthermore,patternsallowbalancingstandardizationonthe onehandandflexibledesignontheother.

Thecurrentstateofresearchandpracticewithregardtodesign patternsforthemasterdataarchitectureisstillatanearlystage ofdevelopment.OttoandSchmidt(2010)identifyrelevantdesign decisions and options, but do not come up with comprehen-sivearchitecturalpatterns. Andthepractitioners’ communityis discussing different architectural styles, such as analytical and operationalMDM(seeSection2.2).Thesestyles,however,aretoo simplistictoexplainthearchitecturalpatternsinthecaseofBosch.

Table4

Feasiblemasterdataarchitecturepatterns.

Technical approach

Organizationalapproach

I(Central) II(Hybrid) III(Local)

A(Analytical) 䊎 䊉

B(Transactional) 䊉 䊉

C(Coexistence) 䊉

D(Parallel) 䊉

Thispaper takes this discussion furtherwith regard to two mainaspects.First,thequestionofarchitecturaldesignmustnot bereduced totechnicalaspectsonly,but shouldratherbalance bothorganizationalandtechnicalconsiderations.Thisisevenmore importantassuchacomprehensiveapproachwouldallowto iden-tifyfeasiblepatterns.Organizationalandtechnicalaspectsshow stronginterdependenciestheanalysisofwhichcouldpavetheway foridentifyingfeasiblemasterdataarchitecturepatterns.

Second, theBosch case alsoshows that design patterns for themasterdataarchitectureareusedasanapproachtomanage thecomplexityoftheissueathand.Complexitydimensionsare, forexample, thenumberand heterogeneityof differentmaster dataclasses,theorganizationalstructure,andtheusecase(White, 2010).However,thispointhasnotbeendiscussedsufficientlyin ordertobeabletoexplainthecaseofBosch.TheBoschcaseshows theneedtoincludefurthercomplexitydimensionswhen design-ingthemasterdataarchitecture.Amongthosearetheseparation offunctionalandtechnicaldesignresponsibilities(seeFig.2),the diversityofbusinessprocessestobesupported,andtheurgencyof action—asinthecaseofhumanresourcesmasterdata,forexample. Itisthecombinationofthisextensivesetofdimensionswhichhas ledtothedesignoftheparallelapproachatBosch—anapproach whichhasnotbeenconsideredeitherinresearchorinpracticeso far.Ofcourse,thepaperdoesnotwanttogeneralizefromonecase atthispoint.Itis,however,quitelikelythattheapproachofBosch couldbeadoptedbycompanieswithsimilarcharacteristics.

5.2. Theorganizationalfitofmasterdataarchitecturedesign

ThecaseofBoschsuggeststheassumptionofthemasterdata architecture being dependent on organizational factors. There seemstobetheissueofanorganizationalfitofmasterdata archi-tecturedesign.Contingencytheory,ingeneral,claimsthatthere isno“onesizefitsall”approachtocorporateorganization.A num-berofresearchershavedemonstrateditsapplicabilitytoenterprise architecture management (Lahrmann, Winter, & Fischer, 2010; Leppänen,Valtonen,&Pulkkinen,2007;Ylimäki,2006).These con-tributions, however, remain very unspecific when it comes to contingenciesofthemasterdataarchitecture.ThecaseofBosch isnovel,asitexplicitlyaddressestheissueoforganizationalfitof masterdataarchitecturedesign.

Apartfromthat, theBoschcase showsthatcontingency fac-torsfor enterprisearchitecturemanagement—suchas modeling capabilities,adopteddesignparadigms,organizationalpenetration (Riege&Aier,2009)—arenotappropriatetoexplainthe organiza-tionalfitofmasterdataarchitecturedesign.Contingencyfactors forthemasterdataarchitectureareratherbusinessprocess diver-sity,urgencyofaction,heterogeneityofdataclassesandmodels, knowledgeaboutmasterdataclassesinthebusinessunits,andthe relationshipbetweengroup-wideandlocalMDMactivities.

Furthermore, the Bosch case shows the tight relationship betweenmasterdatagovernanceandmasterdataarchitecture.The groupguidelineistheoverarchingreferencefordatagovernance questionsatBosch.Itsetsoutrolesandresponsibilities,alsorelated tothedesignofthemasterdataarchitecture.Theguidelineis con-sideredtobeaprerequisitewithoutwhichtheuseofmasterdata architecturedesignpatternswouldnotbepossible(seeSection4.6). Thesilenceoftheresearchcommunity,though,standsincontrastto theimportanceofthisaspect.Whiledatagovernancehasreceived someattentionlately(Khatri&Brown,2010;Otto&Reichert,2010; Weberetal.,2009),noneofthecontributionsinvestigatesthe rela-tionshipbetweendatagovernanceandmasterdataarchitecturein detail.

ThegroupguidelineatBoschdoesnotonlyidentifyanddescribe therolesandresponsibilities,butitalsospecifiesthecollaboration betweenbusiness andIS/ITdepartments.Theexplicitdefinition

ofmasterdataarchitecturerelatedresponsibilitiesbetweenthose twocommunities withinBoschhelpedmanage sucha complex issueasmasterdataarchitectureinacomprehensive—i.e. organi-zational/functionalandtechnical—way.Thisaspecthasnotbeen addressed by literatureso far either.Some papers exist which examinetherolesofbusinessandIS/ITdepartmentsinenterprise architecturemanagementingeneral(Gregor,Hart,&Martin,2007; Winter&Schelp,2008),buttheydonotfocusonthemasterdata architectureissue.

5.3. Anevolutionaryperspectiveonmasterdataarchitecture design

Thecasestudyaddressesanotherimportantquestion,namely howmasterdataarchitecturedesignisevolvingovertime.Bosch preferstheparallelapproachtothecoexistenceapproach—unless thereare urgencyconstraints—and theparallelapproach tothe transactional approach in cases of master data classes which require intensive “local” knowledge. The fact that preferences aresubjecttocertainconditionsimpliesthatarchitecturaldesign evolvesover time.Organizationalfit ofmasterdataarchitecture patternsseemstobedynamicratherthanfixed.

EvolutionarytheoryhasbeenusedfrequentlyinIS research, mainlytoexplainchangewithregardtoISartifacts.Ingeneral,a combinationofevolutionarytheoryandcontingencytheoryallows toinvestigatealternativeevolutionarypaths(Teo&King,1997). Thus,itmightexplainwhenandunderwhatconditionsacertain masterdataarchitecturedesignispreferableforanorganization.

Masterdatahaslongsincebeenmanagedonalocallevelat Bosch, whilethegroupguidelinefor MDMis relativelynew.In caseslikethis,acertain“carrot-and-stick”approachseems appro-priateformasterdataarchitecturedesign.AnalystcompanyAMR Researchrecommendstouse“centralMDMfacilitation,not con-trol”(Swanton,Hagerty, &Cecere, 2007)—whichis ofteneasier saidthandone. However,Boschfollowsthisidea,usingagroup guidelineasa“stick”andtheprovisioningofreferencearchitecture patternsincludingworkflowsupportanddataqualityassurance as“carrots” forlocalbusinessunits.In thecourseof the evolu-tionofMDMatBoschingeneraland theongoingadaptationof masterdataarchitecturepatterns,demandfor centralorhybrid approachesmightincreaseattheexpenseoflocalapproaches.

6. Conclusions

Thepaperathandreportsonthedesignofthemasterdata archi-tectureatBosch.Thecaseshowsthatdesigningthemasterdata architectureisa taskwhich combinesboth technicaland orga-nizationalaspects. Boschhasspecifiedfourtechnical and three organizationalapproaches,andhasidentifiedfive“feasible” com-binationsoftheseapproachesoutoftwelvetheoreticallypossible. Theanalysisof thecase suggeststhreemajorfindings. First, designpatternsforthemasterdataarchitecturehavetoincludea varietyofbothorganizationalandtechnicaldesignoptions.Existing contributionsfromrelatedfields—suchasenterprisearchitecture management—arenotsufficienttoexplainmasterdataarchitecture design.Second,masterdataarchitecturedesigniscontingenttoa numberoffactors.Duetothenatureofmasterdataandthe organi-zationofMDMincompanies,existingtheoriesshouldbeextended toexplainmasterdataarchitecturedesign.Importantfactorswhich havenotbeendiscussedinliteraturesofarbutwhicharespecificto MDMincludethevarietyandheterogeneityofmasterdataclasses, theadoptionofdatagovernance,andthedistributionofknowledge aboutmasterdataacrosstheorganization.Third,anevolutionary perspectiveseemstoberequiredinordertoexplainmasterdata architecturedesigncomprehensively.Preferencesforcertain mas-terdataarchitectureapproachesandtheirdependenceonvolatile

parameterssuggesttheexistenceofcertainevolutionarypathsof masterdataarchitecturedesign.

Neitherthescientificbodyofknowledgenorthepractitioners’ communitysofarhasreportedaboutacasewhichallowsasmuch insightintotheissueasthecaseofBoschdoes.Thus,thepaper’s maincontributiontothescientificbodyofknowledgeisyielding insightintoandunderstandingofacontemporaryphenomenon, whichis,atpresent,ratherunexplored.Thepaperlaysthe founda-tionforfutureresearch,inparticularformultiple-casestudiesand empiricalinvestigation.

Practitionersmaybenefitfromthepaperbecauseitoffers direc-tionandguidanceinthecomplextaskofdesigningthemasterdata architecture.

Limitations exist with regard to generalizability of results. Single-casestudiesbydefinitiondonotallowfortheoretical sam-pling.Hence,thefindingsofthepapermustbetriangulatedwith similarcases. Triangulationmust takeinto accountthe general characteristicsofBosch,namelythesizeofthecompany,the indus-try,and themulti-national andmulti-divisionalorganization.In additiontothat,replicationofthefindingsshouldalsoconsiderthe specificcharacteristicsofMDMatBosch,namelythelong experi-encewithmasterdatabothonalocalandgrouplevel,theexistence oftheMDMreferenceframework(seeFig.2)andtheadoptionof thegroupguidelineacrossthecompany.

Acknowledgements

Theresearchpresentedinthispaperisaresultofthe Compe-tenceCenterCorporateData Quality(CCCDQ).TheCCCDQ isa consortiumresearchprojectandpartoftheresearchprogram Busi-nessEngineeringattheInstituteofInformationManagementatthe UniversityofSt.Gallen(BEHSG).

References

Allemang,D.(2010).Semanticwebandthelinkeddataenterprise.InD.Wood(Ed.),

Linkingenterprisedata(pp.3–23).Berlin,Germany:Springer.

Avgeriou,P.,&Zdun,U.(2005).Architecturalpatternsrevisited—Apatternlanguage. Paperpresentedatthe10thEuropeanConferenceonPatternLanguagesof Pro-grams,Irsee,Germany.

Benbasat,I.,Goldstein,D.K.,&Mead,M.(1987).Thecaseresearchstrategyinstudies ofinformationsystems.MISQuarterly,11(3),369–386.

Bernard,S.A.(2005).Anintroductiontoenterprisearchitecture(2nded.). Blooming-ton,IN:Authorhouse.

Bitterer,A.,&Newman,D.(2007).Organizingfordataquality.Stamford,CT:Gartner, Inc.

Brackett,M.H.(1994).Datasharingusingacommondataarchitecture.NewYork,NY: JohnWiley.

Brown,C.V.(1997).ExaminingtheemergenceofhybridISgovernancesolutions: Evidencefromasinglecasesite.InformationSystemsResearch,8(1),69–94. doi:10.1287/isre.8.1.69

Buschmann,F.,Meunier,R.,Rohnert,H.,Sommerlad,P.,&Stal,M.(1996). Pattern-orientedsoftwarearchitecture:Asystemofpatterns.Chichester,UK:JohnWiley. DAMA.(2008).TheDAMAdictionaryofdatamanagement.BradleyBeach,NJ:Technics

Publications.

DAMA.(2009).TheDAMAguidetothedatamanagementbodyofknowledge.Bradley Beach,NJ:TechnicsPublications.

Delbaere,M.,&Ferreira,R.(2007).Addressingthedataaspectsofcompliancewith industrymodels.IBMSystemsJournal,46(2),319–334.doi:10.1147/sj.462.0319 Dreibelbis,A.,Hechler,E.,Milman,I.,Oberhofer,M.,vanRun,P.,&Wolfson,D. (2008).Enterprisemasterdatamanagement:AnSOAapproachtomanagingcore information.UpperSaddleRiver,NJ:IBMPress.

Eisenhardt,K.M.(1989).Buildingtheoriesformcasestudyresearch.Academyof ManagementReview,14(4),532–550.

Goodhue,D.L.,Kirsch,L.J.,Quillard,J.A.,&Wybo,M.D.(1992).Strategicdata planning:lessonsfromthefield.MISQuarterly,16(1),267–274.

Gregor,S.,Hart,D.,&Martin,N.(2007).Enterprisearchitectures:enablersofbusiness strategyandIS/ITalignmentingovernment.InformationTechnology&People,

20(2),96–120.doi:10.1108/09593840710758031

Haerder,T.,&Reuter,A.(1983).Principlesoftransaction-orienteddatabaserecovery.

ComputingSurveys,15(4),287–317.doi:10.1145/289.291

Hasan,H.,Hyland,P.,Dodds,D.,&Veeraraghavan,R.(2000).Approachestothe devel-opmentofmulti-dimensionaldatabases:Lessonsfromfourcasestudies.The DataBaseforAdvancesinInformationSystems,31(3),10–23.

IBM(2011).InfoSpheremasterdatamanagementserver.Retrievedon2011-02-18 from<http://www-01.ibm.com/software/data/infosphere/mdmserver/>. Inmon,W.H.(1992).Dataarchitecture:theinformationparadigm(2nded.).Boston,

MA:QEDTechnicalPublishingGroup.

Khatri,V.,&Brown,C.V.(2010).Designingdatagovernance.Communicationsofthe ACM,53(1),148–152.doi:10.1145/1629175.1629210

Knolmayer,G.F.,&Röthlin,M.(2006).Qualityofmaterialmasterdataanditseffect ontheusefulnessofdistributedERPsystems.InJ.F.Roddick(Ed.),Advances inconceptualmodeling—Theoryandpractice(pp.362–371).Berlin,Germany: Springer.

Kokemüller,J.(2010).Masterdatacompliance:Thecaseofsanctionlists.Paper presentedatthe16thAmericasconferenceoninformationsystems,Lima,Peru. Lahrmann,G.,Winter,R.,&Fischer,M.M.(2010).Designandengineeringfor sit-uationaltransformation.InF.Harmsen,E.Proper,F.Schalkwijk,J.Barjis,&S. Overbeek(Eds.),Practice-drivenresearchonenterprisetransformation(pp.1–16). Berlin,Germany:Springer.

Legner,C.,&Schemm,J.(2008).Towardtheinter-organizationalproduct informa-tionsupplychain—Evidencefromtheretailandconsumergoodsindustries.

JournaloftheAIS,9(3/4),120–152.

Leppänen, M., Valtonen, K., & Pulkkinen, M. (2007). Towards a contingency frameworkforengineeringanenterprisearchitectureplanningmethod.Paper presentedatthe30thInformationSystemsResearchSeminarinScandinavia, Tampere,Finland.

Loshin,D.(2008).Masterdatamanagement.Burlington,MA:MorganKaufmann. Maedche,A.(2010).AnERP-centricmasterdatamanagementapproach.Paper

pre-sentedatthe16thAmericasConferenceonInformationSystems,Lima,Peru. Markus, M.L.,Steinfield, C. W.,Wigand, R. T., & Gabe, M.(2006).

Industry-wide information systems standardization as collective action: The case of the U.S. residential mortgage industry. MIS Quarterly, 30(SI), 439–465.

Oberhofer, M., & Dreibelbis, A. (2008). An introduction to the master data management reference architecture. Retrieved on 2011-03-18 from < http://www.ibm.com/developerworks/data/library/techarticle/dm-0804oberhofer/>.

OpenGroup.(2007).TheOpenGroupArchitectureFrameworkTOGAF—2007Edition (Incorporating8.1.1).Zaltbommel,TheNetherlands:VanHaren.

Otto,B.,Ebner,V.,&Hüner,K.(2010).Measuringmasterdataquality:Findingsfrom acasestudy.Paperpresentedatthe16thAmericasconferenceoninformation systems,Lima,Peru.

Otto,B.,&Reichert,A.(2010).Organizingmasterdatamanagement:Findingsfrom anexpertsurvey.InB.R.Bryant,H.M.Haddad,&R.L.Wainwright(Eds.), Pro-ceedingsofthe25thACMsymposiumonappliedcomputingSierre,Switzerland, (pp.106–110).

Otto,B.,&Schmidt,A.(2010).Enterprisemasterdataarchitecture:Design deci-sionsandoptions.Paperpresentedattheproceedingsofthe15thinternational conferenceoninformationquality,LittleRock,AR.

Pula,E.N.,Stone,M.,&Foss,B.(2003).Customerdatamanagementinpractice:An insurancecasestudy.JournalofDatabaseMarketing,10(4),327–341. Radcliffe,J.,White,A.,&Newman,D.(2006).Howtochoosetherightarchitectural

styleformasterdatamanagement.Stamford,CT:Gartner,Inc.

Riege,C.,&Aier,S.(2009).Acontingencyapproachtoenterprisearchitecture method engineering. In G. Feuerlicht, & W. Lamersdorf (Eds.), Service-orientedcomputing—ICSOC2008workshops(pp.316–326).Berlin,Germany: Springer.

SAP(2008).SAPlibrary—SAPnetweavermasterdatamanagement(MDM).Retrieved on 2009-02-19, from <http://help.sap.com/saphelpmdm550/helpdata/ en/43/D7AED5058201B4E10000000A11466F/frameset.htm>.

Sarsfield,S.(2009).Thedatagovernanceimperative:Abusinessstrategyforcorporate data.Cambridgeshire,UK:ITGovernancePublishing.

Shanks, G. (1997). The challenges of strategic data planning in practice: an interpretivecasestudy.JournalofStrategicInformationSystems,6(1),69–90. doi:10.1016/S0963-8687(96)01053-0

Smith,H.A.,&McKeen,J.D.(2008).DevelopmentsinpracticeXXX:Masterdata management:Salvationorsnakeoil?CommunicationsoftheAIS,23,63–72. Spewak,S.H.,&Hill,S.C.(1993).Enterprisearchitectureplanning—Developinga

blueprintfordata,applicationsandtechnology.NewYork,NY:JohnWiley. Swanton,B.(2005).Masterdatamanagementorganizations:Abalanceofcontroland

responsibility.Boston,MA:AMRResearch,Inc.

Swanton,B.,Hagerty,J.,&Cecere,L.(2007).MDMstrategiesforenterpriseapplications. Boston,MA:AMRResearch,Inc.

Teo,T.S.H.,&King,W.R.(1997).Integrationbetweenbusinessplanningand infor-mationsystemsplanning:Anevolutionary-contingencyperspective.Journalof ManagementInformationSystems,14(1),185–214.

TIBCO.(2008).ManagingmasterdatawithTIBCOcollaborativeinformationmanager: Atechnicaloverview.PaloAlto,CA:TIBCOSoftwareInc.

Wang,R.Y.(1998).Aproductperspectiveontotaldataqualitymanagement. Com-municationoftheACM,41(2),58–65.doi:10.1145/269012.269022

Weber,K.,Otto,B.,&Österle,H.(2009).Onesizedoesnotfitall—Acontingency approachtodatagovernance.ACMJournalofDataandInformationQuality,1(1) doi:10.1145/1515693.1515696

White,A.(2010).ThefivevectorsofcomplexitythatdefineyourMDMstrategy. Stam-ford,CT:Gartner,Inc.

White,A.,&Radcliffe,J.(2007).FourdimensionsofMDM:Understandingthe complex-ity.Stamford,CT:Gartner,Inc.

White,A.,&Radcliffe,J.(2008).Masteringmasterdatamanagement.Stamford,CT: Gartner,Inc.

Wieczorek,S.,Stefanescu,A.,&Schieferdecker,I.(2008).Testdataprovisionfor ERPsystems.Paperpresentedatthe2008internationalconferenceonsoftware testing,verification,andvalidation,Lillehammer,Norway.

Winter,R.,&Schelp,J.(2008).Enterprisearchitecturegovernance:theneedfora business-to-ITapproach.Paperpresentedatthe23rdannualACMsymposium onappliedcomputing,Fortaleza,Brazil.

Yin,R.K.(2002).Casestudyresearch:designandmethods(3rded.).ThousandOaks, CA:SagePublications.

Ylimäki,T.(2006).Potentialcriticalsuccessfactorsforenterprisearchitecture. Jour-nalofEnterpriseArchitecture,2(4),29–40.

Zachman,J.A.(1987).Aframeworkforinformationsystemsarchitecture.IBM Sys-temsJournal,26(3),454–470.doi:10.1147/sj.263.0276

ZF.(2010).Annualreport2009.Friedrichshafen,Germany:ZFFriedrichshafenAG.

BorisOttoisAssistantProfessorattheUniversityofSt.Gallen,Switzerland,and VisitingResearchFellowattheTuckSchoolofBusinessatDartmouthCollege inHanover,NH.HismainareasofresearchareDataGovernance,DataQuality Management,andMasterDataManagement.Hisresearchhasbeenpublishedin numerousinternationaljournalsandheismemberoftheScientificAdvisoryBoard ofeCl@ss,theinternationalclassificationandproductdescriptionstandard.Priorto hiscurrentpositionsheworkedforFraunhoferIAO,PricewaterhouseCoopers,and SAP.