Participants in this conference are Beth Gold-Bernstein (BGB); JT Taylor (JTT); Derek Miers (DM); and Lyndsay Wise (LW.)

BGB: Hello, everyone, and welcome to the very last session of the ebizQ "SOA in Action" virtual conference. I'm Beth Gold-Bernstein, chair of the conference and moderator of this panel. I hope you've enjoy the show and got a chance to visit the virtual booths. If you haven't, there is still time after this panel session. Visit all the booths for a chance to visit an iPhone. We'll be announcing the winner next week in our newsletter, so you still have an opportunity to be part of that drawing.

We are interested in your feedback. We had over 2100 people registered for this show, and we'd like to make it even better next time. So after the show, you'll be receiving an email about our post-conference survey and there will be a $250 gift card drawing for the survey. So, we're hoping you'll take the time to give us your feedback and help us improve our virtual conferences. After this panel session, we'll be giving away four books, so be sure to stick around for that drawing.

Now, we're going to be talking about SOA trends. The intersection of SOA, EDA, BPM and BI. I have with me a most distinguished panel. First, I'd like to welcome JT Taylor, CTO of iWay Software. Prior to joining iWay, JT was the founder and CTO of Semantic Solutions, an independent software vendor and reseller targeting the application development market and previous to that, he was the senior director of Global Product Marketing and Chief Software Architect at Software AG, and while there, he was responsible for Software AG's information integrator and put a lot of Semantics into that. So, I've been talking to JT a number of years. I know we're used to talking with analysts but in my position, I talk to a lot of smart people making this technology in the, in the, at the vendor's and JT's one of them -- I always enjoy speaking with them, so welcome, JT.

JTT: Thank you, welcome. Thank you.

BGB: We have Derek Miers, CEO of BPM Focus. Derek is a well-known independent industry analyst and technology strategist and provides BPM training and consulting to organizations around the world. Derek is also co-chair of the BPMI Organization. And he is also serving a very important role on this panel as our representative Brit. Yesterday, Joe McKendrick had Phil Wainewright on his panel, so we felt the need to keep that up.

Now, you must admit, everything sounds so much more erudite with a British accent, and actually, Derek is very erudite so we're very welcome, very excited to have him here. Welcome, Derek.

DM: Thanks, Beth, for that. To put you right, I’m actually a Kiwi if you’d believe.

BGB: You are!

DM: And, there you are, you learn something new everyday.

BGB: Oh, okay.

BGB: Oh, okay. Thank you for setting us straight there. Okay. So we have an old bio on you, okay. Lyndsay Wise is our final panelist. She is a senior analyst at Wise Analytics and Lyndsay just recently left the Technology Evaluation Center. We've worked with Lyndsay on "BI in Action." Lyndsay is an expert in business intelligence, so we're very happy to have her as part of this panel. Welcome, Lyndsay.

LW: Thank you, Beth.

BGB: Now, I wanted to do this session because currently, there's a lot of confusion in the marketplace around each of these acronyms in particular. In Randy Hefner's session this morning, there were a lot of questions of BPM and SOA and companies are being bombarded with the message that you've got to have it all, and they are confusing messages about how these things relate.

Last week, I was in Vegas for IBM's Information on Demand and was rather surprised to hear Steve Mills use the terms "SOA" and "BPM" interchangeably, as if they were the same thing. In his keynote yesterday in this conference, Roy Schulte said that BPM is so important that some people believe you should not do SOA without BPM. But it's not the same thing as saying that BPM and SOA are the same, okay?

And I've been having discussions in my blog with the author of SOA For Dummies around the same thing. Similarly, I've participated in a number of discussions with enterprise architecture about whether EDA is a subset of SOA, whether it's a separate architecture, and to top all of that off, last spring I participated in a series of podcasts with probably ten to fifteen different vendors on the evolution of BI, which has been around longer than any of these things.

So, I'm hoping we can sort these things out in this discussion. So, to start off, I thought it would be helpful to first define each of these things. So, JT -- I'm gonna ask you first. Can you give us your definition of SOA? And again -- I'm gonna invite, I'm going to try to make this very lively and interactive. This is a live session. So, Derek and Lyndsay, if you disagree with anything, chime in at the end.

