blob

At the start of the year this mad scientist embarked on a quest to replace the state of the art Web 2.0 “best of breedPSA system (Professional Services Automation) that we used (we had not created it, but purchased it) with something better than the “best”.

After much research (need PSA? Ask me!) we concluded with deep regret that there were no best of breed players that could satisfy our needs and decided to build it ourselves.

It is not something that our CEO Jonathan Maldoff and I often decide to do. In fact, I can’t remember the last time we did that, especially for a core internal system that tracks the heart of our business: project management and related time spent and billing.

Our experience has shown it is not often cost-effective to build it yourself. You need to become software authors, develop subject matter expertise, follow development and project management methodologies, maintain and support code, and keep up with standards. Not easy nor strategic for many corporations.

We are strong proponents of the best of breed (BOB) approach. Best of breed can ensure you have the finest software minds working for you at the cost of a license and with guaranteed support. Then you integrate this with your other BOBs to get a best of breed suite going.

The risk to integrating multiple solutions is that if you aren’t careful in your method, you can end up with a myriad of different systems to maintain and learn, an inconsistent user interface, multiple vendors to call for support, and multiple points of failure in integrations. However, we believe that by working with the right integration partner you can reduce or eliminate these risks – making this partner your turn-key single point of contact and achieving a true win-win.

This is why we normally favor integrating applications that are experts at what they do and putting them under a common framework, rather than building it or picking one single solution that does it all, because such all-encompassing solutions rarely do it all well. Inevitably you find out that those systems do certain things very well (typically their original components that made them famous, not surprisingly) and the rest is so-so or even just plain awful.

If you do prefer large systems that do it all due to the lure of simplicity of having less to deal with, just be careful. The reality is that many such systems are in fact amalgamations of many applications in their own right due to mergers and acquisitions. Oracle, Microsoft and IBM, all leading players in ERP “large systems”, have made so many acquisitions of  best of breeds that they cannot always claim easy integration, a unified interface, or in some cases even architecture. So now even best of breed isn’t good enough?

It dawned on me that when I talk about best of breed, in my mind I really mean “pure play best of breed”. There’s a difference, and a big one at that. In many markets “Pure Players” are the applications that have focused on their strengths and not wavered under the temptation to build it bigger to capture  incremental markets. Those that lack discipline suffer from “scope creep”: the applications become bloated and unfocused (look at Microsoft Office for example) and there exists a law of diminishing returns – for each added feature there is a disproportionately lower return on that investment (and therefore a lower benefit to you, the user, for your money).

But back to our internal PSA system that we chose to develop. Why did we do it when so many great PSA systems exist? Having done enough research to know they wouldn’t fit, (and that I wasn’t deluding myself), it came down to 3 key factors.

First the PSA’s simply had too much functionality. Too much, you ask? How is that a bad thing?

It’s a bad thing when you need user interfaces that are efficient time savers and you are instead faced with a beast to navigate with a slew of questionable bolt-on features. When this beast gives you nearly unlimited configuration options with five levels of menus when just one level should be enough – it’s just plain confusing. When the simple need to enter a time record requires (count’em) 24 clicks, it’s a show-stopper.

It’s very common for BOBs to mutate over time into BLOBs instead. The gooey BLOBs can destroy cities while the software BLOBS destroy corporate efficiency…

Second, the PSA’s didn’t integrate as well or as easily as they should. As integrators we thrive on great applications that can talk easily to the world at large, but we hit a wall here which was a show-stopper.

Third, we took the opportunity to invent a new development methodology based on leading edge Web 2.0 principles and our User Interface experience (ok, fanaticism), then we fused this with the latest .NET, jQuery, and Web Service architecture to achieve simplicity, functionality, and integration flexibility only dreamed of by most web apps.

For us, this last part was a bonus: we sent the kids to the candy store and let them run around until they passed out! We’re different though, in that we have software development expertise as a core value already. Our clients also expect us to stay ahead of the pack,  to be in the best position to consult with them, so that they can focus on what they do best as well. Experimenting is a constant reality around here. But what is a bonus to us isn’t a bonus to most companies, it’s often a difficult drag on everyone.

The lesson therefore is to use BOBs whenever possible but avoid BLOBs that claim to do it all (or use only the parts of their systems that clearly fit your needs), and try to stick with an architecture that generally fits with your corporate structure to make integration and maintenance that much easier.

Want to see a demo? Email-me – but it’s not for sale… yet 😉

Advertisements