Participants in this Roundtable are Ron Ambuter, CTO, BPM Workstream Group, JPMorgan Chase; Hub Vandervoort, CTO, Progress Software; Keith Swenson, Chief Architect, Fujitsu. The moderator is Ronan Bradley, Principal, Lustratus Research.

Replay a 1:50 answer from Ron Ambuter on how JPMorgan combined SOA, BPM, BAM and reuse:

Download audio file

Replay a 3:50 answer from Hub Vandervoort on how CEP is adapting in financial services:

Download audio file

Replay a 2:33 answer from Keith Swenson on how BPM is working in financial services:

Download audio file

Participants in this Roundtable are Ron Ambuter, CTO, BPM Workstream Group, JPMorgan Chase; Hub Vandervoort, CTO, Progress Software; Keith Swenson, Chief Architect, Fujitsu. The moderator is Ronan Bradley, Principal, Lustratus Research.

Ronan Bradley: Hello, and welcome to the latest of the ebizQ in Action Conference series. This roundtable discussion will be entitled Building on SOA to Meet Today's Financial Services Industry Challenges. I'd like to start by introducing our panel.

First of all, we have Ron Ambuter who with over 20 years of experience in IT management, in general, and financial services, specifically, and has a particular focus on workflow and BPM. As Division Vice President in JPMorgan Chase, of the Centralized Transactions Operations, Ron is currently focused on horizontal enterprise business technology strategies touching on Business Process Management, customer experience and business agility. All of which I think we'll agree are major challenges for any financial services organization.

The second participant in today's roundtable is Keith Swenson. Keith is Chief Architect at Fujitsu Computer Systems Corporation for the Interstage family of products. Keith has been a pioneer in web services and has helped the development of many of the workflow related standards. Currently, Keith is also the Chairman of the Technical Committee of the Workflow Management Coalition.

Our third speaker will be Hub Vandervoort who is CTO of Progress Software and has over 25 years of experience as a consultant and senior technology executive in the networking communications software and Internet industries. As CTO of Progress Software, Hub has responsibility across the SOA Portfolio of products, including Progress Sonic, Progress Actional, and Progress DataXtend, Semantic Integrator, all very relevant products to today's discussion. Also prior to his CTO position, Hub has led a number of key initiatives including Sonic's expansion into financial services market worldwide.

And finally, me, Ronan Bradley, with 18 years experience in the IT industry primarily with software vendors focusing again on financial services, most recently an analyst with Lustratus Limited, a technology analyst firm.

As I said, today's discussion is focused on financial services. Of course, anybody who has knowledge or worked in financial services recognizes there really is no such thing as a typical financial services organization. Financial services spans a huge diversely different business ranging from retail, banking, to capital markets.

Each of these different areas involve very different types of IT problems and challenges to be solved. Clearly, there are different third parties to be integrated in. All financial services organizations in today's markets must work closely with the regulators for creating reports in a timely and accurate fashion.

Depending on the focus, whether retail or in capital markets, they will also need to integrate with various service providers and market data providers, and of course, other banks in terms of counterparties for exchanges. Within each financial services organization, there are wide diversity of core systems, information warehouses of which a few are listed on this slide. Again, these will depend on the type of organization we're considering, but what is clear is that any financial services organization has a major need for integration technology and a major need to be able to facilitate real-time flows of information across this complex network.

Ron Ambuter: Well, there are really four different initiatives that came together a year at JPMorgan. One was a focus on Service Oriented Architecture to see if that was going to be helpful for us. Another was Business Process Management, BPM and how to focus on business processes. Another was the whole concept of reusability, how could we get better leverage out of the efforts that we were making to build and buy applications by reusing components instead of rebuilding and rebuying them over and over again.

And the third aspect, which from my point of view is really a subset of Business Process Management but has a life of its own over here is Business Activity Monitoring, the ability to real-time monitor transaction processes and be able to react immediately to issues that maybe arising rather than worrying about how to apologize for them the next day. When we took at those four initiatives, they all seemed to overlap and overlay with each other.

Each of them can standalone but Business Process Management is a far more effective approach when its coupled with Service Oriented Architecture approach and the same thing with reusability is a factor of both of those and Business Activity Monitoring also so. I think that the overall drivers, probably the same thing that have been driving everything since I came into this line of business 127 years ago which is reduce cost, improve customer experience, and maintain competitive edge. So Service Oriented Architecture certainly seems to offer a lot advantages in those areas both internally and within the business community. Does that help?

