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.
- Use existing UI components that are already present as GP Callable Objects (COs)
- Use GP’s inherent form capability (“Web Dynpro Form”, “Data Input Form”, etc.).
- Use Visual Composer (VC) to create the UI component
- 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 |
| Form | |
| 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 |
| Miscellaneous | |
| 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.
Summary
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.
- SAP Managed Tags:
3 Comments
