Skip to Content

SAP is very strong in enterprise data modeling. This is not very surprising because because SAP has long experience with that matter since R/3. SAP created  a methodology (SAP SERM) and developed tools like Data Modeler (see my weblog series starting with Data Modeling and Database Design in ABAP – Part 1 ). SAP was one of the first who combined business objects (BOR) with data models.

Later SAP used BOR objects as backbone of their SOA strategy. So the methodology changed a bit:

  • UML enhanced by concepts of SAP SERM and became UMLplus
  • there was a redesign from a conceptual point of view because BAPIs as methods of BOR objects don’t have a common granularity
  • BAPI data types have been replaced by concepts we know from ebXML
  • the BAPI programming model was replaced by SOA communication patterns
  • a lot of mature and well-understood concepts from ALE have been ported to SOA context

What’s Concept Model of Enterprise SOA?

This was guided be a sophisticated SOA methodology which you can find on SCN:

These concepts are the foundation for SOAP web services in B2B and A2A context with

  • standardized data types
  • standardized communication patterns
  • an underlying business object model

These concepts are the basis for a semantic model – a framework called enterprise SOA although SOA@SAP would be a better name – which I described in a blog  Semantics of Web Services. SAP provided powerful tools like Enterprise Service Workplace which help users to consume web service from SAP Business Suite.

But sometimes this is not enough: As Enterprise Architect you have to deal with different SOA frameworks and methodologies and you have to bridge the gap between the different worlds. The same is true if you want to implement your own Enterprise Services. From my experience it above mentioned standard are quite complex because they are full-fledged and cover many details.

Ontologies as Tool for Documentation

Enterprise SOA Object & Services Modeling guidelines define many concepts. To mention a few:

  • subtypes of Business Objects: Dependent Object, Transformed Object, Technical Object, Mass Run Data Object, Template Object
  • Dependent Objects: Access Control List, Accounting Clearing Object History,  Accounting Coding Block Distribution, Address, Attachment Folder, Business Folder, Business Plan Foundation, Business Process Assignment
  • subtypes of Service Operation Categories: Compound Operations like B2B, A2A and A2X operations, Core Operations like CRUD, Query and Action Operations
  • Business Document Objects, Message Types which are types as Message Data Types
  • Actions, Action Data Type and Action Data Type Elements
  • Global Data Types like Amount, Binary Objects, Code, Date, DateTime, Duration, Graphic, Identifier, Measure, Name, Numeric, Percent, Quantity, Ration, Sound, Text, Time, Value and Video
  • Data Types: Node Data Type, Intermediate Data Types, Filter Data Type, Key Data Type, Action Data Type, Query Data Type, Query Intermediate Data Type, Extension Data Type, Basic Global Data Types, Aggregated Global Data Types
  • subtypes of Service Operation Categories: Compound Operations like B2B, A2A and A2X operations, Core Operations like CRUD, Query and Action Operations

 But this is not sufficient to understand eSOA methodology – we need

  • classification of those concepts
  • textual definitions (perhaps as links)
  • comments
  • definitions of relationships between concepts
  • examples i.e. instances of those concept
  • links to other sources information

In fact we have standardized tools to express those concepts in a formal way using ontologies using W3C standards like OWL. I already blogged in my weblog series “Enter Semantics” about applications of ontologies to build expert systems but we can use them as successor or topic maps. But we can use those tools for creating, querying and visualization of concept models. So they both useful as (cheat) fact sheet, formal definition and can be used as guideline to find ones way in textual definition.

Ontologies have been successfully used to express complex domain in medical and life sciences think of classifications of diseases, genes and definition the foundations of specific  knowledge domains

Towards a SAP SOA Foundation Ontology

Ontologies have the chance to raise knowledge management to a higher level because of the following features:

  • they have the power of description logics what means that they can check logical consistency of defined concepts
  • they can contain links to other sources information and can serve as central hub linking different sources of information: SAP Library, whitepapers, Release Notes, applications like Enterprise Service Place resp. Solution Composer and even non normative resources like blogs and so on.

In my opinion one of the world’s best software companies has to ship would class software as well as world class documentation of the software as well as the underlying concepts and standards. The sheer amount of documentation as well as its complexity of the concepts make it necessary to use new techniques. Other domains like medical information science provide well understood methods and tools with complex knowledge.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply