Michael Seubert, Axel Kühl, Dirk Richtsteiger (Coaching Team)

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

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

Introduction


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 Contentwhich is

generally accepted & well known in the business world (outside-in) consistent and redundancy free

„Who does what when how“


Governance Process: PIC 0 and PIC 1,2,3

PIC 01 PIC 02 PIC 03

PIC 1 PIC 2 PIC 3

GDTPIC

ESA EntityIdentification

& Cut

IntegrationScenarioStructure

ServiceOrchestration

Identification of BO’s,PC’s, DU’s

(Name and Semantics)

Identification of PC’s and PC

interactions withinIntegration Scenario(Name and Semantics)

Identification andcut of Service

Operations andInterfaces within

PC interaction(Name and Semantics)

Definition of Node Structure of BO

NodeStructure Elements

Actions, Queries,Interfaces

GDT’s

Detailed Definition ofGlobal Data Types

AssignmentGDT’s to BO

nodes

Definition of Actions,Queries, compound

services

PIC 01approval

Required tostart PIC 1

PIC 03

approval of PCIM’s(Interfaces and Serv.Operations) required

to start PIC 3

ChangeRequests


Process Integration Content (PIC) Governance

Governance Coaching, Steering, Approval

• Business Objects• Interfaces / Operations• Global Data Types (GDTs)

PIC 1 PIC 3PIC 2

Scoping,

Identification

Definition

Implementation

Structure Elements Service 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

Identification GDTs

PIC 1,5

PIC Council Approval

PIC Governance Process: Roles and Tasks


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 B C

Methodology Council:Methodology, Design Rules, Procedure Model

D

Organizational structure with roles and tasks (A – D)


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



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



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 council

Staffed with representatives (10 – 12) from AP Operations Platform areas (10 - 20 % FTE)

Development Business UnitsNetweaverCoaching Team

(interface, process and business object experts)

Responsible for high quality of Process Integration Content

C


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

Governance for Business Objects and Operations


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


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

EscalationInform SVP

Sign-Off PhaseConsolidationOpen Issues

PIC MeetingOpen 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 OKOK 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 wordAfter change before review

Business Object Taskforce (BOT) 1

New generic concept

1 ) BOT: staffed with architects of development areas


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 ProcessPIC Governance Process

New generic concept

eSOA Guideline

Offline Review by IE + KM + Coach

PIC MeetingOpen Issues

PIC Scheduling

Online Review

First occurrence

of new concept

Further occurrencesof new concept

Creation/Change of BO in Aris


BO finally approved


Alignment in AP and between AP and BS

BOT / BOWPIC 1-3,GDT

ANT

SDMC

PIC 0,1-3 Enterprise SOA

Architecture Team

Horst SchnörerBernhard Drittler

Stefan Kaetker (sponsor)

Klaus Enders (operational lead)

Günter Pecht-SeibertMichael SeubertAP

Business Suite

Process Modeling, PIC 0

Stefan Kaetker

Info Highlights, Escalation path

Alig

nm

ent,

if S

AP

rele

van

ce

SAP aligned (AP + BS)

Alignm

ent, if SA

P

relevance

Info about Topics

with Modeling Impact


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)

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)

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"


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.


PIC Review Documents: Version Handling (2)

Initial Document

PIC 1 .

preparation PIC1 Review PIC1 postproc.

PIC 2 .

PIC2 Review PIC2 postproc.preparation

changes in ARIS

PIC 3 .

preparation PIC3 Review PIC3 postproc. SAP wide review

.

changes in ARIS

preparation

New Initial Document

time

Changes:

review cycle

1 1+2

1

1+2+3

2

3

1 +

2 +

3 +

1

.Q & A Doc

Review Document

.

changes in ARIS: To be documented in Q & A


BO PIC Governance Process Type

BO PIC Gov. Process Type

Reviewer Time PIC steps

Normal IEs, KM, Coach

1 or 2 weeks PIC 1, PIC 2, PIC 3, PIC 1-2, etc.

Lean Coach ca. 1 week always PIC 1-3

Lean Fast Track Coach 2 days always PIC 1-3

Bug Fix Coach 3 days always 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


Additional Governance Rules


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


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


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) 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: <MT-name>_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. Owner informs Steffen Wolf (D040280) from AP Operations via e-mail that the excel is provided

Starting of PIC Process via leading Business Object


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 reviewIntegration 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


Interactive Form Message Split

InteractiveForm Message

Message(Type A)

Message(Type C)

Message(Type B)

for example, Interactive FormCustomer Requirement Fulfillment Request

For example,Customer Invoice Request Request

For example,Customer Requirement Fulfillment Confirmation

For example,ProductAvailableToPromiseUpdateNotification

IForm Customer Requirement & Outbound

Delivery Processing

Sales Order ProcessingSales Order Processing

Fulfillment OutFulfillment Out

Fulfillment InFulfillment In

