• No results found

Enterprise Data Management with SAP NetWeaver MDM


Academic year: 2021

Share "Enterprise Data Management with SAP NetWeaver MDM"


Full text


Andrew LeBlanc

Enterprise Data Management

with SAP


NetWeaver MDM

Build Foundations for Continual Improvements

with SAP NetWeaver MDM


Contents at a Glance


The Importance of an EDM Strategy

... 31


Challenges and Approaches to Your EDM Strategy

... 61


The Strategic Role of Enterprise Data in an

Enterprise Service-Oriented Architecture

... 79


EDM Assessment Scorecard

... 103


Company Business Strategy Integration

... 121


Data Quality Management

... 169


Design: Data Architecture

... 223


Design: Data Standards

... 275


Governance Organization

... 305


Governance Processes

... 327


Realization: Deployment

... 349


Realization: Technology

... 385


Building an EDM Program

... 479


EDM for Materials

... 503


EDM for a Large ERP or Enterprise Application Project

... 527


Globalization Within an EDM Strategy

... 543


The Future of Enterprise Data Management

... 557



... 565



... 567



Acknowledgments ... 21

Preface ... 23



The Importance of an EDM Strategy ... 31

1.1 The Many Facets of Master Data ... 33

1.1.1 A Simple Definition ... 33

1.1.2 Principle or Primary Objects: SPACE ... 34

1.1.3 DNA of Decision Making ... 34

1.1.4 What Master Data Is Not ... 35

1.2 The Consequences of Haphazard Management of Enterprise Data ... 36

1.2.1 Lack of Accurate Knowledge of Your Own Business .... 37

1.2.2 Supply Chain and Internal Operational Inefficiencies ... 37

1.2.3 Cost Avoidance ... 38

1.2.4 Data Security Breaches ... 39

1.3 The History of Master Data ... 40

1.3.1 The Growth of Packaged Enterprise Applications ... 40

1.3.2 The Development of Component & Supplier Management (CSM) ... 40

1.3.3 The Push Toward Upgrades and Conversions for Y2K.... 41

1.3.4 The Rise of Master Data Management as a Function ... 41

1.3.5 Online Marketplaces, Catalog Management, Buy-Side, Sell-Side, and Maintenance Repair and Operations (MRO) Materials ... 42

1.3.6 The Post-Internet Commerce Boom ... 42

1.3.7 SAP’s Holistic Approach to Master Data Management (MDM) ... 43

1.3.8 Moving Forward to Enterprise Information Management (EIM) ... 44

1.4 Classification of Data ... 44

1.5 Master Data Versus Enterprise Data ... 46

1.6 EDM Scenarios ... 48

1.6.1 MDM IT Scenarios ... 48

1.6.2 MDM Business Scenarios ... 51



1.7 Joint ASUG\EDM Survey: The Need for a

Comprehensive Data Management Approach ... 55

1.8 EDM Framework ... 56

1.9 Summary ... 58


Challenges and Approaches to Your EDM Strategy ... 61

2.1 Factors to Consider When Developing an EDM Project ... 61

2.1.1 Project Design ... 62

2.1.2 Organization ... 62

2.1.3 Resource Constraints ... 63

2.1.4 External Drivers ... 64

2.2 Typical Approaches or Compelling Events ... 64

2.3 Common Pitfalls in EDM ... 66

2.3.1 Company Business Strategy Integration ... 67

2.3.2 Data Quality Management ... 69

2.3.3 Design: Data Architecture and Data Standards ... 71

2.3.4 Governance Organization and Governance Process ... 73

2.3.5 Realization: Deployment and Technology ... 74

2.4 Summary ... 76


The Strategic Role of Enterprise Data

in an Enterprise Service-Oriented Architecture ... 79

3.1 Benefits of Enterprise SOA ... 79

3.2 Basics of Enterprise SOA ... 81

3.3 Interaction of Enterprise SOA and Master Data ... 81

3.4 Basic Requirements for Enterprise Services ... 83

3.5 Business Objects in Enterprise SOA ... 85

3.6 Anatomy of an Enterprise Service ... 86

3.7 The Enterprise SOA Metamodel ... 87

3.8 GDTs in Enterprise SOA ... 93

3.9 Business Object Structures in Enterprise SOA ... 95

3.10 Other Critical Enterprise Data Issues ... 97

3.10.1 Decoupling Layers in Enterprise SOA ... 98

3.10.2 Increased Requirements for Business Object Design Governance ... 98

3.10.3 Designing Business Object States ... 99

3.10.4 System of Record (SOR) Management ... 99


3.11 Recommendations for Managing Enterprise Data in

Preparation for Enterprise SOA ... 100

3.12 Summary ... 102


EDM Assessment Scorecard ... 103

4.1 Assessment Benefits ... 103

4.1.1 General Benefits of an EDM Assessment ... 103

4.1.2 Benefits of Enterprise Application Implementation Projects ... 104

4.1.3 Benefits for Overall Corporate Knowledge and Enterprise Architecture ... 104

4.2 As-Is EDM Assessment Process ... 105

4.3 Preparing for the Assessment ... 106

4.3.1 Standard Interview Questions ... 106

4.3.2 Requests for Information ... 107

4.3.3 Cataloging Documents ... 108

4.3.4 Gathering Findings ... 109

4.3.5 General Guidelines on EDM Assessment Meetings... 110

4.3.6 Guidelines for Assessments ... 111

4.4 EDM Best Practices ... 112

4.5 Scoring Your Company Against EDM Strategy Best Practices ... 114

4.6 Sample Summary Results ... 115

4.7 Detailed Assessment Results ... 116

4.8 Summary ... 117



Company Business Strategy Integration ... 121

5.1 Company Business Strategy Basics ... 121

5.1.1 Corporate Strategy Inputs to an EDM Program... 122

5.1.2 Components of the Company Business Strategy Integration ... 123

5.2 The EDM Program Charter ... 123

5.2.1 Vision ... 125

5.2.2 Mission ... 125

5.2.3 Strategic Objectives ... 125

5.3 The EDM Program Business Case ... 126



5.3.2 Pain Points: Examples of Issues

for the Current Situation ... 129

5.3.3 Business Benefits in a Business Case ... 130

5.3.4 Qualitative Benefits ... 131

5.3.5 Quantitative Benefits ... 134

5.3.6 Building a Financial Model ... 139

5.3.7 Putting it Together: Building Your Story ... 145

5.4 EDM Program Design Guidelines ... 150

5.4.1 Sample Design Rules ... 151

5.4.2 Strategic Direction ... 153

5.4.3 Executive Intent ... 154

5.4.4 Principles to Determine Program Scope ... 154

5.4.5 Domain-Specific Guidelines ... 155

5.5 EDM Program Scope ... 156

5.5.1 Domains in Scope ... 157

5.5.2 Objects in Scope ... 157

5.5.3 Attributes in Scope ... 158

5.5.4 Other Scoping ... 158

5.5.5 Grouping Objects in Scope into Primary and Secondary Objects ... 159

5.6 EDM Program Policy ... 161

5.6.1 A Sample EDM Policy Guideline ... 161

5.6.2 Security and Compliance ... 166

5.6.3 Training and Awareness ... 167

5.7 Summary ... 167


Data Quality Management ... 169

6.1 Introduction to Six Sigma Quality Management ... 170

6.1.1 The Term Sigma in Statistics ... 170

6.1.2 The Six Sigma Quality Management Program Definition ... 171

6.1.3 Important Foundation Concepts for Six Sigma... 171

6.1.4 Five Standard Steps of Six Sigma ... 172

6.1.5 The Most-Used Tools Within a Six Sigma Quality Management Program ... 173

6.1.6 Classifying Data Quality Defects ... 174

6.2 The Elements of the Data Quality Management Dimension .... 175

6.3 Define ... 177

6.3.1 Leveraging Other Dimensions for the Define Component ... 177


6.3.3 Determining Good Data Quality Rules ... 180

6.3.4 General Requirements for Developing Metrics ... 181

6.3.5 Scoping: Selecting Where to Measure ... 183

6.4 Measure ... 187

6.4.1 Column Property Analysis ... 188

