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.

Defect Management

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.

Price

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.

Implementation

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.

Reporting

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.

Shameless plug

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) last year, we have had the most consistent group of developers of any IWMS vendor. As a result we have ONE code base, ONE Java Platform, ONE Database and ONE design pattern. This allows for a simple IT infrastructure to support Lx IWMS which made our move to the cloud, with IWMSCloud®, 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. Our application might not look as fancy as some of the firms with multiple platforms and many third party applications cobbled together, but having a single platform and code base allows us to offer unparalleled functionality at a much lower cost.

Previous IWMS related Blogs

What is IWMS anyway?
IWMS? It’s Location! Location! Location!
The Power of Location Management
IWMS – Why so expensive?
IWMS in the “Cloud”

The term “Integrated Workplace Management Systems” or “IWMS” was coined by Michael Bell formerly of The Gartner Group. This new term was then used as the basis for producing an IWMS market assessment including a Gartner Magic Quadrant. This type of assessment is commonly produced by Gartner to compare technology vendors in many industries. Without a common term, in this case IWMS, there would have been no way to ‘lump’ a bunch of vendors together into a comparison document. In reality, at the time the term was coined, the vendors thrown into the IWMS bucket were very dissimilar and often addressed very different markets. Since then, however, using the IWMS blueprint provided in the IWMS market analysis containing the Magic Quadrant, the vendors have actually enhanced their products, changed messaging and in some cases merged to better fit the image of “IWMS”. While features of the vendors have grown more similar, they remain different in some very important ways, most notably their expertise in specific customer bases and specific functionality that addresses that base.

I for one, have worked for two IWMS vendors and competed in the market since long before the term was coined, having co-founded Lucernex in 2000, then taken over as CTO and head of product management at Accruent in 2003 then returned to Lucernex to become President. I have seen most of the vendors products, have talked to any number of people who have worked for the different vendors and seen marketing and Blogs from many vendors. We all seem to be trying so hard to fit the mold of “IWMS” when really we should be distinguishing ourselves based on our unique knowledge and features.

If you look at the key vendors in the space in addition to Lucernex you will find Accruent, Tririga, Manhattan, Siterra, Planon, amtdirect, Bricsnet, Qube, BIG, FM Systems and many more. What’s most interesting is that there are enormous differences between these vendors both in their background and expertise and in the functionality that they deliver, yet we are all “IWMS” vendors. For example, Lucernex leadership came from commercial real estate, retail, hospitality and corporate technology. Our products reflect that as we are very strong in site selection, lease analysis, transaction management, construction project management, lease administration and capital project management. Our knowledge of prototypical development design, planning and management as well as lease administration and rent accounting is second to none among “IWMS” vendors. If you look at each of the other vendors you will find a variety of other specialties as well.

The easiest way to assess what an IWMS vendor is best at is to look at the background of the leadership. If all executives of an IWMS firm come out of construction management, you can bet their construction project management features are really good. If their leadership came from real estate brokerage, their site selection and lease management features are likely their best functions. Strong facilities management is likely to come from someone with a background in corporate or campus property management. No one vendor is best at everything and, no matter what any vendor says, no one is best to fit every customer.

My hope is the market will begin to segment and become redefined by what is really needed by the different end user communities. After all, what is needed by a 200 store retailer is not the same as what is needed by a University with 2 campuses, or a corporation with 5 locations, or a government agency with 300 global locations, or a restaurant chain with 20,000 locations worldwide, or a cell phone company with thousands of towers and hundreds of stores. I look to organizations like IWMSNews and FacilityLeadership to begin to dissect the market instead of simply picking up where Gartner left off.

Some vendors have already begun to move away from the pure IWMS moniker. At Lucernex, for example, we still use the IWMS tag for our solution but truly consider our offerings to be Location Performance Management or LPM software. Qube software and amtdirect don’t use the IWMS name at all and Accruent has begun to use Enterprise Location Management or ELM to describe their solutions (though this may change due to the recent purchase of Accruent by a Private Equity firm).

We need new thought leaders whose agenda is not to lump us all together to be able to write a single report trying to compare us all against a single set of requirements. Instead, identify the needs of the different end user communities, see what features and functions are most important to them and how they need them delivered and compare the vendors to those requirements. What I believe we would find is there are several strong vendors in the IWMS market that are the best at serving one or two groups of user communities which would make it easier for buyers to know what is available to them and which vendors to compare.

I welcome additional opinions from customers and other vendors.

Go to our Lx IWMS product page to find out more about the Lucernex IWMS.