KS: That's good in terms of something that has certainly become higher visibility and priority in recent years in financial services, which is the whole regulation risk management side of things. Do you think that's the increase of relevance of those issues is that holding back this adoption of SOA? Is it promoting the adopting of SOA? How's that playing?

RA: Well, I mean, regulation and risk is a factor of life in our business. We have to address that regardless of what technology approach that we take. However, the concept of SOA allows us to react probably quicker, and more expeditiously, more cost effectively also. So I think that they tie in, but I'm sure that we'd have to face the risk and regulations regardless. Just allows us to do it probably more effectively, more efficiently.

KS: Okay. And do you think that if it can allow you to it more effectively and efficiently, do you think there are any specific challenges when attempting to use SOA to operate with those environments? And I'd throw that out to the panel in general if other people want to comment as well.

RA: For our point of view, moving our perspective to SOA is a major change in how we do things, and how we look at things. So the challenges are more in the cultural level than they are in the technology level although there are some certainly some technology challenges involved. But the most difficult thing for us to move into SOA arena is adjusting expectations, and workgroups, and control points, and governance, and all the things that are inherent within that type of change.

KS: Okay. So this is as much as about changing the way that you operate as anything else?

RA: Yeah, I think that the benefits of SOA are prima fascia. I think that this obvious that there's a just a myriad of advantages to head in this direction. It's just changing the directions of the organization to accommodate it that offers some work and some challenges.

KS: Okay. Would any of the other speakers like comment their own experience of how those challenges are best faced and addressed?

So we're getting the advantage of reuse, but we're running into the problems of reuse, which is that things have to be coordinated better, and so that's where SOA governance becomes much more important than we've needed in the past with traditional styles of programming.

Not only do to you have to coordinate everybody in leading up to the SOA deployment, and the actual runtime application of the SOA, and make sure everything is lined up. But once it's in production, you have to also provide a very high level of visibility at a velocity that's greater than the actual business that's going on, measuring things nightly when transactions are happening hourly or in the second allows for big windows of exposure.

So the visibility and the provisioning, if you will, are the two sides that sit around the main pipeline. And what SOA creates is one -- an environment where not only do you get the agility but you can inject more measurement points. The loose coupling actually enables you to take much more measurement than you could have in siloed application development and perhaps obtain greater visibility.

The potential exists here to obtain greater visibility, and use that as informed information for how you go about making change, and apply regulation, and whether you're in compliance. But the fact that SOA is also enabling us to go on broader expanse. I mean include more parties, more rich multiparty interactions that span more domains and so forth, circles you back to the governance problem. Now that we have more people involved in these environments and can measure them and change them much more quickly, how do you coordinate them? So yeah, definitely challenges beyond the technology. SOA creates some new problems and also enables the solution to many of those problems as well.

RA: Some of the challenges that we face I think are incumbent upon a large organization although they may be equally valid in a small organization. But we have rules and responsibilities that are compartmentalized by groups of folks, and we realize that as you go into this stuff, education and cross-pollination of information is critically important. It's not just the technology folks that need to understand this stuff, it's the risk folks, and it's the governance folks and it's the finance folks, and it's the business side folks. And even coming up with a common lexicon so that when somebody says a word, all of the pictures in everybody's mind is the same is a bunch of work, I guess.

KS: Okay. And that certainly goes well beyond the simply the tooling that can implement that although clearly the tooling has to be able to support that. I mean do you see that providing the common lexicon? Is that something that fits within a governance solutions in terms of the software? Is something that is totally dependent solutionv -- which is it?

RA: Well, the governance approach that we're taking is very definitely related. Everything is trying to come from the same point of view and the tools that we're looking to use are very helpful in driving that. It isn't necessarily that it's a right or wrong, it just has to be consistent and that's what we're striving for.

HV: Right. Absolutely. I mean, again, when we talk about these multiparty or what we sometimes refer to as federated interactions between either different divisions, or departments, or even companies, the thing that's interesting is that with all the mediations, if you will, that need to go on in a SOA environment -- transports, protocols interaction model, processes, and so forth, and then likewise, the fact that domains have different infrastructure and so on. It's interesting in our observations that it's easy to get bogged down in trying to get alignment on a lot of different points across all the groups. And what we find is that they really tend to three key lynchpins that play into it.

And if you get those three right, you can avoid struggling with agreement around a lot of other areas. And those specifically are getting your transports aligned between business entities so that you can use eventing-oriented mechanisms to communicate across domains that you get your policies correct so that from an SLA and security, and as well sort of visibility and commitment kind of approach, you can get those things into the picture.