6.4.2 Data Profiling ... 189

6.4.3 Link to Data Standard ... 190

6.4.4 Data Analysis Test Plan ... 190

6.4.5 Testing General Rules ... 191

6.4.6 Testing Complex Rules ... 192

6.4.7 Testing Style Rules ... 192

6.5 Analyze ... 193

6.5.1 Data Quality Reports ... 193

6.5.2 Sample Data Quality Metrics ... 195

6.5.3 Relating Data Quality Metrics to Business Metrics... 202

6.5.4 Data Quality Scorecard ... 205

6.5.5 Tools for the Analyze Step for the Data Quality Management Program ... 209

6.5.6 Determining Where to Focus ... 210

6.5.7 Determining Root Causes ... 211

6.6 Improve ... 212

6.6.1 Steps Involved During the Improve Phase ... 212

6.6.2 Tools and Other Options to Fix Quality Defects ... 213

6.7 Control ... 214

6.7.1 Control for Common Issues ... 215

6.7.2 Understanding External Requirements and Regulations ... 216

6.7.3 Developing the Controls Framework ... 216

6.7.4 Determining Applicable Technology Controls ... 219

6.7.5 Identifying Additional Control Needs ... 220

6.7.6 Creating Plans to Address Control Needs ... 220

6.8 Summary ... 220


Design: Data Architecture ... 223

7.1 General Enterprise Architecture ... 223

7.1.1 Elements of All Enterprise Architectures ... 224

7.1.2 Common Enterprise Architecture Frameworks (EAFs).... 225

7.2 Components of the Data Architecture EDM Dimension ... 229

7.3 Business Process Integration ... 230



7.3.2 Creating and Maintaining

the Business Process Integration ... 235

7.4 Enterprise Data Distribution Approach ... 237

7.4.1 General Factors to Consider When Developing and Choosing an Enterprise Data Distribution Approach.... 242

7.4.2 Sample Specific Company Enterprise Data Distribution Approach Requirements ... 243

7.4.3 Other Technical Considerations ... 244

7.5 Enterprise Data Model ... 245

7.5.1 The Enterprise Data Model Structure ... 245

7.5.2 Data Domains, Attributes, Elements, and Values... 246

7.5.3 Business Value of the Enterprise Data Model ... 248

7.5.4 Existing Enterprise Conceptual Data Model ... 250

7.6 Logical Data Model (LDM) ... 252

7.6.1 Business Value of the Domain Logical Data Model... 254

7.6.2 Workforce Logical Data Modeling Process ... 255

7.6.3 Material Master for Parts Logical Data Model ... 259

7.7 Application Architecture ... 260

7.7.1 Assumptions ... 262

7.7.2 Example Company Vision for Workforce Management Master Data ... 263

7.7.3 Example Technical Releases for a Domain ... 264

7.7.4 Sample Workforce Management Application Architecture Project Releases ... 266

7.8 Source and Target Mapping Model ... 268

7.8.1 Business Value of Source and Target Mapping... 271

7.8.2 Alternative Source and Target Mapping Model formats ... 271

7.9 Summary ... 273


Design: Data Standards ... 275

8.1 The Concept of Global Data Types ... 275

8.2 Data Standards EDM Dimension Components ... 277

8.3 Business Object Definitions ... 278

8.3.1 Sample Format of the Business Object Definition ... 278

8.3.2 Using the Business Object Definition ... 280

8.4 Data Dictionary ... 280

8.4.1 Process to Develop Data Standards ... 281

8.4.2 Sample Data Standard Format ... 282

8.4.3 Data Dictionary from Standard SAP ... 283


8.5 Schema Standards ... 285

8.5.1 Schema or Hierarchy Basics ... 285

8.5.2 Defining Schema Standards in Relation to EDM ... 288

8.5.3 Schema Business Value ... 289

8.5.4 Sample Organization Schema Standard ... 290

8.5.5 Applying a Schema Strategy ... 296

8.6 System of Record (SOR) ... 297

8.6.1 Purpose of the SOR Component ... 297

8.6.2 Creating the SOR ... 298

8.6.3 Sample SOR ... 299

8.6.4 Recommended SORs for Schemas ... 301

8.6.5 Business Value of the SOR ... 303

8.7 Summary ... 303


Governance Organization ... 305

9.1 Organization Structure Concepts ... 305

9.1.1 SAP Organization Structure Terminology ... 305

9.1.2 Key Concepts of Organization Design ... 307

9.1.3 Considerations when Establishing a Governance Organization Structure ... 307

9.2 Components of the Governance Organization ... 308

9.3 Enterprise Data Governance Organization ... 310

9.3.1 Standard Enterprise Data Governance Organization Roles ... 310

9.3.2 Enterprise Data Governance Organization Structure .... 311

9.3.3 Enterprise Data Governance Position Descriptions ... 315

9.4 Business Data Organization ... 315

9.4.1 Business Data Organization Roles ... 317

9.4.2 Central versus Decentralized Business Data Organization Structure ... 318

9.4.3 Business Data Organization Structures ... 320

9.4.4 Business Data Organization Position Descriptions ... 324

9.5 Summary ... 324

10 Governance Processes ... 327

10.1 SAP Process Decomposition ... 327

10.2 EDM Governance Process Types ... 329

10.3 Business Data Processes ... 330



10.3.2 Examples of Business Data Processes ... 333

10.3.3 Additional Considerations for Business Data Processes ... 338

10.4 Enterprise Data Governance Processes ... 338

10.4.1 Standard EDM Services ... 339

10.4.2 Enterprise Data Governance Change Request Process ... 344

10.5 Summary ... 347

11 Realization: Deployment ... 349

11.1 EDM and ASAP Implementation Methodology ... 350

11.1.1 ASAP Basics ... 350

11.1.2 Typical Data Issues with ASAP Projects ... 350

11.2 Elements of the Deployment EDM Dimension ... 353

11.3 Change Management ... 354

11.3.1 Overview ... 354

11.3.2 A Model for Organization Transformation ... 355

11.3.3 Transforming the Organization ... 356

11.3.4 Suggestions for Creating and Communicating the Message ... 357

11.3.5 Relating Change Management to Your EDM Program ... 358

11.4 Standard Project Plans ... 359

11.4.1 EDM Strategy Development ... 359

11.4.2 MDM Tool Data Repository Implementation ... 360

11.4.3 MDM Roadmap Development Plan ... 361

11.4.4 Data Migration and Cleansing Implementation Plan.... 362

11.5 Data Migration and Cleansing ... 363

11.5.1 Common Terminology ... 363

11.5.2 Process Overview ... 365

11.5.3 Approach ... 366

11.5.4 Outsourcing versus In-House Data Migration and Cleansing ... 368

11.6 Managing EDM Data Design Documents ... 370

11.6.1 Design Document Style Guide ... 370

11.6.2 Design Document Repository in SAP Solution Manager ... 370

11.7 EDM-Related Business Standards ... 372

11.7.1 SAP Current Approach for Business Standards ... 373

11.7.2 Benefits and Business Value of Adopting Business Standards ... 373


11.8 Special Deployment Issues ... 374

11.8.1 Integration to Business Intelligence (BI) Strategy ... 374

11.8.2 Globalization ... 377

11.8.3 Regulatory Considerations ... 377

11.8.4 Security Plan Requirements ... 380

11.9 Summary ... 384

12 Realization: Technology ... 385

12.1 EDM Reference Technical Architecture ... 386

12.2 Components of the Realization: Technology EDM Dimension ... 388

12.3 EDM-Related Technology Functions Reference List ... 389

12.4 EDM-Related Applications Inventory ... 394

12.4.1 SAP ERP and Other Enterprise Applications ... 395

12.4.2 Reverse Business Engineer (RBE) ... 396

12.4.3 Legacy System Migration Workbench (LSMW) ... 398

12.4.4 SAP NetWeaver Process Integration (PI) ... 400

12.4.5 SAP Composition Environment (CE) ... 401

12.4.6 SAP Solution Manager ... 403

12.4.7 SAP NetWeaver System Landscape Directory (SLD)... 405

12.4.8 ARIS for NetWeaver and Other Enterprise Architecture Tools ... 407

