Tying together SOA, BPM / Workflow, and Web 2.0
I was on my way home from the airport listening to Dana Gardner’s SOA Insights podcast from 11/15, which brought up the topic of Web 2.0 and SOA. Before I get started, I wanted to thank Dana for putting this together. It’s great to have another podcast out there on SOA. I’ve always enjoyed the panel format (it was a blast having the opportunity to be on one this past year), and Dana’s got a great group of panelists including Steve Garone, Joe McKendrick, and Neil Macehiter, plus the occasional guest.
Anyway, as they were discussing the Oracle OpenWorld Show, the conversation turned to Web 2.0 and SOA. Joe compared Web 2.0 and SOA to the recent “I’m a Mac” commercials from Apple, saying that “they’re trying to understand each other.” Steve went on to point out that he thinks that one is going to support the other. When I think about Web 2.0, I think about the user facing component of our IT systems. With that assumption, Web 2.0 and SOA are complementary, not competitive.
I’d like to take the conversation away from Web 2.0, however. I’d like to take a step back and look at a larger picture that tries to tie a number of these concepts together. I can’t say it ties everything together, as I’m not going to discuss BAM or MDM, as this post would get way too large, but they fit in as well. Let’s start with SOA. SOA is all about services. For the purpose of this discussion, let’s view services as the functional activities performed by our IT systems. (I realize SOA can be applied more broadly than this). Many enterprises are relying on Web Service technologies for these services, and Web Services are intended for system-to-system interactions. I can use a BPEL tool to externalize some automated processes, but it’s still all system to system. So, how do humans come into the mix? Clearly, humans are involved. So now we bring in a BPM / Workflow tool. If you’ve worked with the workflow tools, you’ll know that an integral part of it is task management. A user gets assigned a task, it pops up via some notification mechanism, and they go and do what needs to be done. Today, it probably involves firing up some application, which is built on top of those services we mentioned earlier. So we get a picture like this:
Simple, right? The real issue with this picture is the application/service component. Odds are that application does a lot more than just this particular task. In fact, there’s probably a whole bunch of things the user must go through to get to the right part of the application. How do I get contextual information out of the task and into the application, if that contextual information is even there? Would you rather get a task that says, “Check your email” or “Read the email from your boss, John Q. Hardnose, he’s in a bad mood today.”
Where the systems need to go in the future is in the form of actionable, task-based interfaces. A great example of task-based interfaces is the Dashboard in Apple’s MacOS X. It consists of widgets that, for the most part, have a very limited purpose. They are intended to be lightweight. For example, there’s an address lookup. It’s far more convenient for me to go there to lookup an address, than to have to launch AddressBook. This task-based approach hit home for me when I was reading Keith Harrison-Broninski’s book, “Human Interactions: The Heart And Soul Of Business Process Management.” Something that would help in the efficiency of business processes would be if the tasks contained appropriate context so that a lightweight user interface could be quickly provided that allowed the user to perform that action. Now if the tasks contained a link to an HTML page, that HTML could immediately be rendered within the task management system, allowing the user to do what they need to do. How could that be done? Well, if the task management system is built on Portal technology, now we have a vehicle for shared context, incorporation of Web 2.0 collaboration technologies, AJAX capabilities, and the HTML rendering engine we need. We wind up with this:
When I think about this, I think of huge potential gains in efficiency. I also hope that I’ll see it in my lifetime! The hard part will be determining in how this can be built out incrementally. Even SaaS has a role in this, since the traditional application providers are part of the problem. They simply don’t have a means or the architecture to take in appropriate context and quickly launch the application to the right user interface to allow tasks to happen efficiently. SaaS has the potential to do this, but there’s still a long, long way to go. I, for one, am excited to be along for the ride.
4 Responses to “Tying together SOA, BPM / Workflow, and Web 2.0”
Leave a Reply
[…] Joe McKendrick brought the subject of event driven architecture again on his SOA in Action blog. I’ve previously commented on this subject, most recently here, here, and here. This is a subject that I like to comment on, because I feel that appropriate use of events are a key to the agility that we strive to achieve. It’s very simple. Services execute actions. Processes orchestrate actions. Events trigger the transitions within the process. You need all of them. A solid messaging infrastructure is critical to event processing, so it’s very surprising to me that the MOM EAI ESB vendors aren’t all over this. Tibco has their complex event processing product, but they really haven’t pushed the event message very hard. What about the registry/repository vendors? Lots of talk about services, but not very much about events. The fact is, just as an enterprise can’t leverage SOA without services, they can’t leverage EDA without events. The two are complimentary, and I encourage the EA’s out there to start doing the work to identify the events that drive the business. […]
[…] Events: The importance of events has received some recent press, but unfortunately got mixed up in the awful marketing message of SOA 2.0 earlier in the year. I think we’ll see renewed interest in event description, as I see it as a critical tool for enabling agility. Services provide the functional aspect, but there needs to be a library of triggers for those functions. Those triggers are events. Along with this, the players in the Registry/Repository space will begin to market their ability to provide an event library just as they can provide a service library. […]
[…] I’ve previously posted on the integration between SOA, BPM, Workflow, and EDA, or probably better stated, services, processes, and events. There are people who will argue that EDA is simply part of SOA, I’m not one of them, but that’s not a debate I’m looking to have here. It’s hard to argue that there are natural connections between services, processes, and events. I just recently posted on BI and SOA. So, it’s time to try to bring all of these together. Let’s start with a picture: […]
[…] this beyond the developer, I bring in the advent of BPM and Workflow technologies. I’ve blogged previously on how I think this will create a need for very lightweight, specific-purpose user interfaces. […]