And then thirdly, you have to get your semantics aligned among the members. And that doesn't have to be a common vocabulary in its entirety, but certainly what we regard as the data in flight, those things that fly between domains and different working groups have to be highly normative. I mean in a strict technical sense that suggest employing canonical models.

But having the tooling that enables for a good event-oriented process paradigm, a strong policy enforcement and visibility mechanism, and a strong semantic alignment between those groups can really enable domains to interoperate and govern themselves without getting bogged down in things like infrastructure, decisions and so on.

RA: That's just really about putting up a base technology platform that's going to enable then the collaboration at the higher level.

HV: Well, at a minimum of philosophy, if not a common technology. So it doesn't predicate a common technology, of course, it goes faster if you have common technology to provide for all that. But if you get alignment on the expression of semantics and policy, you can even do it with the dissimilar technology.

RA: If I can ratchet it up a level above the technology layer, however, to just as a case and point, our organization, many organizations that I've familiar with over the years tend to be business-focused silo organizations. And let's say a business has some technology applications that they were using to manage a piece of their business that was likely to be on a set of infrastructure that was owned by that business, the technology was owned by the business. The costs were all owned by that business. The costs rolled up into the unit costs of whatever product that they were providing, and everything was easy to control. Now, we're looking at technology that really provides significant advantage to the organization by looking horizontally across these businesses and sharing things.

And now, the question gets to be how to do it technically is one thing, but how do we allocate the costs of services that are used across multiple different organizations and they're used ad hoc, they're used as needed. How do we allocate the costs? How do we appropriately give our product costs squared away and all that sort of stuff?

Those are the cultural challenges that I'm sure that as time goes by it'll become easier, and easier, and there will more and more best practices out there to leverage, but right now, it seems to be a lot of work and a lot of focus to try to get some underlying governance put down.

KS: From the sounds of that, that governance must extend or have participation from the business side as well. This can't be an IT only initiative.

RA: Yeah, I think this whole evolution, revolution in the technology approach is finally bring the pendulum to dead center with the influences going back and forth between the business and IT over the decades, swinging one way or the other. I think that this really calls for a true partnership between the business and the IT folks to be effective. And it seems to be seen that way, and it seems to be effective that way here at JPMorgan.

HV: Well, there's no doubt that, this is Hub, again. There's no doubt that BPM and BAM, in particular, provide high levels of alignment with the business. Those are things that they can visualize; they can see, they can understand. But at the same time, providing the underlying infrastructure to enable BPM and BAM, the visibility and the control, and governance at the process level is a key lynchpin. So they kind of work in a triangular relationship, process, and process governance, dependence on SOA, and visibility depending on SOA, and the visibility being absolutely essential to providing informed governance, and it becomes a closed loop at that point.

KS: Yeah, that's absolutely right. And in fact, that's the role the BPM plays. While SOA is, basically, a technology trend, BPM is essentially a management trend and it's very important that you notice that a lot of people look at BPM and they get confused between the management trend and the technology trend.

A lot of technology product companies have looked at BPM and looked only at the technology and come up with a kind of a programming language that they claim to solve the problem, which is great for the IT side of the house, but it leaves the business side out of this. As far as the adoption of BPM goes, one of the biggest barriers to adoption of the real business process is essentially the fear that the manager will lose control of the process.

And I know that we tend to think of processes as very stable concrete things that never change but, in fact, a good manager and a good organization is constantly modifying and adapting the process to account for situations as the arise. And the fear of losing control, losing the ability to respond to these kind of things is one of the barriers to BPM adoption. But it's also the capability, the agility that BPM brings that, ultimately, allows for people to adopt the technology and to the adopt the cultural change that's necessary to automate your business in that way.

KS: Keith, could you just expand on the fear of loss of control? Is that because the process is now automated and therefore invisible to the business manager or is it because it's not extending beyond the department the business manager has remit within?

KS: No, it's a little different than that. Lucy Suchman wrote a great book in 1988 called Situated Action. Now, what it documents is how organizations are successful not because they do the exact same thing every day, but quite to the contrary, it's because they adapt what they do so the way that the situation changes every day.

So people are joining and leaving teams, they're taking vacations, they're out sick, there are changes in the law, there are changes in market pressure, a new competitor may suddenly appear, or a new opportunity may suddenly appear, which if acted upon could give the organization a market edge. So the companies that are successful today are the ones that have seen those opportunities and that have been able to respond to it.

But, I think, managers have a fear that they will be locked into last year's process and will be using last year's process in order to face this year's challenges, and that's a very real fear. Again, it's hard to overemphasize how important agility is when it comes to modeling and implementing real business processes.

