Prior to the early 1990’s, large organizations depended on local talent to build core business applications from the ground-up. These, now called, ‘legacy’ applications were fundamental in capturing, persisting, sharing data within the business in addition to facilitating common business processes. Every application had a purpose, and that purpose was relatively focused. This level of specialization and customization enabled technology to be built into a business process rather than a business process laid within a tool.

The tailor-made application concept boded many advantages, most notably they enabled the business to define their own destiny from a support, maintenance, and integration perspective while tightly aligning to the operational support model. On the contrary, this flexibility came at the cost of increased implementation timelines, sustained domain expertise, and reduced agility to respond and integrate with emerging technologies.

Queue the world of ERP

ERP or Enterprise Resource Planning technology entered the market around the late 1980’s and promised to capitalize on the strengths of customized technology while eliminating the risks and downfalls of homebrew solutions. This technology panacea aimed to seamlessly integrate the business through a web of module-based software – All applications spoke the same language, shared a RDBMS footprint, and could be customized and configured to suit the business’s specific processes. A company who previously built and supported (and paid for the sustenance of a software engineer $$$) 10+ systems could consolidate into a single system to manage core operations and conduct business electronically. Jack-frickin’-pot.

…But what’s the catch?

Let’s begin with time. Most ERPs are built in a modular context – it’s like an a la carte menu for technology, however, some modules are mandatory perquisites for others which means if your objective is to deploy a certain tool, you may be forced to deploy multiple others to yield the expected behavior which can substantially drag out the implementation timeline.

Money. Aside from the obvious correlation to time, ERPs traditionally required a specialization of the particular technology…A specialization large consulting groups paid a lot of money to procure and worked very diligently to protect the intellectual property. Where previously anyone could build a custom application, only the preferiti were endowed to implement on the software’s behalf.

And perhaps the biggest gotcha is the collective effect of a substantial time and monetary investment – You’re stuck. After implementation, it’s quite possible that an organization can become held ‘over the barrel’ by a software vendor (and implementation consultancy) and incapable of adapting and evolving technologically due to the need to recoup the cost of implementation and realize an ROI.

Queue the world of Specialized Applications

Hybrid. Flexible. Cheap. Intuitive. The business cannot afford to miss opportunities to compete due to IT’s inability to scale an application to meet the demands of the market. Savvy business analysts and managers look to the market of open-source technology and cloud-based applications to meet their specific business unit and line-of-business objectives – wait for it…Often without the knowledge of enterprise IT or compliance which introduces a wealth of risk – but that is not the purpose of this article. Rather, for this demonstration, let’s assume that IT was a champion for the adoption of a Specialized Application and they guided the business through a seemingly best practice SDLC and implementation.

What happens? Well…for starters, things look good at first. The business has fully adopted the technology (which is always a fight with IT-driven tools) and feels a sense of ownership. They’ve began working with IT or a shared services group to build orchestrations and integrations with other Specialized Applications, taking advantage of modern API frameworks, and they’re building a critical dependency on what is often-times a fly-by-night product.

I would be generalizing if I said the intent of all entrepreneurial software developers is to build and sell – So I’ll say it’s the intent of 99.8%. The wide-spread goal is to gain a critical mass of customers and revenue to where they’re perceived as a threat (or weapon) by the big boys and get purchased. The effect of this to the customer is abandonment of support, terminal releases, and a rapidly deteriorating asset which one’s now business is based-upon.

Queue the Systems Compatibility Complex

As we saw in the 80’s and prior, applications had a very long life and were slow to evolve; although this sounds bad in today’s technology environment, it made a lot of sense for maintaining compatibility between applications and congruity of business process. ERP helped us out too with a release/maintenance schedule and application backbone between modules which limited the risk of incompatibility between upgrades (although, we’re always weary of our customizations weathering the upgrade-storm).

So what about today?…and what effect will Specialized Applications have on an organization’s IT footprint, and how will they influence the next generation of technical architecture?

  1.  I hope businesses like pasta because they’re going to be swimming in spaghetti – Previously, it was a rather manageable task to maintain a map of system integrations, versions, upgrade schedules, etc. By combining lethargic core applications with hyper-evolving systems, we’re creating a compatibility nightmare. In today’s environment, it’s not uncommon to manage and maintain 3+ versions of a software to ensure continuity with other applications which have not or cannot be upgraded to a modern application standard.
  2. I hope businesses like regression testing – because they’re going to be doing it…forever. Even the most minor changes to one application can have a massively negative impact upstream, cross-stream, or downstream. Migration cycles are either extended to accommodate a more comprehensive regression effort, or production support and IT lives a life of break-fix and T1 ticket management.
  3. I hope businesses like long ringtones and archived blogs because they’re not getting anyone on the phone that can help resolve their specific integration issues. In fact, they’ll run a risk of voiding the warranty of the enterprise software they own by tying in unsupported applications.

Surely there’s a balance. Surely there is a way managed IT applications and specialized business-owned applications can live in harmony. Surely we don’t have to wait for small software vendor’s to get acquired by large software providers before we can sustain a healthy technology ecosystem.

But how?

Sign up to receive the latest insights.

We promise not to spam you and only send the good stuff!

  • Should be Empty: