Loraine Lawson spoke with Marc Smith, director of Technical Marketing for Lombardi Software, which recently partnered with Progress Software to incorporate Progress' Enterprise Service Bus (ESB) into Lombardi's Teamworks BPM platform.
Lawson: Please tell me a bit about your company to get us started.
Smith: Lombardi is a business process management Suite (BPMS) software vendor, based in Austin, Texas. We're known in BPM circles as a pure-play vendor. Lombardi was founded in 2000, and deployed its first production customers in 2002. We've expanded to Europe recently, opening offices in Paris and Frankfort. We are a private company with over 150 customers across the Global 2000 and several in the Fortune 100, such as Dell, Pfizer, Hasbro and Sprint. We continue to be ranked as a leader in BPM. We focus on enabling our customers to help them implement their business process strategy. We have clients like Pfizer that are doing it across the enterprise, as well as companies that are just getting started with smaller projects.
The value we bring to the table is that we bring a complete BPM suite that our customers use to not only automate processes, but also help manage their processes by providing lots of visibility into what's happening. That's one of the key tenets of our product: to move beyond basic process automation and enable process management. What we're trying to provide is not just the tooling, but the entire framework and the methodologies to help customers optimize the processes that they design and get visibility into how those processes are performed. We have the leading tools to help business analysts in this regard.
Lawson: There's an ongoing debate at IT Business Edge's Mergers and Acquisitions blog on the role of business process management with SOA. What's your take?
Smith: We are finding that, for customers that have already embarked on an SOA initiative, BPM can come to their rescue in some instances. They're in a position where someone has to start using those services that have been developed after spending a lot of time, effort and money. Business teams would love to make their business processes more efficient and effective using those shared services, and they see a BPM platform as a vehicle for that. So we are finding that when we're introduced to the SOA groups, they're happy to see us. We're an enabling technology because we're able to help them deliver the return on the investment that's already been made in developing shared services.
BPM can also help SOA in the sense of providing direction and prioritization in terms of what services to build first. Working hand in hand with service implementation efforts, customers are finding they have a new way of building applications more quickly than they ever have before by using a BPM platform.
Lawson: How so?
Smith: There's a fairly new term that's been coined: "composite application platform." While we're not in the business of providing more traditional composite applications, people are recognizing that BPM platforms like Lombardi can be used to access services, connect those services, and orchestrate the workflow between those services and the people that use them. An example: Hasbro, one of our flagship customers, is a big SAP shop. They decided to use Lombardi Teamworks to provide an easier way to implement their order fulfillment process - and most of their users are actually independent vendors in Hong Kong and China, so they're outside the firewall. Hasbro uses Teamworks to build process-oriented applications that have simple user interfaces allowing their vendors to basically do order fulfillment and interact indirectly with SAP-in fact, multiple SAP systems. You might contrast that use of a BPM platform to build an application to, say, Netweaver or other kinds of traditional application development platforms where a lot more coding would be involved to build the application.
Lawson: Without the coders?
Smith: Certainly with fewer coders. The coders' jobs have become very focused which they like. They get to define the services, implement the services, but they don't have to build every bit of the entire application. More importantly, they don't have to make tiny changes to the applications as the business requirements change. That's what really slows down development. They used to have such a big backlog for small changes that the business wanted and they just couldn't get to it. With a BPM platform, the developers still have to be involved, but they don't have to do all the small changes. I characterize it as a better division of labor between the business and IT folks.
Eclipse is the technology that's used in our process designer tools. Business analysts see a set of views that can be used to define the high-level flow of work between different process steps. Basically, analysts specify what steps are performed by which people or group or systems - the high-level workflow. But you can also drill into any of those elements in that process diagram and see another view that's got implementation and configuration details specified in it. With these views, developers can specify how each of those steps should be performed. Visual programming replaces the more traditional coding workbench.
Lawson: You recently announced that Lombardi's Teamworks would be integrated with Progress' Enterprise Service Bus (ESB). Why tie in with one ESB?
Smith: As a BPM suite, we provide the basic tools for integration to external systems because they're important to almost any process. So the connectivity to those systems is key. We've got some basic integration adapters that can let people directly connect to systems, but the conversation has changed from "can you connect to this particular system?" to "can you connect to particular services."
Some companies have already undertaken big SOA projects and we're already coming into a SOA-driven environment where there's a lot of existing plumbing and services. They start asking how they can leverage the work they've already done with their SOA initiatives. Or they might ask us how we might help them prioritize what SOA work they do.
In smaller companies, they can get by with point-to-point adapters, but in larger enterprises whose IT departments are starting to work more in earnest to build a service-oriented architecture, they either have ESBs or are considering how to use ESB to provide connectivity to the services that are key to their business processes. Our Teamworks product will work with any existing third-party ESB or middleware product to achieve connectivity to systems and services.
In those cases where a customer hasn't yet adopted an ESB product or they're just starting a SOA initiative, they sometimes say, "We'd love to start a BPM initiative but we have to wait because we don't have any underlying infrastructure, isn't that important?" Rather than wait, we've started working with compatible ESB partners to offer a seamless solution for those companies that want an ESB but haven't already selected one. Progress' Sonic ESB product has a very similar philosophy and architecture to Teamworks, with a nice seamless integration to our product compared with other more generic middleware.
The partnership with Progress is just an example of where we'd like the opportunity to provide a more complete solution to customers that haven't yet adopted any particular ESB technology.
This is a "best of breed stack" solution: That's how you might think about this joint offering. Teamworks can stand alone; it does have its own integration facilities. But if customers want a more complete stack, we can talk to them about using Progress Sonic if they're interested.
Lawson: David Linthicum criticizes the stack approach in SOA. How do you feel about that?
Smith: The A in SOA means architecture. The technology solution has to fit your requirements, and requirements differ from business to business, thus the "stack" will be different from business to business and perhaps not even leverage Web services (gasp!). The notion that we can create a set of "one size fits all" enabling technologies is just silly, and those that promote the single-stack approach should rethink the core concept of SOA, and how it's something you do, not something you buy, nor will there ever be a "standard stack."
Lawson: But aren't you selling a stack by partnering with Progress and other companies?
Smith: The stack solutions that most people are referring to are usually offered by those vendors that have the entire stack as part of their solutions, the IBMs and TIBCOs, Those stacks have come to life through acquisition and by evolution and, in the end, they're fairly complex, they're large, and they're often unwieldy. A medium-sized company might think twice before going to the whole enchilada there.
Teamworks and Sonic ESB are different. They're best of breed in their respective areas, plus they've adopted architectures that are more nimble and modern than some of the older architectures that have evolved from the more traditional vendors. We're not stack-vendors, per se. We're each best of breed vendors for particular pieces of what might be assembled as a stack in an enterprise. Both of our architectures are aimed at being very nimble and agile and avoiding the high cost of traditional code development. Our architectures are more configuration-oriented and our products are built out of components that can be easily reconfigured when changes occur in the environment. It's more of a configuration than a coding approach.
Progress and Lombardi are using Eclipse to host their design environments because it can provide that one-stop design shop for defining the entire business process implementation and its integrations. In Eclipse, you can view the high-level business process flow that the business analyst might define. With the click of a button, you can look at a lower-level Teamworks implementation view and with another click you can look at the ESB implementation view. Configuration-or reconfiguration - of integrations using the ESB becomes simpler, in the context of the business process. And you can see all the process definition details linked together in one environment, which is quite different than some of the other offerings out there, even from stack vendors, where you have different distinct tools that aren't very well integrated at all and require a lot of expertise and a lot of extra work by the teams that are trying to collaborate to use their individuals tools to create a common solution.