MICHAEL VIZARD: Hello, and welcome to the this edition of the ACM Queuecast with your host, Mike Vizard. Joining me today to talk about business process management is Edwin Khodabakchian, Vice President of Product Development for Oracle. Welcome, Edwin. How are you?
EDWIN KHODABAKCHIAN: Good morning. Thank you for having me.
MV: My pleasure. I guess what we wanted to get started with is there's been a lot of talk over the years about service-oriented architectures and Web services, and I want to get a sense of how that's going to play out as we move forward with business process management. How do these worlds come together, and how do you see the synchronization of those efforts, and what impact does a standard set of Web services have on our ability to manage business processes?
EK: That's a good question. A lot of our customers are looking at Oracle to provide a solution that makes it easier for them to integrate those applications. And I think SOA is an industry standard that enables you to take your existing assets, break them down into core IT services that can then be reassembled into a portal, for example, if you're building a customer support application; reassembled into an end-to-end business process if you are trying to streamline an order to cash business process or if you are trying to take a business expense report application and customize it; or even, you know, reassemble those services into real time analytics. So as such, I think SOA and the set of standards that help you take your existing assets and expose them as services are a core infrastructure that are really going to help the industry deliver on the promises of business process management and more agile business processes.
MV: So what standard should people be paying attention to in this area? I've seen the Web services committees move upstream. I've seen the talk about the business process execution language and there's standards work there, and it's not quite clear to me how far along that is. What should people be expecting to see in this next iteration of business process management?
EK: So again I think when you look at SOA, the real pattern is about exposing services, and there are a set of standards for doing that: WSDL, XML Schema, and various types of security management in that area. Those standards are obviously important. Once you've exposed the services, you start thinking about how you are going to assemble them into end-to-end work flows. As you mentioned it, there is a business process execution language, which is actually quite a mature standard that evolved from the merger of X language, which was the standard Microsoft was working on, and WSFL, and has been submitted to Oasis. Oasis has been working on it for almost two years now. So BPEL, business process execution language, gives you the foundation for really starting to assemble a set of services into end-to-end processes. And those processes could be very short-lived. They could be long-lived. They could have business events into them. They could have compensation, parallel processing. So all the core semantics for executing business processes out of services is what's captured in the business process execution language. As you've mentioned, Version 2.0 is coming out this year, and what was really done within 2.0 was to take the 1.1 submission from the key vendors that submitted it and try to clean it up so that it became mature. So, 2.0 is out this year. On top of BPEL, there is a set of standards that are emerging that are simplifying the development of business processes. You have BPMN, which is the notation standard, which defined how you visualize a business process on a screen so that a business analyst can take a look at it - so it's all about visualizing business processes. You have BPEL for People, which is an extension provided to the core BPEL standard, that enables you to aggregate people as core activities of these end-to-end business processes that you're modeling. So there is a lot of activity going on on top of the BPEL foundation to really deliver things such as People Rules, Business Analyst Views, and over the next few years we should expect those layers to get as mature as what the BPEL standard is today.
MV: What are we really trying to accomplish there? Are people going to create standard business processes, or are we just trying to standardize all the interfaces and the tools and the interaction levels which represents everything from I guess I would call BPEL something like layer eight or nine because it's outside of the normal IT space, down to everywhere there's an interaction all the way down to the network layer?
EK: I think you need both, basically. I think again to be successful and deliver on the promise of business process management, you need a standard to be able to take the core IT assets and expose them, and that's all those standards you need for interfacing. And then you need a standard way of representing business processes so that you don't use a proprietary opaque language for representing those business processes. So I think those are the two directions where the industry is working in parallel to really deliver on the promise of business process management.
MV: So I may have a business process where it's an accounting application or some subset of that that 90 percent of the world uses, so I can just standardize on the same business process, but then I may have some extensions to that that I'm using, some tools to really customize and add some value around the business process itself. So instead of trying to reinvent every part of the wheel, I'm reinventing the parts of the wheel where I can add some value?
EK: Absolutely. It's the concept of assembly. So you can take the part of the process that exists maybe in your SAP or Oracle E-Business Suite application, expose this as a service, and then on top of that build your own version of the process where you decide to extend this by changing slightly the business rules or extending the process so that there is an additional manual review, or because you have both Oracle and Siebel, you want at then end of the customer creation process, you not only want to update your Siebel system, but you also want to update your Oracle system. So the idea is to take the pieces of processes that already exist on all your existing systems, expose them as building blocks, and then be able to build new assemblies that leverage what you already have but adapt them and extend them.
MV: Some people would say this means the death of the applications suite as we know it because now we can go back to best of breed and pull in different components because it's all going to tie into SOA and BPM type systems, and then there isn't going to be this need for an end-to-end suite, and yet we still see the dominance of Oracle and SAP in the marketplace. So what do you think is going to happen there?
EK: Yeah, I think if you look at basically an entire application such as the ones that were provided by SAP or Oracle, process is just one dimension of it. You have analytics, you have all the customization aspects, you have the learning aspects, the screens. So there is a lot of value from a customer to get all the different business processes that they want to purchase from one vendor because you get the integration of those things out of the box, and therefore you get better analytics and things like this. Nevertheless, I think customers that adopt a package need to always be able to customize that package, to change the business process that we ship out of the box for, for example, order management, to the different way you might manage order in your line of business, and they may be slightly different. So there is always a customization aspect. And then you might want to take that order management and extend it further than what was provided out of the box by the package vendor by integrating it with your existing system because again, when you take advantage of a package application, it's never in a vacuum. He lives in his ecosystem of other applications you already have. So I think where we're going is not necessarily this idea of this nirvana where you can pick and choose the pieces from every vendor and they will magically work together. But I think you will buy package applications, but those package applications will be much more customizable and extensible than they were in the past. And they would be extensible in a standard fashion, so you don't need to buy proprietary tools from one vendor to go customize those business processes or integrate them with other systems.
MV: So how difficult is it today to orchestrate business processes across multiple applications, and is this something that we're going to see built in at the application server level now or the database level or some combination of that? Or where does that function actually reside?
EK: Yeah, it's a very good question. If you have Retek, for example, and you're using that as your point of sales for all the cashier management transactions, and you have Oracle Financials, you need to be able to integrate those two pieces together to align those systems. The way you would go about doing that is to take your existing systems, ReTek and Oracle, and build services out of that. And there are adapters for that, and so again the technology for taking those systems and making them available as services is pretty mature. Going forward, the systems will be natively built out of services themselves so you won't even need adapters anymore. Once you have those services, then you start thinking about what's the process, what's the flow of information that you need between those systems, and that's what you would use, for example, the BPEL representation to say, "Well, every time I have a transaction, I'm going to wait for a batch of them. And then I'm going to move that. I'm going to validate, make sure there is no error. I'm going to reconcile this with some of the customer information I have," because, you know, a customer or the way a Retek represents California and their system is different from the way Oracle represents California. So there is some data coding thing, and what we call common view in general: create a common view of your customers, your receipts, your transactions. And then again you would invoke Oracle to push that data in there. So the technology today is available for customers to be able to build those type of integrations in a very easy and standard fashion. What the next step as you highlighted is I think for vendors to provide built-in templates of how all these systems can be integrated together so that the customers don't even need to bother about building those integrations. They'll be provided out of the box. We'll be providing a set of them, obviously, now that we own Retek, Oracle, PeopleSoft, Siebel, there is a set of well-known integration scenarios between those systems that we're going to make really dead simple for our customers. But again, the idea is that all these things are done in standards, and if your customer has a custom system that he needs to bring into those template integrations, then he can easily do that using our tools.
MV: I guess historically a lot of the criticism that people throw at enterprise apps in general is that they have to bend their business to the business processes that are already coded in that software that comes from the vendor. Are we getting to the point where that's going to change enough where the business rules and the business process management software is going to be flexible enough so that it adapts more readily to whatever new business model that the business wants to deploy or implement versus having to wait 12 or 18 months to get the software to catch up to the business?
EK: Yeah, that's the one and single goal that we're focusing on. So I think I talked a little bit earlier about the idea that the processes, the data models, the screen flows that we'll be shipping out of the box will be much more customizable going forward and in a standard fashion so you don't need Oracle-specific skills to make that happen. And that's really the goal we're delivering on. I think it's something that exists today with early adopters. So, for example, Belgacom, who has been one of the early adopters of our SOA technology, is modeling their DSL PRovisioning using the service-oriented architecture. So they've taken payment, network management and customer management systems - systems that are heterogeneous - exposed them as services, and are able to set up business processes that are about provisioning a user for DSL. When they went and moved to interactive TV, it took them much shorter time to market to deliver that new solution. The other aspect is now they look at those and monitor those processes on a weekly basis, and they continually streamline those processes and enhance them to do better exception management and make sure that the SLAs that they're providing to the users that are setting up new accounts are always managed. So I think that's really the key new thing I would say around service-oriented architecture is the idea that you have these assemblies that are not necessarily done in code that are leveraging your core IT services. But those assemblies are done in meta-data, such as BPEL, and therefore they can be changed in a much easier fashion. I think we're delivering that with early adopters, and I think the next step is really to make that available to the masses, which is what we're doing by making that part of our package application. I think the other thing that customers are expecting from us is to make sure that now that you have those assemblies, why can't a business user come in and tweak it. So I'm expecting that over the next couple years, two to four years, you'll have much better tools for configuring and customizing the processes all the way to the end user, not even just the business analyst, but end users will be able to look at the knobs that an assembly provides and be able to tweak them, to adapt them better to what they want to achieve.
MV: So this kind of sounds like the revenge of the business system analysts who used to be king back in the era of the IBM mainframe, and now finally we're getting them the tools where they can be the kings again. Is that what's going to happen?
EK: Yeah, I think it's just a maturity model. I think the benefit of this model compared to traditional cage tools, you know, when we present our store strategy, a lot of our customers say, "Hey, this seems to be like the Holy Grail of computing. We've always wanted that. Why is that happening?" which I think is similar to what you're asking me. I think if you look at the Web architecture, it matured based on standards, and now that basically every code-driven paradigm has matured, I think people are looking at more of those declarative programming artifacts where system analysts or people that don't necessarily need to understand core IT assets can really participate. And given that they have a much better understanding of the business, they can now basically adapt those systems much more effectively. And we're delivering on it, I think, because the code is mature. J2EE and Java have matured over the last ten years, and I think people are ready to go in beyond code and look at those declarative artifacts.
MV: You mentioned the tracking of meta-data. Does that mean at some point down the road the software gets smart enough to track the behavior patterns over what's happening across an entire vertical market and then maybe start making some recommendations about how the software should be adjusted to changing business processes as they're actually happening?
EK: Well, I think the first step towards that that we're seeing a lot of customers asking for is the idea that now that they are representing their business processes in this higher level first-class artifact, which is BPEL, they want to be able to say, "Well, how long does this process take? What is the percentage?" If you have a decision branching in the process, and you have gold customer versus silver customer, how many of the users to go each of the branches? So the first aspect to really providing more self-adapting processes is to provide the censoring capability to really capture better real time events out of those business processes. And I think that's what the whole goal of the BAM segment, business activity monitoring, is about. And there are some interesting early deliveries of those solutions. I think once customers start getting much better visibility into what those processes are, then the next step is, "Well, let's automate some alerting, so that if we're out of this threshold for our service level agreements, then we can basically take manual steps towards that." You can see the natural progression as the technology matures and the customers get more familiar with the technology to have automated action-taking based on those alerts, which will be effectively about adapting your business processes in real time based on how they're executing and how the environment is executing, as well.
MV: So, Edwin, last question. If you're in charge of the technology strategy for your company, how would you go about starting to introduce these concepts into your company, because it feels like there's a certain amount of cultural effort that has to go around this in addition to just mastering the technology.
EK: Yeah, that's a very good question. I think the first key thing is it find the application, an application that your business users really care about, that they've been frustrated to deliver in the past, because, you know, again, the pieces they needed were siloed in different back end systems, or they needed to take an application and deploy it differently on multiple channels, and again, the IT wasn't flexible enough to adapt the business process on these different channels. So find a big IT business sponsor, take an application that is not necessarily big - you want to start with something small - but that is something meaningful to their business, and then use this SOA methodology in terms of looking at the application in terms of parts and assemblies, which is something definitely new. Because again in the past when IT was looking at an application, it was all about making it robust, scalable, you know, built to last. Whereas I think the new IT is all about, "Let's build an application keeping in mind that over a month we're going to change that application, and as we get better understanding of the business processes, then we're going to try to streamline them." So then you start looking at this problem in terms of what are the core services that you need to reuse out of your existing system, and what are the new assemblies that you want to keep agile in modeling them. And then select a set of tools, standard tools to model those elements, put the business real time dashboards to monitor them once they're in production. And then you will see over time what started small can now start being expanded because you realize that this business process was just a gear out of a bigger business process, and then you start looking at the ones that are on each side of the part that you automated, and you start to extend it. And as you get this more iterative, organic approach to delivering this SOA solution, first of all your business user gets his ROI right away because you're building an application that is meaningful to them, and then over time I think you get a much better understanding of what the standards are and you can grow it from smaller processes to much larger processes in a successful way.
MV: Edwin, I want to thank you for joining the show. That was terrific. And I wish you the best of luck.
EK: Thank you very much. It was a pleasure.
Originally published in Queue vol. 4, no. 8—
see this item in the ACM Digital Library