Why NetWeaver matters as a composition platform, part three

Now in part three, we'll complete the introduction of the Enterprise Process Framework by translating the Business Process Models into executable and manageable Enterprise Business Processes.

We previously covered in the part two the Enterprise Process Inventory and the Enterprise Process Definition phases of our Enterprise Process Framework. Now we'll cover the Enterprise Process Design, Development, Execution and Support.

Enterprise Process Design

At this point we need to add technical specifications to our business process models. That means somebody will need to act as the translator between two very distinct languages. I know SAP is pushing for the BPX. So for the sake of this explanation, let's assume we, the BPX, are that translator. We'll need to extend a model defined using business language (create, check, approve, notify, update, analyze, mitigate, assign, get, identify,… and a million terms later…) into a model described in technical terms (EP, VC, WD, GP, WS, RFC, BPM, Java, Abap, SCA, SDO, -- a million terms later). How are we going to do that? In traditional development paradigm, state-of-the-art application architecture says you need to define clear separation layers between Presentation -> Action -> Data. MVC (Model View Controller) is a good concept abstraction example to do it. Webdynpro, SAP UI development technology, allows you to do it. But that is not going to help us here. As much as we can we want to get away from traditional development means resulting in development projects and coding. At this very moment even before start the technical specifications, the need for composition technologies is clearly an absolute necessity. What really is of essence here is how can a BPX translate business language into composition language not plain technical language?

Not defining composition specifications and jumping straight into technical specifications would mean mission impossible or suicide attempt for the most BPX.

So let's take our model and add composition specifications to it. I'll make two major assumptions: first the BPX is well averse in the composition technologies of NetWeaver (Visual Composer, Guided Procedures, CAF Service Layer, UI patterns) as well as a basic understanding of the other NetWeaver technologies like (Webdynpro, Adobe, BPM…) and second, the BPX cannot code.

Let's reuse our example we've defined in Part II of this blog and the grey and red boxes. (sorry about the unreadable content but the colors are what's important).

- In yellow we have the process roles. How do you determine them at design time and runtime, manually via user interaction or programmatically in background?
- In green we have the process actions. If tied to a role what kind of user interface and user experience or interaction? What kind of business logic local or remote? Accessing data locally or remotely? Analytical, transactional or both?
- In red, we need for each action to know the input, output, exceptions and result states.
- In grey, we have the user interface to provide to the role to execute a particular action. What kind of UI? Visual Composer (VC), Web page, Webdynpro, EP iView, Adobe Interactive PDF Form… or is there any predefined UIs that can be reused? Does this UI need to provide ad-hoc and contextual analytics or reports to support any decision making? Can the analytics be composed? Is there a need to access contextual documentation?
- In blue we have the systems hosting the services or data to access or update. What's the communication protocol to use? WS, RFC, JDBC…? Which BAPI or web service or Enterprise Service can be reused? Synchronous or asynchronous? Real-time or not? Do we need to access backend systems via CAF Service Layer or BPM or UDDI or ESR?
- In purple, we have the events or result states. What trigger the events? a UI or a program?
- About the process flow, what workflow engine? GP or BPM? Are we doing content-based routing based on a parameter or event-based routing or even role-based routing? What are the workflow requirements? Any due-date handling? Delegation? Parallel processing? Optimistic versus pessimistic scenarios?

Once we get to this level of composition specifications we should have a clearer understanding of the development units to define technical specifications for.
- UI: what's the layout, what's the user interaction and experience…? What's the UI technology to use?
- Business Logic or Services: what's the algorithm or control based on the input parameters in order to get successful output or not? What's the development language to use?

At this point, we can use traditional technical specifications templates we're used to in our traditional development environment. That's when you need to have your friends from IT to come in and help you. The best would be to get support from the IT Enterprise Architects, Planning or Strategy teams because unlike IT Development, Realization or Support teams who have to deliver productive solutions, they see the big picture and can spend resource on prototypes. That would be a development job assuming we cannot find or reuse existing or predefined UIs or Services. And once those objects are developed and tested at the unit level, we can then use them to compose the end-to-end business process.

Enterprise Process Development

Business Process Flow can be composed using Guided Procedures (GP) or BPM Design time environments. The choice should have been made earlier. SAP positions GP for departmental processes versus BPM for enterprise processes. I'd argue with it. But the only thing I'd like to say is that GP is a much easier tool to get, setup, use and test than BPM. The usage of BPM Design is relevant in scenarios where no user interaction is required and it's pretty much about data process integration or EAI. I'm sure NetWeaver Product Management will enlighten us more on the pros and cons.

The CAF Tutorial Center in SDN (https://www.sdn.sap.com/irj/sdn/developerareas/netweaver?rid=/webcontent/uuid/d8dbd703-0801-0010-c9bf-c04bc52f562f) is full of how-to guides for BPX to start getting familiar with GP. Just install NW04s Sneak Preview or log into your NW04s server and you can start prototyping right away.

BPM in SDN ( https://www.sdn.sap.com/irj/sdn/docs?rid=/webcontent/uuid/0398f1df-0901-0010-c096-b4a578bcae5b) is the place for BPM information. Because BPM relies on XI and because XI cannot be installed as easily as NW04s Sneak Preview, you might want to ask your IT organization is there's a BPM server you can log into to experiment with the BPM Design environment.

Analytics can be composed using VC. As part of a process step, an analytics report can be a great tool to support a decision making. A BPX can compose it, make it available as part of a process step in GP, and map the parameters between the GP process step and VC analytics. That provides the end-user with a task to perform in GP and a link to launch the analytics passing automatically the input parameters for contextual report. That's what I call the power of embedded analytics as part of business process providing seamless and integrated user experience without a line code.

VC in SDN ( https://www.sdn.sap.com/irj/sdn/visualcomposer) is the place to get started. Like GP, VC is easy to get, setup, use and test. Just install NW04s Sneak Preview or log into your NW04s server and you can start prototyping right away.

Enterprise Process Execution and Support

Whether you use NetWeaver Java or Abap stack to run your business processes, both have their pros and cons and both are strong and mature platforms. At first I'll give you the consultant's answer: it depends. But I'd be more than happy to elaborate on those at a later stage if required. But if you manage to get to this point, I'd say "Congratulations BPX and welcome onboard with SAP Enterprise SOA". This is a small step but producing executable business processing with minimum support from IT is a big one towards the goal of the Agile and Flexible Enterprise.

I'd like to leave the technical considerations like performance, scalability, monitoring to our friends from IT who will get plenty help from our friends from SAP product management, development and consultants. The most important thing is that once you're able to demonstrate your running process to your management, you'd have helped your organization to see that what used to take months can take weeks and what used to take weeks can take days. And hopefully your management will use your prototype as an example for further and more serious commitment to NetWeaver Platform.

That kind of momentum is what SAP is obviously looking after. SAP customers and partners can start to embrace NetWeaver as composition or business process platform. It doesn't have to be the whole NetWeaver enchilada. It can be one step at the time and it can be via the composition paradigm. For that there's a need for a lot more willing BPX souls with innovative spirit to unlock the value behind all these innovative business processes… one prototype at the time.

Want to read more from this author? Click here to read Andre Truong's weblog. Click here to read more about Enterprise SOA on SDN.