Skip to Content

Enterprise SOA Explorations: The Famous Question of the Division of Labor

If you are expecting a political discussion focused on Marx’s definition of this eternal debate in this blog, then you will probably be disappointed by the discussion that follows. This blog concerns the relationship between Business Process Experts (BPXs) and more technical project roles (usually originating from IT departments) in an Enterprise SOA environment. Although I won’t be discussing the conflict between capitalist and proletariat, a comparison of this famous relationship and that of the BPX and developer / technician would definitely be intriguing and ideal for those late night TechEd discussions with colleagues.

A Caveat:  The role of the BPX is just being defined and here I go and change the definition. This blog is an attempt to empower BPXs.  Some might argue that this empowerment really isn’t necessary or is counter-productive.  In my opinion, the more control BPXs have over their process-related environment, the more productive they become. This change mandates that BPXs no longer restrict their work to primarily non-technical tasks but that they move into tasks that are more closely related to process implementation. The related question is whether BPXs want this independence. This means that they are more responsible for their processes. The critical question is where to draw the line: How far can the BPX role description be stretched to increase productivity without over-extending these individuals.

Now some of you might be thinking that this is just my interpretation of the present and future role of the BPX in the entire development process. However, if you look at SAP’s material on Composite Applications, you see a similar interpretation.  The slide below is from a SAP TechEd Session: “CD153: Modeling Composite Views with SAP NetWeaver Visual Composer”. As seen in the slide below, when dealing with Composites, the BPX works with GP while the developer is responsible for tasks in CAF Core.


Furthermore, I discussed this issue with Volker Stiehl in recent “Composition Methodology Meet-the-expert session dial-in informaiton is available!”  who also agreed that BPXs should be involved in some Guided Procedures (GP) tasks.

Although this blog will focus on Guided Procedures, I will also discus other SAP tools in SAP’s NetWeaver landscape.  It is important to note that the activities of the BPX span multiple application areas.  Thus, an accurate description of their entire work environment would include GP, Visual Composer and other tools. 

Of course, in an ideal world, the ability to import a design into GP would eliminate the necessity of writing this blog. However, as Guided Procedures Explorations: BPEL Integration – The long answer has shown, this is currently impossible. Thus, processes to be implemented in GP must be “designed” twice – once in the typical design tool (such as ARIS) and once in the GP design-time.  Furthermore, a possible import based on BPEL or another standard might not solve all problems inasmuch as the assumption of a 1:1 relationship between design and implementation is usually not met. The process in question usually must be enhanced / changed in its implementation stage to reflect its true characteristics in a real business context. 

The primary motivation for this blog is that BPXs should perform all tasks (including those in GP) that can be seen as being included in their role description.  In my opinion, these tasks include building processes in the GP design-time. BPXs shouldn’t have to perform tasks that require information to which they do not access (for example, regarding portal infrastructure) or necessitate development activities (for example, the development of Web Dynpro services) where they have no experience. 

An examination of a possible UI development strategy shows the possible enhanced role of the BPX. In our example, we have a GP process that requires a User Interface (UI) component to meet a particular user requirement. We have at least four possibilities to deal with this requirement.

  1. Use existing UI components that are already present as GP Callable Objects (COs)
  2. Use GP’s inherent form capability (“Web Dynpro Form”, “Data Input Form”, etc.).
  3. Use Visual Composer (VC) to create the UI component
  4. Create of a new Web Dynpro UI component

Of course, the easiest solution is that all four possibilities are performed by a technician or developer based on the design document provided by the BPX. However, I feel that the BPX could very easily perform the first three possibilities.

A closer examination of VC shows that the majority of functionality with the exception of the creation of web service-based data sources could easily be performed by BPXs.

Regarding GP, the functionality is much more extensive. Thus, it is necessary to examine the functional characteristics of the GP Design-time environment in detail to determine what tasks a BPX might be able to perform.  This examination is based on the assumption that 1) this environment should no longer be viewed as monolithic and 2) the functionality can be divided into BPX-based activities and non-BPX-based activities. 

To deal with the non-BPX-based tasks, I am going to create a new role: GP Technician (GPT). This role is restricted to GP-based tasks that are not able to be performed by the BPX. The actual individual who performs these tasks may be a developer but must also be aware of infrastructure-related system characteristics. For example, this individual must be aware of the location of various services or UI components and must be able to create COs based on concrete technical implementations (for example, a Web Page on a particular portal in the infrastructure).

GP Design time Environment for BPXs and GPTs

There are two possibilities in GP to influence the UI:

  • The visibility of COs

  • The visibility of particular functional elements

Both are configurable via the “Manage permissions” section of the GP Administration navigation area.

As I have suggested in earlier blogs, it is not possible to use non-standard roles in the “Required Permission” select-box. Thus, we must create an appropriate environment based on the three standard roles: “basic”, “advanced” and “expert”.  For our purposes, I am suggesting that BPXs should be assigned the portal role associated with “advanced” and GPTs should be mapped to the portal role associated with “expert”.

Our goal is to create an environment that supports BPXs when they work with GP.  I envision that BPXs create the first draft of their processes based on the top-down approach – including the ability to use available actions and in some cases COs that are process-oriented. If the necessary CO is unavailable, then BPXs can create dummy COs that provide basic logic and / or include input and output parameters.  The GPT can them come and create the COs that are missing. The BPX can then check to see if the process meets his/her requirements.  The advantage of this development process is that the GPT doesn’t have to get involved until absolutely necessary.

