Similar to the enablement of applications to the web in the late 90’s, service oriented architecture (SOA) is a major paradigm shift in how we do and think about business processes and the data that supports it.
SOA is really just a fancy name for the next generation of middleware. Built on web services technologies, SOA includes the basics of identity, directory, applications management and data integration protocols. Not that it all happens in the SOA middleware, but SOA is the facilitator and enabler of more robust transactions.
One of the things this means is that workflows once disjointed because they flowed through disparate systems can be unified in the middleware. However, this creates new problems. While the business process and be unified through a single stream of work, the front end user interface does not necessarily support it. For example, if your performance process includes doing performance management in Workstream, compensation in SuccessFactors and allows drill downs into the Sum Total learning system, the front end user interface has to be rebuilt to support the new workflow. While the middleware accommodates the integration of process, the UI/portal layer does not necessarily know how you want it presented.
Think if you had a single talent application suite. Theoretically the performance scores and configuration flow easily into compensation and so on. Each of the vendors is good enough to know that their user interface needs to allow managers to jump around easily within the process and go forwards and backwards in the process to view data, and they have tooled the user interfaces to be able to do that. But if you are working off of disparate systems, your portal tool doesn’t necessarily know what to do when the user wants to “jump.” HOW you want data presented is completely different than the fact that data CAN be presented.
What it does know is simply what can be brought forward from the SOA middleware. That is, no matter what the event or action trigger is from any application attached to the SOA middleware, the UI can present the user with a single task list from all the disparate systems. Portals will also gain in sophistication, mostly from allowing more configuration in how end users see the business process. Until then, SOA enablement is limited by your ability to construct the user view.
3 responses to “Changing the Game: SOA and Business Process”
At least a couple interesting issues here. Regarding workflow, I think you will see more tools for managing workflow among distributed serivces. Business Process Execution Lanaguage (BPEL) enabled tools have much promise for this. This is a geekly core technology upon which some nice graphical workflow tools are being built. In a fairly easy, intuitive manner you can graphically model workflow among a set of distributed services and build in dependencies, branching, etc. See:
http://docs.hr-xml.org/2005-Oct-Meeting/HR-XML-2005-10-Oracle-BPEL.ppt
Where workflow among web services is important, you’ll see HR systems providers relying on BPEL engines. This will be for orchestrating workflow among their own components as well as third-party components. The above slide deck mentions on-boarding, which is a terrific use case since most on-boarding processes will rely on a mix internal and third-party controlled steps.
A second issue you seem to raise is whether data you get back from a distributed application will be available/presented in a way that is as flexible as a bundled application. This seems another way of exploring the perineal question of what is best — a bundled suite of applications of applications or best of breed. I don’t have the answer to that one. However, regarding SOA, perhaps what buyers should be looking for is applications that support SOA in a fundamental way. There should be some “service bus” notion that allows the application to call internal/bundled services as well as those of third-parties. “SOA” isn’t just a few web services slapped on top.
But SOA isn’t magic. You could still have mismatches between systems in the granularity of operations and data. This could make it difficult to provide the seemless interaction between arms-length systems. This is another reason buyers should check that their solution providers are actively involved in industry standards initiatives.
One follow-up thought, there is a OASIS standard that has been out there for a few years, Web Services for Remote Portlets Specification. One of the problems this specification is intended to solve is where you need to share GUI components from distributed services. Here’s an article that even includes an HR example:
http://websphere.sys-con.com/read/43215.htm
The WSRP really fits the use where you need to return more than just XML data from a service (a remote portlet) to a client application (local portal). It fits the use case where you want to return a graph or other UI component and associated functionality.
While WSRP seems to be part of an approach to addressing some of the issues you raise above, it appears that adoption has been a bit spotty and the spec likely needs another pass before it is sufficiently robust/mature. I’m visiting WS-I.org today where there is a group of companies gathering/drafting some additional requirements for WSRP.
There does seem to be more attention to this issue of reliable, standard means for combining different services into one application view. I’d expect initiatives such as the OpenAjax Alliance may also approach this issue from another angle.
[…] My boss and I have been doing a lot of brainstorming around manager self-service environments. I’m advocating a new interface layer leveraging an undefined business workflow toolset and SOA. Mashups, essentially. Double Dubs has been talking about SOA again and as usual I agree with him. However, there are big gaps and lots of disparity when you look at whether application X allow you to pick up discrete funtionality to use in a mashup. Worse, I’m still not certain that I have the proper platform to build this new layer on. SOA is still in it’s infancy with most of the vendors we use and they only change slowly and carefully. […]