HV: Keith, this is Hub, I think that is an excellent point. It speaks to one axis of the problem. Metaphorically, I'd say that the guy's afraid you're going to pour his process into concrete and you can't change it anymore. And indeed, BPM and SOA enable a much greater agility than that perception would suggest. On the other axis though, what I think is interesting, is that SOA is allowing us to reach way further and create multiparty interactions in ways that no prior generation permitted.

I mean the web allows us to connect to a billion points but one at a time. Now, we can actually build applications that the end user experience could be made of 20 different systems worth of technology across multiple domains. And what I think is interesting observation as well, is that process ownership, as Ron was suggesting earlier, tends to follow P&L ownership. In other words, I'm not going to take accountability for a P&L if I don't also control the process.

KS: Right.

HV: And given that that's true, and now processes begin to extend across domains, domain owners get very uncomfortable when the suggestion is made that another domain might be manipulating or controlling process within their domain or usurping their control over processes for which they may have P&L accountability, or regulatory, or risk accountability over.

And so this tension of control of the process that follows business accountability is really exacerbated in a SOA environment because you got all these domains of accountability and yet they have to provide for a single uniform experience. And I think that that's where the cultural shift is happening more than anything. And that, conventionally, we used to use hierarchy as our main management control, right.

We'd just make everybody in our domain do what we needed them to do. But now, that you're in this multi-domain environment, you don't have hierarchy anymore and you have to find new mechanisms to facilitate it. And I say the shift -- I personally I feel that the shift is more away from hierarchy toward a notion of trust and commitment.

And so to achieve trust and commitment, you got to have a federated governance system where everybody can see one another, and therefore trust them, and enough of a sense if they have enough control over the federation that as change is made, they're not going to be undermined, usurped, marginalized and so on.

RA: I mean that's definitely the direction that we're heading. We've been doing BPM and BPM type stuff for many years. And to be honest, I think we're getting it pretty much right. The effectiveness of our BPM program and the ability for our IT and our business people to work together has been very encouraging and it gets better and better.

But we get to the point then we realize that there are better ways of developing our BPM applications using more agile development approaches than we have in the past; that's a challenge and change. And we realize that when we looked at each individual project or application as a separate BPM project that stood on its own, and realize now you can create processes that you can expose as services and reuse, that there's a huge advantage to that, that's just augmenting the BPM approach and that's where the challenge is going across the horizontal level become more apparent and very definitely we've decided to put in a governance body that is multi-business across the top, it has the authority and they can feel that they have the control and the input to not be compromising their --

HV: Sovereignty?

RA: -- profitability.

KS: And do you think that the current economic conditions are going to encourage people to move in this direction? Or is it going to force people back into their silos and focusing on their individual objects?

RA: From my point of view, it's very definitely forcing them forward. The business environment is becoming increasingly cost conscious and at the same time, customer experience conscious. And I think that there's a lot of concern among the business folks and the customer facing folks that doing things the old is too expensive and too slow so there's a lot of hopes and expectations built around the new approaches, but they are equally concerns about how to control the new approaches. We knew how to control the old way but the old way was too slow and too expensive. So here's a new way and that's great but how do we provide the controls for risk and for financial responsibility that we need? And that's where we're spending a lot of time trying to put together the right models.

KS: Yeah, the current economic client is definitely pushing this forward. I mean, BPM does make organizations more effective. It does allow them to do more with less. It also allows them to track what's going on and to be more accountable, more responsible about reporting what they've been doing. I mean, it's a funny sort of thing as this technology comes around. I mean Sarbanes Oxley was, basically, an outcome of everybody having all this information and the ability to report. So then along came something that made it a requirement to report. I mean, I think, we're going to see trend is going to be that as this technology supports business processes, and as people are more and more efficient on it, it's eventually going to become a requirement you'll have to have this in order to remain competitive with everyone else.

KS: Okay. And Hub, you see the same in terms of the ability to gain visibility into the data flows and the process flows with event processing technology?

HV: Well, no question about it. I think that there's kind of sort of two issues. I think the cost issue has always been front and center with SOA and SOA has always purported to reduce cost. I would agree more or less on the same basis points that BPM provides for the same. But what maybe belies some of the cost advantages that you get, and this is particularly true in financial services is that the velocities of the business itself are increasing.

I mean I think Ron would agree that financial services is moving kind of in a logarithmic increase in velocity. Decade over decade, things are ten times faster than they were a decade ago for sure. And given those velocity increases, what I find interesting is that the relationship between your visibility and the speed that you can visualize how fast things are moving has to be far greater than the speed of the pipeline itself, meaning in strict terms in financial services we were at T+3 ten years ago; now, we're at T+0.