So, JT -- start off. What's the definition of SOA?

JTT: Well, that's a pretty big question, Beth. I believe, in my opinion, the answer is SOA is a paradigm, it's an approach to using technology, to -- in your IT infrastructure deliver a set of reusable, agile services that can be applied to a multitude of projects from the system that you have in place already. So a service-oriented architecture is simply an architectural approach where you try to expose as many systems as possible as a collection of services to then be later combined or reused for integration or for portal project or BPM project in reference to the comments made earlier. But that's my definition of it.

BGB: Okay. And how about EDA and SOA -- separate, subset of SOA? How do you see those two things?

JTT: Well, I think EDA is a further revolution of, I guess, an SOA. It's another, again, in my opinion, a flip side sort of coin. In a service-oriented architecture, you have a collection of services that are providing functionality, business-level functionality, access to your systems, to be recombined and repurposed within your project. With an event-driven architecture, what you're doing is asking those systems to actually generate a, some type of an event, when a business event occurs. So you generate a technical event that can be responded to and reacted to from a business event occurring. So you may be monitoring the system for a certain level of invoice that's coming in or order level that's coming in. And then you want to generate an event for that. You can respond to that by calling, in turn, other services that may kick off a separate business process or a specialized business process or generate reports or really whatever type of thing you'd like to accomplish.

An event-driven architecture is one where your underlying systems generate IT events for you from business activity that is taking place. A service-oriented architecture is where the underlying systems respond to request for services. And these two things really are combined in a multitude of projects where, like, BPM again, to go back to that. A business process management system to use services as well as be driven by events.

BGB: Okay. Now, Roy Schulte started some of the brou-ha-ha a couple of years ago when he called out EDA as a separate architecture and really Brenda Michaelson is the one that convinced me that if they are separate, they are better together because EDA is very, very loosely coupled and the more loosely you couple something, the more agile you create your infrastructure. But they can be separate. You can implement an enterprise, an event-driven architecture, without having services there. You can just generate events and send off alerts and things like that.

But when you combine it, now Roy in his keynote yesterday talked about event-driven SOA. So they are being combined and SOA will encompass more than just event-driven. There is also request/reply. But they do play together there. Now, Derek, let's move on to BPM. Can you give us your definition of BPM, please?

DM: Well, I'd say BPM really is a continuous performance improvement method. It's like a management philosophy. It's like a discipline. Around constant improvement of business processes. And, of course, it can leverage your SOA infrastructure. But at the end of the day, I see SOA more as an approach to systems development that delivers applications through composition and orchestration. Both discrete and independent component. It’s a design philosophy for driving SOA though is sort of process-oriented business thesis is driven by the architecture and set up to support change from the onset whereas the BPM part of the house is really looking at, driving the business tools and improvement over time. And it's really about driving the process it takes to do that, using models to drive that.

BGB: Okay.

DM: Technology to do that as well. But I would focus more on the business level rather than the technology support mechanism. I remember a conversation with Daryl Plumber, an important Gartner analyst. And he said something like, you know, your decisions in BPM are going to have a lot more influence over your success at SOA rather than the other way around.

BGB: Okay. So, it's a discipline. And a technology, which you can use to practice the discipline.

DM: Well, a BPM platform is driving the process using models. And those models might be called components, services, if you like. But you've still got to come up with a model sooner or later. You've got to think about how you build that model, how you monitor it and how you improve it -- which is where the BI element comes into --

BGB: Okay --

DM: Also, sort of a multiple overlapping category in the BPM suite, which is neither here nor there.

BGB: Well, Lyndsay, since we have that lead-in to BI. Can you please define BI for us and tell us also, do you see this BI shifting in any way since you've been covering this space?

LW: Sure. BI in general is more than just a set of software analytical tools or an approach to capturing data or viewing data. Realistically, what it is is a solution that enables organizations to analyze information and really to make better decisions. So, really, it uses technology in order to enable better decision making. And what you ask in terms of trends, it's actually a really interesting question especially with the convergence of business intelligence and BPM.