12.4.9 SAP Solution Composer ... 410

12.4.10 Business Object Repository (BOR) Browser ... 412

12.4.11 Enterprise Services Workplace (ESW) ... 414

12.4.12 SAP NetWeaver Business Intelligence (BI) ... 415

12.4.13 SAP Enterprise Services Repository (ESR) ... 417

12.5 Data Profiling Requirements and Evaluation ... 419

12.5.1 Basic Features of a Data Profiling Tool ... 419

12.5.2 Standard Analyses for Data Profiling Tools ... 420

12.5.3 Analytical Methods for Data Profiling ... 421

12.5.4 SAP and Other Data Profiling Tools ... 422

12.6 EDR Requirements and Evaluation ... 422

12.6.1 General Capabilities Recommended for an SAP EDR ... 423

12.6.2 Capabilities Not Recommended for Use for the Company EDR ... 425

12.6.3 Important Factors to Consider When Developing and Choosing EDR Options ... 427

12.6.4 Standard Features of an EDR ... 428



12.7 SAP NetWeaver MDM Basics ... 433

12.7.1 Basic Modules of the SAP NetWeaver MDM Tool ... 434

12.7.2 EDR Specifically in SAP NetWeaver MDM ... 437

12.7.3 The MDM Console Main Functions ... 439

12.7.4 Functions of the MDM Repository ... 439

12.7.5 MDM Data Manager Modes ... 441

12.7.6 MDM Data Field Types ... 441

12.7.7 Basics of Taxonomies and Attributes ... 443

12.7.8 SAP NetWeaver MDM Repository Table Types ... 443

12.8 EDR Modeling Using an SAP NetWeaver MDM Repository .... 445

12.8.1 Designing LDMs with SAP NetWeaver MDM ... 446

12.8.2 Sample LDM Using SAP NetWeaver MDM ... 453

12.8.3 Checking Rules in SAP NetWeaver MDM: Validations ... 457

12.8.4 Designing a Taxonomy ... 458

12.8.5 Leveraging SAP-Supplied Repositories for ERP and Other Enterprise Application Integration ... 460

12.9 SAP NetWeaver MDM Advanced Technical Infrastructure Topics ... 464

12.9.1 Sizing SAP NetWeaver MDM ... 464

12.9.2 Master and Slave Repositories ... 465

12.9.3 Solution Landscape for SAP NetWeaver MDM ... 466

12.9.4 Building Workflow for SAP NetWeaver MDM Processes ... 469

12.9.5 SAP NetWeaver MDM Backups and Archiving ... 470

12.9.6 Portal Integration ... 471

12.9.7 SAP NetWeaver BI Integration ... 472

12.9.8 Users and Authorization ... 472

12.9.9 Collaboration Through Locking and Version Control.... 473

12.9.10 Security in SAP NetWeaver MDM ... 473

12.10 Technology Recommendations for EDM Dimensions and Components ... 475

12.11 Summary ... 475


13 Building an EDM Program ... 479

13.1 Common Approaches for EDM Projects ... 479

13.2 Beginning with the End in Mind ... 480


13.2.2 Expectations of an EDM Strategy Project ... 483

13.2.3 Enterprise-wide versus Domain-Specific Deliverables... 483

13.2.4 Sequence of Successive Projects to Achieve a Sustainable EDM Program ... 486

13.3 MDM Roadmap Program Plan ... 486

13.3.1 Project Team Organization ... 487

13.3.2 Project Roles and Responsibilities ... 488

13.3.3 Special Considerations for Project Deliverables ... 488

13.3.4 Watch Items ... 489

13.4 Independent EDM Strategy Projects ... 489

13.4.1 Project Team Organization ... 490

13.4.2 Project Roles and Responsibilities ... 491

13.4.3 Project Team Communications ... 492

13.4.4 Special Considerations for Deliverables ... 492

13.4.5 Watch Items ... 493

13.5 Support Large Enterprise Application Implementation ... 494

13.5.1 Project Team Organization ... 494

13.5.2 Project Roles and Responsibilities ... 495

13.5.3 Special Consideration for Deliverables in Blueprinting ... 496

13.5.4 Watch Items ... 496

13.6 Focused Internal Business Objective ... 497

13.6.1 Project Team Organization ... 497

13.6.2 Project Roles and Responsibilities ... 498

13.6.3 Special Considerations for Deliverables ... 499

13.6.4 Watch Items ... 499

13.7 Commercial Initiatives ... 500

13.7.1 Project Team Organization ... 500

13.7.2 Project Roles and Responsibilities ... 501

13.7.3 Special Considerations for Deliverables ... 501

13.7.4 Watch Items ... 501

13.8 Summary ... 501

14 EDM for Materials ... 503

14.1 Introduction to Direct Materials ... 504

14.1.1 Definition and Variants in Industry ... 504

14.1.2 Types of Direct Materials ... 504

14.1.3 Typical Products and Their Metrics ... 507



14.2 Major Roles in Direct Materials ... 508

14.3 Typical Product Development Process ... 510

14.4 General MRO Items versus Direct Materials ... 512

14.5 Defining World-Class Direct Materials Content ... 514

14.5.1 Required Content Features ... 514

14.5.2 Should Have Content Features ... 515

14.5.3 Nice to Have Content Features ... 516

14.6 Bottlenecks to Efficient Materials Management ... 517

14.6.1 Synchronizing Catalog Items to the Solid Model and to Specification Documents.... 517

14.6.2 Mapping Engineering Specifications to the Manufacturer and to the Supplier ... 518

14.6.3 Seamless Guided Searching from Individual out to Open Internet ... 519

14.6.4 Product Data Interoperability ... 520

14.6.5 Coordinating the Manufacturing and Design BOMs .... 521

14.6.6 Part Renumbering ... 522

14.6.7 Managing Direct Materials Data Structures ... 524

14.7 Summary ... 525

15 EDM for a Large ERP or Enterprise Application Project ... 527

15.1 Case Study Background Information ... 527

15.1.1 Case Study Company ... 527

15.1.2 Project Objective ... 528

15.1.3 EDM Involvement ... 528

15.2 ERP Project Organization ... 528

15.3 Interfacing with Vertical Workstreams ... 530

15.3.1 Vertical Workstream Coordinator Role ... 530

15.3.2 Information Collected by Vertical Workstream Coordinators ... 531

15.3.3 EDM Team Assignments: EDM Core Team to Vertical Workstreams ... 532

15.3.4 Responsibilities Between the Horizontal EDM Team and Vertical Workstreams ... 533

15.3.5 Involvement of Vertical Workstreams by Master Data Object ... 535

15.4 EDM Project Deliverables ... 536

15.4.1 Shared Deliverables ... 536

15.4.2 EDM Team Deliverables ... 537


15.5.1 Assumptions and Preparation ... 539

15.5.2 Grouping the ERP Implementation Workshops in Terms of EDM Impact ... 539

15.5.3 Mapping Deliverables to Cycles ... 540

15.6 Conclusion and Recommendations ... 541

15.7 Summary ... 542

16 Globalization Within an EDM Strategy ... 543

16.1 Issues to Consider ... 543

16.2 Types of Globalization Conversions ... 544

16.3 Language Master Data in SAP Applications ... 545

16.3.1 Attributes to Consider When Examining Globalization 545 16.3.2 Master Data Language Limitations in SAP tools... 546

16.3.3 Employee Master Data Example ... 546

16.3.4 Example of Language-Dependent Objects in SAP Applications ... 547

16.4 Typical Options for Globalization and Language ... 548

16.4.1 Best Practices for Localization ... 550

16.4.2 Globalization Strategy ... 551

16.5 Conclusion and General Recommendations ... 554

16.6 Summary ... 555

17 The Future of Enterprise Data Management ... 557

17.1 Business and Technology Drivers ... 557

17.2 Increased Mergers, Acquisitions, and Partnerships ... 558

17.3 Increased Scorecards and Metrics ... 558

17.4 Increased Awareness of the Impact of Data Quality ... 559

17.5 Enterprise Service-Oriented Architectures ... 559

17.6 Enterprise Architecture ... 560

