Enterprise soa object service operation design part i process integration content pic governance
Download
1 / 81

Michael Seubert, Axel Kühl, Dirk Richtsteiger (Coaching Team) - PowerPoint PPT Presentation


  • 91 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Michael Seubert, Axel Kühl, Dirk Richtsteiger (Coaching Team)' - roanna-clark


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Enterprise soa object service operation design part i process integration content pic governance

enterprise SOA Object & Service Operation DesignPart IProcess Integration Content (PIC) Governance

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

Nicole Leuchter (AP Operations)


Table of content pic governance
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



Governance process for business content business objects operations and data types
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
Governance Process: PIC 0 and PIC 1,2,3

IntegrationScenarioStructure

ESA EntityIdentification& Cut

ServiceOrchestration

PIC 01

PIC 02

PIC 03

Identification of BO’s,PC’s, DU’s(Name and Semantics)

Identification of

PC’s and PCinteractions within

Integration Scenario(Name and Semantics)

Identification and

cut of Service

Operations andInterfaces within

PC interaction(Name and Semantics)

ChangeRequests

PIC 03approval of PCIM’s

(Interfaces and Serv.Operations) requiredto start PIC 3

PIC 01approval

Required tostart PIC 1

NodeStructure

Actions, Queries,

Interfaces

Elements

PIC 1

PIC 2

PIC 3

GDT’s

Assignment

GDT’s to BOnodes

Definition of Actions,

Queries, compoundservices

GDT

PIC

Definition of Node Structure of BO

Detailed Definition of

Global Data Types


Process integration content pic governance

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

Process Integration Content (PIC) Governance

Governance

Coaching, Steering, Approval

Implementation

Scoping,

Identification

Definition

  • Business Objects

  • Interfaces / Operations

  • Global Data Types (GDTs)

PIC 0

PIC 1

PIC 1,5

PIC 2

PIC 3

Identification

Structure

GDTs

Elements

Service Operation

PIC Council Approval



Pic governance process and roles for business objects

Governance & Guidance by Coaching Team

Approval by Process Integration Content Council (PIC)

Business Objects / Nodes / Operations Data Types

Methodology

Business Objects / Nodes / Operations Data Types

PIC Governance Process and Roles for Business Objects

D

Methodology Council:

Methodology, Design Rules, Procedure Model

A

B

C

Development

by Project

Integration Experts / Content Owner

Organizational structure with roles and tasks (A – D)


Pic governance roles and tasks 1
PIC Governance: Roles and Tasks (1)

A

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


Pic governance roles and tasks 2
PIC Governance: Roles and Tasks (2)

B

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 /


Pic governance roles and tasks 3
PIC Governance: Roles and Tasks (3)

C

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 Units

    • Netweaver

    • Coaching Team (interface, process and business object experts)

  • Responsible for high quality of Process Integration Content


Pic governance roles and tasks 4
PIC Governance: Roles and Tasks (4)

D

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 0 3 review steps
PIC 0-3 review steps

PIC 0: Business Objects and Operations Identification

  • 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


Detailed pic 0 3 process for business objects
Detailed PIC 0-3 Process for Business Objects

Identification + Definition of Key Entities by PIC0 IE

PIC 0

Creation/Change of BO in Aris (english) according to guidelines

Color Legend:

Coaching

by IE + KM

BO Owner

Suited for Review? Check by IE

Integration Experts (IE) + KM Representative

  • AP Ops starts review:

  • Q&A-, SignOff-Excel

  • Inform: owner + experts

Name + Definition OK?

Coaching Team

AP OPS

  • secure copy in word

  • After change before review

Offline Review

by IE + KM + Coach

BO-Coach contacts PIC0 coach

1 ) BOT: staffed with architects of development areas

Escalation

Inform SVP

Critical Issue?

Check by owner

2 ) Clearing House: staffed with PIC0-Coach, Applicationexpert, PIC1-3 Coach, Integrationexpert, Object Owner, KM Representative

Name + Definition OK?

Clarification in Clearing House 2

Business Object Taskforce (BOT) 1

New generic concept

Online Review

