1. Michael Seubert, Axel Kühl, Dirk Richtsteiger (Coaching Team) Nicole Leuchter (AP Operations) enterprise SOA Object & Service Operation Design Part I Process Integration Content (PIC) Governance

2.  SAP AG 2004, Business Object Governance, Michael Seubert / 2 Table of Content – PIC Governance Process Integration Content (PIC) Governance Introduction PIC Governance Process: Roles and Tasks Governance for Business Objects & Service Operations  Additional Governance Rules  Governance for Alignment of B2B / Level 3 Services  Milestones and Deliverables for BOs PIC Governance for GDTs  Milestones and Deliverables for GDTs Coaching Procedure Model (CPM) ARIS User Access Rights Business Object Modeling Service Operation Design Global Data Type (GDT) Design

3. Introduction

4.  SAP AG 2004, Business Object Governance, Michael Seubert / 4 Governance Process for Business Content: Business Objects, Operations and Data Types Guidance for identification, design and maintenance of Business Objects, Operations and Data Types according to defined roles, tasks, milestones and design rules with the objective to define high quality Business Content which is generally accepted & well known in the business world (outside-in) consistent and redundancy free „Who does what when how“

5.  SAP AG 2004, Business Object Governance, Michael Seubert / 5 Governance Process: PIC 0 and PIC 1,2,3 PIC 0 1 PIC 0 2 PIC 0 3 PIC 1 PIC 2 PIC 3 GDT PIC ESA Entity Identification & Cut Integration Scenario Structure Service Orchestration Identification of BO’s, PC’s, DU’s (Name and Semantics) Identification of PC’s and PC interactions within Integration Scenario (Name and Semantics) Identification and cut of Service Operations and Interfaces within PC interaction (Name and Semantics) Definition of Node Structure of BO Node Structure Elements Actions, Queries, Interfaces GDT’s Detailed Definition of Global Data Types Assignment GDT’s to BO nodes Definition of Actions, Queries, compound services PIC 01 approval Required to start PIC 1 PIC 0 3 approval of PCIM’s (Interfaces and Serv. Operations) required to start PIC 3 Change Requests

6.  SAP AG 2004, Business Object Governance, Michael Seubert / 6 Process Integration Content (PIC) Governance Governance Coaching, Steering, Approval Business Objects Interfaces / Operations Global Data Types (GDTs) PIC 1PIC 3PIC 2 Scoping, Identification Definition Implementation StructureElementsService Operation Goals of the Governance Process for Business Objects (BOs) consistency of semantics across development units reuse wherever possible similar treatment of similar objects (customer invoice – supplier invoice) identical modeling and documentation rules high quality content for Business Process Platform PIC 0 IdentificationGDTs PIC 1,5 PIC Council Approval

7. PIC Governance Process: Roles and Tasks

8.  SAP AG 2004, Business Object Governance, Michael Seubert / 8 PIC Governance Process and Roles for Business Objects Development by Project Integration Experts / Content Owner Governance & Guidance by Coaching Team Business Objects / Nodes / Operations Data Types Methodology Approval by Process Integration Content Council (PIC) Business Objects / Nodes / Operations Data Types A BC Methodology Council: Methodology, Design Rules, Procedure Model D Organizational structure with roles and tasks (A – D)

9.  SAP AG 2004, Business Object Governance, Michael Seubert / 9 PIC Governance: Roles and Tasks (1) Integration Experts (in Development Business Units) Detailed definition of business objects nodes, associations, and data types according to guidelines Specification of needed service interfaces and operations Central contact person for BO and operation owners in business unit (“multiplier”) Work with central team on Governance & Methodology Responsible for preparation of PIC Approval with all relevant documents in close cooperation with the coaching team Content Creation Teams Decentralized (Content Owners in Dev. or SM) Create Content Responsible for Content A

10.  SAP AG 2004, Business Object Governance, Michael Seubert / 10 PIC Governance: Roles and Tasks (2) Coaching Team Governance and coaching of the local integration experts Ensure unified design process of business objects, service interfaces and data types Ensure consistent design of the object model and service interfaces Lean approval of BO if they are based on well known concepts Responsible for Methodology & Guidelines Responsible for Content Inventory Responsible for implementation of Governance Process / Improvement / Scalability / B

11.  SAP AG 2004, Business Object Governance, Michael Seubert / 11 PIC Governance: Roles and Tasks (3) BO Process Integration Content Council (BO PIC Council) Approval of Business objects, node structure and assigned data type design All methodical issues have to be addressed to and solved by the methodology councilmethodical Staffed with representatives (10 – 12) from  AP Operations  Platform areas (10 - 20 % FTE)  Development Business Units  Netweaver  Coaching Team (interface, process and business object experts) Responsible for high quality of Process Integration Content C

12.  SAP AG 2004, Business Object Governance, Michael Seubert / 12 Methodology Council Works with Coaching & Governance Team on methodology issues and methodology development Proposal and Review of general concepts, guidelines, templates, patterns, methodological issus Approval of the overall design approach Responsible for a consistent methodological approach PIC Governance: Roles and Tasks (4) D

13. Governance for Business Objects and Operations

14.  SAP AG 2004, Business Object Governance, Michael Seubert / 14 PIC 0-3 review steps It is recommended for new BOs to pass each PIC 1-3 review step seperately No restriction on number and combination of PIC 1-3 review steps deliverables for each PIC step must be fulfilled (details, see following slides) Allowed steps / combinations are: PIC1, PIC2, PIC3, PIC1-2, PIC2-3, PIC1-3 No overlapp of different PIC review phases of the same BO Preparation phase may overlapp PIC 1:Node-Structure for Business Objects PIC 2: Node Data Types for nodes PIC 3: Final definition for Business Objects and Service Interfaces / Operations PIC 0: Business Objects and Operations Identification