Sales Order

IForm Customer Requirement Fulfillment

Request

Customer Requirement Fulfillment ConfirmationCustomer Requirement Fulfillment Confirmation

Customer Requirement

Out

Switch /Split

IForm Customer Requirement

Fulfillment Confirmation



Customer Invoice ProcessingCustomer Invoice Processing

Customer Invoice Request RequestCustomer Invoice Request Request

RequestInvoicing in

ProductAvailableToPromiseUpdateNotification


Switch /Split


IForm Customer Requirement & Outbound Delivery

Processing

Example: Form Split in A2A Scenario with Partial Use

Sales Order ProcessingSales Order Processing

Fulfillment Out

Fulfillment In

Sales Order

IForm Customer Requirement Fulfillment

Request

Customer Requirement Fulfillment Confirmation

Customer Requirement

Out

Switch /Split



Customer Invoice ProcessingCustomer Invoice Processing

Customer Invoice Request Request

Request Invoicing in



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


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 !


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 extension

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) Add row Add name of Extension (column D): <BO name><Extension name>_Extension

e.g.: PersonnelChange_Template_CN_Extension

Add “date of entry” and set “Extension” in Request column of excel sheet.


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)

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) 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)


Governance for Alignment of B2B / Level 3 Services


eSOA Cooperation Model Business Suite / AP

Joint PIC 0Joint PIC 0ReviewReview(to validate(to validate

Level 3 Level 3 Services)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 contentDo not block agile projects for content development on both sidesFocus 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 foreSOA by Evolution

Full scope service enablement for

eSOA by Design

Joint Steering Committee(NW, Biz Suite, AP, evtl. B1)

PIC 1, 3in Business Suite

PIC 1,2,3in AP

AlignmentFor Level 3

Services

DecisionDecision


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 ModelsEnterpriseServicesrealized in AP

SAP-wide BO ModelKernel(smallest common denominator)

BS Business Object ModelsSol. spec. Extensions

SAP-wide BO ModelKernel(smallest common denominator)

Other SAP Solutions

Level 3EnterpriseServicesrealized in BS

Transformation(Projection ++)

Kernel copy inBS BO Model

Mapping forrelevant servicesalong integrationscenarios must beprovided

Kernel

Kernel


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 ServiceB.Drittler; M.Seubert; Suite IE; AP IE

SAP Core: Projection based on AP Object ModelM.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 CoreB2B Service labeled with suffixB.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


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


Milestones and Deliverables


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


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


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

TypeCardinalityBCO?GDTProcurementDocument N 1 ProcurementDocumentElements

NodeID E 0..1 NodeID

SystemAdministrativeData S 0..1 BusinessTransactionDocumentAdministrationData

CreationDateTime E 1 DateTime

CreationSystemAccountUserID

E 1 SystemAccountUserID

LastChangeDateTime E 0..1 DateTime

LastChangeSystemAccountUserID

E 0..1 SystemAccountUserID

BuyerID S 0..1 BusinessTransactionDocumentID

Value E 1

schemeAgencyID A 0..1

SellerID S 0..1 BusinessTransactionDocumentID

Value E 1


BillToID S 0..1 BusinessTransactionDocumentID

Value E 1


BillFromID S 0..1 BusinessTransactionDocumentID

Value E 1


TypeCode E 0..1 x BusinessTransactionDocumentTypeCode

ProcessingTypeCode E 0..1 x BusinessTransactionDocumentProcessTypeID

PostingDateTime E 0..1 DateTime

ReleaseDateTime E 0..1 DateTime

TransactionDateTime E 0..1 DateTime

Name S 0..1 Name

Value E 1

languageCode A 0..1 LanguageCode

CancellationInvoiceIndicator

E 0…1 InvoiceCancellationInvoiceIndicator

AcceptanceStatusCode E 0…1 AcceptanceStatusCode

todo ToleranceGroupCode E 0..1 x BusinessTransactionDocumentToleranceGroupCode

to be discussed InputTypeCode E 0..1 x InputTypeCode

to be discussed TextMessageScenarioCode

E 0..1 x TextMessageScenarioCode

to be discussed (no concept for doc langu)

LanguageCode E 0..1 x LanguageCode

CurrencyCode E 0..1 x CurrencyCode

GrossAmount S 0..1 Amount

Value E 1

currencyCode A 1 x CurrencyCode

NetAmount S 0..1 Amount

BO Documentation- Definition- Nodes- Associations- Elements- Integrity- Actions- Queries- Service Operations

BO Elements

SupplierInvoice

SupplierInvoiceParty

SupplierInvoice

SupplierInvoiceBDTReference

SupplierInvoiceItem

SupplierInvoiceLocation

SupplierInvoiceItemParty

SupplierInvoiceItemProduct

SupplierInvoiceItemAttachment

SupplierInvoiceItemDescription

SupplierInvoiceItemLocation

SupplierInvoiceItemProductCategory

SupplierInvoiceItemHierarchyRelationship

Structure


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)

