Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
philip_kisloff
Active Participant


In Karthik SJ's insightful - but coy 😉 - blog about the problems of coordinating a common view of an enterprise's business process Lost in Translation: Business to IT, a passage about the shortcomings of the existing tools available bears a second look.

"The exercise [in documenting existing business processes] not only proves to be time-intensive but produces inaccurate and duplicate content. After several interviews and workshops, the business ends up with a number of processes that are captured and documented a number of times without any consistency or re-use. Besides this, the Business finds it is a major challenge to maintain, synchronize and govern content across the plethora of tools used by analysts."

While reading that I was reminded of the case for the widespread adoption of SAP Solution Manager and the promise to "provide a single version of the truth", one place where all landscape description, business processes designs, documentation and test validation can be stored.

For sure, when it comes to documenting business processes, SAP Solution Manager is not the easiest tool to use, but it does have a couple of unique advantages over other tools: it is aligned to business processes as have been defined by SAP and therefore provides a common structure for mutualised support teams; further, it has direct links into all SAP systems, providing a layer of meta-information that enriches and supplements the business process understanding. Where SAP Solution Manager falls down with respect to displaying business processes is with the graphics tab, that allows neither gateways nor an integrated representation of interfaces into the business process. Graphical representation of a process flow is really non-negotiable when it comes to sharing and understanding a previously unseen business process to a new audience.

The absence of a gateway construct is immediately apparent as a limitation, hence the popularity of incorporating tools like ARIS. The challenge of documenting interfaces "the Solution Manager Way" however, are more problematical to explain. This blog is about suggesting ways to meet that challenge. Detailed information on the Solution Manager approach can be found in the SDN article Interface Documentation with SAP Solution Manager. Summarizing the main issue in the Figure 1 below, the left hierarchy represents the business structure, and the right hierarchy represents the structuring of interface information, added to SAP Solution Manager 7.0 since ST SP15 /18 and STSER2008_1.



Figure 1: Side-by-side representation of business and interface hierarchies showing the point of interface assignment between two steps.

By way of visual orientation, Figure 2 shows both hierarchies on the left, and the graphical representation of these steps (in the Graphics tab) on the right.



Figure 2: Solution Manager Graphic Tab showing linking to business process and interface hierarchies.

There are good and bad parts of the current approach. The good thing about the SAP Solution Manager interface hierarchy is that it provides an almost identical symmetry for mapping between the two sets of hierarchical information. This makes for easier "bolting-on" additional interface-specific attributes to document interfaces for a business process (think: a place for everything and everything in its place). Unfortunately, it has the drawbacks that visually the interface assignment between process steps carries no additional information other than a simple icon indicating that further information is held in the interface hierarchy. It doesn't even have a name in the graphical diagram. To locate the additional interface information, there is a dependence on a cumbersome cross-referencing process with the interface scenario and adherence to a consistent naming convention.

Lastly, interface specific objects (e.g. ALE function modules etc) can't be documented in the interface hierarchy. Although they can be mentioned in the interface step attributes, but then special provision has to be remembered to be made in the business process step. Unless that is done, testing management will be incomplete. If it is done, then the business process model becomes very technical indeed, defeating the advantage of having all the information in the separate interface hierarchy!

The solution for SAP to the gateway and interface problems is obvious: to provide a graphical BPMN layer on top of the business process structure in SAP Solution Manager. Such as solution was demonstrated at TechEd '10 in Berlin and Las Vegas by Wulff-Heinrich Knapp as part of the Business Process Library (BPL) toolset.

Less clear however, is how best to incorporate and represent the message flows between two systems. This blog is about suggesting how interfaces in SAP Solution Manager can be shown accurately in a BPMN modelling tool. Remember that whatever is proposed here must not require changes to the functionality of SAP Solution Manager, while nevertheless providing a framework for enforcing best practice as there is flexibility and ambiguity in how Interface Scenarios are represented for different business processes and types of interfaces. A very good exposition of this can be found in How to Use Interface-Documentation on SAP Solution Manager.