17.7 Business Process Management (BPM) ... 561

17.8 Summary ... 561

Appendix ... 563

A References ... 565 B Glossary ... 567 C Author Biography ... 575 Index ... 577


Enterprise data is a critical foundation for mastering and scaling an enterprise service-oriented architecture (enterprise SOA). You must know a few key concepts to prepare for this future architecture.


The Strategic Role of Enterprise Data

in an Enterprise Service-Oriented


Well-managed enterprise data is critical to Service Oriented Architecture (SOA) strategies such as enterprise service-oriented architecture (enterprise SOA). In this chapter, we will briefly cover enterprise SOA and the following concepts that you must know to begin to prepare for enterprise SOA:

왘Enterprise Services basics focusing in on data

왘Anatomy of a business object (BO) for enterprise SOA

왘Importance of global data types

왘Other concepts, such as BO lifecycle status, and managing Systems of Record (SORs)

First, let’s examine the benefits of enterprise SOA, balancing the ability to be agile with continuous innovation while controlling costs.


Benefits of Enterprise SOA

The vision of enterprise SOA is to help your company both innovate and react quickly to market forces while still controlling costs. Traditional meth-ods provide many benefits, but to separate yourself from the competition in the future, you can take advantage of these benefits. Enterprise SOA is one way for you to achieve that goal for innovation, faster reaction time, and controlling technology costs. Figure 3.1 shows a general diagram of an enter-prise SOA application.


Figure 3.1 General Diagram of an Enterprise SOA Application

The following are some external drivers motivating companies like yours to pursue enterprise SOA:

왘Need to differentiate

To compete and remain profitable, competing on cost is not enough. You must continually differentiate your business by focusing on your core competencies.

왘Total customer offering requirement

Providing a standalone product is not enough. Customers require a total experience with your product, including services for the product. When Apple developed the iPod, they not only thought about the music player, but the entire value chain of services around it.

왘Information overload

You have a lot of data in your company. It is important to aggregate disparate information and to be able find the right information to determine trends and react more quickly.

Legacy 3rd Legacy 3rd Party SAP NetWeaver Business Process Platform

Platform Process Components

Platform Process Components Composite Applications

PartnerPartner SAPSAP

SAP R/3 SAP R/3 Enterprise Services Repository Analytics


Interaction of Enterprise SOA and Master Data 3.3

왘Growing domestic and international regulatory compliance mandates

Businesses must increasingly meet additional regulations for security, pri-vacy, and financial practices. In addition to meeting the standards, you must prove how you derived the results and that you provide controls to ensure that you will meet the standards going forward.

These are some of the business pressures and opportunities that a company must face. Enterprise SOA provides tools and techniques to respond to those challenges while keeping costs under control.


Basics of Enterprise SOA

Enterprise SOA is how SAP does Web services. SAP has designed enterprise SOA to be compatible with the industry SOA standards, but went beyond this to develop an architecture that allows you to leverage your existing infrastructure and allows you to truly scale SOA in an orderly way. Figure 3.2 illustrates business process management with enterprise SOA.

Enterprise SOA is a standard SOA architecture with Enterprise Services rather than just building Web services from the ground up. Also, enterprise SOA is designed to leverage complex landscapes with a mix of packaged applications, internally developed applications, and Enterprise Services.


Interaction of Enterprise SOA and Master Data

By referring to the simple model of enterprise SOA shown in Figure 3.3 you can see the increased requirements for harmonized master data. Enterprise data needs to be shared across applications and Enterprise Services. In addi-tion, scaling enterprise SOA requires a logical and even possibly physical decoupling of master data from the applications. Referring to Figure 3.3, you can see one landscape comprised of two applications. One business scenario crosses the two applications and transactions or business documents are being passed from one application to another.

For the business documents or transactions to be understood or have proper context, the master data in both systems must be semantically and possibly even structurally equivalent. As a result, the master data in both applications must be harmonized. It is even more efficient if there is just one SOR for each master data BO. This single SOR is preferred for all business data objects.


Figure 3.2 Business Process Management with Enterprise SOA Compose and Orchestrate Manage and Optimize Integrate and Deploy Model and Build Analyze and Discover Enterprise Service Repository 1 2 3 4 5 1 2 3 4 5

• Analyze business requirements • Identify needed business objects, services, and views

• Discover available enterprise services in ESR for reuse

• Identify missing services for new business logic

• Compose views by reusing implemented services and BOs • Compose and orchestrate services and views to form new business process

• Manage change & maintain version (governance)

• Monitor service execution (e.g. performance, availability, process progress, events) • Design and model business objects (BOs) • Implement new business logic

• Model and build UIs

• Create new services reusing existing assets and publish to ESR

• Package and deploy application • Configure runtime

(adapt to IT landscape) • Test and validate application • Execute application


Basic Requirements for Enterprise Services 3.4

By decoupling the applications from the BOs, you can manage the master data and their metadata centrally. With the addition of Enterprise Services, this requirement for standardized master data and enterprise data is even more imperative.

Figure 3.3 One Scenario, Two Applications, and Master Data in Enterprise SOA


Basic Requirements for Enterprise Services

Enterprise Services are Web services with an enterprise-level business value. They are a combination of single Web services combined with business logic. In contrast, Web services are used mainly to work with specific pieces of functionality. The following are a few of examples of possible Enterprise Services for Sales Order Processing:

왘Read sales order item

왘Create sales order

왘Change sales order

왘Find sales order by buyer and basic data

From a business perspective, “order cancellation” is represented as a Web serv-ice, which we call an “Enterprise Service" in the context of enterprise SOA.

System Landscape

System A

System A System B

System B

Business scenario

A business scenario is represented as a flow of business documents (transactional data)

Many business documents reference master data Business scenarios that are carried out beyond system boundaries need to reference the same master data representations through the process


SAP’s literature for enterprise SOA provides the following explanation and descriptions for Enterprise Services:

Enterprise Services have all of the characteristics of Web services plus addi-tional requirements, and the following characteristics differentiate Enter-prise Services from regular Web services:

왘Business semantics

Enterprise Services are structured according to a harmonized enterprise model based on process components, BOs and global data types (GDTs). Quality and stability: Enterprise Services ensure a stable interface for future versions, providing backward compatibility. Their behavior, pre-requisites, dependencies of usage, and configuration possibilities are well documented.


Enterprise services are based on open standards. The interfaces are described according to the Web Services Description Language (WSDL). WSDL is the industry standard for defining Web services. They are created by using GDTs, which are based on the United Nations CEFACT standards organization Core Component Technical Specification (CCTS) standard. SAP literature recommends that large enterprise customers adopt the current release of the SAP ECC ERP application. Midsize customers should start with an SAP All-in-One solution. The SAP NetWeaver platform powers both solu-tions.

An enterprise SOA-compatible landscape enables customers to extend their business solutions quickly and easily to meet their unique needs. Customers will still rely on the existing and stable functionality provided by SAP solutions. To fulfill a specific industry requirement or business need, you could take advantage of Enterprise Services provided by SAP or strategic business part-ners through the Enterprise Services Workplace (ESW), as shown in Figure 3.4. With these Enterprise Services, customers can rapidly enhance their existing business processes or develop and deploy new applications to handle specific business processes. This extends and increases the value of SAP solutions. An example of packages of Enterprise Services is the electronic bill present-ment and paypresent-ment (EBPP) Enterprise Services bundle. It bundles Enterprise Services that support authorization with settlement processes that are used to communicate with credit card processors. Any company that handles busi-ness-to-consumer interactions that require credit card authorization and pay-ments can take advantage of these Enterprise Services.


Business Objects in Enterprise SOA 3.5

Figure 3.4 Discovering Enterprise Services in the Enterprise Services Workplace (ESW)


Business Objects in Enterprise SOA

In enterprise SOA, a BO represents a specific view on well-defined business content. This business content is generally accepted and well known in the business world. At the highest level in enterprise SOA, BOs are classified into two groups:

For More Information