OK with changes

ConsolidationOpen Issues

PIC Scheduling

PIC Meeting

Open Issues

Owner corrects open topics + informs coach

Sign-Off Phase

Not OK

Coach checks + set status in ARIS

OK

Creation of BO in ESR by Owner

Save all review documents

SAP wide Review

(only PIC 1 + 3)

Document Accepted?

Check by AP OPS

Change Request

IE informs AP Ops about Change Request

BO finally approved


Bot governance process for new generic concepts
BOT Governance Process for New Generic Concepts

PIC Governance Process

BOT Governance Process

Creation/Change of BO in Aris (english) according to guidelines

Topic Owner

PIC Reviewer:New generic concepts

Integration Expert:Critical methodological topics

Request for BOT

New generic concept

BOT (Methodology Council)

eSOA Guideline

Further occurrencesof new concept

First occurrenceof new concept

Online Review

Offline Review

by IE + KM + Coach

PIC Scheduling

PIC Meeting

Open Issues

BO finally approved


Alignment in ap and between ap and bs
Alignment in AP and between AP and BS

AP

Stefan Kaetker

Michael Seubert

Günter Pecht-Seibert

Info about Topics with Modeling Impact

Process Modeling,

PIC 0

BOT / BOWPIC 1-3,GDT

ANT

Info Highlights,

Escalation

path

Stefan Kaetker (sponsor)

Klaus Enders (operational lead)

SAP aligned

(AP + BS)

Alignment, if SAP relevance

Alignment, if SAP relevance

SDMC

Business Suite

Horst Schnörer

Bernhard Drittler

PIC 0,1-3

Enterprise SOA

Architecture Team


Bo pic governance focus on pic1 3
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
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
PIC Review Documents: Version Handling (2)

Initial Document

New Initial Document

Review Document

1

1+2

1+2+3

Changes:

preparation

PIC1 Review

PIC1 postproc.

preparation

1

1 +

1

..

..

PIC 1

preparation

PIC2 Review

PIC2 postproc.

2

2 +

..

PIC 2

..

preparation

PIC3 Review

PIC3 postproc.

SAP wide review

3

3 +

PIC 3

..

Q & A Doc

..

changes in ARIS

changes in ARIS

changes in ARIS: To be documented in Q & A

time

review cycle


Bo pic governance process type
BO PIC Governance Process Type

  • 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



