Speeding the Arrival of the Integrated Enterprise

Looking at the current state of line-of-business applications and how companies use them to track and manage their operations, one can’t help but notice how there’s a strong resemblance to the days before the networked enterprise, circa 1987. Back then, resources were dispersed in little silos we called PCs, each with its own island of resources.

When we connected all those islands with the help of server networking, we got huge returns. Suddenly we could share the same contract someone wrote using Microsoft Word instead of having to save it to a floppy and copying it manually. Life was great.

Why is it then that some 20 years later, most companies aren’t doing the same with their business systems? The problem is almost identical, except instead of individual PCs, it’s individual applications. The vast majority of organizations run one application for their sales force automation, another for accounting, perhaps another for e-commerce, and so on.

Help Is on the Way

Because none of these systems typically talk to each other, duplicate information has to be manually entered or imported over and over again, leading to human error and lack of business intelligence. After all, if it takes two weeks for AR (accounts receivable) to be manually updated from sales, the CEO isn’t going to have what he or she needs to make accurate business decisions. Add inventory to the mix, and you have a recipe for a truly disconnected company — sound familiar?

It’s not like we haven’t tried. The panacea, while elusive, has always been to integrate all the modules that we run our businesses on into a single consolidated system that shared data where needed, maybe even hummed as it did its work. Why then, aren’t we there? Actually there are several reasons, but help is finally on the way.

Initially, all line-of-business application software was based on-premise (within the local area network), as there was no Internet yet. When the idea that inter-application integration could bring big automation benefits, end customers began trying their hand at database level integration, which was the only way to get two systems to talk to each other. This proved incredibly expensive and complicated because not only was it technically difficult, it required that software vendors run on the same platform and provide adequate documentation and database access.

It was also extremely fragile because when a database table from one system changed with a point upgrade, it threw everything out of whack. These are just some of the problems end customers faced. The lesson learned was that while it’s true that database integration is the tightest way to integrate data, it’s definitely not a job for end customers.

Leave End Customers Out of It

Around the time of the dot-com bubble, a solution to the problem was announced — Web services. If the press of the day was to be believed, Web services would finally make inter-application integration a reality. Even legacy systems could be integrated with newer systems via XML brokers such as BizTalk from Microsoft. The concept is simple enough. Exchange data between systems as needed using XML documents over http, the lingua franca of the Internet.

This way it doesn’t matter what the database structure is — provided both systems could natively speak XML. Headlines are one thing, but as the saying goes, the devil’s in the details. Again, end customers were chartered with the job of integrating their applications using technology, and again it proved costly and impractical, bringing us to our current predicament.

By now, it would seem the lesson is clear. Application integration is a job for software companies — aka ISVs (independent software vendors) — not end customers. The good news is that the ISVs are finally doing something about it, leading to two completely different approaches to the problem, each with its own set of pros and cons.

Solution 1: Core Module Integration

• The Approach. A software service provider acts as a central hub and other application service providers integrate their core modules (i.e. accounting, inventory, etc.) into the that hub, each consuming its own utilities as needed via Web services. If you sign up enough providers, voila, you have a complete solution from soup to nuts.
• The Pros. You don’t have to deal with core module integration, which is now completely in the hands of the software vendors, where it should be. Also, you can theoretically turn on just the service providers you need, in a pay-as-you-go fashion.
• The Cons. First, this approach really only makes sense for the Software as a Service (SaaS) model. If you want the option of eventually bringing it in-house, you’re out of luck. Also, because you have several software companies providing their version of a module, user interface design and workflow aren’t going to be the same across applications, making it potentially more difficult to train users.

  Another issue is that because major modules are provided from each vendor, there are multiple throats to choke and multiple vendors to pay, each with its own set of business policies. Another potential pitfall is the level of integration itself, which may not be as complete due to inherent design differences between applications. Finally, there’s the question of reliability and data integrity. Because each vendor is running its application on its own data center, you have to multiply the possibility of an outage by as many vendors as are contributing to your overall solution (based on the service level agreement of each vendor), and the impact on the dependency other services have on a downed provider (for example: Did the downed service provider’s invoice application actually update accounts receivable before the outage or not?).
• The Players. Right now, there’s really only one: Salesforce.com with its launch of a service called AppExchange. The per-user, per-month base price is approximately US$65 to $125 for CRM (sales, service and marketing), then additional per-vendor pricing for other modules you use, such as accounting, etc.

Solution 2: All-in-One Super Suite

• The Approach. A single vendor provides all the core modules within a single all-in-one business suite, which consumes utilities via Web services as needed. Some call this ERP, some ERP (enterprise resource planning) and CRM, others call it all-in-one business management software.
• The Pros. You don’t have to deal with core module integration, which is now completely in the hands of the software vendor, where it should be. Because all core modules come from a single vendor, they have a uniform design and workflow, improving the learning curve. Tighter integration should translate into better communication between modules, which in theory should result in better business intelligence (BI).

  One vendor means one throat to choke, one bill to pay, and a single point of failure in the event of an outage if the system is consumed as a subscription service. Also, there’s no chance that data from one core module is affected by an outage of another because they’re all in the same location. Because there’s no need for stitching core modules as a service, vendors are able to provide on-premise deployment when it’s time to get onto — or off of — the monthly service treadmill. Finally, price is going to generally be cheaper compared to the equivalent from a collection of providers.

• The Cons. While price is cheaper when compared to the equivalent from a collection of providers, if all you need is a single module, the reverse can also be true (but if you think you need one module, you’re missing the big picture). Core module configuration options are also potentially more flexible in a dispersed model because you can mix and match different vendors as needed.

  Finally, there’s a bit of a paradox. Because it’s extremely difficult to write an all-in-one solution, it’s less likely a startup can pull it off. The reason most large software companies don’t do it is because it simply doesn’t make financial sense. Big business software is all about getting you hooked on that first module (e.g. a contact manager), then as a captive customer they can spoon-feed you add-on modules at virtually any price they like. Put another way, big software isn’t going to cannibalize their existing business model.

• The Players. At the high end of the spectrum, serving mostly Fortune 1,000 businesses, there’s SAP, headquartered in Waldorf, Germany. They practically invented the concept of ERP, and have since integrated CRM into the mix to create an uber-suite. At the mid-market level there are companies like NetSuite and Aplicor. Both companies have for years offered a hosted-only version of their suite at around $100 per user per month, with thousands of happy customers.

  At the smaller business end of the spectrum, one company — BizAutomation.com — has announced its upcoming all-in-one suite, which it will offer for on-premise deployment or as a service (SaaS). Its subscription price is said to be in the $49 per user per month range, with availability this summer. By offering both on-premise and on-demand versions, the company claims its customers will be able to keep their options open, opting for on-demand then transitioning to on-premise when it makes sense, or vice versa.

As elusive as the concept of the integrated enterprise has been, it’s great to report that businesses of all sizes finally have options that can make it a reality. The only hurdle now is educating businesses to the productivity benefits that come with it. Hopefully, that doesn’t take another 20 years to happen.