Because as business intelligence becomes more mature in organizations and as organization really strive to constantly improve their processes, there seems to be this convergence of business intelligence and BPM so that organizations will use BI applications on top of BPM in order to really monitor and set metrics to see how business processes are performing.

DM: Well, you could argue that a lot of BPM suites seem to incorporate a lot of BI-type functionalities indirectly.

LW: Right. Exactly.

BGB: Absolutely. And, you certainly could implement BI without BPM or without SOA, correct? Companies have been doing that for years.

LW: Definitely. But I think that as organizations move towards trying to optimize their environment and their performance, they'll see that it becomes almost essential to really integrate with BPM and then to use SOA to kind of tie together all the layers.

BGB: Okay. So, what I'm hearing is some commonality at the definition level. SOA is a set of concepts, guiding principles for best practices for architecture. BPM is a discipline for optimizing and managing business processes, and BI is also a process and discipline for better decision making. But let's now talk about each of these in relation to SOA.

So, JT -- let's talk about, you know, SOA, EDA and these other things. How do you see them coming together? Is there a synergy between them?

JTT: I absolutely believe there is a synergy. I think that what we're seeing in our discussion today in convergence is really the result of an evolution, you know, that had taken place within the industry, with the types of technologies that are available, systems that are available. We can now, more readily combine functionality from a business process management suite that's going to manage a process and monitor a process for, you know, improvement purposes and a business intelligence tool that's going to support decisions within that business process with an underlying service-oriented architecture that can, you know, respond to or conduct steps within the business process and in event-driven architecture, which can then in turn generate events that may even initiate or change the way that that process behaves.

So what we are really seeing is more of a convergence of the architectures that are being built. The solutions that are being built for customers by combining different technologies, different types of underlying Middleware products, BPM suites, BI tools, into an overall solution that's really geared towards the true operational business processes of an organization. And really combining all these tools to support that.

BGB: Okay, Derek -- I'd like to get your view on this now. Especially, you know, with BPM and SOA and people saying they are the same thing. I think there is the biggest confusion with those two.

DM: To be honest, I don't really agree that they are the same thing.

BGB: No.

DM: They've got a number of very common approaches, philosophies, that process at the center of both of them. But the reality is that SOA is primarily a technology driven way of developing IT systems. BPM, on the other hand, is more about business taking control of its own future and really driving things with model. And I think there is, not that there's gonna be a road crash but I think there's a synergy between the two approaches. But they're not the same thing.

BGB: I would agree with that. They are absolutely not the same thing. The SOA --

DM: I might add, I was going to say that I might add that I think that, you know, they are both focused on the production engine of the business. The production engine in the sense of those rigorous transactional things that have been, you know, if we thought about processes, a spectrum between procedure at one end and transactions, if you like. And business practices at the other end. The sort of things that you and I do, Beth. You know, at the business practice end, which is what knowledge workers do, BPM is starting to get to grips with supporting that. And if you look at it numerically, it's about eighty percent of what the business process is all about, is more about the practice things, are more about adapting process on the fly than controlling it and changing the floor.

BGB: Okay. And if it is more about adapting business process, then are you saying that SOA would enhance that ability to adapt to business process?

DM: Well, you're gonna have services that do things for you and you're gonna to invoke them and really this comes down to a cultural position of the organization. Some businesses are go back to the old CMM, CMI thinking are very much level I, level II type organizations. And their aspect is always going to be about control. Whereas you look at a level IV, V organization, they're going to be about empowering their employees and doing things with processes and letting them be in control rather than an assistant be in control. And there are some real challenges there in terms of, for the IT department, to be able to wrap their head around those sorts of things.

BGB: Okay.

DM: On the other hand, if we look at BPM and Software-as-a-Service, I'm just thinking futures for you for a second, there's a real opportunity starting to open for this knowledge worker demand and business process and software delivered on the fly. Which you can't really see happening from a pure SOA orientation, although of course, there are services and Web services that you are going to incorporate into those things.

