Web application integration: the next frontier?
Fri, Mar 30 2007
By Jonathan Oxer
I've written quite a lot in the past about how web applications are starting to take over from traditional software that runs directly on your computer. The benefits have been discussed many times such as being able to access your software from any computer with a web browser, and never having to install updates or security patches. Paying a small monthly fee to a Software-as-a-Service (SaaS) provider is often a much smarter way to go than paying a large fee up-front to purchase software that you have to install and manage.
The downside though is that the current state of the art in web applications is disjointed, single-purpose programs that do one specific thing very well. The classic SaaS poster-child is Salesforce.com, which is a web-based tool for sales people to track prospects and manage relationships with customers. There are web apps and SaaS providers for managing your photo collection, your to-do lists, your project scheduling, and your documents, and now thanks to a couple of buddies from New Zealand you can even manage your business accounts (Xero) and business plans (PlanHQ) directly in your web browser. For many computer users we're already at the point where there is almost no need to install software on their computer at all. Everything they need to do on a daily basis can be run directly in a browser.
But it's not all cookies and cream. Yesterday morning a potential reseller came along to Internet Vision Technologies to get a rundown on what our system can do for his clients, and he outlined a typical business scenario that demonstrated there's still some way to go yet before we all reach software nirvana.
In this scenario he discussed the tale of woe of a client who wanted to:
* manage their website content
* manage their contact database
* generate personalised emails
* manage and publish internal operational procedure documents
* sell products online and track orders.
It's a very typical set of basic business operations, but the pain is in the lack of integration between the various tools used to solve the different parts of the problem.
For website content management they use the Typo3 CMS. For personalised bulk email they use Vision 6. For online sales they use OSCommerce patched into the Typo3 website. Their contact database ends up being a mish-mash of the users list in their CMS and the recipient lists in Vision 6. And they don't have any solution at all for managing versioning and publication of internal documents.
Imagine adding a few more business tools to the mix: perhaps a timesheet system for internal staff; a jobs listing published by the HR department; a project management system for timelining and tracking deliverables; a private wiki; a job-ticketing system for tracking customer requests; a quote management system; a warehouse management / inventory / shipping system; and a repository for storing marketing collateral. Sure, there are web-based systems out there to solve all these problems individually, but think about the mess you'd have when trying to work with so many different systems all the time!
Typical domestic computer users don't really care very much about integration. The software they run on their own computer generally works on the assumption that they will be the only user, and any integration is generally done using the operating system as the glue. For example, you can edit an image in Photoshop and save it on your hard drive, then in your word processor you can paste it into a document. The two programs don't need to talk to each other directly because they only need to care about where the operating system has stored the file.
Web-based systems have a totally different architecture and can't rely on being inside the same "sandbox" as other programs that they may need to share data with. Even though they are inherently more networkable than a typical desktop app the reality is that they often exist in separate silos with close to zero interoperability.
It doesn't have to be that way though. One of the fundamental design decisions behind SiteBuilder was that it wouldn't just be a content management system, even though that's what it was initially used for: it was designed as an extensible framework with integrated modules (129 at last count!) covering a wide range of business functionality. Working within that highly integrated environment every day I tend to lose sight of the pain that most people go through when trying to put together a comprehensive suite of tools to manage their business processes, and the meeting yesterday really brought it all back to me.
So the SiteBuilder approach of building an internally-integrated, whole-of-business software suite is one approach that has worked extremely well for us, but it's not the only way to do it. After all, web-based applications already have the benefit of being online and having a ready-made communications infrastructure to link them together. So why not just get them talking to each other? After all, that's what mash-ups are all about.
Unfortunately it's not quite that simple, at least not yet. Most web applications are designed to be stand-alone, to manage their own internal user lists, and to provide access only through a human-readable web interface rather than expose their underlying data to other systems. They each have their own menu systems, templating methods, and idiosyncrasies. Creating a unified and consistent user interface that integrates a bunch of different SaaS offerings within a comprehensive menu system while only asking you for a single username and password and sharing the data between each application is a Herculean task.
Many of the tools needed to do it already exist. The single-username-everywhere problem can be solved if all web applications follow the OpenID standard. XML and sitemap tools can create unified menus that encompass multiple web applications. And initiatives such as Zaltana, created by my friend Scott Penrose, aim to solve the problem of each system looking totally different.
But these tools are really still at embryonic stages, and for most people the problem is insurmountable unless they opt for a system that is designed from the ground-up to provide an integrated environment.
The moral of the story is to think carefully about your different business systems and whether they are as integrated as they could be. Is your website content management system totally separate from your back-office inventory system? Then it'll be hard to display stock levels on your website in real time. Do your customer satisfaction surveys, your emarketing system, your newsletter signups, your website, and your quotes database all have their own internal lists of contacts? Then you have a recipe for disaster, or at best you'll miss out on the benefit of having all those programs function as a cohesive system.
A bit of homework and some effort tying your systems together can pay off big-time in improved efficiency, productivity, and ease of use, so keep your eye on the big picture to get the most bang for your software buck.