15.  SAP AG 2004, Business Object Governance, Michael Seubert / 15 Detailed PIC 0-3 Process for Business Objects Offline Review by IE + KM + Coach Creation/Change of BO in Aris (english) according to guidelines AP Ops starts review: Q&A-, SignOff-Excel Inform: owner + experts AP OPS BO Owner Coaching Team Integration Experts (IE) + KM Representative Escalation Inform SVP Sign-Off Phase Consolidation Open Issues PIC Meeting Open Issues PIC Scheduling SAP wide Review (only PIC 1 + 3) Owner corrects open topics + informs coach Coaching by IE + KM BO finally approved Document Accepted? Check by AP OPS Creation of BO in ESR by Owner OK Not OK OK with changes Coach checks + set status in ARIS Online Review Color Legend: Save all review documents IE informs AP Ops about Change Request Change Request Identification + Definition of Key Entities by PIC0 IE Suited for Review? Check by IE BO-Coach contacts PIC0 coach Critical Issue? Check by owner Name + Definition OK? Clarification in Clearing House 2 Name + Definition OK? 2 ) Clearing House: staffed with PIC0-Coach, Applicationexpert, PIC1-3 Coach, Integrationexpert, Object Owner, KM Representative PIC 0 secure copy in word After change before review Business Object Taskforce (BOT) 1 New generic concept 1 ) BOT: staffed with architects of development areas

16.  SAP AG 2004, Business Object Governance, Michael Seubert / 16 BOT Governance Process for New Generic Concepts Request for BOT Integration Expert: Critical methodological topics PIC Reviewer: New generic concepts BOT (Methodology Council) Topic Owner BOT Governance Process PIC Governance Process New generic concept eSOA Guideline Offline Review by IE + KM + Coach PIC Meeting Open Issues PIC Scheduling Online Review First occurrence of new concept Further occurrences of new concept Creation/Change of BO in Aris (english) according to guidelines BO finally approved

17.  SAP AG 2004, Business Object Governance, Michael Seubert / 17 Alignment in AP and between AP and BS BOT / BOW PIC 1-3,GDT ANT SDMC PIC 0,1-3 Enterprise SOA Architecture Team Horst Schnörer Bernhard Drittler Stefan Kaetker (sponsor) Klaus Enders (operational lead) Günter Pecht-SeibertMichael Seubert AP Business Suite Process Modeling, PIC 0 Stefan Kaetker InfoHighlights,Escalationpath Alignment, if SAP relevance SAP aligned (AP + BS) Alignment, if SAP relevance Info about Topics with Modeling Impact