If you are an SAP customer, you can find information about service-enabled sce-narios on the ESW and on an interactive Wiki, which are both hosted on SDN (www.sdn.sap.com). For more information on ESW, see “What Is ES Workplace?” General information about service-enabled scenarios is available on the Enterprise Services Wiki (www.sdn.sap.com/irj/sdn/share-bp), along with detailed documen-tation of the services offered for specific scenarios. Because the Enterprise Services Wiki allows users to add and edit content collectively, it promotes content sharing among a community of SAP developers, customers, and partners using Enterprise Services to integrate, compose, and deploy applications.

Enterprise Architect


Business Process Expert

Applications, e.g. Enhancement Packages

for SAP ERP ECC Hosted System on SDN ESR E S Workplac e •ES Packages •Enterprise Services •Education


왘Business Process Objects (BPOs) Transactional BOs (time point related).

왘Master Data Objects (MDOs)

BOs with mainly master data character (time span related).

BO definitions are driven by business relevance. BOs are defined, and stored in the Enterprise Services Repository (ESR), and implemented free of redun-dancies. BO governance process, guidelines, and rules are defined in the ESR. Examples of BOs include sales order, supplier invoice, or outbound delivery. Internal application system tables are not considered BOs. Now, let’s examine the structure of an Enterprise Service, focusing on the enter-prise data or BOs.


Anatomy of an Enterprise Service

All Enterprise Services have a standard repeatable pattern or structure. This pattern or structure supports uniformity and a foundation for governance. Following are the standard rules that govern all Enterprise Services:

왘BO encapsulation

A BO is defined only once. Also, there is no duplication of BOs.

왘BO relationship to process components

A process component contains a set of semantically related BOs.

왘Integration scenarios

Integration scenarios model the interaction between process components.

왘Service operation

A service operation belongs to exactly one BO. One BO has multiple oper-ations.

왘Service interface

A service interface groups service operations together.

왘Global data type (GDT)

GDTs are reusable elements stored in a common dictionary. Several GDTs form message types.

An Enterprise Service is a callable entity that provides business functionality and is published by SAP in the ESR. Enterprise Services are structured according to a harmonized enterprise model based on GDTs, process compo-nents, and BOs. They are well documented, guarantee quality and stability, and are based on open standards. The following are additional requirements for an Enterprise Service over a Web service:


The Enterprise SOA Metamodel 3.7

왘Structured according to harmonized enterprise model (process compo-nents, BOs, interface patterns, and GDTs)

왘Published in the ESR

왘Guaranteed interface stability

왘Well-documented contract and behavior

왘Based on open standards (WSDL, XML, SOAP, and so on)

Additional usability requirements should be available for Enterprise Services:

왘Easy to discover (have a harmonized classification scheme)

왘Easy to understand (business language)

왘Easy to invoke (based on open standards)

왘Have a stable interface and stable behavior (well-defined lifecycle) Common guidelines and patterns for modeling and implementation of Enterprise Services make life easier for service consumers, such as business process experts, when they may be designing a new business process for your company. SAP has already put many product and process standards into place that also apply to Enterprise Services.

For Enterprise Services, additional design guidelines and patterns exist on different levels, as follows:

왘Map of process components and BOs

왘Well-defined service interfaces and service operations per BO

왘Structure of message types (signature of service operations)

왘Common set of reusable data types

왘Transactional behavior at runtime

왘Service implementation (business application code)

Now that you have seen the characteristics of Enterprise Services, let’s look at the pattern or metamodel of enterprise SOA. This describes how Enter-prise Services and enterEnter-prise data work within enterEnter-prise SOA.


The Enterprise SOA Metamodel

The enterprise SOA metamodel is the consistent relationship or pattern of processes, services, and BOs. BOs are at the heart of this model. You should also understand several other key entities so that you can grasp the standard


pattern of enterprise SOA, and, as a result, the impact of BOs on enterprise SOA. They include service operations, service interfaces, process compo-nents, and BOs, as shown in Figure 3.5.

Figure 3.5 The Enterprise SOA Metamodel

Service operations logically belong to service interfaces, and service inter-faces belong to process components. Service interinter-faces adhere to a certain pattern, which makes it more intuitive to quickly find and identify Enter-prise Services. A manage-type interface typically incorporates create, read, update and delete types of service operations. For instance, the Create Sales Order service operation belongs to the Manage Sales Order service interface, and the Manage Sales Order service interface belongs to the Sales Order Processing process component.

Modular, context independent, reusable pieces of software that expose their functionalities as services. Contains, at least,one business object. Business Object Model 1 1..* 0..1 0..1 1..* 1..* 1 1..* * 1..* * 1 references * 1

Service Description based on WSDL & XSD

e.g. Sales Price Information Service Service Interface Operation Data Type (Message Type) Definition: XML Schema

Global Data Types Process


Process Component e.g. Price Master

Data Management

Specific view on well-defined and outlined business content.


The Enterprise SOA Metamodel 3.7

As a result, the navigation hierarchy is as follows:

왘Process components have one or more service interfaces

왘Service interfaces have one or more service operations

In enterprise SOA, an application has a logical decomposition to logical deployment units to process components to BOs with service interfaces and service interfaces to service operations, as illustrated in Figure 3.6. Let’s look in more detail at the concept of logical deployment units.

Figure 3.6 Basic Entities of an Application

Logical Deployment Units

A logical deployment unit is a set of process components that can be operated on a separate system, isolated from other process components. Important things to know about deployment units include the following:

왘Different deployment units can be instantiated on different physical systems.

왘The deployment unit is not equivalent to the installable entity, which can be broader.


Due Item Processing Due Payment approved Trade Receivables Payables... approved Due Clearing approved VAT Declaration new Trade Receivables Payables... approved

Due Item Processing

Due Payment approved Trade Receivables Payables... approved Due Clearing approved VAT Declaration new Trade Receivables Payables... approved Due Payment Trade Receivables Payables... Due Clearing VAT Declaration Trade Receivables Payables... Process component –level two (drilldown in detailed model) Business object – level three Deployment unit – level one


왘With regard to characteristics, in a given customer landscape, the follow-ing can be true about a deployment unit:

왘Other software can replace a deployment unit.

왘A deployment unit can run in multiple instances and can be connected to multiple instances of other logical deployment units.

왘A deployment unit can be ignored in an application configuration (if inactive in the current system).

Process Components

Process components can be seen as the building blocks of each enterprise SOA solution. They are modular, context independent, reusable pieces of software that expose their functionalities as services (see Figure 3.7). A proc-ess component contains at least one BO.

Figure 3.7 Drilling Down on the Details of a Process Component

derived from derived from Message Type Supplier Invoice Cancellation Execution Request Accounting Cancellation Request Invoice

Supplier Invoice Processing Supplier Invoice Create Supplier Invoice Supplier_Invoicing_In Cancel Supplier Invoice Global Data Types Service Interface Business Object Process Component Service Operation Message Type


The Enterprise SOA Metamodel 3.7

The following are typical characteristics of process components:

왘Structuring and modeling constructs

왘Not tangible entities in the development environment

왘Group of BOs at the granularity of a business process to be used as a reuse element in integration scenarios

왘Fit into a typical customer organization

왘Belong to exactly one deployment unit (discussed in more detail in the next section)


BOs are logical objects of significance to the business. They represent a class of entities with common characteristics and common behaviors describing well-defined business semantics. BOs are used to model a business process, for example, sales order. The following are characteristics of BOs:

왘BOs represent a specific view of well-defined and outlined business content.

왘The BO definition is driven by business relevance and SAP experience.

왘BO guidelines and rules are defined, including the following key types of BOs:

왘BO purchase order

왘BO template: maximal template of product with all attributes, unavail-able for use in the Logical Deployment Unit (LDU)

왘Dependent object: substructure of BO to be reused in another BO address

왘Business foundation object: BO in foundation layer and business partner

왘BO identification and all BO models and data types run through a govern-ance process, including review, final approval, and released documenta-tion

왘BOs are encapsulated by a process component. In an application, a BO is defined only once in one process component. A process component can define one or more BOs.


Service Interfaces

A service interface is a named grouping of operations. The service interface patterns commonly used are Read, Create, Update, Manage, and Delete.

Service Operations

