Helping you drive digital innovation
Subscribe
RSS Feed of the Mendix Blog
Thanks for Subscribing

Keep an eye out for Mendix resources coming straight to your inbox.

The One Idea Radical Enough to Solve the Trillion-Dollar IT Debt Crisis

on November 14, 2013

Share:

Editor’s note: a version of this post was published December 16, 2013 on Sandhill.com. View that article.

There’s a massive, trillion-dollar problem building within IT organizations.  As a CIO, you’re likely already in the middle of it but perhaps unaware of the scale and impact on your organization and unsure how to address it.

According to Gartner, IT debt (“the cost of dealing with delayed and deferred maintenance of the application portfolio”) threatens to reach one trillion dollars globally by 2015.  The analyst firm notes that after a decade of tight budgets, the scale of the maintenance backlog has created a systemic risk that is going to significantly impact IT organizations.

Sources of Rapidly Growing Maintenance Backlogs

CIOs are facing a mountain of IT debt

Sure, tight budgets are one reason why IT teams have been unable to keep pace with the growing maintenance backlog, but there are other factors at play here.  On the business side, the pace of change is accelerating—rapidly.  With multiple departments and business units seeking new sources of growth, innovation, and competitive advantage, demands for new applications and functionality are at an all-time high.  (As an aside, the accelerated pace of change is also shrinking timelines and heightening expectations, putting added pressure on IT.)

And then there’s the fact that IT, despite those tight budgets, continues to rely on decades-old application delivery methods: either customizing rigid legacy systems or coding custom applications.  These traditional approaches are fraught not only with cost but complexity and risk.  As a result, solutions can’t be delivered fast enough, changes can’t be introduced easily or frequently enough, and the maintenance backlog continues to grow rapidly.  Often, corners are cut and short-term compromises made at the expense of quality and future extensibility.  It’s no wonder that 94% of IT projects are in trouble or fail altogether.

Related: 10 Things Every IT Leader Should Know to Survive & Thrive in the App Revolution

What is a CIO to do?  After years and years of failed attempts, it is more than apparent that throwing more money or people at the problem isn’t the answer.  Gartner’s suggestions to develop an inventory of applications or publish an annual report on the status of the application portfolio help to shed light on the problem, but do very little to solve it.

Embrace Radically New App Delivery Approaches

There’s only one way IT organizations will ever be able to dig themselves out of this hole and solve the trillion-dollar IT debt crisis: fundamentally change the way they deliver applications.  Identifying small, incremental improvements to existing methods simply isn’t enough; the pace at which the deficit grows is accelerating and IT will never get ahead of business demands.  Instead, CIOs must embrace radically new application delivery approaches that eliminate all of the traditional bottlenecks and dramatically increase speed, efficiency, and output.

If you are serious about putting a dent in your own company’s pile of unpaid IT debts of application backlog, deferred app modernization, delayed maintenance and change requests, or ignored security and compliance concerns, you must be willing to disrupt the status quo within application development.   Here are four suggestions to help you chart a new course:

  • Accelerate Development by Canning Code – When you replace traditional coding with new, visual model-driven development, the application development process accelerates dramatically.  An analysis by the global system integrator Capgemini found that by changing to this development approach, development time decreases dramatically to only 2.5 hours per function point compared to 10.6 hours for Java and 15.5 hours for C#.  The reason is that the entire project team can much more quickly and efficiently create and collaborate on application models, intuitively understand the functionality, easily identify and make changes, and instantly run the working application.
  • Tap Non-Professional Developers – By some estimates, there are up to 10 times more non-professional developers than there are professional developers.  When you replace custom code with intuitive model-driven development, you can tap this pool of business engineers (as we like to call them) to dramatically increase development capacity, while still ensuring maintainability and control.  The result is more apps and functionality and because the business is more involved in the process, better outcomes.
  • Extend, Don’t Customize, Legacy Systems – Legacy systems are rigid and extremely difficult to customize.  Rather than pouring precious resources into long, complex customizations, consider adding an agile layer on top of these systems that allows your team to easily extend them with new functionality business users need.  For instance, a $17B manufacturer with 24 operating companies and dozens of SAP instances used Mendix to extend their legacy SAP systems, an approach that yielded substantial cost savings and a significant reduction in time to market.
  • Remove Technology and Infrastructure from the Equation – Technology, infrastructure and deployment issues should not slow a project down or even concern your development team.  Application developers are too often slowed down and distracted with database issues, infrastructure set-up, security concerns, and more.  Instead, consider deploying a platform that makes application deployment as easy as plugging an appliance into a power outlet.  For instance, with platforms where visual models are at the same time the actual running system, where the entire technology stack is already provided, and where operational tasks are automatically managed, you can deploy applications to the cloud literally with a single click.

The trillion-dollar IT debt crisis is staggering, but not hopeless.  There are ways to effectively address the rapidly growing mountain of debt; the key is to change the decades-old ways that got everybody into the hole in the first place.  It might sound too good to be true, but times have changed.  The idea of reinventing application delivery as we know it might be radical, but it is already being implemented by the CIOs who have found that it’s just the thing needed to get ahead of the demand and become a true partner to the business.

Subscribe to Our Blog

Receive Mendix platform tips, tricks, and other resources straight to your inbox every two weeks.

RSS Feed of the Mendix Blog
Mendix

About Mendix

Mendix drives digital transformation by empowering customers to bring new digital products to market and developing applications at the speed of ideas.

