News Stay informed about the latest enterprise technology news and product updates.

Wizards using wizards: SOA and BPM for humans

Speaking via cell phone from a coffee house in London, Greg Carter, CTO of U.S.-based Metastorm Inc., a BPM company moving into SOA, talks about his company's human-to-human approach to those technologies using the NBA's Washington Wizards as an example.

First of all, what is Metastorm?
Metastorm is provider of business process management software. We have been selling our products since 1996. I'm in London right now where our development and international headquarters is. About 50 percent of our business is in the US, the other 50 percent is throughout the rest of the world, primarily in Europe, the UK, Africa. We have been working around a pure play, human-to-human BPM product direction for many years and we have about 1,200 customers in over 41 countries. In terms of the human-to-human part of this, can you describe that in a real world way, what kind of processes are we talking about?
Overall, the processes tend to be unique. If you think about a typical business process, let's say posting a ledger entry. Pretty much anyone who has any type of accounting system has that type of process and it may built into SAP or Peoplesoft. That's not the kind of process that people would deploy our technology for. Where they would deploy our technology would be the Washington Wizards, the basketball team. What are the Washington Wizards doing with your software?
They had a unique requirement to allow their scouts to identify potential players, whose names come from a lot of sources. They built a system that was tailored to their own recruitment process and they have their unique way of starting to track players at a very young age. There are different gateways. There are different types of reviews, there's going to games, looking at how they are performing scholastically and there are interviews and things like that. That very unique process to the Washington Wizards was implemented using Metastorm BPM and they use it today. They use it inside their home office. They actually go out to the field and do investigation. So, it's a human-based process that involves not only some automation and the traditional ideas of workflow, but because of our very integrated, role-based forms technology, we can actually allow people to capture metrics about the different potential players, but also to be able to input anecdotal evidence and really weave that kind of notebook concept where I would go and take notes about the player into the very integrated managed process in the home office. The scouts out in the field, how do they access the main system, where this information about the players is being stored?
We actually have Web, as well as connected and disconnected clients for things like Microsoft Office. So, much like you might use a groupware product like Outlook today, in a disconnected way, our integration with our Outlook client allows you to work in the same fashion. So, these scouts get their information from the central system, so work is assigned to them to do different investigations. They can then go offline, be at a game somewhere and actually take notes and look up some reference material. Then they can reconnect when they get back to the home office. So, that's the kind of custom system you are able to create with your software?
That's correct and the differentiation would be that you are doing much more configuration, you're using a process model and you're using very high-level tools to describe the process. That, in turn results in a process-based application as opposed to assembling different coding objects and using a development tool to do this. You're developing the process application using a process metaphor. So, it's very easy for people to make very sophisticated and precise workflow and process application without having to result into going into code.

And that really is our position on a lot of SOA activity. We think that more and more organizations are building composite applications by looking at services and assembling them either into composite services or using them directly in application, whether or not they have a SOA technology in place. They're just kind of willy-nilly picking services. But we think what BPM brings to the table is the ability to look from a business value perspective at the processes that a business needs to achieve its goals and part of our methodology is understanding the information and the business functions that are required to reach that goal as part of the process. Once you know the goal, you know the steps in the process and the functions and data required to achieve that goal, you then have identified either the discrete processes or the composite processes that are going to deliver the most value. So, we really think that our methodology and our technology help organizations hone in on where to start using SOA and service enablement. When somebody starts to implement your software products, do they need programmers to set this up? Is this something that an intelligent end-user can implement?
I would say it is not something that an end-user would implement, but someone who is familiar with Visio and has used that type of diagramming tool to draw a flow chart, would have more than enough skill to describe a process. All of it would be accomplished using wizards so there is no need to go into a programming tool or to use scripting. We do have integration with Visual Studio and scripting environments for more advanced applications. But I would say in the case of that Washington Wizards application, that was all done without any development.

For more information

Why you should model your SOA

Special Report: BPM inside the belly of the SOA whale

So they were set up by a business analyst or a process developer?
It was a set up by a business analyst and a process developer who was much more on the process side than the development side. So the basketball Wizards use the Metastorm wizards to take them through linking everything together and setting up all the screens?
That's correct and just to relate that back to services and how we've built our technologies around making services relevant to that higher level user, if you had published a series of Web services around, let's say setting up a new player in the back end rostering system or the team management system. If you'd published different services to add a player, you can actually import those services from a WSDL or another repository and we would automatically generate a very high-level wizard that instead of showing you the low-level parameters, it would actually look like it was built into our product and it would appear in a list of available functions when you went to use the integration wizard and it would guide your through using that service. The business analyst, they would have no idea if it was a Web service, if it was a Java Bean, if it was a .NET assembly. They could care less. All they know is inside their application, they now have that high-level player management functionality. Once I've imported that functionality, I can then deploy it to the repository so it can be shared among any number of applications.

Dig Deeper on Service-oriented architecture (SOA)

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide.com

SearchWinDevelopment

DevOpsAgenda

Close