BGB: Okay. I am going to bring our audience into the conversation a bit. Ask them what they think! I would have to agree, I just really do not think SOA and BPM are the same thing at all, although both help improve business agility and processes in the end. But there are, they focus on different things. Services can be about a process but it's a way of organizing an architecture and I think processes are a way of managing the business and they sort of, one goes on top of the other. At some point.

Now, I'd like to bring Lyndsay into the conversation now and add the BI into the mix here. How do you see that going, Lyndsay?

LW: Well, I definitely almost wanted to expand on what JT was saying. In terms of convergence of solutions, what I had mentioned before about BI and BPM, etc, all moving in the trend of really using BI to have optimized business processes. But another area, in terms of BI moving across the organization and kind of being placed on top of different ERP, SCMs or CRM systems, in order to really have these solution interoperate and really integrate and converge with one another, SOA becomes a key piece to that. In terms of the background and the IT infrastructure.

BGB: Okay. Now, here's a question. I'm going to give it to you first, Lyndsay, from the audience and by the way, if you have a question, just press the "ask a question" button on the console and they'll just keep coming in. Where do you see, now this is a question that has to do with EDA as well. Where do you see EDA going in the future? Will BI get folded into SOA completely? Now, I'm not sure I understand that question. EDA in the future. So, EDA, BI and SOA. I can't imagine BI, I'm not sure about the folded in. But I'll leave that to you, Lyndsay.

LW: Right. I mean, I always see BI as being an independent piece. Yes, it will integrate with other areas but in terms of BI, there will always be a stand-alone BI component and I don't really see it getting folded in to the mix. There might end up being full solutions that everything is integrated with one another, but in terms of it getting folded in anywhere, I don't necessarily see that happening.

BGB: Right. And when I think of BI, I think the secret sauce is really in those analytics for decision making.

LW: Exactly. It's being able to get the right information to the right people and being able to analyze that information. So --

BGB: Okay. So you may, and the BPM and BI -- certainly there's a lot of partnership going on now there. And maybe BPM companies having some BI capabilities, partnering for more advanced BI capabilities, I see as those two as a trend getting more closely folded in. Do you see that?

LW: Oh, definitely. Definitely. There's a lot of overlap. Not just in terms of using BI, let's say to optimize business processes but also the other way around in terms of BI and BPM, like you said, converging and different vendors creating partnerships to really be able to optimize both sets of software.

DM: If I just may interject here for a second?

BGB: Absolutely!

DM: It's quite interesting to me inside the OMG recently. We've had an ongoing initiative there called BPRI, which stands for Business Process Runtime Interface. And that was really to do with, really to do with the runtime information and artifact of a process, in terms of making it available in a standard format. Which should be easily consumed by a BI platform. The interesting thing to me was there weren't any BI vendors that seem to be interested in stepping up to the plate to take part in it for a discussion. And for the moment, we've had to put the whole thing on the backburner. Because we've been unable to engage any of the BI vendors, any of the significant ones, into a discussion about having a standard interface where they could extract stuff out of a BPMS in order to present decision, information and what have you to the organization.

So I'm not so sure that there's a marriage made in heaven, really, in the sense that BI vendors, I suppose I'm talking about the majors, the Cognos' and the Hyperions and the what-have-you, that’s -- some of those are getting swallowed and taken to other places. They seem to want to just control the executive order and apply at that level. It's hard to see how that is a marriage made in heaven although I see a real synergy effect it that would only come to the table.

BGB: Okay! Derek, can I ask you this question from the audience actually. To clarify what you mean by level I, level II organizations --

DM: Oh, I was referring to the capability maturity model.

BGB: Okay.

DM: So, a level I-type organization is where most people, you know, make up their own way of doing things. Level II-type organization, you standardize the work at the business unit level. Level III-type organization, you standardize the work across the organization, not just as a single business unit. Not just to have different business units doing similar things in different ways. Level IV, you're really starting to run the business by the numbers, which is archetypically where the BI vendors are trying to support organizations going, and level V is sort of the nirvana sense of, just think of Toyota and GE and that's your level IV, V type organization.

