The Zero Footprint Advantage

The decision making process for selecting an ERP system is often reliant on the needs of Accounting and Operations people whose primary concern is functionality.   Yet I.T. Administrators bear the burden of deploying the application and anything that goes wrong seems to fall on their shoulders.  Ask any I.T. person what they want in a business system and the answer is “Something that is easy as possible to maintain.”  For this reason I.T. Managers often assume that what would be easiest is a browser-based solution because they don't have to install anything on their users' client machines.  Think again.  xTuple's zero footprint solution is easier than that.

The first time users evaluate xTuple ERP they use our installer utility to install both the xTuple client and the PostgreSQL database on their local machine.  This makes it easy and fast to get going.  What most folks don't realize is that under the hood the xTuple client has zero dependencies on any 3rd party runtimes or frameworks such as Java, .NET, Python, etc.  What this means is that if you install the client software on a server in a shared folder anybody on the network can use the application simply by navigating to and clicking on it.  That's right: Zero installation is required for clients.  For convenience, users can drag a shortcut to their desktop to get to xTuple in one click.  When it's time to upgrade the client, just update xTuple on the server, run the database upgrade utility and Voila! You're done.  Everybody is upgraded.

The diagram above shows how simple an xTuple enterprise installation is.  You may shrug your shoulders at this and say, “So?  How hard is that to keep it simple?  Isn't that easier?”  It is easier for you to administer and for us to develop against. But, in general, keeping architecture simple is not easy.  Developers like to solve complex problems, and they like to bring lots of different tools to bear doing so.  It takes extreme discipline to say “No” when someone wants to add another development library or technology into the mix.  It also takes discipline to write a sophisticated program like an ERP system in a low level language like C++.  Many, many ERP systems are built on RAD (Rapid Application Development) tools that make development easier for programmers, but life hard for administrators.  This trade off is because these tools require a client side runtime that actually compiles the application on the fly.  Examples of environments that work this way are .NET, Java, Gupta, FoxPro and Access (yes, people do write and sell ERP systems written in Access!).

Compare the xTuple installation above to a typical client/server solution based on .NET below:

Note in the Microsoft enviornment above the ERP client is usually installed on the client PC.  This doesn't have to be the case, you could put it on the file server. Then, however, you'd have to set up a litany of exotic active directory group security policies on your domain to allow for that, because Microsoft won't let you run a .NET executable that way by default.  Otherwise, with the client software on client machines, every time you do an update you have to change the software on all client computers   Again, this can be handled by Active Directory (I've actually done this), but it adds a lot of complexity and invariably a lot of problems to your administration.  Furthermore many I.T. Managers are self-trained and don't know how to do this sort of thing.  No matter where you put the ERP client all the client P.C. machines must have the correct version of the .NET framework.  You can let the machines self upgrade, but a lot of shops turn automatic updates off because it causes too many problems.  Again, you can push the .NET framework through Active Directory group policies, but that also adds a lot more complexity to your administration.  Or you can just go around and upgrade both the client and .NET framework machine by machine by hand.  That's what most people end up doing.  Java is the same, just exchange the .NET framework for the Java framework in the diagram above.

These are the sorts of problems that have given client/server solutions a bad name, and are why I.T. Managers are so attracted to browser-based solutions.  Here's a diagram of a typical example below:

Let's start by looking at the server.  It has a lot more dependencies (i.e., moving parts that can break).  The web server, application server and java framework all have to be set up together and be compatible.  Of course most good systems have an installer program that takes care of this, but the fact is all these servers and components require knowledge and time to operate and maintain.  The more moving parts there are, the more points of failure there are.  This diagram doesn't even do true justice to the library requirements to make it work.  The box labeled “AJAX” is usually a conglomeration of at least a half dozen or more library frameworks that have been brought to bear to make the technology function.  They are typically developed by different organizations that don't necessarily work together, and invariably when one of these parts is upgraded, it can break something else affected by it.

The client side story is similar.  A pure browser-based solution would require nothing but a common browser, and any browser would work.  But in practice compatibility problems with browsers are chronic.  What works on Explorer doesn't work on Firefox or vice versa.  Or what worked on Firefox last week, doesn't work on it now that Firefox just upgraded itself on 50+ machines.  Now the administrator has to lock down the browser so everyone has the same one at the same version.  Guess what?  You're back to managing clients on local machines again.  But what's worse is this client is used for a lot of other things, so by locking it down for the ERP you've just ensured a lot of other programs users want to use probably won't work.

This is all compounded by the fundamental problem that browser technology was designed for multi-media, not online transaction processing for ERP systems.  Because implementing ERP in a browser in its purest form is clunky, many solutions improve the interface by making the browser install local plug ins, such as Java applets or Active X controls.  Now you are back to having to make sure all the clients have the correct runtimes to support the plug ins.  Again this is theoreticaly handled by automatic updates, but by opening the door to that, you are introducing security issues.  No, what really happens is administrators end up having to strictly control browser versions and plug-in deployment.  By doing so you are also likely to be locking your users into a specific browser technology and perhaps even a specific browser version, which is again back to managing client software on a machine-by-machine basis either through a complex active directory solution, or manual deployment.

Finally, there are the SAAS (Software As A Service) browser solutions.  Doesn't that eliminate the server maintenance complexities?  Probably, but not the client side dependencies.  Plus, for pretty much all CEO and CFO folks I have worked with the notion of letting someone else control and store your mission critical financial data is a non-starter.  “Cloud” pundits dismiss this as out-dated thinking as they believe new technology is making this a more viable option that is the inevitable future of all software.  The problem is ownership. Control is not a technological issue--it is a pshychological one. Many people will always want to control their sensitive financial data for the same reason they would rather own their homes than rent.

So you see, any way you look at it the xTuple solution is the simplest and most elegant solution you could have to administer, and best of all it runs on any operating system you like!   Now if only it could make a good cup of coffee....