The highest granularity of an entity type is the service operation. When it comes to the implementation of a composite application, the business proc-ess expert or the software architect should have the desired single Enterprise Service operations and the orchestration in mind. This is where the devel-oper needs detailed technical information to orchestrate and compose the Enterprise Services.

You can browse the ESW to help you find a particular service operation. To do so, find and display the WSDL for a particular service operation, for our example, the Create Sales Order service operation. From the list of the proc-ess components in ERP, select the Sales Order Procproc-essing procproc-ess compo-nent. This results in a list of Enterprise Service interfaces that support this process component.

Global Data Type (GDT)

A GDT is an SAP system-wide defined data type with meaning, structure, and values oriented on industry standards, where available. Referring to the enterprise SOA metamodel shown in Figure 3.8, you can see how process components, service interfaces, service operations, and GDTs are related. Let’s now look at GDTs, and later on BOs, in more detail with reference to enterprise SOA.


In contrast to the general notion of “object” in an object-oriented sense, the term “business object” is used here to describe the type and not the instance level. Con-sequently, the BO sales order, for example, describes the category of all sales orders and not a single sales order instance.


GDTs in Enterprise SOA 3.8

Figure 3.8 Enterprise SOA Metamodel Defining Entities and Relationships


GDTs in Enterprise SOA

As mentioned previously, GDTs are SAP system-wide defined data types with business content. They are defined in accordance to industry standards and offer customers a way to use one common data structure. Figure 3.9 shows an example of a GDT. GDTs are elemental data structures that are used to build up more complex BOs. For the example, there is at SAP-defined GDT called Price, which is an extension of the CCTS Core Data Type of Currency. Finally, the Currency Core Data Type references the Primitive Data Type for a float real number.

The following are standard characteristics for GDTs in enterprise SOA:

왘Conform to the following open standards: ISO 15000-5 and UN/CEFACT CCTS

왘Defined in the ESR

왘SAP sytem-wide approved with reference to the governance process for Process Integration Content (SAP PIC Process)

approved Credit Management approved Credit Management approved Credit Management Credit Management Account approved Credit Agency Identifier Credit Agency Report approved Credit Management Account approved Credit Agency Identifier Credit Agency Report approved Deployment unit Process component

Business object model Drilldown from

BO map to BO model

Business object


왘Semantic building blocks for service definition and interfaces for reuse

왘ESR-provided functionality to define CCTS data types to allow for cus-tomer-specific GDTs or to extend or adapt SAP’s GDTs

Figure 3.9 Example of a GDT

UN/CEFACT CCTS, shown in Figure 3.10, is a methodology for developing a common set of semantic building blocks that represents the general types of business data in use today.

At SAP, a governance process driven by the Process Integration Content (PIC) methodology assures that GDTs have the following characteristics:

왘High quality

왘Standardized across all application areas

왘Designed for reuse

왘Tailored to comply with open business standards

Technically, a GDT is an aggregated data type, which consists either of other aggregated GDTs or of so-called core data types — the smallest unit of this type of modeling approach. Currently, more than 20 core data types are defined. The following two are the most prominent:


Represents a definitive value, a method or a property description in an abbreviated or language-independent form. The possible values are defined by a code list. Examples are currency code or country code.


Represents BO node instances. The possible values are given by keys of BO node instances.

From primitive GDTs, you will build up more complex BO data structures.

1 1..*

1 1..* 1..*1 Global Data Type (SAP)

Core Data Type (CCTS) Primitive Data Type (XSD) Example: Price Example: Currency

Example: float, string, token, binary


Business Object Structures in Enterprise SOA 3.9

Figure 3.10 Detailed Data Model for the UN/CEFACT CCTS GDTs


Business Object Structures in Enterprise SOA

BOs are the primary structuring elements of enterprise applications, provid-ing the major portion of application business logic. Although there are exceptions (technical objects such as Workflow Item, for instance), a BO is commonly understood to be an independently viable business entity with unique, identifiable instances. This entity includes state and behavior and is accessible from other BOs or service implementations exclusively through its core services. • PurchaseOrder 1 n n 1 n 1 n 1 n n 1 1 n 1 • PurchaseOrderParty • PurchaseOrder DeliveryTerms • Amount • Binary Object • Code • Date Time • Identifier • Indicator • Measure • Numeric • Quantity • Text • PurchaseOrderParty Elements • PurchaseOrder DeliveryTerms Elements • PurchaseOrdering_In • PurchaseOrdering_Out • PurchaseOrderRequest • PurchaseOrder ChangeRequest • PurchaseOrderMessage • Invoice Message • Delivery Terms • Address • ProductID • float • string Business Semantics no Business Semantics Usage specific global Semantic Structure Data Typing B2B / A2A - Interface / Service Operation Message Type B2B / A2A -Message Data Type Business Object Business Object Node Node Data Type

Global Data Type

CCTS Core Data Type


BO nodes can also have additional identifiers called alternative keys. Alterna-tive keys are defined by data structures included in the elements data type of the BO node. Alternative keys can be used to create foreign key associations between BOs. The underlying elements data type of a BO node is not permit-ted to be arbitrarily complex. It must be essentially flat, which means it can-not contain table-like substructures. This ensures that the BO node’s set of attributes can always be mapped to a structure composed solely of scalar data types.

More complex BO structures may be constructed using the composition mechanism for BO nodes as shown in Figure 3.11. A BO’s tree of nodes is defined in ESR by compositional associations (compositions for short) between the respective parent and child nodes. In Figure 3.11, SalesOrder-Item is a child node of SalesOrder. A compositional association represents a strong semantic relationship: One or more instances of the child node depend on the existence of one instance of the parent node. One instance of a parent node may have zero, one, or multiple associated instances of a cor-responding child node.

In general, semantic relationships between BO nodes are defined in the Enter-prise Services Inventory (ESI) by unidirectional, binary, named associations. Inside a BO, an arbitrary number of associations between the different nodes are possible in addition to the (BO internal) compositional associations, which must be present to build the BO’s tree of nodes. Relations between different BOs can be established only on the node level and only by using associations between their nodes as shown in Figure 3.11. Very often, an association between nodes is a “foreign key relation” in the sense that one or more attributes of the source node completely identify the associated target node instances. ESR offers corresponding modeling and execution capabilities.


The Enterprise Services Inventory (ESI) is object-based, not object-oriented. ESI is a directory that will contain all of the Enterprise Services and variants for use in your company. It deals with the concepts of BOs, nodes, and instances but does not represent these concepts in a one-to-one correspondence with object-ori-ented classes and instances. As a result, not all object-oriobject-ori-ented concepts are avail-able within ESI; for example, inheritance is not availavail-able.

In ESI, a BO is defined as a tree of BO nodes with a single root node. Each node is structurally defined by one underlying GDT, the so-called elements data type. BO nodes and their corresponding elements data type are depicted as identical enti-ties because this more closely reflects the common understanding. Each BO node implicitly inherits one technical identifier represented by the generic GDT NodeID.


Other Critical Enterprise Data Issues 3.10

Figure 3.11 Conceptual Version of BO Nodes

Now that you understand the general principles of BOs, the following sec-tion focuses on other critical enterprise data issues for enterprise SOA.


Other Critical Enterprise Data Issues

Additional challenges remain with respect to managing enterprise data for enterprise SOA. They are important, even if you choose to not implement a SOA strategy such as enterprise SOA. They become critical as you try to scale enterprise SOA and extract the business benefits from enterprise SOA. The challenges include the following:

왘Decoupling layers in enterprise SOA

왘Increased requirements for enterprise SOA-specific BO governance

왘Management of BO states

왘SOR management

왘Metadata management

First, let’s start with the requirement for decoupling the layers in enterprise SOA and how that affects the design of enterprise data, such as BOs.

Material Customer Invoice ItemItem

Customer Party Taxation Terms Product BO Material BO CustomerInvoice Service Product BO Service Customer BO Customer

Each business object is modeled as a hierarchical structure of nodes and each business object node is made up of data fields.


3.10.1 Decoupling Layers in Enterprise SOA

A major benefit of enterprise SOA is decoupling the layers. BOs are one of the most important layers to manage. Generally, as you move farther down the architecture, the dependencies grow, and changes are much more criti-cal. Changes to BOs have a lot of leverage to services, applications, and even-tually processes and UI Workcenters.

