Andrew LeBlanc
Enterprise Data Management
with SAP
®NetWeaver MDM
Build Foundations for Continual Improvements
with SAP NetWeaver MDM
Contents at a Glance
1
The Importance of an EDM Strategy
... 31
2
Challenges and Approaches to Your EDM Strategy
... 61
3
The Strategic Role of Enterprise Data in an
Enterprise Service-Oriented Architecture
... 79
4
EDM Assessment Scorecard
... 103
5
Company Business Strategy Integration
... 121
6
Data Quality Management
... 169
7
Design: Data Architecture
... 223
8
Design: Data Standards
... 275
9
Governance Organization
... 305
10
Governance Processes
... 327
11
Realization: Deployment
... 349
12
Realization: Technology
... 385
13
Building an EDM Program
... 479
14
EDM for Materials
... 503
15
EDM for a Large ERP or Enterprise Application Project
... 527
16
Globalization Within an EDM Strategy
... 543
17
The Future of Enterprise Data Management
... 557
A
References
... 565
B
Glossary
... 567
Contents
Acknowledgments ... 21
Preface ... 23
SECTION I
1
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
Contents
1.7 Joint ASUG\EDM Survey: The Need for a
Comprehensive Data Management Approach ... 55
1.8 EDM Framework ... 56
1.9 Summary ... 58
2
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
3
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
4
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
SECTION II
5
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
Contents
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
6
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
7
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
Contents
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
8
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
9
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
Contents
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
Contents
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
SECTION III
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
Contents
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 ... 577Enterprise 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.
3
The Strategic Role of Enterprise Data
in an Enterprise Service-Oriented
Architecture
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.
3.1
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.
3.2
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.
3.3
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
3.4
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 scenarioA 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.
왘Standards
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)
3.5
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
Wiki)
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.
3.6
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.
3.7
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
Component
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.
approved
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
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.
Note
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
3.8
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:
왘Code
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.
왘Identifier
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
3.9
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.
Note
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.
3.10
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
3.11
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:
Launch
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.
3.12
Summary
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.
Note
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
Index
A
A2i 43 ABAP 398 Accelerated SAP 349 ACORD 373 Ad-hoc reporting 390 Aerospace and Defense 503 AIAG 373Alternative keys 96
Application Architecture 229, 260, 423 Application-to-application data delivery
392
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
B
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
C
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
D
DARPA RaDEO 508 Data Acquisition 415 Architecture 58, 71, 482, 501 Attributes 246 Champion 164Cleansing 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
Index
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
E
EDM Best Practices 112 Component 484, 488 core team 69, 490, 529Data 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