And when you go from three days order to settlement or trade to settlement to now under two hours trade to settlement. If I'm doing nightly reporting, I'm way out of alignment. Whereas ten years ago, that was three times faster than the speed of the pipeline. Today, you the ability to run awry in risk, terms, and exposure terms has been seen multiple times in the industry in recent years.

And in part, that's because the visibility wasn't keeping up with the speed of the pipeline. If a guy can do $7 billion worth of illicit trades in one day, and you find that out at the end of the day, that's not very good. So what we're leading to into your question is Complex Event Processing becomes kind of the next level of BAM, if you will. That at the point when simply putting on a dashboard is -- despite being substantially better than running it through the data warehouse in a nightly report, may not be enough when you start to consider the speed and volume and of the pipeline itself being so fast and so vast that you now have to put autonomics on that.

And certainly when you look at our customers, you're going to look at the FSA that have to surveil the entirety of the UK markets, all markets and do that in real-time and pickup on fraudulent or suspect trading in the span of minutes from the occurrence or even preemptively to a substantial fraudulent event taking place. You can only do that when you're processing or computing a result on thousands if not tens of thousands of events a second and doing that in sub second kind of analytics. And only CEP really kind of takes it to that level as the higher level of visibility.

KS: Okay. And I'd like to just remind the people attending this roundtable that they can ask questions by pressing the question button at the bottom and submitting a question, which we'll get to in the discussion where possible. If I could just pick up for that point, Hub. Given what's been going on in the financial markets recently and changes in regulations, do the panel participants expect that regulation and risk is going to become a larger priority again and likely to become more involved in the source of technologies that we're talking about here? Because in the lead-in, I think, Ron, if I could characterize what you said, as that's why its there's it's not driving the move towards Service Oriented Architecture or to greater levels of real-time integration.

And if you'd like comment on that. Will risk management and regulation get back in the driving seats to a greater degree?

HV: Well, I understood, this is Hub again. If I understood Ron correctly, is that that's just a fact of life, a table stake that risk and regulation are always going to be present. I think the breath of regulation in the last few years certainly with things like REG NMS MiFID and now PCI are all driving a lot of project-level work as we're seeing it and much of that is actually being satisfied with both SOA, BPM, and visibility-oriented technologies. But there's no question that with now as we're beginning to measure the credit debacle is eclipsing a trillion dollars in aggregate losses. I think the idea of real-time value at risk, real-time quantitative risk adjustment, and risk assessment is going to become more and more important. And BPM and CEP become essential roles in that. One, to take in account all of the different various ways I want to do those risk adjustments and risk surveillance types of applications.

And then, how do I alert the appropriate stakeholders in real-time to the right process they have to execute to deal with those things? I mean mortgage lending couldn't be a more prime example where the velocities outstrip the ability of the risk monitoring, and risk adjusting to actually keep up with the velocity, and then it ultimately led to the unraveling we see now.

RA: It could even be a subprime example. It's a two-edged sword. Actually, the risk of the controls and the immediacy of actions, the applications of rules that the BPM, SOA environment provide speak very well to managing risk more and more effectively. The other side of the coin, in the days of encapsulated monolithic applications that were bounded, the risk was more easily defined, and more easily controlled than if you have loosely coupled applications.

And you have to be concerned about who's getting a hold of what, where, how, and when as far as confidential information, or customer data and stuff like that. So on one side, it offers some tremendous advantages and opportunities. The other side it offers some challenges and some thought that need to go into how to govern this stuff.

KS: Yeah, Hub makes some very good points about Complex Event Processing and being able to monitor things in real-time and be alerted about things. But he also made another comment, which was how then do you respond to it? And what we've seen with a number of our customers, is that once they get the BPM system in place, they have in place all of the people using it, and they're connected in that way, it becomes very easy to deploy new services, and new products in the financial field.

But one customer who saw an opportunity, they had all of the right people on board, they had them all connected, what they needed to do was to change the way they were connected, they needed to change the way the information was passing back and forth. They were able to design up a process in an afternoon and literally be in a new line of business the next morning. And this is the velocity of change that we're seeing; it's filling in the role of helping to train people about what's expected of them, what they have to do. It's passing the information back and forth and really allowing companies to respond much more quickly than they have in the past to these kinds of regulations and risks that they see.

