This blog contains various ideas / thoughts about Enterprise SOA topics. I might write longer blogs about these topics later but I wanted to get the ideas out in the community to start discussions. You never want to have your ideas die in isolation – it is more satisfying to see your ideas out in the world where they are exposed to others.
Many of these fragments contain more questions than statements but this reflects the fact that I am not sure in which direction the ideas are taking me. These ideas are not fully developed otherwise they would be blogs of their own. If someone wants to take these ideas and create their own blogs, please feel free to do so.
GP (CAF) and XI
I have written numerous blogs about Guided Procedures (GP) and have received some comments about Exchange Infrastructure (XI). I think an analysis of the relationship between the two technologies demands more attention. Of course, XI concentrates more on automated processes (without human interaction) while GP focuses more on processes that contain human interaction. This obvious distinction would be sufficient to fully describe this relationship if processes were either purely automatic or based on only human interaction. As is evident in the real business world, this is rarely the case. Many processes contain parts of each process type. Thus, the technical implementation may include components that are based in XI and some that are based in GP; thus, a new process type – “mixed” processes is born.
Questions arise concerning the impact of this realization on the relationship between the design process and how the resulting processes are implemented. For the BPX designing a process at an abstract level, the technical realization of the process steps is largely irrelevant – indeed, the technical implementation may change over time (for example, when a legacy application is replaced by an service-enabled application). The most important factor is that the domain requirements that are the foundation for the process are fulfilled.
Related questions / points might be:
- In some ways, XI and GP are actually very similar. For example, both have the ability to integrate legacy applications – albeit at different levels. XI has its adapters and GP has its various Callable Objects.
- If a process is largely based on human interaction but still includes a series of service-based, should “automatic” process be wrapped by a single XI web-service? Or should CAF Core be used?(Note: This would probably be an interesting blog – When do I use XI and when do I use CAF Core? XI for existing services and CAF Core for extending services?)
- What do operations-related tasks, such as deployment, monitoring, etc. of such mixed processes look like?
- Who initiates the process XI or GP? Or is this decision based on domain requirements?
- If a service needs to be developed, then there must be some technical role in the project who decides what the optimal development platform is – either XI, CAF Core or something else.
Enterprise SOA and BPM
Whenever I read about Enterprise SOA, I always think “Technically very cool. But what is the business case for moving in this direction.” Without a motivation for moving towards Enterprise SOA, it will never make inroads into the corporate world. It is only when you start looking at how to combine Enterprise SOA with process optimization that this new technology really begins to show its potential.
This does not mean that BPM is purely SOA-based. In the real world, there are many processes that still contain process activities that include legacy applications; thus a process landscape, especially those processes that involve human interaction, that is purely service-based is probably still has a long way to go before becoming reality. Therefore, it is critical to use process tools that are able to use these legacy applications.
Thoughts on the Future of Business Packages
I have a love / hate relationships with Business Packages (Business Packages (BP) are prepackaged software from SAP or Partners that usually focus on a particular industry or organizational role. For more information, see the Portal Content Portfolio. I love the ability to basically install the software, add a few systems in the portal, perform a few customizing changes in the backend and the end-user has an initial set of IViews / Web Dynpros that he/she can use. I hate the problems that occur when the customer requirements don’t exactly match the functionality included in the business package. In the past, there were limited customizing options:
- You could change the associated IView properties
- You could perform back-end customizing (usually via IMGs)
- You could change the Portal PCD objects (for example, removing BP IViews from pages or adding new IViews to pages, worksets provided by the BP)
If the necessary functional requirements were not met by these changes, things got difficult. And these discrepancies are bound to occur, because the functionality in the BPs represented SAP’s attempt to create a standard that met the requirements of as many customers as possible.
However, recent developments, especially as seen in the latest version of the Business Package for Employee Self-Service (mySAP ERP), have given me hope that things are changing for the better. In particular, the XSS now includes the use of GP processes for certain life events (marriage, etc.) The advantage of this change is that organizations can now change the processes to accommodate differences between their own processes and those rolled out by SAP (Of course, the support issues are interesting. If you change a standard process from a BP, what happens to your SAP support…). The main advantage is that BP processes are no longer hidden in some Web Dynpro wizard but can be adapted. Of course, since these Web Dynpro components included in the existing BP-based processes all support the GP Interface, they can be can also be used in new GP processes.
A more radical approach would be to release parts of BPs as Visual Composers models. Then it would be possible to change the UI itself to fit a company’s needs. If you look at XApps, especially XApp Analytics, you can download the associated Visual Composer models and floor plans. The “important note” from SAP regarding these applications is intriguing and might be suggestive of future developments in this area: SAP xApps Analytics will not be maintained or supported by SAP, nor will SAP provide new versions and/or releases of such SAP xApps Analytics.
Ideally, Business Packages might provide similar VC models. This would give BPXs much more freedom to adapt existing BP content to the particular characteristics of the corporate process landscape in which they work. This is critical, because it is often these differences between the existing SAP standard and distinct organizational context that represent the innovative / dynamic heart of the organization that provides it with a competitive advantage in the marketplace.