This last reason is why the simplest representation of SAP Solution Manager in a BPMN modelling tool (continuing the separation between interface hierarchies and business process hierarchies) has in some way to be masked or encapsulated in a more coherent and visibly useful form.

 

Mapping a BPMN modelling tool onto Solution Manager Interface hierarchy.


A common artifice for structuring documentation in SAP Solution Manager is the use of a dummy process labelled as a divider e.g. "--------Process 1 -------" which is a null process without any steps, and only serves to separate one group of processes from another within the same scenario.  This doesn't map very well to a visual display of the interfaces described in a hierarchy, without generating all sorts of problems. The only way I can see around this is to co-opt the scenario level to become more than a thematic division, and represent either (a) group of interfaces within a process, or (b) all interfaces between two different systems. Lets investigate the pros and cons of each approach.

 

A) Interfaces Scenarios map to a process





Interface Scenario = "BPMN model X”



Pros


  • All message flows listed within a particular business processes

  • Allows unique naming/alignment of message flows between business processes/interface  scenarios


Cons



  • Does not promote re-use of interfaces between business processes


 


B) Interface Scenarios are between logical components




Interface Scenario = "System A -> System B"

Pros


  • Message flows listed across all business processes and business scenarios

  • Promotes re-use of interfaces


Cons



  • Observance of unique naming required across business processes


 

Mapping BPMN interface steps onto Solution Manager Business Process hierarchy.


There now follows three alternatives for representing steps in a process described by BPMN so that Solution Manager can act a back-end repository with corresponding steps.

 






Option1) Using throw/catch events without modelling send/receive steps





Message flows between throw/catch intermediate events make the process very clear in BPMN, but these events would not normally appear as business process steps in SAP Solution Manager. This option would be useful for when there are no objects to document separately the send/receive steps.


Option 2) Message flows between send/receive steps.





The step ornament would make the throw/catch events unnecessary. Steps for send/receive would be documented in the business step level, allowing for creation of test cases.


Option 3) Use of Data Objects to provide a business step for documenting interface objects





The Data Object artefact would appear as business process step associated with message flow to handling objects used in interface. This could be allowed under the bpm.org specification for BPMN 2.0 because "Data Objects provide information about what activities required to be performed". Also, annotation of message flows is now allowed. Having the same advantages of Option 2, the data object would only be associated with a particular system, meaning it would be limited for interfaces that send or receive from systems where only one of the systems are documented.



Where would this fit in with existing and future BPM modelling tools?


The life cycle of a business process follows the Design, Build and Run path. Design is when novel processes are communicated and recorded, perhaps building on legacy designs. Build integrates the design into the core components using development tools such as NetWeaver BPM. The Run part is where ongoing maintenance, testing occurs, and serves as a starting point for adaption, restarting the lifecycle again.

 

Design


The possibilities currently available to capture a new business process, mentioned at the beginning of this blog, are the plethora of desktop design tools. One of their disadvantages are that they only really only permit collaboration from a shared softcopy or picture, and are generally exacting in adherence to the BPM notation standards, something that is not really conducive to a free-flow of ideas and collaboration between often geographically dispersed business process owners and business analysts.

Currently under beta test the new cloud based Simple way to model processes in the Web using a subset of BPMN 2.0 (common executables) which eases the involvement of genuine business users and not just fully fledged BPM modellers. As it is cloud based, it is ideal for the collaborative design process required. My personal opinion is that Gravity should become a template creation of the process in the design phase.

 

Build


The NetWeaver BPM tool in the NWDS comprises of two perspectives, the Process Modeling perspective to sketch processes, mainly addressed to business analysts, and the Process Development perspective to make the process executable, mainly addressed to developers. My experience is that whatever is created in NWDS stays in NWDS because unfortunately the Process Modeling perspective is embedded in Eclipse, a technocratic development environment originally devised by developers for developers. Having said that, there may be extensions currently under development I know little about to bring the BPM design into SAP Solution Manager.

 

Run


What is also needed is something that merges the capabilities of both the design and build tools, and that would be a graphical Business Process Blueprinting tool. It's positioning would be to both to document processes for development in the implementation projects and also serves the requirement of maintenance projects.




7 Comments
Labels in this area