Mdro governance
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
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
    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.xlse.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
    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
    Interactive Form Message Split

    For example,

    ProductAvailableToPromiseUpdateNotification

    Message

    (Type A)

    Switch /Split

    Interactive

    Form

    Message

    Message

    (Type B)

    For example,

    Customer Requirement Fulfillment

    Confirmation

    for example, Interactive FormCustomer Requirement Fulfillment Request

    Message

    (Type C)

    For example,

    Customer Invoice Request Request


    Example form split in a2a scenario with partial use

    Fulfillment In

    Fulfillment Out

    Customer Requirement Fulfillment Confirmation

    IForm Customer Requirement Fulfillment Confirmation

    Customer Invoice Request Request

    ProductAvailableToPromiseUpdateNotification

    Example: Form Split in A2A Scenario with Partial Use

    Sales Order Processing

    IForm Customer Requirement & Outbound Delivery Processing

    IForm Customer Requirement Fulfillment Request

    Switch /Split

    Sales Order

    Customer Requirement Out

    Customer Invoice Processing

    Request Invoicing in


    Additional mapping for interactive form message split 1
    Additional Mapping for Interactive Form Message Split (1)

    Mappings

    Message Structure C

    Message Structure

    Interactive Form

    Message Structure A

    Message Structure B

    • 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
    Additional Mapping for Interactive Form Message Split (2)

    No completion/enrichment of split messages with additional information: Split message contains only information from Interactive Form !

    CustomerRequirementFulfillmentRequest

    InteractiveFormCustomerRequirementFulfillmentRequest

    ProductAvailibilityToPromiseUpdateNotification

    Submit „ATP Confirmation“

    CustomerRequirementFulfillmentConfirmation

    Submit „Delivery Confirmation“

    CustomerInvoiceRequestRequest


    Additional governance rules for business object extensions
    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
    Additional Governance Rules for Data Flow Verification (DFV)

    ARIS currently does not support Data Flow VerificationTherefore 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 Business Objects and Operations

    Governance for Alignment of B2B / Level 3 Services


    Esoa cooperation model business suite ap
    eSOA Cooperation Model Business Suite / AP

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

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

    Joint PIC 0

    Review

    (to validateLevel 3 Services)

    Definition of

    Service Bundles for

    eSOA by Evolution

    PIC 0 in Business Suite

    PIC 1, 3in Business Suite

    Decision

    Full scope service enablement for

    eSOA by Design

    PIC 0 in AP

    PIC 1,2,3in AP

    Alignment

    For Level 3Services

    Joint Methodology

    (Modeling, Service Pattern, Lifecycle Management)

    Via Service Definition Methodology Council (SDMC)


    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

    Principles: Signature Alignment for Level 3 Services

    Enterprise Service Repository

    BS Business Object ModelsSol. spec. Extensions

    Level 3EnterpriseServicesrealized in BS

    Other SAP Solutions

    SAP-wide BO ModelKernel(smallest common denominator)

    Kernel

    Kernel copy inBS BO Model

    Mapping for

    relevant servicesalong integrationscenarios must beprovided

    SAP-wide BO ModelKernel(smallest common denominator)

    Transformation(Projection ++)

    EnterpriseServicesrealized in AP

    AP Business Object Models

    Kernel


    Esoa cooperation model with business suite

    • 100 % down-to-field level identical services not feasible 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

    PIC 0 in Business Suite

    Define and align SAP Core

    PIC 0 in AP

    PIC 0 Alignment Process

    PIC 1-3 in Business Suite

    PIC 1-3 in Business Suite

    eSOA Cooperation Model with Business Suite

    Level 3 Services

    Align BO & PC cut (Coaching Teams only)

    Validate Level 3 ServicesS.Kätker; B.Drittler; M.Seubert; AP IE; Suite IE

    SAP wide alignment required and feasible?

    No

    Yes

    SAP Core: Projection based on AP Object Model

    M.Seubert; B.Drittler; AP IE; Suite IE (PIC 1-3 in AP)

    B2B Service

    B.Drittler; M.Seubert; Suite IE; AP IE

    Extensions required?

    Yes

    B2B Service with extensions based on SAP Core

    B2B Service labeled with suffix

    B.Drittler; M.Seubert; Suite IE; AP IE


    Join pic 0 review
    Join PIC 0 Review BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    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


    Governance for Business Objects and Operations BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    Milestones and Deliverables


    Milestones four step approach for pic council approval
    Milestones: Four Step Approach for PIC Council Approval BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    PIC 0: Business Objects and Operations Identification

    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


    Approval topics
    Approval Topics BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    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

    • BO Documentation BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    • - Definition

    • Nodes

    • Associations

    • Elements

    • Integrity

    • - Actions

    • Queries

    • Service Operations

    BO Elements

    Structure

    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


    Milestone 1 bo structure pic 1
    Milestone 1: BO Structure (PIC 1) BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    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

    Generated from ARIS via “Documentation-Report”


    Requirements pic1 detail bo structure
    Requirements PIC1 (Detail): BO Structure BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    • Visualisation of BO structure

      • Semantic understanding of BO

      • Uniform representation “SAP Serm/UML Plus”

      • Contains

        • Packages

        • Nodes / Subtypes

        • Compositions / Aggregation / Associations


    Requirements pic1 detail bo documentation

    • BO Documentation BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    • - Name

    • Definition

    • Process Component

    • LDU (opt.)

    • Packages

    • Nodes / Subtypes

    • Compositions / Associations

    • Integrity

    • - Business Object Environment

    • Node Element Structure

    • Interfaces / Operations

    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


    Milestone 2 bo node elements pic 2
    Milestone 2: BO Node Elements (PIC 2) BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    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


    Requirements pic2 detail bo node elements

    BO Elements BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    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


    Milestone 3 bo service operations pic 3
    Milestone 3: BO Service Operations (PIC 3) BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    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


    Document based integration message type and operation signature
    Document based integration: BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasibleMessage 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.


    Requirements pic3 detail service operation documentation 1
    Requirements PIC3 (Detail): BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasibleService 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
    Requirements PIC3 (Detail): BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasibleService 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
    Requirements PIC3 (Detail): Message Type Document BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    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
    Requirements PIC3 (Detail): BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasibleForm Message Types

    For Form Message Types the same modeling rules and documentation guidelines apply as for non-form Message Types. Essentials are:

    • 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.”

    • Complete definition of message types (including element structure and mapping to BO)

    • 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, …)

    • 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
    PIC3 Approval BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    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
    PIC3 Incremental Approval Process BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    • 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


    Pic3 approval check list 1
    PIC3 Approval: Check List (1) BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    • 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
    PIC3 Approval: Check List (2) BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    • 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) BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible


    Detailed pic process for gdts qualifier
    Detailed PIC Process for GDTs & Qualifier BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    Color Legend:

    Creates /changes document in ARIS (english) according to guidelines

    Coaching

    by IE + KM

    Owner and

    Integration Expert

    AP OPS

    Suited for review?

    Check by Integration Expert

    rejected

    Coaching Team

    AP OPS

    Schedules the PIC review of the GDT

    Agenda two days before

    Scheduling

    PIC Council Meeting

    Critical Issue

    PICC Corrections

    objections

    Coaching Team

    Check of overall integrity of GDT in catalog

    Check of applied PICC changes

    Escalation

    AP OPS

    Schedules the SAP review; creates GDT

    Scheduling

    SAP review

    Critical Issue

    Change Request

    ARIS: copy of GDT with suffix “_Vx”

    IE informs AP OPS /

    Coaching Team about Change Request

    GDT approved finally


    Detailed sap review process for gdts qualifier
    Detailed SAP Review Process for GDTs & Qualifier BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    Color Legend:

    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”

    Owner and

    Integration Expert

    AP OPS

    Coaching Team

    Information of SAP review community with list of GDTs for new SAP review

    SAP review (two weeks)

    Objection(s) during review (by e-mail to coach or AP OPS)

    no objections

    Interaction coach <-> reviewer, owner / requestor

    objection rejected or withdrawn

    GDT approved finally

    GDT withdrawn

    GDT again in PIC Review

    AP OPS

    ARIS: GDT PIC status set to “GDT approved”;

    Portal: GDT Status set to green;

    GDT moved to archive

    GDT request dicussed and changed during SAP Review

    Coaching Team

    GDT PIC status set to “Withdrawn”

    Coaching Team

    GDT PIC status set to “ready for review”

    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

    AP OPS

    Further ESR actions have to be done if necessary


    Closed content governance cycle for gdt codes values
    Closed Content Governance Cycle for GDT Codes & Values BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    SAP Customer

    Consistent Content Delivery

    SAP Composite

    Applications

    SAP Composite

    Applications

    SAP Business Suite

    A1S

    SAP Composite

    Applications

    provides basis

    Application Platform

    Code-GDT & values

    New & change request

    PIC approved content

    Global Data Type PIC


    Gdt pic governance in aris
    GDT PIC Governance in ARIS BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    Document flow of GDTs follows progress of the governance process.GDT Group gets moved to appropriate Governance Group according to new status:


    Applying for new qualifiers
    Applying for New Qualifiers BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    1

    2

    2

    3

    • 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:

      • GDT owner consolidates requested qualifiers, IE requests approval

      • ARIS Objects Allowed Qualifier move through Governance Groups according to PIC progress

      • Coaching Team integrates approved qualifiers

    1

    2

    3


    Applying for new qualifiers for restricted cdt gdts
    Applying for New Qualifiers for Restricted CDT/GDTs BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    • 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
    Applying for New Codes / Code Lists BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    1

    2

    3

    • 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:

      • Group <Code_list_name> moves through Governance Groups according to PIC progress

      • Coaching Team integrates approved code list

    1

    2

    3


    Change request for codes code lists
    Change Request for Codes / Code Lists BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    • 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
    Application for Alternative Business Terms (ABT) BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasiblefor 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:

  • An ABT doesn’t follow standard Governance Process

  • Coaching Team is informed per email and checks the ABT for any contradiction in

    • code semantics

    • other code names

    • other ABTs

  • Coaching Team may raise a veto - else the ABT gets tracked at the code


  • Change requests on structure or nature of gdt
    Change Requests on Structure or “Nature” of GDT BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    • 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:

      • Change Request follows standard Governance Process

      • Coaching Team integrates approved changes into existing GDT, if Change Request is compatible (no new version required)


    Governance for Global Data Types (GDTs) BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    Milestones and Deliverables


    Milestone 1 application for approval
    Milestone 1: Application for Approval BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    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 2 picc approval
    Milestone 2: PICC Approval BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    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 3 sap wide approval
    Milestone 3: SAP-wide Approval BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    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


    Coaching BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasibleProcedure Model (CPM)


    Cpm in a nutshell

    BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    approved

    CPM in a Nutshell

    Check !!!

    Coaching

    Procedure Model

    Modeling Guideline

    PIC Document


    Cpm general
    CPM – General BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    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
    CPM – Structure BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    • 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
    CPM – BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasibleSteps & Topics for BOs (1)

    • Object Capsule

    • Object Category

    1. BO Cut and Understanding

    2. BO Definition

    • Standard (ISO 11179), Patterns, and Guidelines Compliance

    • Derivation of BO Name from Definition

    • Derivation of BO Category from Definition

    • Term

    • Abbreviation

    3. BO Name and Category

    • Determination of Roles (Object Specializations)

    4. BO Specializations

    • Cut and Definition of Nodes

    • Derivation of Node Names from Definitions

    • Determination of Roles (Specialization)

    • Root Node

    • Node Category

    5. BO Nodes:Definition, Name, Specializations

    • Structure Relationhips

    • Associations for Navigation

    • Cardinalities

    • Integrity Conditions

    • Cross-object Structure Consistency

    • Hiearachies and other Structures on Nodes

    • Arrangement According to Relationships

    6. BO Node Environment

    ...


    Cpm steps topics for bos 2
    CPM – BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasibleSteps & Topics for BOs (2)

    ....

    • 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

    7. Elements: Definition, Name and Structure

    • Elements

    • Integrity Conditions

    • Nodes

    • Filtered Relationships

    8. Typing

    • 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

    9. Operations, Queries and Actions

    • 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

    10. Message Types

    • Message Data Types (MDTs) for MTs

    • Typing of Levels of MDT

    • Integrity Conditions

    11. Message Data Types

    12. BO Template and Projection

    • Template object

    • Projection profiles


    Cpm steps topics for gdts
    CPM – BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasibleSteps & Topics for GDTs

    • Business subject and use case

    • Lookup of a “suitable” GDT and qualifier from the GDT catalog

    1. GDT Determination

    • Standard (ISO 11179) and guideline compliance

    • Business standard and pattern compliance

    2. GDT Definition

    • Derivation of GDT name from the definition

    • Standard (ISO 11179) compliance

    3. GDT Name

    • Restriction and length

    • Attributes and elements

    • Formal Model Integrity in ARIS

    4. GDT Structure

    • Permissible value range for GDT and its elements

    5. GDT Value Range

    • External integrity conditions of GDT

    • Internal integrity conditions of GDT between elements and attributes

    6. GDT Integrity Conditions

    • General use or example use cases

    • Further information about GDT

    7. GDT Use and Notes

    • Type of code list

    • Code definition, name, and value

    • Formal Model Integrity in ARIS

    8. Code List

    9. Qualifier List

    • Definition of qualified GDT


    Cpm areas of expertise 1
    CPM – Areas of Expertise (1) BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    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
    CPM – Areas of Expertise (2) BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible

    • 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
    CPM - Screenshot BO Model; it contains the new, leading and stable concepts; no 100% alignment cross all SAP solutions feasible


    ad