| Twitter
  • geot2

    Very interesting pitch; I’ve added you to my web bookmarks. FYI, read your ad in UK The Guardian’s, “More From Around the Web.” Didn’t mean to click there, knowing it’s ads, not news, but did so mistakenly. And am glad.

    I’m a student, an old one, just switched to C#, looking to reenter the market in enterprise development.

    Not sure about some of the terms. Was going to post quite a few questions here till I caught myself – wasn’t familiar, I admit, with Mendix.

    Still, as a life long programmer, C, C++, and now C#, etc., it’s interesting.

    Please excuse my curiosity and some naivete. It may be better to look at these questions as exposing that, and then simply let me know the one… thing I really need to know.

    1) Overall, is this an app generating system, and is there Mendix consultancy?

    Besides the ANTLR parser, within, (similar to yacc?), it seems to contain “canned” apps or functionality (?), like Web access, SQL, Windows or mobile UI generation … ‘?’s

    2) Like the idea of UI vs code. Where does the code fit in, and the UI, vis the platform?

    At first it seems like a workflow system, like Microsoft’s WF. But no, it’s very nearly C, and coding. Then, there are libraries, again, e.g. Web access? Then, and I’m probably already off, but.., then does the ANTLR generated code integrate, in some special way, with libraries?

    Esp., In an active way?

    E.g., C#, for all I was resistant to the higher level, idiomatic, .NET platform, being formerly a C++ guy, actually opens new vistas, backwards. I.e., as they call it, “reflection,” into, and even dynamic synthesis of, C# compiled (intermediate) code.

    Is there anything like that, or even an intermediate level code, here?

    And a, hopefully very different question, is that what your contributor dealt with, e.g., with his DateTime piece? Is there a level to operate in, even beneath this ‘library’ level?

    3) is there a Mendix (data) Modelling component? Bound to what?

    4) Besides Agile, other commendable practices, does the platform embed certain ‘patterns’ (a la, the Gamma book), providing, above paradigm, a sort of school-of-thought?

    My C# series school, ended this year with a capstone project. I implemented it as a Windows/MVC pattern. The result was: a View based on a fat UI library, the Model was left open, providing only that it feed a very general interface, i.e. strongly or weakly typed entities (I provided MS EF & SQL), and the whole thing designed to drastically simplify the Controller; four or five lines to support each button, or other, event

    I see a very general similarity here. E.g. swappable outputs, like Windows, vs Web, vs WPF and even WCF,…. The Model’s a given but you’ve really enticed me to look at a graphical Controller writer. But alas, that’s beyond my interest for a purely hobby product.

    But enough about mine. Are there similarities in design? It is a platform but how far does it go?

    4) Here’s a really awful question to ask. What does the customer have when he leaves Menidx?

    I.e. is it different than, everything he had before he left? All his code, runtime, ability to add or modify parts that may have been provided? Or would you say such a one is best remaining with his partner, Mendix?

    Thank you very much. Naive, I know; I’m returning from long sabbatical. I’ve looked at some of your exhibits. Perhaps, in my haste, it’s 3AM here, I missed a link to a nice case study that programmers and enterprise engineers could get.

  • jefflivesinchicago

    Potentially interesting, but hard to test against any comparisons… as a former developer, I have to admit some of this sounds great, some of it sounds too vague to really see what’s happening, and some of it sounds possibly “panacea-ware”

    I say this as an interested person, and as somebody who may want to give you some insight into the mindset of objections likely to come from former developers…

    1. I’d love to see if the visual->code method can work in a non-one-way method, i.e. what happens when multiple people make multiple tweeks, and un-tweeks and re-tweeks that end up substantially changing the actual idea not just the specifics, as is often the case in the office politics of many enterprises, where different “main goals” masquarade as “just this minor tweek” being constantly added to the pile of things to modify. I ask because I’ve had to debug code that was written by a visual system that had tweek upon tweek and re-definition of the “main idea” a number of times, thus resulting in a MESS, not just of code, but of purpose expressed in code…. and I’d love to see if mendix’s visual code development system has a way to express the warnings of “sloppy thinking” or somesort of “you may regret this change” alerts, or at least something like “you are likely to break the following dependencies if you change x” warnings….

    2. Removing infrastructure is great, as long as it isn’t a ploy to get the whole enterprise on yet another cloud kidnapping your future agreements forever.

    3. Extending, rather than customizing legacy systems is a great idea, as long as you can not be screwed when the legacy system updates something in the interface you depend on. There may be less risk of this than the usual forked-code customisations that often occurr. This part may be more for lawyers than programmers.

    4. using non-pro developers can be great, can be a nightmare, depends on the office politics and the main idea… I am not at all opposed to this, just want to make sure that if something bad happens, it can be fixed rather than papered over….

    5. often, systems from vendors like this seem to be “making the easy part even easier” and “ignoring the hard part” where the clean-sheet apps are transferred to a new system, and the mess fixing of political and highly dependent on oddball stuff code is left for the cannon fodder in-house developers who get stuck in the mud…

  • Brian Allan Cobb

    Glad I’m out it.

    Wish I’d studied something else.

  • Drowlord101

    The guy’s right, overall. I’m not sure I’m in complete agreement with “visual model-driven development” but “real developers” should be building inter-operable tools and components that “smart non-developers” can assemble into solutions.

    When you look at how much development is invested in simple forms, retrieval, summaries, and workflow, there’s no good reason that highly capable people would hoard that work and churn out laborious iterations of already-solved problems.