The following table lists an initial suggestion of which COs should be available for BPXs.  I have attempted to focus on those COs for BPXs that are based on activities that do not require infrastructure knowledge. This list is of course just a first attempt and should definitely be adapted based on organizational characteristics. However, it is critical to see that 1) GP can not be a monolithic application if it is also to be used by BPXs and 2) GP administrative functions allow the creation of two or more design environments using permissions. New is also the concrete link / mapping of thesepermissions to the BPX role in the development process.

 Callable Object Type Role
 Service GPT
 User Interface GPT
 Web Pages BPX
 Interactive Form GPT
 Web Dynpro Form BPX
 Data Input Form BPX
 Data Display Form BPX
 Data Display and Acknowledgement BPX
 Process Control  
 Interactive Form/File Approval GPT
 Decision Dialog BPX
 Offline Approval BPX
 Visual Approval BPX
 Numeric Decision BPX
 Decision (Comparison to Predefined Value) BPX
 Terminate Process BPX
 Initiate Process (Using Predefined Template) GPT
 Business Logic ??
 User Management  
 Choose a User BPX
 Read User Information BPX
 Check User BPX
 Assign Users to Process Role GPT
 Resolve Manager of User (Requires SAP HR) BPX??
 Return Process Role Member List GPT
 Send an E-mail in Background with Attachment (optional) GPT
 Send Notification GPT
 Read System Properties GPT
 Write to System Log GPT
 Current State Information (for example, Date and Time) BPX
 File Input ???

A similar table for GP functions would be useful and may be included in future blogs on this subject.

One idea might be to use GP itself to support this development work between GP and BPX.  A process based on “Send Notification” COs might be able to assist the communication that takes place between the two roles.

BPX Design finished BPX BPX selects process that is finished (is there a WD to do this?)
Implement Dummy COs GP Technician GPT replaces the Dummy Cos with real ones and updates processes so that they are active
Test Process design BPX BPX gets a link where he she can test the process
Accept/Reject process BPX BPX can accept the completed process or reject it with comments.

Other points that should be considered:

  • BPXs cannot activate the process. This is performed by the GPT.
  • Of course, the configuration work (including creation of transport packages, setting of end points) is performed by the GPT or GP administrator.
  • An Enterprise Service Repository (ESR) that reflects the search demands / semantics of BPXs is also necessary to assure that the BPX can find the process elements he/she needs.
  • The manner in which documentation (specifications, etc) are transferred between GPT and BPX is still relatively unexplored territory and will be left for other blogs or other bloggers to investigate.


Some might complain that the BPX should not be empowered and already has enough work on his/her hands without performing additional more implementation-related tasks. I agree completely. In the ideal world, the BPX would push a button in his design environment and the GP process would be created automatically. Unfortunately, this is currently not possible. Thus, the creation of processes in the GP environment must be a manual endeavor. The upcoming release of the Composition Environmentwill in all likelihood not change this problem.

Since BPXs have the most knowledge about their processes, I feel that they are the best candidates to fulfill these tasks.  An awareness of technical limitations that stem from their exposure in this environment may also influence their ability to design processes that not only represent the realities of the business world but also the limitations of the resulting IT implementations.

You must be Logged on to comment or reply to a post.
  • First of all, great post. 
    My comment is around the emerging role of “interaction designers.”  For year in the web world this role has played the intermediary between domain experts and technical experts.  This third role is a user expert.  They can provide design for navigation (eg: better to structure the application with only a few choices then a few more sub-choices or a large flat list) , usability (should we use a table of radio buttons or a drop down?), user validation and mock-up (create a paper prototype and pass it by a few users to see what obvious mistakes can be fixed before a line of code was written), and perhaps most important- the user cognitive model.

    The user cognitive mode is simply how users think of the relationship between data,  navigation, pages, etc.. .  THe analogy in Windows would be to imagine if every Microsoft developer or product manager decided to implement their own interaction model?  You might have the situation, for example,  that some files can _only_ be opened by application that created it, while others can be opened by double clicking the file.  Or, you might have the situation that a single click means “open” on the desktop, but in Windows Explorer, single click means select.

    In the end- I think that we will see that the best BPX people are naturally interaction designers as Richard suggests, but until we recognize these skills as an important part of creating usable software, our applications will succeed or fail seemingly at random.

    • I agree that interaction design is critical for user acceptance. The question is what tools are available for BPXs to perform this function.  I think that Visual Composer is currently the only real possibility  to adjust UI components to user requirements.


  • One of the challenges with this approach is that the limitations/capabilities of the tools often dictate the “functional roles” of the project participants, as well, of course, of the functionality of the ultimate solution.

    A couple of the challenges I see with the current approach are:

    – The data model is *intimately* bound to the UI model (in Visual Composer).  I think an intermediate tier of “data services” is a much better long term approach.  Also, much richer data transformation capabilities can be added to this middle tier.

    – Flexibility of the UI.  For certain use cases, VC is perfect. At present, there are many use cases, however, where more flexible solutions (e.g. more general purpose UI technologies) can deliver a better user experience (more suited to the task, process, or user)

    – Rick