KS: Okay. And certainly, that sounds like from the technology point of view, we get greater ability to change and move forward quickly. However, that then comes back to the earlier point that it really moves into developing new cultural of collaboration. And to use Hub's phrase of a while back developing a common lexicon. And one of the questions from an attendee was, when you refer to the common lexicon, were you talking about purely to the common architectural level or was that a broad as I was painting in terms of allowing the different parts of the organization to participate in decision process and to move quickly?

HV: Well, I think what I was trying to say was that you can certainly gain a lot benefit if you can get the membership of the federation, however that federation comes about whether its cross company, or cross divisional, or even cross departmental.

If you can get them all to share a common technology for enablement and the kind of things we're talking about, the governance side, the enforcement, and visibility side, the actual process control side. You can share a technology, great. It all, obviously, will fall into place much more smoothly. But I think though, one the principle underlying ideas behind SOA is heterogeneity that we're going to allow heterogeneous systems to interoperate. And juxtapose against the previous ideal, people get hung up quite often on trying to get agreement on way more things than they need to get agreement on. So they try to get agreement on data models, and infrastructure platforms, and development methodologies, and tooling, and what kind of -- are you going to use Apache, or are you going to use BEA. And people get hung up on all of these things that are really in the way of getting an effective SOA and federated environment to work.

Again, the three things that you really have to get right is an event-oriented transport, a really strong expression of policy that you can both cleanly express and enforce, and ultimately the ability to get semantic alignment among those parties. So when I, and the he lexicon, as Ron used it, I think, perhaps extended to a more social vocabulary so that business leaders all say the same thing.

And the technical corollary to that is having a strong semantic. And if you can share that semantic in a canonical model, then the federated members simply need to agree on the model. How they implement that is their choice from a tooling standpoint, but the model and the canonical whether that's derives from FpML or FIX or some other derivation, those models help immensely in allowing you to achieve the collaboration and the lexicon is may be one way of representing that.

RA: I think at the base level what we're hoping to start with is a common vocabulary so that we can use a word and it means the same thing to everybody at the table and we don't run off in different directions unbeknownst to each other. A lot of effort going into doing lunch and learns and interactive training to make more and more people familiar with the concepts that we're dealing with and with the vocabulary that we're using so that they can communicate more effectively with each across groups.

HV: And that certainly leads to the formulation of an effective technical semantic as well.

RA: Yeah, I think that we're making a lot of effort to define some across organizational class structures, class hierarchies that are important for us to be able to reuse some of the processes that we're building in our BPM environments and to use some common technology definitions there also.

HV: But again, to that point, Ron, where it's easy and see many customers run into problems where they try to think about common models and it starts to smack very much of the mid-80s projects that tried to create enterprise data models and, of which collapsed under their own weight.

The idea here is not to get, for example, every single person in the company to agree on the definition of customer, or to agree on the definition of a security, for example. But if I can figure out what the data and flight requirements are, and stated another way, with the intersecting requirements are of each stakeholder's view of customer security that becomes the central canonical information.

It's generally a small fraction of the entirety of the enterprise data model. But by mapping through a canonical, you can get very rapid agility from that and a uniform governing the environment as well.

RA: Yeah, I can agree with that emphatically. I mean I didn't mean anything other than that at that level. I'm not looking for universal data model.

HV: Ron, I didn't suggest that you meant that as trying to sort of tease apart the differences between what does semantics in the technical sense mean versus the semantics in the social sense.

KS: Okay. To some questions coming in, first one, is how should we go for risk assessment and modeling for SOA in the financial services industry? So how do we adjust the way we assess risk and model in a world where we're now using SOA? Anybody like to take that question?

HV: I'll take a stab at it and maybe try to frame it a little bit because, I think, Ron alluded to type of risk that is certainly very valid. It's sort of the I need to have good identity and authentication, authorization of access to data, probably want to include privacy in that, so encrypting sensitive data when its accessed, and making sure that the authorization is scoped to NDA considerations or privacy considerations.

Probably enough strong audit around that as well so that I can keep and a non-reputable trail of who accessed what data and I think that realm of risk management I would put all under the heading of security, loosely. And I think that that's an essential kind of first-order problem that you have to deal with.

But what we're seeing is a much more sophisticated form of risk, which I'm sure, is going on at JPMC as it is in many of our customers where at the outset is trying to get a much more real-time picture of value at risk. So what is out there? How exposed am I on any given security, any asset in any particular region world or market. And then, once I understand the value at risk, to try to apply more sophisticated quantitative analytics to do risk adjustment, and risk assessment so all risks are not created equal in other words.