So when I was describing level II-type business, you find real interesting differences between those sort of organizations in terms of how they design the processes, how to sit up to run projects. You know, quite different from between level II and level IV, or level III in terms of the organizational structures that are used.

BGB: Okay.

DM: Does that answer your question?

BGB: Yes, yes. It's the SCI Institute and to say that process, now we're talking about process as if it's a new thing. But, Deming did process worked 50 years ago, and worked with the Japanese who, in the manufacturing and they beating the pants off of us in manufacturing. And he said, 50 years, over 50 years at this point, 60 years ago, saying that process was the core for business competitiveness and I think now we're first getting around to understanding how to create that from the bottom up into our enterprises.

DM: Yeah, and I think that the real issue was the word process. Because, if you think about it, everybody you talk to has a totally different flavor of what they mean by the word "process." So you know, the high-level executive divisionary, the strategy guys, they think about process as process as a purpose. You know, you have a customer relationship with process. You have a process for purchasing or whatever. But process is purpose and really this sort of idea there is you can pick this notion of purose and work out what roles, what behaviors you really want to exhibit and from that you’re going to design the organization.

The problem comes when you start talking to the organization, particularly the IT function that supports the organization. They immediately apply sort of functional decomposition approach and think, well, you know, that's the way in which we're organized so that's now a process as we go, and the two are not the same thing. A process is not necessarily the parts between all the activity. And so the problem with the word "process" almost is that everyone's got their own subtle interpretation of what it means. And these procedural notions abound, really everywhere, where you have a sort of sequence of activity. But it's very, very difficult to get everybody singing from the same songsheet in terms of how we're going to approach that. And there's a certain degree of maturity that you just have to go through. You just have to develop your skills and experiences. You can't bypass some of these things.

I mean, I had a conversation with a guy in Saudi Arabia who set up the accounting standard for the country. And he was saying, "Well, you can't tell me anything about standards, about process, because, you know, I used to be an auditor. And I know all about process." And really, what I'm, the reason I'm using those as examples is because he knew that process from his point of view at that point and it's one of these areas where there's lots and lots of wrinkles.

BGB: Okay. Now, we have one of our listeners -- is disagreeing a bit with Lyndsay. And says, "more and more Web 2.0 apps are integrating BI both structured and unstructured information. I think the operational world and analytical world are symbiotic. BI is critical to process enablement. It cannot be a silo. I think closed-loop processing is already here and being implemented." Lyndsay, do you want to respond to that?

LW: Sure. I mean, I definitely agree with that statement. But I think what I was trying to get at is, even though there will be that integration and we do see it with different, especially with the unstructured and structured element coming in and BI really transitioning over to encompass process improvement, there's still going to be kind of the area of BI just also being separate from that and being implement in a strictly way that's geared for better decision making within the organization.

Aside from that, even though these implementations are taking place, it's still very early on and it's going to be the next couple of years until we really see them permeate throughout the industry. Right now, it might be a few organizations that are more mature. However, in terms of actually being commonplace, it's not as common yet in terms of data warehousing, really being able to handle unstructured data and etc. I definitely agree with the statement. However, I do that BI -- even though it will integrate with these areas -- will still always also be a standalone.

BGB: Okay. There are certainly ways to integrate it and there's a whole other architecture that we're not even talking about here in terms of information architecture, data architecture -- so, that has to do with it as well. Okay. Another question from our audience. And I'm going to give this to you, JT, to start off with: In case an enterprise is in a situation for rearchitecting their enterprise architecture and re-engineering business processes, should they first do an SOA architecture as foundation and create BPM on top of it? Or should they be done independently. Is there a best practice that you should build the services first, then design an overarching BPM using those services?

JTT: Well, I think that given everyone having enough time and money to take that type of approach, you know, that's one approach. But it's really -- to be honest -- it's not one that we generally recommend or even see out in the common, you know, in the marketplace. And the reason is, is because SOA, first off, as I've think we've agreed is a very technical approach to delivering a collection of services. And so, given that, it has a variable entry and therefore an incremental approach serves many purposes. You know, getting the initial set of tools in place that you may need. Getting your resources trained up. Getting your infrastructure prepared.

