–

Breaking the mindset of enterprise software

MM: In our interviews with other innovation leaders in this general area, they’ve shared with us that this new provisioning model — software as a service (SaaS) — or process as a service (PaaS) — really leads to several very interesting developments.

One is that it breaks the mental mindset of enterprise software. That is to say if we were buying an ERP system that’s got 50,000 function points, you can compare function points from SAP — from Peoplesoft, from Oracle — compare and contrast the inherent capability. “What do we need?” Then make a technical decision of which platform best serves a particular need.

With this multi-tenant architecture and SaaS or PaaS, oftentimes you’re using one-tenth of 1 per cent of the overall capability of a platform. This has a net effect of confusing or overwhelming buyers such that they need an equally complex methodology for determining their needs — as opposed to reverse engineering them from a standard set of function points. Would you concur with that, first of all?

IG: Yes. Very much so.

I think we as an industry — as an entity — make things a lot more complex than they should be, to confuse customers with either features they don’t need or requirements that are just too significant to be fully implemented. I think that at the end of the day, this SaaS model — the main objective or main requirement is for it to lower the barrier to adoption — to make the technology as consumable by users as possible.

I also believe that what we’re talking about — BPM SOA is new. It’s based upon architecture elements that are new to customers. This requires, we believe, a little bit of training and education. Also, as much practice as possible.

Over the past eight years in the first wave of BPM software, we’ve seen that many of the implementations were conducted by the professional services group of the software vendor. So you’d have the vendor going to the customer, asking what problems they had at the business level. The customer would open up and describe the problem. Then the vendor would deploy an army of fairly expensive consultants to fix the problem, using the BPM technology of the vendor.

In some cases, it would fix the problem. Unfortunately, in many cases, it wouldn’t. But that really was beside the point. Even when it would fix the problem, what would happen is that the customer would not learn anything about the way that solution was implemented. So, yes — the problem was fixed. But it was unclear whether it was fixed in a better way than could have been done with more traditional development tools.

Because the customer was not really involved in the implementation of that solution, there was no way to scale it up. There was no way to leverage this investment at a knowledge level, in order to solve the next problem that would arise at the business level.

We think that this technology — this BPM technology — to truly make an impact on the market — must be used by customers themselves. There must be a self-empowerment of the customer. They must adopt this technology themselves. Either doing it with their internal IT department or with system integration partners. But very importantly, they must not use the resources — the professional services resources — of the vendors. Otherwise, this knowledge transfer won’t happen, and essentially you won’t have any repeat sales within that account. That’s something that we’ve seen again and again in the marketplace.

That’s what has been slowing down the adoption of these technologies by customers in general. That’s why we tend to flip the model over and to say, “Okay. First and foremost, Mr. Customer, you’ve got to come to training. You’ve got to learn the technology. We’re not going to teach you about how to use our product. We’re going to teach you about the standards that exist today for BPM. The standard way of modeling — of describing — business processes.”

There’s that great notation called the business process modeling notation or BPMN. For the first time, it’s a standard way for customers and organizations to describe their business processes. It’s usable by the business people as well as the IT people. Then there are lower-level standards — more technical standards to turn these models into applications and running systems — into systems of action.

I think standards here are playing a key role. Again, one of the reasons why adoption was actually slower than anticipated is that those standards could take quite a bit of time to mature. But now they’re there. They’re available. They’re supported by several vendors — especially the larger ones. We think for that reason, and also because SOA is now becoming the way of architecting new systems for the enterprise. We think the time has come for the BPM industry to really take off in a big way.

–