You must design each layer horizontally, based on Figure 3.12. In addition, you must look at supported scenarios that cut across the layers vertically. Any potential design change must be weighed against its impact on existing entities on each layer, especially impacts on the BOs.

Figure 3.12 Standard Decoupled Layers in Enterprise SOA

3.10.2 Increased Requirements for Business Object

Design Governance

SAP has designed a process to determine impacts on the BOs when designing Enterprise Services called the Process Integration Content (PIC) process. PIC is the main process for the design and governance of Enterprise Services.

Services Services Services

CRM BW ERP UI UI Workcenter Composite Process Actions Exchange Infrastructure Service Enablement Systems Services Actions Role 1 Role 2 BA CK EN D COMPOSITE A PPLIC A TI O N

Step 1 Step 2 Step 3 Step 4

Action -UI BO model DB DB DB Database UI Business Objects, Services Remote Services Local Services Business Objects Local Remote


Other Critical Enterprise Data Issues 3.10

The four steps for the PIC process are PIC 0, PIC 1, PIC 2, and PIC 3, as shown in Figure 3.13. The first step, PIC 0, is the most critical scoping impact step to semantically harmonize the BOs for the new or modified Enterprise Service. As you can see, the rest of the steps in the PIC process center around the design of the BO nodes, GDTs within the BO node diagram, and finally the service operations and messages data types that are used to access the BOs within the process components. Next, let’s look at designing BO states, SOR management, and managing metadata.

Figure 3.13 Summary of the SAP PIC Method for Enterprise SOA BO Design

3.10.3 Designing Business Object States

Managing the lifecycle states of the enterprise BOs is important. By clearly defining the BO states, tracking process sequence is less important. Defining the states and their links across domains, such as sales, design, manufactur-ing, and so on, is important as well. Figure 3.14 shows the lifecycle of a material including the services and when they are available for that BO. At each of the points where services are available there are major state changes for the material.

3.10.4 System of Record (SOR) Management

The ESR may help with this challenge. You need to track the preferred SOR or main reference location for the BOs.

3.10.5 Managing Metadata

Metadata needs to be managed so that it is readily accessible and uniform across the enterprise. There are many types of metadata, such as attribute

“ How to ” guidelines PIC 0: Business Objects and Operations Identification

Semantically harmonized definitions cross solutions GDT: Node Structure for Business Objects

Node Elements (referring to Global Data Types) Final Definition for Business Objects and Service Interfaces/Operations

Detailed signature definition containing all elements and integrity constraints

Global Data Types Name, Definition, Structure,Value Ranges Pic 1 Pic 2 Pic 3


definitions, business rules, service definitions, schemas, mappings, and so on. Reusability of Enterprise Services and BOs will rely on standardized metadata.

These are just a few additional enterprise data issues that you should con-sider as you prepare your company for enterprise SOA.

Figure 3.14 Sample Lifecycle of a Material


Recommendations for Managing Enterprise Data in

Preparation for Enterprise SOA

As you have seen, BOs are at the heart of enterprise SOA. The enterprise SOA metamodel and process components are designed to manage BOs. These BOs are constructed using GDTs or standard definitions for the elements within the BO for attributes, such as a date, purchase order ID, or address. These GDTs are used in one or more BOs and messages used to access these BOs. As a result, when you are developing an EDM Program, you should consider the following to lay a foundation for future enterprise SOA:


Pre-Launch Inactive

Growth Maturity • Reuse & Subscribe

• Reliability & Testing • Find Replacements • Find Other Sources • Mfg Part Change Notices

• Where Used Analysis • BOM Validation • End of Life Predictability • DFM-Reengineering • Regenotiate

• Synchronize Part Data with ERP • Synchronize Part Data with PLM • View Comprehensive Part History • Maintain Available to Purchase Catalogs

• User Searches

• Maintain Approved Supplies • New Part Introduction • Define Specification • Request and Evaluate • Issue Intern. Part Number • Design Buy • Build\Acquire Math Model • HTS Compliance • EH&S Compliance • Approval • Tracking • On-Going Reporting • Preference Management • Engineering • Procurement • Spend Analysis • End of Life Mgmt. • EOL Notices • EOL Buy • Final Inventory • Int. Channel Mgmt. • In-Service Management • Tracking • Field Notices • Maintenance\Replacement Lifespan of Services

Change of Object State


Recommendations for Managing Enterprise Data in Preparation for Enterprise SOA 3.11

왘Architect each type or domain of enterprise data independently.

Each domain will have different business requirements, application land-scapes, and data flow diagrams. Try to have a preferred method for the creation and distribution of enterprise data, but be prepared to pragmati-cally design each differently.

왘Continually decouple enterprise data from applications.

Enterprise SOA and other SOA strategies take advantage of the loose cou-pling of the layers. Loose coucou-pling of BOs will be important to scaling and leveraging the business benefits of enterprise SOA.

왘Start to introduce BO node diagrams when modeling BOs.

Using some form of entity relationship diagramming is common when modeling your enterprise data objects. Start to introduce and design your Logical Data Models (LDMs) using the BO node diagrams as defined in the UN\CEFACT standard.

왘Start to track the SOR for enterprise data BOs.

Begin to think about what it would take to track the SOR for all BOs. New tools like the ESR along with SAP NetWeaver MDM may help with this.

왘Enterprise BO states are more important than before.

For enterprise data objects, design the object states. Especially include the object states across domains and how they are linked together. To main-tain flexibility in Enterprise Services, BO actions and states must be clearly defined. By defining states, process sequence tracking becomes less important or rarely necessary. Start to use diagramming such as UML (Unified Modeling Language) object state diagrams.

왘Strategy drives process and process drives enterprise data.

Focus on enterprise data that has the most impact for your company busi-ness strategy. This company busibusi-ness strategy will drive requirements for business processes and Enterprise Services. The selection of Enteprise Services will require that you design the related BOs.

왘Resist the desire to create one repository for all metadata.

Metadata is more important, including metadata for BO definitions, serv-Exception to the Rule of Process Drives Data Requirements

The exception to the rule is when you are using EDM as “triage” to begin to align business processes, or when you have many business process variants so that it is difficult to come up with one set of global processes. Aligning the enterprise data will help you begin to align those business processes without having to standardize on one process.


ices definitions, reference data definitions, business rules, and others. Each class of metadata is logically maintained in an associated repository. SAP NetWeaver MDM, ESR, SAP NetWeaver XI, and others are used to maintain that metadata. When trying to aggregate all metadata, you lose the business or technical context of the metadata.



This chapter provided you with a brief explanation of enterprise SOA and the issues around enterprise data that you should consider to prepare your company for this future architecture. Preparing for enterprise SOA is espe-cially important if your EDM Program is partially supported.

Now that we have looked into the future requirements for your enterprise data, let’s get back to your immediate needs to build a business case for EDM. In Chapter 4, you will see the components of a business case, includ-ing many EDM examples.


This chapter is not meant to replace detailed design text on enterprise SOA. You need to learn many more details to fully understand enterprise SOA. Refer to




A2i 43 ABAP 398 Accelerated SAP 349 ACORD 373 Ad-hoc reporting 390 Aerospace and Defense 503 AIAG 373

Alternative keys 96

Application Architecture 229, 260, 423 Application-to-application data delivery


Approved Vendor List 524

ARIS for NetWeaver 236, 390, 391, 393, 407 ASAP 494, 496, 527 Blueprint phase 539 Blueprint workshops 539 Data issues 350 Project 372 Aspect development 41 Assertion testing 421 ASUG\EDM survey 103, 559 Attributes versus fields 449 Automotive 503


BAPI 398, 412 Basics of taxonomy 443 Batch profiling 419

Benchmarking study metrics 138 BI 415

Bill of Materials (BOM) 506, 521 BPM 561

Business case 127

Case studies 139

Management 390

Business Data Organization 309, 315, 495

Centralized versus decentralized 318

Positions 324

Roles 317

Structure 320

Variant scenarios 321

Business data processes 230, 330, 470, 495

Examples 333 Business driver 557