And, so, an incremental approach choosing, I guess the answer to the question -- I would do the reverse. I would, in fact, start with looking at a business process or a segment of a business process that I would like to automate or improve and then take that and use that as a driver to then take a service oriented approach to accomplishing that, which would mean the technical enablement of the systems that are involved in that process. I would use an SOA approach to achieve maximum reusability and agility, include those in this current business process project, and then take -- again, continue to reiterate through that cycle. Take another business process or another business process segment, another collection of systems. See how much reusability you can garner from the first project, turn it over to the second and then sort of move that as a wave through your infrastructure, automating and re-engineering the process and automating, support that.

I mean, I guess my opinion is that the business processes should govern the organization behavior and systems should support that. So I would actually start from the process angle first and then take the SOA approach as an implementation approach.

BGB: Okay. And I would, go ahead, Derek…

DM: I was going to say, Beth -- can I just support that and sort of take it a little stage further on this thing?

BGB: Sure.

DM: Everything JT just said is, I think, absolutely correct there. The keynote about it, it really comes down to "Where are you going to start?" and how much scope are you really going to deliver and how much are you are going to bite off in the first crunch of doing that sort of thing? And it really means, I think, the best practice really comes down to ensuring that you engage in delivering something very quickly. That delivers a real benefit to the business.

That means, you know, identifying a project that's not too complex, that's got a significant benefit coming from it, that for argument's sake is a relatively low-level of quality in terms of its maturity from a process point of view, and you can, you know, this is the archetypical low-hanging fruit. Really, you want to get the business behind you, pushing you rather than in front of you resisting. And, if you try to do all those things at once, just say run an organization-wide BPM program or organization-wide SOA program, you're gonna run out of steam before you get to the end game.

So you've gotta do things in bite-sized chunks and increments and develop from there.

BGB: Hmmm, yes. Think strategically, implement tactically perhaps. And, JT, I will agree with you. Those of you who missed the session just previous to this, Brenda Michaelson and I presented something called "Business-Driven Service Design." And it is exactly what you talked about, JT. Starting with a business process business requirement, actually, it's either business process events or interactions because there are different styles of solutions there. And then drilling down to that, to define the business activities and then different layers of services from there. So a business-driven approach to get there. But I agree with everything you've said.

I just want to share the results of the survey and put to rest, also our audience is also in agreement, they're not the same thing. Sorry, Steve Mills, please stop talking about them as if they were the same. Stop confusing everyone there. Different things but very synergistic. Now, this is an excellent question that came in from the audience that I'm going to throw out to the panel here: What approaches should be taken to align SOA, EDA, BPM and BI? Each one is a significant undertaking. So when do you start looking at the intersection without being overwhelmed. Who wants to take a first stab at this? Best practices --

DM: I'll take a first stab at it, if you'd like, Beth.

BGB: Excellent. Go ahead, Derek.

DM: In a sense, all of these initiatives need organizational, executive support. You shouldn't be doing any of these things without having them underwritten, signed off, bought into, call it what you like of the steering group of the organization. The steering group which probably contains the COO, the CIO, and, you know, key managers. Because each initiative in its own right has a real impact in terms of what's going to go on, or how the business is going to approach it and what have you. And I think, the other point is that you really want to start, again, come back to this point and doing things in a manageable, measurable sort of way and looking at each part of the program as it develops and actually ensuring that you're delivering a lot of success early up front to get the business really behind it. Because otherwise, you're not going to get through any of these. Whether or not you think you are, but without that business support, you're really going nowhere fast. And you will get overwhelmed.

But I would very much be focusing as JT was putting it just nice, on business-driven opportunities. You know, the low-hanging fruit.

BGB: Okay. Anyone else want to answer that?

