IWMS expert and Lucernex President, Joe Valeri (see Joe’s management summary here), discusses the differences between a single platform and multi-platform IWMS and why you should care.
Have you ever looked at an older house and noted how it’s had extensions added that don’t fit the original house? Whether it’s the pattern of the windows, the exterior surface or the shape of the extension that does not match you can tell it’s just not right and makes the whole structure look bad. Inside the house, the switch and outlet layout in the new rooms are different and the plumbing does not work as well as it did before. The air conditioning doesn’t get the house as cool and even the foundation of the house is cracking because the new and old sections are settling differently.
Now imagine the same process only with software. Start with one application from one company and add on parts from many other applications built on different platforms. Much like a house you have to match up the foundation perfectly and connect the wiring and plumbing perfectly, using a pattern and style identical to the past, or things just won’t work right.
With software it’s easier to disguise the exterior differences by adding a new user interface to all applications to make them look like one. However it’s infinitely harder to match up the structural elements of the applications and make them work like one especially if the platforms vary. The truth is no matter how good a development team is and how much time and money you spend on it, no two applications can ever be joined together in a way that allows them to operate as well as a single code, single platform application that was developed by one software firm. It would be like Rembrandt trying to finish a painting half completed by Picasso – no matter how great the artist, the result won’t be as good.
What are the problems you will see with disparate platforms?
Complex and expensive IT Architecture
The most obvious problem occurs in applications that are installed behind a client’s firewall – complex and expensive hardware configuration. If an application has one Java application, one .NET application, two databases plus third party workflow and reporting applications, you can end up with dozens of servers just to get a single instance of the system. The cost of purchasing and, worse, maintaining that hardware can be enormous. The client also needs to hire a much wider array of IT staff to support the numerous platforms and code types.
When a defect occurs in a single code base, single platform system, you have one set of logs to read to find the source of the error and one set of code to fix. If you have multiple code bases not only is it much harder to find the problem, curing the defect can be exceptionally hard as the developer has to diagnose code across a cobbled together interaction of two disjointed systems with different designer patterns.
Cross platform functionality
Let’s say you want to create a workflow that covers a wide section of the real estate lifecycle. In a cobbled together application you will have a workflow engine from a third party that won’t be able to work seamlessly with the Java part of your application, the .NET part of your application and the different databases. It can’t possibly be as easy and capable as a work flow engine that is built into the core of the application by the same software developers that created all of the functional code.
When a company purchases several other software companies to obtain parts of their application and then invests millions of dollars trying to make several applications look like one application, then adds on multiple third party applications for workflow, reporting and other features, the application has to be pretty pricey to pay off all the debts, past investment and third party vendors.
The complexity of the IT Infrastructure will make implementation of a multi-platform system longer and the disjointed operation of the cobbled together applications will make implementation take far longer than a single platform, single code base system.
Though there are dozens more examples I could provide let me leave you with one more – reporting. How do you report out of a disparate application with multiple databases? Answer – using expensive IT resources and an expensive third party reporting application. Good luck using ad-hoc reporting tools or leveraging your existing investment in enterprise reporting unless it matches the application the vendor requires you to use.
Most IWMS applications being offered by vendors today were created from the whole or parts of other applications merged together. They try to hide it with a common user interface but behind the pretty exterior there is a cracked foundation and mismatched plumbing.
Here are some ways to unearth the cobbled together multi-platform systems
1. Ask to see an architectural diagram of the hardware used. Even if you are buying a hosted SaaS or Cloud solution, ask to see the diagram and ask your internal IT department to interpret it. Make sure the vendor includes the applications that run on each server. If you see multiple database instances (other than for redundancy) or multiple types of application server, you know there’s a problem.
2. Ask how many databases are used by the system
3. Ask about ad-hoc reporting – is there a way for a non-technical end-user to report against the system?
4. Ask the vendor directly if they bought any of their code from any other company. With the exception of small third party code libraries (like a spell checker or user interface controls) the answer should be ‘no’.
5. Look at past press releases for the company and see what companies they have bought over time to assess how much of the application came from someone else.
While the multi-platform problem has a bigger negative impact on in-house implementation, its almost as big a problem for hosted solutions. Hosted providers can hide their platform disparities from client IT departments however the functional problems multiple disparate platforms present are just as substantial in a hosted solution.
Lucernex has employed the same group of developers since 2000 with the same chief architect and same product designer. Other than the addition of Ken Brown (of SLIM fame) in 2009, we have had the most consistent group of developers of any IWMS vendor. As a result we have ONE code base, ONE Platform, ONE Database and ONE design pattern. This allows for a simple IT infrastructure to support Lx Retail which made our move to the True Cloud a snap. We have a workflow engine we developed into the core of our application and a simple, intuitive ad-hoc report builder that any user, technical or not, can use effectively after an hour of training.