Business Intelligence strategy 374 Business logic 426 Business maps 410 Business object 85, 91, 95, 278, 559 Design governance 98 Encapsulation 86 Lifecycle 559 Models 415 Node diagram 99, 101 Nodes 96 States 99 Structures 95 Template 91

Business object definition 277, 278

How to use 280

Sample format 278

Business Object Repository (BOR) 412

Browser 412 Business process

Management 230, 561

Objects 86

Repository 404

Business Process Integration 229

Uses 234

Business scenario 328

Group 328

Maps 410

Business strategy 32, 560

Business strategy integration 57, 67, 390, 482

Components 123


CAD 40, 520 Cadis 41


Catalog search 429

Catalog search functionality 392 CCTS 84, 93 CE 401 CEFACT 84 Central MDM 467 Change management 353, 354 Chemicals 503 CIDX 373 Classification 363, 438 Classification of data 44 Cleansing 363 Client system 458 COBIT 216

Column Property Analysis 396, 420 Common Information Model 405 Company business strategy

Basics 121

Integration 121 Compelling events 486 Complex configured items 506 Complex Data Rule Analysis 421 Complex entities 159, 423

Component & Supplier Management 41 Composite Application Framework 401 Conditional master data 396, 452 Configuration data 45 Configured-to-order 504, 505 Consolidated MDM 467 Consumer products 503 Control Chart 173 Control objectives 217 Controls Access 219 Configuration 219 Monitoring 220 Procedural 220

Core Component Technical Specifica-tion 84, 275, 373

Core Data Type 93 Cost avoidance 36 Cost containment 497 Cost of goods sold 504 Cross-functional team 494, 498 Cross-Industry Solution Maps 410 CRUD Matrix 230

CSM 41

Customer data integration 53, 500


DARPA RaDEO 508 Data Acquisition 415 Architecture 58, 71, 482, 501 Attributes 246 Champion 164

Cleansing and harmonization 392

Custodian 165 Distribution 416 Domains 246, 248 Elements 247 Entities 246 Fields 247 Governance processes 425 Mart 393 Modeling 391, 415 Owner 165 Pool 52 Profiling 189, 388, 390, 419 Schematic 272 Subject area 246 Sub-subject area 246 Values 247 Data analysis 184 Complex rules 192 test plan 190 Data defects 174 Defect 174 Error 174 Mistake 174 Released defect 174 Data Dictionary 277, 280, 496 How to use 285

Data Migration and Cleansing 76, 353, 363

Factors to consider 368

Outsourcing versus in-house 368

Process overview 365 Data quality 32 Accessibility 179 Accuracy 178 Availability 179 Committee chair 164 Completeness 178 Consistency 179 Coverage 178



Duplicates 179

Guidelines for rules 180

Integrity 178 Metrics 181 Redundancy 179 Relevance 179 Secure 178 Timeliness 178 Validity 178

Data quality management 57, 69, 169, 390, 482, 489

Determining root causes 211

Tools to fix quality defects 213 Data quality management program

Analysis tools 209

Where to focus 210 Data Quality Scorecard 205 Data Readiness Report 197 Data security 380 Breaches 37 Plan 382 Data Standards 58, 71, 275, 482, 501 Components 277 Management 390

Data, document, record, and application archiving 393

Decoupled layers in enterprise SOA 98 Decoupling 81

Dependent object 91 Deployment 58, 74 Design BOMs 525

Design document repository 370 Design document style guide 370 Design Engineer 509

Direct materials 503, 504

Roles 508 Discovery 421

Document management 390 Domain Data Model 251 Domains 34 Downgrade 365


EDM Best Practices 112 Component 484, 488 core team 69, 490, 529

Data Quality Program 397

Design Document Repository 404

Dimension 484, 488, 489 Extended team 490 Governance processes 329 Manager 312 Methodology 482, 486, 558 Program collaboration 390 Project Manager 491 Scenarios 48 Team 371, 497, 498, 499 EDM Assessment 489 Scorecard 103, 104 Scoring Definitions 114 EDM Component 488 EDM Deliverables Domain-specific 483 Enterprise-wide 483 EDM Program 32, 57, 121, 349, 370, 385, 389, 394, 423, 479, 482, 486, 498, 499 Approaches 64 Business Case 126 Compelling events 64 Design Guidelines 150 Metrics 183 Policy 161 Scope 156, 185 Scorecard 207

EDM Program Charter 123, 124

Mission 124

Objectives 124

Vision 124

EDM Project 62, 403, 482, 483, 486, 491

Commercial Initiative project 500

Communication plan 492 EDM Strategy 32, 489, 492, 503

Development 359

Project 480

EDM-related applications and technolo-gies 388

EDM-related Business Standards 354, 372

EDM-related technology functions refer-ence list 388


Figure 3.1  General Diagram of an Enterprise SOA Application
Figure 3.2  Business Process Management with Enterprise SOA Compose  and   Orchestrate Manage  and  Optimize Integrate  and  Deploy Model  and Build Analyze  and  Discover Enterprise Service Repository 1 2  3 4 5 1 2 3 4 5
Figure 3.3  One Scenario, Two Applications, and Master Data in Enterprise SOA
Figure 3.4  Discovering Enterprise Services in the Enterprise Services Workplace (ESW)


Related documents

Unlike Word Template based invoices where you have to type everything out by hand every time you need to make an invoice, sent the tracking number to the internet address in the

Course of Study School etter e presses this understanding of the theology of ministry than does the seminary ecause the Course of Study has more potential.. for pastoral formation

Check No Supplier Supplier Name Invoice Description Invoice Amt Charge Code GL Amount. 7416358 10345 EL ZARAPE

Taxonomy, constructivist learning theory, experiential learning theory, and systems thinking can guide the AFWC and the CC to design programming specific to the learning needs of

The issues that confront the applied economist or policymaker in using the measures of real effective exchange rates available are illustrated in several case studies from

As most stations have different dominant topics across different time periods, it can be inferred that the aggregated interests of Twitter users within the vicinity of stations

The Voucher Inquiry screen allows you to create a search by Business Unit, Voucher ID, Invoice ID, Supplier SetID, Short Name, Supplier Name 1, Supplier Name 2, Supplier ID,

Identifying the research problem, forming the research question, and selecting an appropriate methodology and research design are some of the initial challenges that

To reduce transmitted vertical vibrations to the carbody, the air suspension parameters of the modeled rail vehicle are tuned so that maximum loss angle oc- curs at lower

You may be entitled to have your own insurance company reimburse you for attorney fees and other costs under a Washington State Supreme Court case

The Financial Plan delivered to a Client does not include specific security recommendations. As a general matter, certain representatives within CGMI are considered covered

Conclusion Offering online support as a standard component of services for independently living people with intellectual disability enables service providers to be flexible

• Supplier Invoice receipt only for Received Purchase Order or Purchase Down Payment  objectives. • Payment to supplier will be matched to Supplier Invoice and Purchase Order

In fact, PSP is the first global optical technique that is able to give non-contact, quantitative surface pressure visualization for complex aerodynamic flows and provide

To review the receiving and invoicing discrepancy, go to the last Supplier Invoice in the Business Document Lines column and open in a new tab?. Click on the Supplier Invoice

If the invoice does not have an Agresso purchase order number, then it is registered as a Supplier Invoice.. Because they can’t automatically be matched, supplier invoices will be

○ The invoice reference field contains the supplier invoice / credit note number Drilling down on the reference number for an invoice or credit note will take you to the invoice

To detect the spatial pattern of the skipjack pelagic hotspots throughout study area, we con- structed a model of fishery performance, which took into account both CPUE (index of

General analyses of statistical data from the latest (2011) Census in Serbia - First results (SORS, 2011) clearly demonstrate that the country’s population is in a downward

automatically created corresponding business documents Supplier Invoicing Supplier Invoice General Accountant Check Automatically Created Supplier Invoice.

• Invoice Date: The date the invoice is created by the supplier. The invoice date should not be sent until the ordered item has been shipped to Access Business Group. • Due Date:

The transaction set identifier (ST01) used by the translation routines of the interchange partners to select the appropriate transaction set definition (e.g., 810 selects the