18.  SAP AG 2004, Business Object Governance, Michael Seubert / 18 BO PIC Governance: Focus on PIC1-3 The PIC Governance Process is ARIS based. That means, all PIC relevant content must be modeled in ARIS. Preparation BO must have PIC0 approval and must be part of the BO Map in ARIS “Change Request” for changes and for new models must be submitted by the content owner and must be approved by the management. (see guideline: //dwdf029/Ap_eng/Content_Governance/10_Business_Object_Governance_&_Coaching/20_Organization/Model_Consistency/Model_Change_Request_Guideline_v1p2.doc ) //dwdf029/Ap_eng/Content_Governance/10_Business_Object_Governance_&_Coaching/20_Organization/Model_Consistency/Model_Change_Request_Guideline_v1p2.doc Starting the review Integration Expert checks whether BO is suited for review and requests the review in the "Workplace" tool (see guideline: //dwdf029/Ap_eng/Content_Governance/10_Business_Object_Governance_&_Coaching/20_Organization/ARIS/Initiating_PIC_reviews_Guideline.doc ) //dwdf029/Ap_eng/Content_Governance/10_Business_Object_Governance_&_Coaching/20_Organization/ARIS/Initiating_PIC_reviews_Guideline.doc AP Operations sends mail with review information to all persons involved in review BO review Questions/discussion takes place in Q&A-Excel All changes are made directly in ARIS and are documented in Q&A-Excel (not in word document!) Each reviewer can classify his topic according to prio  Prio 1 critical: architecture or concept not clear, immediate clarification required  Prio 2 to be solved: architecture or concept clear, changes have to be done  Prio 3 comments: suggestions, nice to have Only the reviewer can set the status to “done” Sign Off Each reviewer must set the sign-off status at due date latest Overall status derived by AP Operations depending on reviewer sign-off, status will be set in ARIS  Not OK:AP Operations schedules the BO for online PIC (at least one reviewer status “Not OK” sufficient)  OK with changes: BO Owner closes open topics and informs Coach when finished  OK: Freeze of BO in ARIS, AP Operations starts SAP-wide review Coaching Team checks general integrity and plausibility of discussion  If all open topics are closed by BO Owner, the Coach can set the sign-off status from "OK with changes" to "OK“ if necessary. In addition the Coach added a comment in the sign-off excel: "All topics closed. Status set to "OK" by Coach"

19.  SAP AG 2004, Business Object Governance, Michael Seubert / 19 PIC Review Documents: Version Handling (1) ARIS does not support versioning at start of PIC 1-3 process an initial document for the BO is created (documentation is generated via ARIS Report) For each review step a “delta” word document between current review version and initial document is created by AP Operations. This “delta” document contains the marked changes and is basis for the review (see yellow bars in next slide) After a PIC 3 review took place (complete approval) an new initial document is created and used to create the “delta” word document  Consequence: All changes since the last PIC3 approval are marked in the “delta” document until a new PIC3 approval exixts.

20.  SAP AG 2004, Business Object Governance, Michael Seubert / 20 PIC Review Documents: Version Handling (2) Initial Document PIC 1 .. preparationPIC1 ReviewPIC1 postproc. PIC 2 .. PIC2 ReviewPIC2 postproc. preparation changes in ARIS PIC 3 .. preparationPIC3 ReviewPIC3 postproc.SAP wide review .. changes in ARIS preparation New Initial Document time Changes: review cycle 11  1+2 11  1+2+3 22 33  1 +  2 +  3 + 11 .. Q & A Doc Review Document .. changes in ARIS: To be documented in Q & A

21.  SAP AG 2004, Business Object Governance, Michael Seubert / 21 BO PIC Governance Process Type BO PIC Gov. Process Type ReviewerTimePIC steps Normal IEs, KM, Coach 1 or 2 weeksPIC 1, PIC 2, PIC 3, PIC 1-2, etc. Lean Coachca. 1 weekalways PIC 1-3 Lean Fast Track Coach2 daysalways PIC 1-3 Bug Fix Coach3 daysalways PIC 1-3 Normal: Standard PIC review process as described Lean: Same process as for “Normal”, but only CT as reviewer involved Used only for small changes due to new or different functionality which are modeled completely according to guidelines Lean Fast Track: Same process as for “Lean”, but only 2 days review time Used only for adding new elements based on existing GDT, no new concepts coach has veto right, if prerequisites not fulfilled -> change to a normal review possible Bug Fix: Same process as “Normal”, but only CT as reviewer involved Used for errors in the model or in implementation (with impact to model) which are modeled completely according to guidelines

22. Governance for Business Objects and Operations Additional Governance Rules

23.  SAP AG 2004, Business Object Governance, Michael Seubert / 23 MDRO Governance MDROs must be approved by PIC 0 (handling should be “as lean as possible”) no PIC1–3 review any more  the application itself is responsible for modeling according to the MDRO Design patterns (see the following guidelines) BO Modeling Guideline MDRO_Documentation_Pattern_EN.doc Mass, Background, and Parallel Processing (MBP) New „MDRO Check“ by Coach The coach only checks that the MDRO corresponds to the MDRO pattern, that is:  Standard structure and standard formulations for MDRO, Nodes, Elements Core Service Queries and Actions Relationships Data Types MDRO must not contain any new concepts  this is only a check not an approval! The check result is “MDRO Check o.k.” or “MDRO Check not o.k.” In case of “MDRO Check not o.k.” an online PIC is scheduled MDRO Checks are requested like PIC review requests via the BO_PIC_ARIS Excel file MDRO Check lasts 2 days Also change requests of existing MDROs are handled via this process

24.  SAP AG 2004, Business Object Governance, Michael Seubert / 24 Technical Object Governance Like governance for BOs with the following special rules Because of the nature of TecOs, terms in the model entities as well as the used GDTs are allowed to be technical  Be aware to use technical terms only when they are needed to express the subject matter of the TecO  Explain terms that are not common known in a comment Combined review for PIC1 – PIC3 is possible

25.  SAP AG 2004, Business Object Governance, Michael Seubert / 25 Additional Governance Rules for Message Types All kind of Message Types (B2B, A2A and A2X) are maintained in ARIS and reviewed in the PIC review process. (Except A2X message types which are generated by a tool) The following documents have to be provided in preparation folder (Link)Link MessageType Word document, provided by AP Operations  The document ist generated from ARIS with report “AP_MT_MessageTypeDocumentation” MessageType Excel document (structure and mapping to involved BOs), provided by Owner  The Message Type structure excel is generated from ARIS with report “AP_MT_ElementStructure”  Naming Pattern of Excel-File: _Vxx_MT_ELStr_YYYY-MM-DD.xls e.g.: PurchaseOrderRequest_V17_MT_ELStr_2008-08-19.xls  The Owner also provides the mapping to involved BOs in the generated excel  use the excel macro Message Type Mapping Macro to copy the already existing mapping from an “old” Message Type Excel into the “new” generated one.Message Type Mapping Macro  Owner informs Steffen Wolf (D040280) from AP Operations via e-mail that the excel is provided Starting of PIC Process via leading Business Object

26.  SAP AG 2004, Business Object Governance, Michael Seubert / 26 Additional Governance Rules for Form Message Types For a Form-MT the same deliverables and governance rules apply as for non-Form MTs, except that: Lean PIC Governance Process is used, because a Form-MT bases on existing A2A/B2B MTs. The basic concept are already approved. Currently all changes to a Form-MT have to be considered as incompatible for the Adobe form rendering engine, therfore:  Before submitting a change request for an existing Form-MT, the integration expert has to present a written acknowledgement by Forms Development (contact: Li, Patrick) that the changes are accepted (mail is obligatory and stored in the review folder, sufficient for a lean review)  For a normal PIC review (for major changes of a Form-MT or a new Form-MT) Forms Development (contact: Li, Patrick) will take part on the review Integration expert informs AP Operations (contact: Wolf, Steffen) via mail, to start review with Forms Development participation Only Form-MT for “Backend output” are PIC relevant ”Backend output” is part of a business process. Only consistent data can be output. The output is automated and tracked in the backend system. The form data is retrieved in outbound process agents. Backend output can only be implemented in AP layer. Interactive Form-MTs are Form-MTs, so the same deliverables and governance rules as for Form-MT apply. Additionally: In case of split of an (incoming) interactive form message an additional mapping must be approved as described in the following slides

27.  SAP AG 2004, Business Object Governance, Michael Seubert / 27 Interactive Form Message Split Interactive Form Message (Type A) Message (Type C) Message (Type B) for example, Interactive Form Customer Requirement Fulfillment Request For example, Customer Invoice Request Request For example, Customer Requirement Fulfillment Confirmation For example, ProductAvailableToPromiseUpdateNotification Switch / Split

28.  SAP AG 2004, Business Object Governance, Michael Seubert / 28 IForm Customer Requirement & Outbound Delivery Processing Example: Form Split in A2A Scenario with Partial Use Sales Order Processing Fulfillment Out Fulfillment In Sales Order IForm Customer Requirement Fulfillment Request Customer Requirement Fulfillment Confirmation Customer Requirement Out Switch / Split IForm Customer Requirement Fulfillment Confirmation Customer Invoice Processing Customer Invoice Request Request Request Invoicing in ProductAvailableToProm iseUpdateNotification

29.  SAP AG 2004, Business Object Governance, Michael Seubert / 29 Additional Mapping for Interactive Form Message Split (1) Message Structure Interactive Form Message Structure A Message Structure B Message Structure C Mappings Mapping to be approved in PIC3 Mapping defined in Excel of Interactive Form Mapping Only projection from interactive form allowed Only simple transformations allowed, besides “pure” element mapping (to check in review!) Application that defines from is responsible for consistency

30.  SAP AG 2004, Business Object Governance, Michael Seubert / 30 Additional Mapping for Interactive Form Message Split (2) CustomerRequirementFulfillmentRequest InteractiveFormCustomerRequirementFulfillmentRequest ProductAvailibilityToPromiseUpdateNotification CustomerRequirementFulfillmentConfirmation CustomerInvoiceRequestRequest Submit „ATP Confirmation“ Submit „Delivery Confirmation“ No completion/enrichment of split messages with additional information: Split message contains only information from Interactive Form ! 

31.  SAP AG 2004, Business Object Governance, Michael Seubert / 31 Additional Governance Rules for Business Object Extensions ARIS currently does not support Extensions. Therefore Extensions are handled via document based PIC Governance Process, that is: Word document contains the delta information (see pattern) which has to be provided in preparation folder (Link) by the Owner of the extensionpatternLink Please inform Steffen Wolf (D040280) from AP Operations via e-mail that you have added the documents. Consistency of multiple extensions for one BO has to be checked by BO-Owner Initiation of PIC Process via Excel BO-PIC-ARIS (Link)Link Add row Add name of Extension (column D): _Extension e.g.: PersonnelChange_Template_CN_Extension Add “date of entry” and set “Extension” in Request column of excel sheet.

32.  SAP AG 2004, Business Object Governance, Michael Seubert / 32 Additional Governance Rules for Data Flow Verification (DFV) ARIS currently does not support Data Flow Verification Therefore DFV is handled via document based PIC Governance Process, that is: DFV info is part of the excel sheet with Message Type (MT) structure Special columns and special sheet for Data Flow Verification added to MT Excel by Coaching Team Owner gets link to the prepared MT excel sheet via email Attention: please edit the excel on the public folder (from link in email), do not edit local copies DFV content is filled in prepared MT Excel by Owner Link to DFV excel has to be provided by owner in preparation folder (Link)Link Please inform Steffen Wolf (D040280) from AP Operations via e-mail that you have added the documents. Starting of PIC Process via Excel BO-PIC-ARIS (Link)Link Search DFV Pair in the Excel (all DFV pair start with DFV_) Add “date of entry” and set “PIC3” in Request column of excel sheet. For further information please refer to the folder (Link)Link

33. Governance for Business Objects and Operations Governance for Alignment of B2B / Level 3 Services

34.  SAP AG 2004, Business Object Governance, Michael Seubert / 34 eSOA Cooperation Model Business Suite / AP Joint PIC 0 Review (to validate Level 3 Services) PIC 0 in Business Suite PIC 0 in AP Joint Methodology (Modeling, Service Pattern, Lifecycle Management) Via Service Definition Methodology Council (SDMC) Strong cooperation about methodology aspects. Keep methodology in sync via bi-weekly Methodology Council Loose coupling for content Do not block agile projects for content development on both sides Focus content alignment on PIC 0 level; PIC 1-3 alignment only for BS “Level 3” services (B2B, key A2A services, shared service center integration) Definition of Service Bundles for eSOA by Evolution Full scope service enablement for eSOA by Design Joint Steering Committee (NW, Biz Suite, AP, evtl. B1) PIC 1, 3 in Business Suite PIC 1,2,3 in AP Alignment For Level 3 Services Decision

35.  SAP AG 2004, Business Object Governance, Michael Seubert / 35 Principles: Signature Alignment for Level 3 Services Underlying assumption: AP BO Model represents the future SAP BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible Approach: Keep Kernel aligned and allow solution specific extensions For all Level 3 services: Mapping has to be provided (“the 2nd is in charge to def. mapping”) Currently only very few objects in Kernel; grow over time on demand  manageable effort Joint Governance of SAP-wide BO Kernel within AP Process Enterprise Service Repository AP Business Object Models Enterprise Services realized in AP SAP-wide BO Model Kernel (smallest common denominator) BS Business Object Models Sol. spec. Extensions SAP-wide BO Model Kernel (smallest common denominator) Other SAP Solutions Level 3 Enterprise Services realized in BS Transformation (Projection ++) Kernel copy in BS BO Model Mapping for relevant services along integration scenarios must be provided Kernel

36.  SAP AG 2004, Business Object Governance, Michael Seubert / 36 eSOA Cooperation Model with Business Suite PIC 0 in Business Suite Level 3 Services PIC 0 in AP PIC 0 Alignment Process Align BO & PC cut (Coaching Teams only) Validate Level 3 Services S.Kätker; B.Drittler; M.Seubert; AP IE; Suite IE SAP wide alignment required and feasible? Yes No PIC 1-3 in Business Suite B2B Service B.Drittler; M.Seubert; Suite IE; AP IE SAP Core: Projection based on AP Object Model M.Seubert; B.Drittler; AP IE; Suite IE (PIC 1-3 in AP) Extensions required? PIC 1-3 in Business Suite B2B Service with extensions based on SAP Core B2B Service labeled with suffix B.Drittler; M.Seubert; Suite IE; AP IE Define and align SAP Core Yes 100 % down-to-field level identical services not feasible Approach: Keep Kernel aligned and allow solution specific extensions For all Level 3 services: Mapping has to be provided (“the 2nd is in charge to def. mapping”) Currently only very few objects in Kernel; grow over time on demand  manageable effort Joint Governance of SAP-wide BO Kernel within AP Process

37.  SAP AG 2004, Business Object Governance, Michael Seubert / 37 Join PIC 0 Review Joint PIC 0 for AP/A1S and Suite in the following cases B2B Services, Key A2A Services for  Integration to 3rd party  Shared service center  AP/Suite Adoption Escalation handling if issues in PIC 1-3 occur Bi-weekly, one per month in Rot, one in WDF IE requests Joint PIC 0 review after successful local PIC 0 Agenda send out 2 days in advance Operations to be handled by Michael Ottenstein

38. Governance for Business Objects and Operations Milestones and Deliverables

39.  SAP AG 2004, Business Object Governance, Michael Seubert / 39 Milestones: Four Step Approach for PIC Council Approval PIC 1: Node-Structure for Business Objects PIC 2: Node Data Types for nodes PIC 3: Final definition for Business Objects and Service Interfaces / Operations Detailed definition containing all elements and integrity constraints How to … … described in guidelines PIC 0: Business Objects and Operations Identification

40.  SAP AG 2004, Business Object Governance, Michael Seubert / 40 Approval Topics BO Name Definition Nodes and structure Node elements typed by GDTs Integrity / Constraints / Business Rules Interfaces Compound Operations Core Service Actions (business semantic) Core Service Queries GDT Name Definition Structure Value Ranges PIC 1 PIC 2 PIC 3 PIC 1,5

41.  SAP AG 2004, Business Object Governance, Michael Seubert / 41 Deliverables for BO PIC Council Approval A pattern based generation out of the ARIS system of the needed documents is provided (Please see ARIS report AP_BO_BusinessObjectDocumentation) The document generation covers: BO Structure Visualisation of BO node structure BO Documentation Semantic (Definitions), Structure (node elements) + Integrity, Behavior (operations, actions, queries) Based on template BO Node Elements Detailed structure of BO nodes Based on Global Data Types Error free ARIS content Execute ARIS check report “SAP_CheckFrameworkAdhocCheck” no errors for submitted content are allowed BO Documentation - Definition - Nodes - Associations - Elements - Integrity - Actions - Queries - Service Operations BO Elements Structure

42.  SAP AG 2004, Business Object Governance, Michael Seubert / 42 PIC Council: Approval for BO Structure („PIC 1”) Requirements  BO Structure (Graphic)  BO Documentation  Check, acceptance and “Go” by Integration Expert Activities  Review and sign-off by integration experts and coaching team  Open topics from sign-off: Presentation by integration expert / BO owner in PIC Council: Review and acceptance Result  Release for SAP-wide Review Milestone 1: BO Structure (PIC 1) Generated from ARIS via “Documentation-Report”

43.  SAP AG 2004, Business Object Governance, Michael Seubert / 43 Requirements PIC1 (Detail): BO Structure Visualisation of BO structure Semantic understanding of BO Uniform representation “SAP Serm/UML Plus” Contains  Packages  Nodes / Subtypes  Compositions / Aggregation / Associations

44.  SAP AG 2004, Business Object Governance, Michael Seubert / 44 Requirements PIC1 (Detail): BO Documentation Business Object Business Object Name Business Object Definition Process Component Logical Deployment Unit (optional) Business Object Capsule Packages Nodes / Subtypes Associations Integrity Business Object Environment Association from  Business Configuration Objects (tbd)  Business Foundation Objects  Business Transaction Objects Node Elements Structure Interfaces / Operations Actions Queries Compound Services / B2B/A2A, Inbound/Outbound BO Documentation - Name - Definition - Process Component - LDU (opt.) - Packages - Nodes / Subtypes - Compositions / Associations - Integrity - Business Object Environment - Node Element Structure - Interfaces / Operations

45.  SAP AG 2004, Business Object Governance, Michael Seubert / 45 Milestone 2: BO Node Elements (PIC 2) PIC Council: Approval for BO-Node Elements („PIC 2”) Requirements  PIC1  BO Node Elements (Assembly of GDTs)  Definition of node elements in BO documentation  GDTs approved by PIC Council or lean approved by coaching team  Check, acceptance and “Go” by Integration Expert Activities  Review and sign-off by integration experts and coaching team  Open topics from sign-off: Presentation by integration expert / BO owner in PIC Council: Review and acceptance Result  Approved node structure  SAP-wide availability for use

46.  SAP AG 2004, Business Object Governance, Michael Seubert / 46 Requirements PIC2 (Detail): BO Node Elements Assembly of node elements Elements belong to/describe nodes Structure of Node Elements Only 1:c or 1:1 Element Names Element Definitions Based On Assigned Global Data Types BO Elements

47.  SAP AG 2004, Business Object Governance, Michael Seubert / 47 Milestone 3: BO Service Operations (PIC 3) PIC Council: Approval of Service Operations („PIC 3”) Requirements  Full business object structure, semantics, integrity (PIC 1 & PIC 2)  Process Components with the Process Interaction Models are well defined  Interfaces / operations identified and named  Complete business object document with service operations  Message type document (for message types derived from this BO)  Check, acceptance and “Go” by Integration Expert Activities  Review and sign-off by integration experts and coaching team for all operations (without C,R,U,D operations)  Presentation of open topics from sign-off by integration expert / BO owner in PIC Council: Review and acceptance Result  Release for SAP-wide review

48.  SAP AG 2004, Business Object Governance, Michael Seubert / 48 Document based integration: Message Type and Operation Signature The Structure of the Message Type is derived from the „defining BO“ („leading BO“) Defining Business object of MT can either be source object or target object (or a third one) The operation signatures of the source and target object are specified according to this MT structure.

49.  SAP AG 2004, Business Object Governance, Michael Seubert / 49 Requirements PIC3 (Detail): Service Operation Documentation (1) Complete business object document (according to pattern) Compound Service Interfaces  Semantic definition, naming according to naming conventions Compound Service Operations  Behavior: ( Inbound or outbound specific) Semantic definition of what the operation offers, it‘s effects and integrity / preconditions Note: Semantic definition of operation and MT are identical except for Inbound / outbound information  Structure: Detailed definition of signature is described (incl. element structure) in message type document Note: It is based on / linked to the defining object  Mapping of BO node elements and message data type (MDT) elements if BO is not the defining BO of operation  List of Elements of MDT not yet covered by BO

50.  SAP AG 2004, Business Object Governance, Michael Seubert / 50 Requirements PIC3 (Detail): Service Operation Documentation (2) Complete business object document (continued) Core Service Actions  Semantic definition with business focus  Business pre and post conditions  Detailed description of what action does (effect on nodes) Core Service Queries  Semantic definition  List elements used in query Comment: Status & Action management (S&AM) will be later included in document. S&AM is not part of PIC1-3. Coached by Frank Michael Kraft Query Response Transformation Nodes (QRTN) are nodes of a BO but their structure is build for and motivated by a core query. Therefore QRTNs are part of PIC3

51.  SAP AG 2004, Business Object Governance, Michael Seubert / 51 Requirements PIC3 (Detail): Message Type Document Complete message type document (according to BO MT pattern) Complete definition of message types (including element structure) If existing, use already PIC approved service interface documentation New documentation corresponding to BO MT pattern  No redundant description b/c BO already described  Only describe differences (Integrity Conditions, …) Ensure that business document object is derived from leading / defining BO (= derivation of MT structure from BO structure according to derivation rules)  In case of non leading BO: provide mapping of operation structure and BO structure. Hint: Generation of needed documents for Message Type is currently not supported by ARIS. Therefore please use BO MT pattern (Word) and pattern for element structure (Excel).

52.  SAP AG 2004, Business Object Governance, Michael Seubert / 52 Requirements PIC3 (Detail): Form Message Types For Form Message Types the same modeling rules and documentation guidelines apply as for non-form Message Types. Essentials are: 1. Form MTs are documented at the defining BO  Add a comment to Service Operation definition: “To support the form based output an additional message type (derived from business object ) is defined.” 2. Complete definition of message types (including element structure and mapping to BO) 3. documentation corresponding to BO MT pattern  No redundant description that is already described for BO or corresponding “normal” MT  Only describe differences (additional elements, Integrity Conditions, …) 4. Ensure that business document object is derived from leading / defining BO Special case: Form MT for frontend output only If no Service Operation exists where the Message type for frontend outputs fits, then skip step 1.  No artificially creation of a Service Interface /Service Operation. Step 2-4 as before.

53.  SAP AG 2004, Business Object Governance, Michael Seubert / 53 PIC3 Approval For each object all operations have to be approved (without the C,R,U,D operations) Compound operations Core Service Actions Core Service Queries For approval Either the operation with all integrity conditions have to be specified and a reference to an already approved message type Or (in case of “leading operation”, which defines the MT) the operation, the operation signature with all integrity conditions and the message type have to be specified. For working in parallel an incremental approval process for PIC 3 is possible (see following slide).

54.  SAP AG 2004, Business Object Governance, Michael Seubert / 54 PIC3 Incremental Approval Process As a basic principle, PIC3 is conducted in a single step To enable work in parallel and to avoid deadlocks, the PIC3 deliverables / PIC3 approval of BO operations may be split in general into 2 parts (PIC3.1 and PIC 3.3) Scope of PIC3.1  Service interfaces and operations that are defined by the BO (leading BO), including the message type structures  Core Service Queries  Core Service Actions Scope of PIC3.3  Service interfaces and operations of the BO which are defined by other BO‘s, including the mapping BO  message type structures for these operations Only in exceptional cases, where a large number of messages type structures is defined by a BO, and additional PIC3.2 step may be conducted (“split of PIC3.1”). In this case some of the service operations from the PIC3.1 scope can be approved by the PIC3.2 step

55.  SAP AG 2004, Business Object Governance, Michael Seubert / 55 PIC3 Approval: Check List (1) What has to be approved  Completeness of deliverables according to scope (AP, PCIM)? Service Interface, Service Operation, MT, Core Service Query and Action  Does the behavior fit the semantic of the BO  Documentation according to pattern?  Definition understandable and meaningful?  Name according to naming rules? Service Interface (compound)  According to Process Component Interaction Model (PCIM)? Operation  According to PCIM?  Link to Message Type  Limitations for MT specified? Also for Op, MT, Core Service Query and Action

56.  SAP AG 2004, Business Object Governance, Michael Seubert / 56 PIC3 Approval: Check List (2) Message Type  According to PCIM?  Structure derived according to derivation rules?  If BO not leading / defining: MT / BO – Mapping provided? Core Service Queries  Parameters specified?  Used GDTs available? Core Service Actions  All needed Actions available?  Parameter specified?  Used GDTs available? Links to document pattern: https://portal.wdf.sap.corp/irj/go/km/navigation/corporate_portal/WS Application Platform/03_Engineering/ContGov/TemplateAndPattern_documents?StartUri=/corporate_portal/WS+Application+Platform/03_Engineerin g/ContGov/TemplateAndPattern_documents https://portal.wdf.sap.corp/irj/go/km/navigation/corporate_portal/WS Application Platform/03_Engineering/ContGov/TemplateAndPattern_documents?StartUri=/corporate_portal/WS+Application+Platform/03_Engineerin g/ContGov/TemplateAndPattern_documents

57. Governance for Global Data Types (GDTs)

58.  SAP AG 2004, Business Object Governance, Michael Seubert / 58 Detailed PIC Process for GDTs & Qualifier AP OPS Coaching Team Owner and Integration Expert Escalation Critical Issue AP OPS Schedules the PIC review of the GDT Agenda two days before Scheduling GDT approved finally Suited for review? Check by Integration Expert Creates /changes document in ARIS (english) according to guidelines rejected AP OPS Schedules the SAP review; creates GDT Critical Issue PIC Council Meeting SAP review Scheduling objections Coaching Team Check of overall integrity of GDT in catalog Check of applied PICC changes PICC Corrections IE informs AP OPS / Coaching Team about Change Request ARIS: copy of GDT with suffix “_Vx” Change Request Color Legend: Coaching by IE + KM

59.  SAP AG 2004, Business Object Governance, Michael Seubert / 59 Detailed SAP Review Process for GDTs & Qualifier Package of GDTs/CLs/Qualifiers prepared for SAP review: Portal: Entry into Portal document with SAP Review status (yellow) and Icon link to GDT doc. ARIS: GDT PIC Status set to “GDT in SAP Review”; GDT folders moved to order “70 GDT in SAP Review” Information of SAP review community with list of GDTs for new SAP review Objection(s) during review (by e-mail to coach or AP OPS) AP OPS ARIS: GDT PIC status set to “GDT approved”; Portal: GDT Status set to green; GDT moved to archive Coaching Team GDT PIC status set to “Withdrawn” AP OPS Portal: GDT Status set to red, comment (objector, date and reason of objection) entered ESR: actions in have to be undone if necessary Interaction coach reviewer, owner / requestor GDT withdrawn GDT again in PIC Review Coaching Team GDT PIC status set to “ready for review” AP OPS Further ESR actions have to be done if necessary objection rejected or withdrawn AP OPS Coaching Team Owner and Integration Expert Color Legend: GDT request dicussed and changed during SAP Review GDT approved finally SAP review (two weeks) no objections

60.  SAP AG 2004, Business Object Governance, Michael Seubert / 60 Closed Content Governance Cycle for GDT Codes & Values Global Data Type PIC Application Platform SAP Business Suite SAP Customer Consistent Content Delivery PIC approved content SAP Composite Applications SAP Composite Applications SAP Composite Applications Code-GDT & values New & change request provides basis A1S

61.  SAP AG 2004, Business Object Governance, Michael Seubert / 61 GDT PIC Governance in ARIS Document flow of GDTs follows progress of the governance process. GDT Group gets moved to appropriate Governance Group according to new status: Process Step Status (= folder) Responsible (move & status update) 1“GDT in preparation”Owner 2“GDT ready for PIC review”Integration Expert 3“GDT in PIC review”AP OPS 4“GDT OK with changes”AP OPS (PIC Meeting) 5“GDT to be checked by coach”Integration Expert 6“GDT Expert Review OK”AP OPS (PIC Meeting) or Coaching Team 7“GDT in SAP review”AP OPS 8“GDT approved (to be integrated in catalog)Coaching Team

62.  SAP AG 2004, Business Object Governance, Michael Seubert / 62 Applying for New Qualifiers Prerequisites by Qualifier Owners: Create Group “ _Qualifiers” Create Model “ _Qualifiers” within Group Add desired qualifiers to Model and inform GDT owner (NOT for CDT qualifiers!) Governance: 1.GDT owner consolidates requested qualifiers, IE requests approval 2.ARIS Objects Allowed Qualifier move through Governance Groups according to PIC progress 3.Coaching Team integrates approved qualifiers 1 1 2 2 3 2 3

63.  SAP AG 2004, Business Object Governance, Michael Seubert / 63 Applying for New Qualifiers for Restricted CDT/GDTs Prerequisites: Create Group “ _Qualifiers” (common for all qualifiers) Create Model “ _Qualifiers” within Group Add desired qualifiers to Model (common for all qualifiers) Governance: standard governance process Example in ARIS:

64.  SAP AG 2004, Business Object Governance, Michael Seubert / 64 Applying for New Codes / Code Lists Prerequisites: Create Group “ _CodeLists” Create Group “ ” within Group Create Model “ ” within Group Add desired codes to Model Governance: 1.Group moves through Governance Groups according to PIC progress 2.Coaching Team integrates approved code list 1 1 2 3 2 3

65.  SAP AG 2004, Business Object Governance, Michael Seubert / 65 Change Request for Codes / Code Lists Prerequisites: Create Group “ _CodeLists” Create Group “ _Vx” within Group (Vx = version number) Create Model “ _Vx” within Group _Vx Add desired codes to Model Governance: standard governance process

66.  SAP AG 2004, Business Object Governance, Michael Seubert / 66 Application for Alternative Business Terms (ABT) for Code Names An ABT is a context specific synonym for an term approved by AP experts An ABT is only a workaround for missing text verticalization features: it replaces an implemented code name only one ABT is possible: it affects all solutions build upon AP Prerequisites: An ABT has to be aligned between the GDT owner (and Integration Expert), Solution Management, and Knowledge Management (AP & ByD) Governance: 1.An ABT doesn’t follow standard Governance Process 2.Coaching Team is informed per email and checks the ABT for any contradiction in code semantics other code names other ABTs 3.Coaching Team may raise a veto - else the ABT gets tracked at the code

67.  SAP AG 2004, Business Object Governance, Michael Seubert / 67 Change Requests on Structure or “Nature” of GDT Change Requests generate a new version (“~_Vx”) as default Change Requests needs to be checked for compatibility (in AP AND mySAP) Prerequisites: Integration Expert requests a change on a GDT (Excel)change on a GDT (Excel) Copy of GDT “ _Vx” within “10 GDT in preparation” will get prepared by Coaching Team Owner applies changes and checks compatibility Governance: 1.Change Request follows standard Governance Process 2.Coaching Team integrates approved changes into existing GDT, if Change Request is compatible (no new version required)

68. Governance for Global Data Types (GDTs) Milestones and Deliverables

69.  SAP AG 2004, Business Object Governance, Michael Seubert / 69 Integration Expert: Check, if GDT review capable Requirements GDT Documentation according to guideline & patterns Documentation in ARIS: /SAP consolidated/10 Data Type Models/ 00 GDT PIC Governance Process/10 GDT in preparation Activities “Go” or feedback (if necessary) by Integration Expert Implementation of changes by owner due to feedback (if necessary) Application for approval by moving GDT into ARIS group ~/00 GDT PIC Governance Process/20 GDT ready for PIC review Result OPS schedules PIC Council Review for GDT Milestone 1: Application for Approval

70.  SAP AG 2004, Business Object Governance, Michael Seubert / 70 PIC Council: Approval of GDT (“PIC 1,5”) Requirements Released (by Integration Expert) GDT documentation GDT scheduled for PIC Council review Activities Online review by PIC Council (PICC experts and Coaching Team) Coaching checks, if new GDT fits to existing GDTs and ensures overall integrity of GDTs Result PICC approval PICC change requests Milestone 2: PICC Approval

71.  SAP AG 2004, Business Object Governance, Michael Seubert / 71 SAP-wide Review: Final Approval of GDT (“PIC 1,5”) Requirements PICC approved GDT Implemented PICC Change Requests (checked by Coaching Team) Activities Integration of GDT in catalog (Coaching Team) Creation of GDT in repository (AP OPS) SAP-wide offline review by experts Result Final approval GDT in catalog GDT in repository and ready for use Milestone 3: SAP-wide Approval

72. Coaching Procedure Model (CPM)

73.  SAP AG 2004, Business Object Governance, Michael Seubert / 73 CPM in a Nutshell Modeling Guideline Coaching Procedure Model approved PIC Document Check !!!

74.  SAP AG 2004, Business Object Governance, Michael Seubert / 74 CPM – General Coaching Procedure Model (CPM) describes Coaching Procedure Steps necessary to ensure a high quality of Process Integration Content (PIC) enables systematic and complete checks of the content triggered by the phases of the PIC governance process (PIC0-3) “Service Catalog” for PIC checks verifying the proper application of the methodology as defined by guideline provides an elementary guideline for coaches, integration experts and content owners to avoid errors in advance

75.  SAP AG 2004, Business Object Governance, Michael Seubert / 75 CPM – Structure When checks take place –> CPM step  assigned to and triggered by PIC governance phase  collects related modelling topics and check tasks What is checked –> CPM modeling topic  subject area which should be processed as a whole  can be refined into “modeling topic details”  has several checks to verify the topic How it is checked –> CPM check task  detailed description what to check  categorized by area of expertise  dedicated error message for every check task with Error ID category (Error / Warning) severity error description  error follow-up action  reference to guidelines  175+ of 850+ check tasks supported by check report

76.  SAP AG 2004, Business Object Governance, Michael Seubert / 76 CPM – Steps & Topics for BOs (1) 1. BO Cut and Understanding 2. BO Definition 3. BO Name and Category 4. BO Specializations 5. BO Nodes: Definition, Name, Specializations 6. BO Node Environment Object Capsule Object Category Standard (ISO 11179), Patterns, and Guidelines Compliance Derivation of BO Name from Definition Derivation of BO Category from Definition Term Abbreviation Cut and Definition of Nodes Derivation of Node Names from Definitions Determination of Roles (Specialization) Root Node Node Category Determination of Roles (Object Specializations)... Structure Relationhips Associations for Navigation Cardinalities Integrity Conditions Cross-object Structure Consistency Hiearachies and other Structures on Nodes Arrangement According to Relationships

77.  SAP AG 2004, Business Object Governance, Michael Seubert / 77 CPM – Steps & Topics for BOs (2) 7. Elements: Definition, Name and Structure 8. Typing 9. Operations, Queries and Actions 11. Message Data Types 10. Message Types Assignment and Definition of Elements for Nodes Derivation of Element Names from Definitions Cardinalities of Elements Qualifiers Integrity conditions Ordering of Elements Extension of Node Elements Data Flow Verification (DFV) Filtered Relationships.... Elements Integrity Conditions Nodes Filtered Relationships Determination and Definition of Queries and Actions for Nodes Derivation of Names of Queries and Actions from Definitions Determination and Definition of Query Parameters Core Query Determination and Definition of Preconditions, Parameters and Results of Actions Compound Operation Determination and Definition of Message Types (MTs) for Operations Determination of Leading BO, BDO and Category of Message Type Derivation of Name of MT from Definition, BDO and Category Derivation of MT Structure from Leading BO Compound Query / Response MT (Interactive) Form, Mass, and Reconciliation Messages Message Data Types (MDTs) for MTs Typing of Levels of MDT Integrity Conditions 12. BO Template and Projection Template object Projection profiles

78.  SAP AG 2004, Business Object Governance, Michael Seubert / 78 CPM – Steps & Topics for GDTs 1. GDT Determination 2. GDT Definition 3. GDT Name 4. GDT Structure 6. GDT Integrity Conditions 5. GDT Value Range 7. GDT Use and Notes Business subject and use case Lookup of a “suitable” GDT and qualifier from the GDT catalog Standard (ISO 11179) and guideline compliance Business standard and pattern compliance Derivation of GDT name from the definition Standard (ISO 11179) compliance Restriction and length Attributes and elements Formal Model Integrity in ARIS Permissible value range for GDT and its elements External integrity conditions of GDT Internal integrity conditions of GDT between elements and attributes General use or example use cases Further information about GDT 8. Code List 9. Qualifier List Type of code list Code definition, name, and value Formal Model Integrity in ARIS Definition of qualified GDT

79.  SAP AG 2004, Business Object Governance, Michael Seubert / 79 CPM – Areas of Expertise (1) Area of Expertise fundamental area of knowledge relevant for checks structures Coaching Procedure Model (CPM)  „orthogonal“ to steps and topics allows easy identification of problem areas in the design of Business Objects, Data Types and Messages  for coaches, integration experts, content owners  for errors and warnings in check report

80.  SAP AG 2004, Business Object Governance, Michael Seubert / 80 CPM – Areas of Expertise (2) GOV – Governance CONCEPT – Conceptional OBJ – Understanding of modelling objects (BOs, nodes, elements, DTs, MTs)  DEF – Definition  CAT – Categorization of modelling objects  ATTR – Attributes NAME – Naming S&R – Structure & Relationships TYP – Typing ARIS – ARIS formal model integrity TMPL – Consistency: template object  projection object

81.  SAP AG 2004, Business Object Governance, Michael Seubert / 81 CPM - Screenshot