And understanding that in an overexposure in oil may not be nearly as damaging as an overexposure in euros at a given point and time. And understanding how to do that quantitatively at the velocities and volumes we're talking about, I think, is perhaps the most sophisticated form of risk management being done today in our customer base. But it's more likely to become mainstream, in large part because of the credit debacle we're seeing now.

RA: The technology is definitely is helping in being able to manage all of the factors to evaluate those types of risks. The challenge is for somebody to sit down and figure out what risks they want to track and what the meaningful values are to determine if something out of profiles, something that needs attention so that they can in effect tell the system what they want to watch.

HV: What a perfect expression of where business and technology come together because for Progress' part in that discussion, we offer a CEP engine that we think is world class, the Apama Complex Event Processing engine and it's used exactly in those ways. But truthfully, as applicable as that technology is, we are entirely reliant and beholding on the chief investment officer and Quants that exist within any investment firms. To tell us; "now that I can look at all these events, how do you want me actually look at them?" And what a perfect meeting of the business with the technologist actually enable that kind of sophisticated risk assessment.

KS: Okay. Keith, I'm sure if you'd to extend that discussion to include BPM in terms of the implications around risk assessment, and modeling in a BPM-driven environment.

KS: Well, it certainly is just as applicable there in all the same ways. I know that when it comes to modeling, one of the difficulty things is an area, which we call process discovery. And it seems like an organization that is functioning, and successful, and working well should certainly know its processes. But in fact, those processes are by and large not known and so you have to go through when you implement this initiative.

We've talked a little bit about cultural change. One of the things you have to do is when getting onboard with a BPM technology is to discover your processes. And if you go out and -- I've talked to an analyst this week who is working with a financial company who has selected BPM technology but they're actually blocked at this point and time because they haven't yet gotten permission to go and interview everybody and find out what the process is.

It turns out these interviews can be quite disruptive and financial companies can be very busy at certain times, such as year-end closings and at tax time. And so, they're actually waiting to get to the point where they can actually go discover the process. And so one of the interesting new technologies that we've come up with is something that can go out and read the log file and history files from your existing enterprise application.

And from that, it will more or less automatically show you your processes; give you insight even though you don't have any sensors to deploy yet in your organization. If we can go look at the existing logs and pull your processes out, it allows you to get around that barrier and get up to speed much more quickly. It sort of kick-starts the BPM process and gets you on the road towards an automated new business process.

KS: Okay. This is a related question come in. I'll just read out from one of the attendees says doesn't want talk to politics but the current economic crisis is built up by stupidity over a long period of time, would real-time monitoring have made any difference? Wasn't the problem one of lack of common sense? Is the problem more about keeping focus and what's really important and seeing the wood for the trees? And then, finally, what are the issues for SOA here? I guess, how do you filter the information really to identify what is important is the essence switch. I guess we've probably covered already. Would anyone like to add anything?

HV: I would certainly with whoever logged the question that there is a bit of politics and avoidance of common sense. I was astonished to find out that mortgage underwriting at least in this region of the country had gone to 66% of gross income that they were actually allowing people to cover their mortgages with 66% of their gross income. And you figure, after taxes that leaves them like 8% to pay for the rest of their lives.

So of course, there was a maniacal common sense problem there. But I would've thought and hoped that greater visibility on the situation might've caused more people to question the sensibility of the way the market was heading. You hear horror stories about people who had no real sense of the risk-adjusted value of some of the investments they were making, you know, pension funds, investing in mortgage-backed securities where the underlying paper was worst than junk. And there was no real measure of risk-adjusted value and I think that's where the sophistication is going up another level.

RA: And a lot of the stuff was built on flogged models; that was the issue. As long as the pyramid kept growing, everything was fine. When the pyramid didn't continue to grown, everything collapsed. And the tools, the technology certainly could help to identify and pinpoint those points of failure more effectively but only if somebody had asked it to do that.

That's the conundrum is to have enough foresight to use the technology to monitor the things that will effectively demonstrate where the risk is in time to do something about, but you will have had to thought about where that risk is going to be coming from to have the tools be able to help so. It comes more from the business side first I think.

KS: Yeah, that's precisely right. Better reports may make it harder to ignore these things but there's not going to be any replacement for good management. You have to be -- you still have to go look at the reports and respond to them.

RA: Yeah, somebody says I've got 66% exposure over here and the business says, well, that's okay because competitive edge we have to be there or whatever the rationale is that has nothing to do with the technology that's watching.