JTT: Well, at the risk of repeating myself -- this is JT -- I would just say again, taking a, finding a problem that had different aspects of some of those areas, BPM or BI, and then using SOA or EDA to actually support it from an interfacing with the underlying systems area. I think that's really the main thing, is if you think about services as things that do something and respond, either accomplish something or, you know, respond with information, events actually generate information from, they're actually considered to be an event service, if you will.

And, then, one way to think about business intelligence is actually as a collection of data services or intelligence services, analytical services, where I could have a service that I gave a customer identifier to and it did analysis against historical information, and operational information and gave me a truer picture of that customer for whatever purpose it may be that I'm considering that. That's a utilization of SOA. That's a utilization of business intelligence and all of that could actually be a part of a business-process managed project.

So, I think, again to go back to the business. Look at a particular opportunity, say "Do I have information that, of a business intelligence nature that I'd like to use to help solve this problem as part of the solution?" and then just go from there, and pull everything together.

BGB: Okay. Now, when I think of SOA and EDA, I think of them as architecture practices. They're concepts for how to, to guide people. Like how to create things in a better way. And we can do it because of how technology is faster. We can have them loosely coupled and things still work fast enough. When I think of BPM and I like that management part, as Derek said in the beginning, it's a set of concepts. It's a way you organize things. But the tools that you would put in place give you the monitoring to enable the management. So if you had business people there, I sometimes call BPM the killer app for SOA because you're giving information, real-time information, in the hands of business people so they can better manage and optimize their business processes.

If you add business intelligence to that, then you're giving them more agile decision-making capabilities. Because you're giving the information there in context along with everything else they need to make their decision making. So maybe you start off with a business problem, understanding the business problem. The constructs are sort of up to IT to decide underneath the cover if this is an event driven, or if this is request/reply or whatever else it is. But what are the business capabilities that you need to implement there? I mean, that's the way I look at, giving successive layers of agility in the organization.

Now, here's a good question and perhaps a good one to end up with. Can anyone give a real-world example from start through BPM to SOA and realization? I'm not sure, what I thought it was an end-to-end, how you start? But again, JT has sort of said this very well a couple of times in this conversation, if you start with a business problem, that's a business process you want to solve and implement it on to SOA and then you sort of figure out how to integrate the underlying systems.

But maybe, maybe it's the idea of a case study? Does anyone want to talk about a case study that they've seen implemented to do this? Derek, have you seen any of the organizations you work with implement it this way?

DM: Well, to be honest, when I put that paper together on the relationship between BPM and SOA a year or so back. I thought I was gonna find a lot. And the reality is, I didn't find too many that were taking that combined BPM-SOA sort of style of approach. I think that's changed. I'm not sure I could talk to a case right now, off the top of my head effectively that would describe that spectrum of activity. Certainly, there's, one can find plenty of cases that have services oriented components within them but they set out to do a SOA architecture to begin with or did they set out really to organize and solve some significant business problem with a business process related issue.

I mean, in a sense, SOA is like a best practice design principle. And if you look inside a lot of the BPM case studies, you'll find people applying business practices and principles that incorporate SOA type functionality. I'm not sure I've seen a SOA case study that talks to the BPM end of the spectrum either, which is perhaps why the individual was asking the question. But, I don't know, one I suppose that occurs to me while I'm speaking now, off and on, in Europe, there's an organization called Telianor which is one of the large telecommunications organization.

And what they did was they found that they had, I don't know, some, I can't remember the precise details, but a large number of different approaches for implementing this type of network, that type of, you know, SDL and that type of Internet access. This type of phone exchange or whatever. And really what they did is, they integrated a whole lot with business process architecture and then created services to handle those components, that handle the specific use cases that were then called by the business process.

And had some dramatic benefits, again, without having the case in front of me, so I can't talk to it specifically.

BGB: Okay.

DM: -- an example. It's probably worthwhile just pointing out there is actually a body of work about case studies around business process that used to be run by the Workflow Management (43:21) Coalition, which was really organized by a colleague of mine, which is a global excellence award in BPM work flow and if I was to go through those cases, I'm sure I would find several. But off the top of my head, it's hard to talk to that right now. That sort of case study, of course, is going to be this year, the case studies for this year are going to be presented in the end of February, an international sort of event but people can find about it they visit the BPMProcess Web site.

