Q&A: Oracle's Dave Shaffer talks BPM

Dave Shaffer is Oracle's senior director of product management, BPM, and SOA. He is responsible for business process management and how it aligns with services-oriented architecture as part of the Oracle Fusion Middleware portfolio.

Q. What tend to be the most common drivers for business process management these days - obviously BPM has been around for many years in a number of guises?

A. I think there are a few categories that we commonly see. The first is people looking to eliminate manual tasks and error-prone systems - the automation of human workflow.

The second is about business visibility. The need for people to see the business processes, how they are executing, where there are bottlenecks. They want something they can layer on top of the existing infrastructure, and they look to BPM to expose that.

The third is where companies see their business processes as a key differentiator. Everybody has a set of core business processes but some companies look to apply BPM as a way to increase their revenue. So different people dive in at different points.

Q. One of the challenges in BPM has historically been that it is a technology or discipline that cuts across both the business and the IT department. Does that make it hard to get right?

A. Yes, we have seen that as an inhibitor at times. Sometimes we are selling to the business, which is looking for a more rigorous methodology. Other times you are selling to the IT department and they are often starting with the need for a systems-based approach. That gap means that there can be two sides, and one of our roles is to help the two sides talk to each other.

Q. Communication between the two is key then?

A. Yes absolutely, the two sides need to talk often and clearly explain in terms that each understands what they are trying to achieve and what constraints they are each facing. A lot of projects in this area may be driven by the business initially, and one mistake is to think of the IT side as a detail -- it's a very important detail! Because for the business to realize the benefits they need the IT department to be on board. The good news is that those two groups seem to be getting closer and closer.

Q. How does services-oriented architecture fit with BPM? SOA often seems to be about an approach to IT systems development and maturity, rather than having very much to offer the business in terms that they understand; but equally BPM is often described as a way of putting a business-focused veneer on top of more flexible IT systems.

A. Yes, we have an SOA maturity model that as you say, focuses primarily on the IT aspects of SOA. We think of SOA as an enabler for BPM, but it is definitely not the same as, or a substitute, for a BPM methodology in its own right. So we do also have some documentation that speaks to the BPM methodology itself.

Q. You say that BPM can be initially driven by the business or by IT. Are there any rules of thumb learned from your customer projects as to which approach tends to deliver greater success?

A. In our experience, if you have the business pull it works better, more often. But our advice in either case is to take an evolutionary approach: take bite-sized projects and automate them. Start with small, manual tasks on the IT side.

IT often knows more about the business than the business knows about IT. So IT can certainly propose solutions to business problems. But we see the greatest leap forward when these proposals are welcomed and embraced by the business.

Q. Many will feel that they have made significant investments in their IT systems already: ERP was meant to automate many processes, while business process re-engineering that was once such a hot topic is no longer particularly fashionable as for many companies it led to expensive projects that did not always deliver. Most analysts today espouse modern BPM as putting a new layer of abstraction, if you will, above existing systems. Is that something Oracle buys into?

A. We definitely believe in the "layering above" approach. We think most traditional BPM vendors have not focused enough on this aspect.

Our BPM tools are designed with the expectation that they will work above existing systems. That fits absolutely with our view of what SOA is all about. In fact we think SOA is a key enabler of BPM: you can layer it on top of existing systems and decouple them from the business logic without having to rewrite them just because a system or process has changed. In fact if there is one thing that we believe will accelerate BPM adoption it is the SOA approach itself.

How should you best tackle mainframe modernization? We think the best way is to be able to build new processes around key, clean interfaces that make change less invasive. Those clean interfaces are possible now thanks to SOA and BPM. BPM on SOA gives you an evolution roadmap of IT systems at the back end connected to business processes at the front.

Q. Does this not require some sort of cultural change though?

A. Absolutely, but the role of an in-between agent that straddles IT and the business is already starting to emerge. Titles like business process architect or similar speak to this trend. Even without such roles, there is a clear need for business people who can describe their IT requirements in a more effective way, and IT people who can clearly describe the IT systems implementation as it affects the business.

Q. Historically many BPM pure-plays specialized in the human aspects of BPM -- workflow, while others were better at the system-to-system level. Is that distinction blurring?

A. Yes, we think that has been another inhibitor to BPM. For our customers today there is almost nobody with a pure systems or pure human element, it is always a blend. If you have to change tools to do that, it is not going to work. That's why larger vendors like us were able to jump in and leap-frog the pure-plays: we were able to straddle both camps.

Q. As you mentioned, one of the drivers for BPM is to garner better visibility of the business processes. What gives Oracle a story in that particular space?

A. We have made acquisitions that have enabled us to instrument business processes and feed them out to business activity monitoring [BAM] dashboards. Out of the box you can get that visibility: what are the exceptions, what is the processing time and so on. This can then be shown in real time in BAM dashboards. They can be viewed in a lightweight interface in the browser using technologies that give you a rich-client interface, thanks to AJAX [Asynchronous JavaScript and XML].

Q. As we understand it, that complements rather than replaces more traditional business intelligence capabilities?

A. Yes, at Oracle we also saw a need for more sophisticated BI tools like those which came from the Hyperion acquisition and Oracle BI Enterprise Edition. These tools provide sophisticated analytics and can also integrate with the BPM solution and feed events to data warehouses as well.

Real-time BAM data is great for seeing the state of the business in real-time but there is also typically a very large data set that needs analysis, for example for regulatory filings. Compliance like Sarbanes, Basel II - in fact if you look at those they often almost mandate BPM, because you have to be able to describe in detail your processes.

Q. What about the latest standards that are at work in supporting BPM? BPEL [Business Process Execution Language] is perhaps the most widely adopted, but there are others, aren't there, like BPMN [Business Process Modeling Notation] and XPDL [XML Process Definition Language] that appear on the surface to be competitive. It's all a bit confusing, isn't it?

A. We think any BPM tools should support BPEL. The business stakeholders may not know or care about BPEL but it offers a way for them to own their processes in an independent fashion. It gives them flexibility, future-proofing, and vendor interoperability. No other BPM standard has the backing of so many key vendors as BPEL. However, BPMN is clearly complementary to BPEL and we see the two standards working very well together as BPMN provides a modeling notation for business analysts to use while BPEL provides an execution language for deployable processes.

Author: Jason Stamper @ www.cbronline.com

Read more ...