BO Documentation- Definition- Nodes- Associations- Elements- Integrity- Actions- Queries- Service Operations

SupplierInvoice

SupplierInvoiceParty

SupplierInvoice


SupplierInvoiceItem









Generated from ARIS via “Documentation-Report”


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

SupplierInvoice

Item

Product

Description

Attachment

Location

Party

BDOReference

Location

PartySupplierInvoiceParty

SupplierInvoice


SupplierInvoiceItem









SupplierInvoiceRequest

Delivery

PurchaseOrder

PurchasingContrcat

ProductCatalogue

Product

Locaktion

Party

Organisation

ProductCategory


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


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











Value E 1



Value E 1



Value E 1



Value E 1







Name S 0..1 Name

Value E 1













Value E 1




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











Value E 1



Value E 1



Value E 1



Value E 1







Name S 0..1 Name

Value E 1













Value E 1



BO Elements


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











Value E 1



Value E 1



Value E 1



Value E 1







Name S 0..1 Name

Value E 1













Value E 1




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 objectare specified according to this MT structure.

BusinessDocument

~ Object

Component Component23

Source Object Target Object

Outbound Operation Inbound Operation

„Defining“ Business Objectof central Object Model

Document based Integration

1


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


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


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).


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 <Form MT name> (derived from business object <BO name>) 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.


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).


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 structuresis 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


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


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_Engineering/ContGov/TemplateAndPattern_documents

Governance for Global Data Types (GDTs)


Detailed PIC Process for GDTs & Qualifier

AP OPS

Coaching Team

Owner and

Integration Expert

Escalation

Critical Issue

AP OPSSchedules the PIC review

of the GDTAgenda two days before

Scheduling

GDT approved finally

Suited for review?Check by Integration Expert

Creates /changes document in ARIS


rejected

AP OPSSchedules the SAP review;

creates GDT

Critical Issue

PIC Council Meeting

SAP review

Scheduling

objectionsCoaching 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


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 OPSARIS: GDT PIC status set to “GDT

approved”; Portal: GDT Status set to green;

GDT moved to archive

Coaching TeamGDT PIC status set to

“Withdrawn”

AP OPSPortal: 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 TeamGDT 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


SAP review (two weeks)

no objections


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 CompositeApplications

SAP CompositeApplicationsSAP CompositeApplications

Code-GDT & valuesNew & change request

provides basis

A1S


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


Applying for New Qualifiers

Prerequisites by Qualifier Owners:

• Create Group “<GDT_name>_Qualifiers”

• Create Model “<GDT_name>_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


Applying for New Qualifiers for Restricted CDT/GDTs

Prerequisites:

• Create Group “<GDT_name>_Qualifiers” (common for all qualifiers)

• Create Model “<restricted_GDT_name>_Qualifiers” within Group

• Add desired qualifiers to Model (common for all qualifiers)

Governance:

standard governance process

Example in ARIS:


Applying for New Codes / Code Lists

Prerequisites:

• Create Group “<GDT_name>_CodeLists”

• Create Group “<Code_list_name>” within Group

• Create Model “<Code_list_name>” within Group <Code_list_name>

• Add desired codes to Model

Governance:

1. Group <Code_list_name> moves through Governance Groups

according to PIC progress

2. Coaching Team integrates approved code list

1

1

2

3

2

3


Change Request for Codes / Code Lists

Prerequisites:

• Create Group “<GDT_name>_CodeLists”

• Create Group “<Code_list_name>_Vx” within Group (Vx = version number)

• Create Model “<Code_list_name>_Vx” within Group

<Code_list_name>_Vx

• Add desired codes to Model

Governance:

standard governance process


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


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)

• Copy of GDT “<GDT_name>_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)

Governance for Global Data Types (GDTs)

Milestones and Deliverables


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





PIC Council Meeting

SAP review


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





PIC Council Meeting

SAP review


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





PIC Council Meeting

SAP review

Coaching Procedure Model (CPM)


CPM in a Nutshell

GovernanceCoaching, Steering, Approval

• Business Objects• Interfaces / Operations• Global Data Types (GDTs)

Scoping,

Identification

Definition

Implementation

Modeling Guideline

7. Elements: definitions,

names and structure

8. Typing of elements

9. Operations, queries and actions

11. Message Data Types

10. Message Types

12. BO Template and Projection

……….

7. Elements: definitions,

names and structure

8. Typing of elements

9. Operations, queries and actions


10. Message Types

12. BO Template and Projection

……….

Coaching Procedure Model

approvedPIC Document

Check !!!


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


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


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


CPM – Steps & Topics for BOs (2)

7. Elements: Definition,

Name and Structure

8. Typing

9. Operations, Queries and Actions


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


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


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


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


CPM - Screenshot