BGB: Lyndsay, have you seen anything in the area of adding the BI to the mix, that significantly added business value. Because we're really, the bottom line is adding business value here. Up and down the stack and we're thinking, you know, business intelligence enabling, you know, getting it to the level of a business decision to me is sort of the icing on the cake once you start to add that. Have you seen best practices for how companies are going about this?

LW: In terms of integrating SOA, I haven't. I'm also, I mean, I've heard different case studies in terms of adding business value of more of BI and BPM integration but in terms of SOA, I have to say, like Derek, I can't think of any off hand at the moment. In terms of case studies that come to mind.

BGB: Okay. Okay. And do you have any metrics, have you seen any companies getting real value out of adding the BI on top of the BPM?

LW: Yeah, definitely. I mean, we see companies that I've spoken to in terms of just being able to really get to the crux of their decisions faster, better decision making, just because they have access to information faster. One of the other things in terms of business intelligence and BPM is more of a move towards operational BI and really enabling getting more information quicker to the right people.

So instead of just having this concept of information capture monthly or weekly, people will do it daily or multiple times daily. And what it does, is it helps with, let's say an organization is identifying if we go back to the automotive industry, which we mentioned a while ago, in terms of part defects or what parts are coming off the chain in terms of manufacturing, and are there any defects, at what particular time. Embedding BI into this process, you can identify, let say at step III, within seven steps, that this is where there's some sort of defect occurring, let's say, eight percent of the time.

So, it's just, it's kind of an odd example, but it just kind of highlights the fact that BI can really be used within BPM to really help enable better processes throughout the organization.

DM: Can I just chirp in there, Beth?

BGB: Sure.

DM: There's another angle there as well. Which is, of course, if you've got your BPM suite running the process and driving work to the business, what it's really doing is gathering a lot of metrics for you around where things are perhaps taking longer, where there's a high degree of variability, which points to low levels of maturity in a particular area of a great degree of variability. We can help you identify the sort of types of cases, the classes of work that are difficult to handle in the system, that are not easily handled in the way that we're set up at this point in time or if the process doesn't do well, whatever.

But really, what it's doing is providing you with the tooling that allows you to get at the data. A lot of organizations don't have this information available. You know, when push comes to shove, they think -- "Well, let's see, we do okay on handling our cases in two days" but they can't tell you exactly why or how. Whereas the BPM suite is going to do that for you and provide the base information that your BI engine is going to deal with.

BGB: Okay. We are running out of time. I apologize. But, just to sort of wrap up what I'm hearing -- if we started, this is not where you'd start in your process for implementing but if we think about the layers of the architecture underlying SOA, those are the services, those are the functions, the applications, wrapped as services or Web services, are all those pieces that we can flexibility combine into business services. The business service layer, you're defining the flow of control across those back-end systems. Maybe to external partners and suppliers, packaged applications, Web services -- so you can flexibly combine the functionality and that is feeding some analytics to BI. And you add the BI on top of it and you can get operational BI. So people get the information they need in order to make faster decision making. Do you think that helps, an accurate representation of the way these things work together.

Well, I believe that helps, and give us your feedback. I want to thank JT, Derek and Lindsay for joining me today. I do have four winners of the books here and I'd like to read those out. The four winners are: E. Marquez of LANstar won Enterprise Integration: The Essential Guide to Integration Solution by Beth Gold-Bernstein; William Rue, K. Caldell Jack-in-the-Box: Service-Oriented Architecture, Concepts, Technology and Design by Thomas Earl; M. Edwards from US Bank won Service-Oriented Architecture for Dummies; and V. Grotto of TMobile, SOA for the Business Developer: Concepts, BPEL, and SCA by Ben Margolis.

So congratulations to all our book winners. I hope you'll all take the opportunity now to visit our exposition and here, you're going to see in front of you in a moment the iWay booth. So take a look at the booths there, they're kind of cool. And thank you all for attending this virtual conference. I hope you all have a great day!