Channels ▼


Other Voices: Is the Custom Application Dead?

Mike Jones is a vice president at Outsystems, a company that focuses on Agile development.

Custom applications were once the vanguard of corporate IT -- specialized software designed to fit nearly every business need and enhance IT's value to the enterprise as a whole. But the perception of custom application development has changed in the last 15 years, mainly due to the growing power of off-the-shelf applications in the enterprise world.

The lure of software packages is difficult to ignore, especially with the damage done to corporate budgets and IT departments by the recession. The perceived cost savings, speed and overall ease of implementing an off-the-shelf software solution makes them, seemingly, the perfect choice for undermanned enterprise IT managers trying to stretch their budgets.

At least, the benefits look good on paperbut do they really stack up in an actual enterprise environment?

The Truth About Software Packages

The benefits of packaged applications are often described as "built-in best practices," which then should result in:

  • Lowering overall costs
  • Reducing the risk associated with implementing new applications
  • Quicker and easier implementations

Taken together, these benefits mean that an enterprise IT team will have an altogether smoother time when packaged software is involved. Delivered as a tested and standardized solution, off"the-shelf software purports to only require minor tweaking to work with most enterprise IT systems. That makes these applications better than custom-built systemsright?

Maybe not.

It appears that the love-fest between CIOs and packaged software is over.

Recently, the COO of an energy company told me that he was tired of being held hostage by his ERP vendor. In this executive's opinion, for the last 14 years his company has been constantly struggling to meet business needs with packaged apps. They were more costly to implement than planned, hard to upgrade and customize, and ended up causing problems across their IT environment.

Best practices aren't necessarily one-size-fits-all, especially in corporate IT. What works for one IT environment may burn another to the ground. This is where off-the-shelf software falls short -- most of it might work with your enterprise, but parts of it will need more than just "tweaking" to work with your business. With large amounts of customization, package implementations become very brittle and expensive, often resulting in difficult upgrades and an inability to respond to changing business needs.

Not Dead Yet -- Custom Application Development

Even with the hidden issues inherent to packaged software, there is still a general belief that these applications have a leg up on custom development when it comes to time to market. In addition, business users typically don't know exactly what they need from an application, making custom development a long, risky endeavor.

This type of uncertainty and constantly changing scope used to be a death knell for custom development, and a catalyst for a host of other problems:

  • Longer build times, often due to last minute changes or project restarts
  • Unexpected costs and overages from these changes
  • The looming idea of project failure, based on project length and expense, making the risk too great for most CIOs.

All of which were, in turn, associated with the process of custom development.

The entire custom application development process received a bad reputation, due to an inability to address rapidly changing business needs and react to change. Faced with this challenge, savvy developers have begun to adopt a way to maneuver around these ever changing requirements -- the Agile method.

Agile Development as the Mythbuster

So how does Agile address a business's lack of certainty about what it needs, the crux of the problem with custom development?

With Agile, developers start with a high level set of business needs to guide their team. The team then addresses the most glaring or important need, and shows a working demo to the business users within a very short period of time. User feedback is solicited to add more detail, and then iteratively and continually to build-out the system. By embracing and expecting change upfront in the project, IT and the business can work together, building the right solution based on business feedback and priority.

Embracing change actually leads to a swifter implementation -- teams work faster as they deliver on only the most important business needs. Agile practitioners sometimes refer to the final applications as "lean" and "fit to purpose" which means the size and complexity of the application is reduced, making it easier to keep up with future business change. Add this practice to a development environment that supports this type of iterative/agile development process, and handling change gets even simpler -- in turn, making these applications "evergreen" and able to deliver greater ROI for the business -- no more software aging!

The cost and risk associated with custom development are also reduced, the former through smaller team sizes and delivery speed. Risks are minimized as development teams are tasked with delivering working application functionality every two weeks -- project and progress visibility is out in the open and there are no processes to hide behind. Either the team is on track or it isn't and everyone can see it, increasing transparency to the larger business as a whole.

Finally, tools cannot be discounted in bringing custom applications back from the dead. While Agile is focused on working efficiently and effectively, corporate IT shops need the right tools to deliver working software and to make the change process as fast and low risk as possible. Ideally, the best application development tools will streamline application change and automate back office functionality, like building and deploying, gathering actionable feedback and providing project transparency across the enterprise.

So are custom applications dead? Hardly. The promise of packaged software seems too good to be true and, for many businesses, it often is. Adding the Agile method, along with the right tools to the mix, makes custom applications much less expensive over the life of the application and provides enterprise IT with a more flexible option. Perhaps we should be asking: "Is off the shelf software dying" instead?

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.