HV: Yeah, no doubt. Technology can't make up for a foolish decision but on the part of a human, but what it can do is raise the visibility. And at the end of the day, I can't trust what I can't see. Or stated another way, if I can't see it, do I even know I can trust it. And by raising the visibility, I would hope that sensible people would make sensible decisions, but they have to see it to be able to make that observation.

RA: All the data is always there. Somebody has to ask the system that I need to be able to see it this way in order to be able to see it. You certainly then can have the system trigger all kinds of event controls if it sees something that it does like, but somebody has to tell the system what its doesn't-like values are.

HV: Exactly.

KS: Okay. We got a lot of questions coming in, so I'll just move on to the next one. This is question says, how should we go for Quant engineering framework? How should be go about putting a Quant engineering framework for a SOA based applications in the financial industry? Can we use the old requirement engineering frameworks to deal with SOA in the new era?

RA: It's not been effective from my point of view. If the old requirements approach is to go through and end-to-end monolithic requirements process where you have all the requirements defined before hand, signed off, sealed and delivered, thrown over to the IT folks and then 27,000 changes to come through in the process, and then at the end, it isn't what anybody expected anyway.

We're finding it much more effective to model the requirements as we're building the applications using an agile approach, but we're actually modeling the stuff into our BPM tool graphically and visibly with the IT and the business folks working side-by-side in small three-week iterations so that we are actually driving the requirements and building out of the same time. If that's the question, that's easily a much more effect approach for us.

HV: Yeah, I would complete agree. Across the 400-odd SOA projects that we've done, the vast majority of them have shifted to what you might characterize as a RAD, agile or extreme approach, but more and more what I'm advising is that people begin to look at their environment more as a continuous experience.

So basically, the old-fashioned way was we did requirements, we did design develop, we did test, test, test, and then we burned it all onto a disk, and that's what we dealt out to everybody for months to work off of when we operated and managed off of that reference implementation that we burned on a disk. But in a multiparty SOA interaction, even if you test right up to the moment of deployment, the likelihood or the possibility at least that the very next day, one of the federated participants in the SOA changed something is very likely.

So the fact that it changed the next day means that whatever reference implementation you put out at test time is only valid for that test. It's not valid even a minute later because you're going to have to constantly test. And so, what I say to people is that the whole development testing and runtime management cycles that we used to see as separate ends of a spectrum have all collapsed in on one another. And the idea of continuous change, and continuous testing, or if you state it another way, management at development time become absolutely essential ingredients and its swirling together and changing the paradigms all over the place.

To see front-office operations where you actually have people that are forced to test in the production environment because there's no other valid test bed that you can build, it's so vast and complicated and so you have to come up with almost like co-tenancy and co-versioning models to do that. You have to have a way of thinking of it all as a continuous experience where even agile might start to look too slow at some point and time.

RA: Business process irrespective of technology or automation, the ability to go in and just model your business processes using some kind of a tool that is a dynamic and that you can maintain is an advantage in and of itself. In our case, we tend to use tools that are coupled tightly with our BPM environments so that we can have an ongoing model for doing simulations and doing what ifs and for doing continuous improvement.

But even if processes never get automated or never get moved into a technology direction, understanding the business processes is very helpful, especially, where we find we're using the same business processes over and over again in different parts of the business, and they can be centralized whether they're automated or not.

KS: In a related question, which I think probably addressed to you Ron is, are you using your BPM-related tools to generate SOA compliant software automatically?

RA: Yes.

KS: Yeah, there's two aspects of that certainly pretty interesting. One is BPM should be able to call SOA services and I think most the vendors claim to do and they do that. But the other side of it is the processes themselves become services. So we're starting to see processes, which are represented as process fragments where different parts of the organization are implementing different parts of the process.

And this comes back to what Hub and Ron said about aligning the semantics across the organization and federating this. We're starting to see federated processes in this same way. So these processes themselves start looking like services. That'll be the trend, I think, for the future in the next to two to five years.

RB: And that's an excellent point to start the wrap-up because we're running out of time. Now, I'd like to thank the participants on the roundtable, Hub, Keith, and Ron, and also the attendees who both listen to this and also posted some interesting questions. Clearly, we started with a very broad agenda and I think we've had quite a far-reaching discussion across a whole range of issues related to SOA, BPM and beyond.

What I'd like now to finish with is to publish a URL to the attendees and encourage them to after this roundtable to go and look for more information on the services and products offered by our two sponsors today, Progress Software and Fujitsu. That should just be appearing now. And then, finally, I'd like to thank again my panel, and also the attendees for attending today.

HV: Thanks for having us Ronan.

KS:Thank you very much.