These Outdated Platorms Fall Short in Five Critical Ways
1. Speed Market
It doesn’t matter if it’s the high-tech electronics market, the healthcare sector or almost any other vertical industry—the escalating pace of business process change is mounting pressure on IT organisations to be more responsive and push applications out the door faster.
Compounding the need for a more agile IT response is business users’ changing expectations for near-instantaneous delivery of application functionality. Primed by consumer technologies like mobile apps and SaaS applications, which can be spun up and activated in near real time, business users no longer have patience for the laborious and drawn-out requirements-gathering and development cycles that have characterised traditional IT rollouts.
Long-standing development methods of hand coding in procedural languages like Java, C# and COBOL, or using more modern languages and frameworks like Hack, Rails, Django, Angular or even HTML5, are just too slow and demand too many specialised resources to hold up under these new rapid delivery requirements. Compared with more modern practices like model-based development and automation, hand coding applications is too complex and presents far too many opportunities for error, especially when dealing with the inevitable slew of integrations that will be necessary for both new and legacy applications.
Business users no longer have patience for the laborious and drawn-out requirements-gathering and development cycles that have characterized traditional IT rollouts.
In addition, hand coding applications make IT teams too dependent on a limited number of individuals with specialised skills. If an e-commerce platform or HR system needs an update or a bug fix and there’s only a handful of .NET programmers up to the task, IT’s ability to respond is fully dependent on those individuals’ availability. In addition, there is no opportunity for recalibrating workloads if everyone on the team doesn’t have the exact same skill set or if specialised talent moves on and leaves the department with a void.
2. Deployment Inefficiencies
IT is trying to address these ineﬃciencies, but it’s doing so by modifying traditional processes using traditional methodologies and tool sets—a strategy that can’t possibly accommodate today’s demands for development agility and flexibility. For example, the waterfall development methodology employs a process that requires everything to be designed up front prior to testing an application. This practice is a root cause of IT’s months-long delivery cycles. Moreover, it is not sutainable as a primary development method given the rate of change when compared with more incremental and iterative methods that allow for agility and flexibility.
In the same vein, a heavy reliance on manual processes—whether hand coding the application in Java or some other procedural language, or writing scripts to automate pieces of the software build—also strains IT’s ability to reliably hit accelerated delivery targets. Because development and operations teams have historically operated in silos, they are using different point solutions that are not integrated or coordinated, leading to inefficiencies and errors when handing oﬀ applications between functions. This dysfunction also exists within each of those silos as the lifecycle of an application flows across build, deploy, stage, promote and manage stages, as well as across diﬀerent environments.
IT’s inability to move beyond sequential development practices, manual coding and siloed groups for development and operations takes a toll on delivery schedules in another way. Because the application development process becomes so protracted, there’s a greater chance that requirements will change, making the application or enhancement obsolete before it’s ever released and dealing another blow to IT’s reputation.
3. Sourcing Technical Talent
Keeping an organisation current in all the relevant development technologies is another major obstacle hampering IT’s development capabilities, especially given the pace of advancements. Mobile and Web applications demand new skills, from HTML5 to responsive design (or even device-specific knowledge) to an alphabet soup of new languages and frameworks, and it’s next to impossible to find the talent, not to mention the budget, to employ specialists in all the various areas of required expertise.
Not only are IT organisations challenged with recruiting the next talent bench, but it is expensive and time-consuming to retrain existing developers in the new skills when there is work to be done and a shortage of able bodies. Those individuals in IT who are well-versed in the latest technologies are indeed critical assets, but there’s a risk of being too dependent on a small cadre of developers who could leave at any time or who simply don’t have the capacity to handle current work- loads.
IT organisations find themselves grappling with scale at a time when all hands on deck are needed to deal with the growing backlog and shortened application delivery time frames. With continuous iteration and application maintenance the two biggest requirements on IT’s docket, it’s incumbent on the organisation to find new ways to do more with less, while retaining internal IT knowledge.
4. Maintaining Legacy Systems
This brings us to the issue of maintaining legacy systems, which is perhaps the biggest challenge straining IT’s already strapped resources. When considering the total lifetime cost of building or buying a new application, experts say that nearly half of the overall expense is directed toward maintenance, including enhancements, break-fix tasks and other related operational expenses. The more complex and older a system is, the more time and money IT has to devote to change and enhance it.
The maintenance burden is multiplied with monolithic packaged applications like ERP. While most companies buy such a packaged application for its best-of-breed standard processes, they inevitably customise it for their own specific diﬀerentiating and innovation processes, which complicates support and maintenance.
The reason is that these monolithic platforms have not been built for change. Therefore, trying to bend them with customisations meant to address new business processes is very diﬃcult and expensive. It also creates a maintenance nightmare that could possibly preclude future package upgrades. A case in point is the growing number of high-profile ERP implementations that have been abandoned due to complications resulting from customisations and ongoing maintenance.
The maintenance burden is multiplied with monolithic packaged applications like ERP.
5. Incurring Technical Debt
When IT doesn’t have the time to build a solid software architecture the first time around, it begets a trail of costs related to fixes and thrown-together enhancements that stack up over time and create a house of cards—a concept known as technical debt. With Gartner’s benchmark calling for system replacement every five to seven years, in addition to moderate changes in between, there’s ample opportunity to incur some serious technical debt—while creating unsecure, nonscalable and error-prone systems if IT doesn’t make the proper changes.
Let’s also not forget the fact that there are more interdependencies within systems, thus increasing the risk that making changes or enhancements to one part of the system will cause breakages or spark problems with other areas down the line. In fact, research shows that the costs related to making changes to applications can be as much as 10x to 50x more expensive than the original cost of developing the system.