Enterprise SOA Explorations: The BPX is dead. Long live the BPX.

[richard_hirsch]

I just finished attending a conference in California – SOCA 2007 Service Oriented Components and Applications) where I presented a paper on Enterprise SOA technology and Guided Procedures.

Although this conference was largely academic and focused on research in this exciting area, much of papers presented had definite implications about how BPX will work in the future.  The purpose of the conference was to:

provide a forum for researchers who are interested in the issues and practices related to the development of service-oriented computing, design and technology, including theoretical foundations, service infrastructures, and their applications and experiences.

I’m not saying that the stuff I saw will be in SAP products the day after tomorrow but I think the trends discussed were very intriguing.

 I would like to comment on the work of Prof.  W.T. Tsai(Arizona State University, Tempe), because after seeing his presentation dealing with Service-Oriented Software Engineering (SOSE) in the panel discussion I just started thinking about how design activities in the future might look. Amongst the areas that Dr. Tsai discussed is the area of Dynamic Process Collaboration (DPC) in Service-Oriented Architectures.  (There were other interesting presentations at the conference but those from Dr. Tsai made the greatest impression on me).

Collaboration in SOA refers to the interaction between two services – how the two services “talk” to one another.  Dynamic collaboration allows two parties not knowing each other establish to their collaboration protocol at runtime. Traditional SOA allows parties to collaborate but with a known collaboration protocol before execution. In dynamic collaboration, as collaboration protocols will be negotiated and determined at runtime, policies need to be generated at runtime to manage the interaction. Dynamic Collaboration is distinguished from Dynamic SOA in that collaboration protocols are known at design-time but services are selected at run-time. 

After the conference, I did some research and found that there are two papers from Dr. Tsai that I found the most intriguing:

• Service-oriented      system engineering (SOSE) and its application to embedded system      developm...: The first part of the article provides a good      introduction to the topic of dynamic collaboration.
• Ontology-based      Dynamic Process Collaboration in Service-Oriented Architecture:  This      paper was presented at the conference and describes in more detail how DPC      works and the role of ontologies in such environments.

Now you might be saying to yourself: “What impact does this have on me as a BPX. I design the applications at a high-level. What happens ‘under-the-covers’ / the technical stuff is irrelevant as long as it works”.  However, the transition from a purely static SOA where the designer has full control over how the composite application looks like to a dynamic collaboration where services collaborate independently at run-time has major ramificationson application design. 

When I first started thinking about these new developments, I thought “Wow. Services are going to create applications on their own.  Sort of like those little dwarfs who come out at night to help the old shoemaker in that famous fairly tale. Would we just tell the services to create a financial application and then the correct services would collaborate at run-time to create a new application on-the-fly without any intervention from the BPX. Was the idea of the BPX “dead” before it progressed from baby shoes to its productive adolescent phase?

After discussing my impressions with other conference participants, I learned that there are related developments that will change the details of process decision without eliminating the need for the BPX.  There will be application patterns - based on collaboration patterns – that will form the foundation of any composite application. The use of these patterns will be on a scale from the static use of existing patterns to creation of new application patterns that can in turn be published to promote re-use.  The use of application patterns will also promote adherence to governance standards. 

Now you might be thinking to yourself: “Hey, this is nothing new.  There are is currently the concept of a “floorplan” in SAP-speak that serves as a pattern for re-use in composite application development. These entities, however, are largely based on static SOA and UI patterns; thus, designers know exactly which services will be used at run-time.

What will be different is not the use of patterns to facilitate re-use and governance in application design but the contents of these patterns.

Based on these new application patterns, various up-and-coming SOA-related technologies will select the particular service that will fulfill the particular requirement at run-time. What is different is that the particular service (its concrete manifestation) will be selected based on service-related characteristics (perhaps, ontology-based matching) rather than selection by a human designer – irregardless of whether it is a BPX or a developer.   

This is one change that stresses the future importance of those individuals / corporations (such as SAP with its Enterprise SOA) who will be supplying services. In order for these services to be able to participate in such collaborative conversations, they must meet certain standards and provides such things as an ontology and semantic support.  These entities that create services will play a much important role in the future. Today, such services primarily provide content.  In future environments, the services from such entities will act autonomously based on the goals that the BPX uses to create his applications which will in turn become more abstract at the same time as being more dynamic. Those BPXS, who are control freaks and want to determine exactly how their applications function at run-time, will still be able to do so.  Those BPXs who are willing to let the applications exist more dynamically (not always easy in a business environment that expects processes to usually be repeatable as well as measurable) – their applications will be more likely to actively respond / react to performance / quality problems and other relevant changes in the environment.

For me, the most intriguing aspect of this new technology is the question: how do you design an application whose exact characteristics are largelyunknown at design time (A related question is how do you create metrics for an application / process whose concrete instances may not be constant…). Currently, designers pick concrete services and include them in their processes.  Such individuals select web-services from a service repository to build their composites.  How will this be possible when the services may not even exist when the application designer is designing the application?  One idea is to build your application based on goals (for example, “less expensive with lower performance” for applications that are not time critical, etc.) / requirements (of course, these goals should match those goals present in your organization – Thanks to Kuo-Ming Chaofor our dinner discussion on this topic).

A Caveat: This entire discussion is largely based on the assumption that most if not all functionality in corporations will be available via web-services.  Obviously, based on the large number of legacy applications not yet service-enabled, a pure SOA environment still has not yet achieved in many corporations.

Thus, the future design environment of the BPX will definitely be different than it is today. Perhaps in the future, the life of the average of the BPXs will be easier in that they will be able to design applications with tools that are even more independent of the underlying technology.  These individuals, however, will be forced to create applications that are more closely linked on organizational goals rather than specific application characteristics.  This change, of course, necessitates increased faith in technology to create often business-critical application on-the-fly in a correct (from a business perspective) and efficient manner.  This loss of control is based on the assumption that service providers have created services that are correctly defined in order for them to work correctly in dynamic collaboration situations.  These service providers – including SAP with its Enterprise SOA – will have more responsibility in such situations; thus, increasing the importance of very high levels of quality assurance for services.

Of course, some of you might be thinking: “What does this stuff have to do with me.  By the time this research hits the shelves, I’ll be sitting in my lounge chair in the Florida Keys enjoying my retirement.” First of all, at the rate this technology is currently developing, it might be here sooner than you think. Furthermore, being aware of future trends is always critical to respond / plan accordingly. Thus, it is critical for “end-users” to be knowledgeable about such future trends rather than completely relying on others to do so for them.