ISB Smart Solutions
Blog Icon
Time for Change
Why IT Needs to Change its Approach to Responding to Business Needs
Posted 07 April 2016 by Andrew Tabata 
time for change

From original post by Michel Ozzello  on April 29, 2013

At first glance it stands out that the way companies currently deal with their backlogs and technical debt is just not working.  Too many IT departments are challenged with unsustainable business models that render them ineffective, or in some cases, irrelevant.  They are in danger of being relegated to little more than cost centers.  And in that state, they are unable to support companies hoping to differentiate through innovative tech.

The problem is simply that current techniques and tools used for delivering and maintaining enterprise systems are hard to use, and the applications these tools deliver are hard to maintain.  This context creates an expensive and unmaintainable problem.

Today, when a business unit needs a new application, or a new piece of functionality in an existing application, your typical IT department responds in one of four ways.  At best these approaches kick the can down the road. At worst, they add to the problem by creating an architecture and technical environment that will be unresponsive and unable to adapt to changing business needs.

Let’s look at current approaches to software change:

1. Buy, and Customize, a Packaged Application.

Consequence: When an organization chooses to buy a packaged application such as SAP or other ERP, payroll or CRM solutions, they are buying into pre-defined functionality that delivers best of breed standard processes for the industry/market it serves. More often than not, organizations find that their processes are somewhat different from what the package offers, and therefore must customize the package. The problem is that packages have not been built for change and customizing packaged applications is hard, expensive, can require hundreds or thousands of consulting hours, and will create a maintenance nightmare.

2. Build a Custom Solution Using In-house Developers or System Integrators.

Consequence: The problem with this approach is that building a large system using the current state of techniques and tools is complex and expensive. Organizations often fall hostage to the system integrators who built the application, because they are the only ones that know how to maintain it. This just ends up being a big add-on to existing technical debt.

3. Select and ‘Rent’ a Cloud-based Solution (SaaS).

Consequence: With the advent of software-as-a-service (SaaS), companies are resorting more and more to ‘renting’ cloud-based applications to satisfy business requirements. By the very nature of the model, SaaS applications offer small degrees of parameterization, and with the exception of a couple of very large vendors, no customization options. To a degree, this is a blessing in that IT tends to use SaaS “as-is” and therefore limits maintenance requirements. It does not, however, address the requirement for custom functionality – namely interfaces, workflows and data repositories that are unique to nearly every organization.

4. Do Nothing!

Consequence: When budget, time or resources are not available to buy or build the needed application, IT often just says “No” to the business. When the IT department chooses to do nothing, it causes its relevance to decrease even further and results in the creation of…

Shadow IT

When the pressure to come up with a solution for the business is intense, and IT can’t deliver what is needed, business teams often decide to take matters into their own hands. This is commonly known as “shadow IT” – applications built, installed or rented outside of IT’s control.

Looking at these approaches dealing with backlogs, one can see that none of them are particularly desirable and they are replete with cost issues, control issues, and scalability issues. Yet, despite their futility, time and again, organizations continue to walk down the same trodden paths expecting to arrive somewhere different – or maybe they feel like there is no other path to take?

The fact is there’s always a new trail to blaze.  In an ideal world, you would not have to worry about the cost of change. You would simply focus on delivering the application your business needs, and know that it would only slightly increase your maintenance costs. In order to do that, you’d need to use technology and an approach that could ensure a flat cost of change across the entire lifecycle of your applications.

See other Articles on these Topics
Click here to see your activities