How to turn application spaghetti into tasty IT services

Unscramble your systems

The promise of IT service management is to deliver services that make sense to their business users. To do that, though, IT departments must be able to untangle their own internal resources.

IT services must be accessible in one place so that users can find them easily and administrators can manage them. And the back-end applications that support those services must themselves be easy to manage and clearly identifiable.

Sounds simple enough, right? Unfortunately, that is not the situation facing many IT departments today.

Employees can access services via a bewildering array of touchpoints, and admins are grappling with a spaghetti mix of applications at the back end. Both of these layers of complexity makes it difficult to offer the streamlined services that users are looking for.

How did we get here, and how can we change it?

Consolidating front-end services can help an IT department to present a more uniform experience to business users.

Consolidate, consolidate

Service desks are one example. They can develop independently, sprouting up alongside application projects and IT service lines, having been developed by different teams.

The result can be confusing for end-users and create problems at the IT level. The IT department can haemorrhage budgets as service desks have to spend on extra staff to duplicate functions and multiple software licences.

Fragmented service desks can also hamper a department’s ability to deliver quality services for employees, especially when information about services needs to be shared.

It can also be difficult for service desk staff who don’t have a full view of all the back-end IT systems and processes to understand what may be causing a particular problem.

IT departments may find it more appropriate to consolidate service desks, providing a single one-stop shop across different products and service lines, no matter what business function or IT product they are related to.

Technical teams can contribute to a single knowledge base, rather than forcing users into a lucky dip of help areas

Consolidation means technical teams can contribute to a single, searchable knowledge base, rather than forcing users into a lucky dip of help areas, in which service staff may have created different workarounds for the same issues.

Ostensibly, this might seem to be a simple case of exporting service tickets and knowledge base data into a common repository, and then using only as many employees as necessary to staff it. In practice, though, there are more considerations.

Process consolidation is a case in point. Many processes distributed around the different service desks may duplicate each other and be handled differently. This is the time to rationalise them, producing a single, integrated approach.

Many manual processes can be automated to reduce the workload for staff and produce a consistent, error-free experience for end-users. Many of the steps underpinning a service upgrade, for example, can be handled without human intervention.

Integrating the service desk with other IT processes is crucial. IT departments should integrate service desk software with systems handling change and configuration management so that a series of events can be triggered via a command from the service desk agent.

Run book automation (RBA) can be a useful way to condense process consolidation and automation into a single system. IT staff can code service processes directly into workflows in a RBA system.

Zip it

All this consolidation of end-user services will get an IT department only so far, though. It will drive efficiencies for sure, but an IT department will experience problems if it tries to layer a service-based culture on top of a pieced-together set of IT systems.

Just like a zipper, the whole infrastructure hangs together more tightly the more you pull it together.

IT departments grow organically over time. Different teams and political regimes implement different applications, and all too often they don't communicate with each other.

These applications can overlap each other's functions and end up running on different hardware and operating system configurations. This leads to several problems.

The obvious one is cost. Maintaining a broad array of back-end systems without standardisation can be a drain on budget, especially as those systems begin to age and support becomes harder to find.

Staff can find themselves spending more time on massaging legacy software to keep it functional than they do working on IT innovations to make the department more efficient.

Legacy hardware and software also tend to be fairly rigid. Older applications may not be customisable and are unlikely to support modern computing concepts such as mobility, open APIs for data exchange and the like.

Those responsible for developing or configuring them may have long since left, making the legacy systems, and the services they support, difficult to improve.

How can you best consolidate these systems to create a more streamlined set of IT resources to support services for your end-users? We can break it into three broad steps: analysis, retirement and rationalisation.

Portfolio perusal

Start by baselining what you already have. Assess your portfolio to understand which category each piece of software is in – whether it is commercial, off the shelf or custom software.

A critical facet of your back-end software is its business value. Describe what the software does by detailing the business processes it supports. Develop categories under which different applications of similar functionality can be grouped.

What is the return on investment from this software today, and what would it be if it were modernised?

On the flip side, consider the cost of the application as it stands, pre-consolidation. How much does it cost to maintain and operate? What are the licensing fees for the application?

How much could be saved it if was replaced with something new, running on modern operating systems and hardware? How much could it contribute to hardware savings if it was virtualised, and is that possible in its current form?

Does the application as it stands prevent you from enhancing a business process in ways that would tangibly benefit the departments that rely upon that process?

During this phase, you can also examine the risk of consolidating the application. If it forms part of a mission-critical set of resources, then aspects such as the size and complexity of the code may be important.

Quantifying the likelihood of service disruptions and their impact on the business can help you when considering the consolidation of particular software assets.

In or out?

Armed with this information, the IT department can make smarter decisions about which applications to retire and which to keep. This is a good time to explore different application categories.

Will all applications in a particular category be replaced by a single, newer one? Will some applications remain and must they be reconfigured in any way?

At this point, it is also worth considering application integration. Which applications should integrate with each other and how? Is there an opportunity to break down silos and share information to make IT services more effective for end-users?

Then comes the consolidation process. Planners can develop a roadmap for each application in each category, so that implementation teams know what will be affected at various stages of the process.

The end result should be a single service desk that can serve different types of users, both internal and external. It should be able to trigger events across a smaller, streamlined portfolio of applications that have been brought together with business-facing IT services in mind.

It all sounds great in HTML format, but naturally it will be harder to do in practice. This is likely to be one of those IT projects that happens incrementally.

But the more resources can be consolidated, the less burdensome the back-end application architecture will be and the more focused the IT services culture can become. ®

Other stories you might like

  • Battlefield 2042: Please don't be the death knell of the franchise, please don't be the death knell of the franchise

    Another terrible launch, but DICE is already working on improvements

    The RPG Greetings, traveller, and welcome back to The Register Plays Games, our monthly gaming column. Since the last edition on New World, we hit level cap and the "endgame". Around this time, item duping exploits became rife and every attempt Amazon Games made to fix it just broke something else. The post-level 60 "watermark" system for gear drops is also infuriating and tedious, but not something we were able to address in the column. So bear these things in mind if you were ever tempted. On that note, it's time to look at another newly released shit show – Battlefield 2042.

    I wanted to love Battlefield 2042, I really did. After the bum note of the first-person shooter (FPS) franchise's return to Second World War theatres with Battlefield V (2018), I stupidly assumed the next entry from EA-owned Swedish developer DICE would be a return to form. I was wrong.

    The multiplayer military FPS market is dominated by two forces: Activision's Call of Duty (COD) series and EA's Battlefield. Fans of each franchise are loyal to the point of zealotry with little crossover between player bases. Here's where I stand: COD jumped the shark with Modern Warfare 2 in 2009. It's flip-flopped from WW2 to present-day combat and back again, tried sci-fi, and even the Battle Royale trend with the free-to-play Call of Duty: Warzone (2020), which has been thoroughly ruined by hackers and developer inaction.

    Continue reading
  • American diplomats' iPhones reportedly compromised by NSO Group intrusion software

    Reuters claims nine State Department employees outside the US had their devices hacked

    The Apple iPhones of at least nine US State Department officials were compromised by an unidentified entity using NSO Group's Pegasus spyware, according to a report published Friday by Reuters.

    NSO Group in an email to The Register said it has blocked an unnamed customers' access to its system upon receiving an inquiry about the incident but has yet to confirm whether its software was involved.

    "Once the inquiry was received, and before any investigation under our compliance policy, we have decided to immediately terminate relevant customers’ access to the system, due to the severity of the allegations," an NSO spokesperson told The Register in an email. "To this point, we haven’t received any information nor the phone numbers, nor any indication that NSO’s tools were used in this case."

    Continue reading
  • Utility biz Delta-Montrose Electric Association loses billing capability and two decades of records after cyber attack

    All together now - R, A, N, S, O...

    A US utility company based in Colorado was hit by a ransomware attack in November that wiped out two decades' worth of records and knocked out billing systems that won't be restored until next week at the earliest.

    The attack was detailed by the Delta-Montrose Electric Association (DMEA) in a post on its website explaining that current customers won't be penalised for being unable to pay their bills because of the incident.

    "We are a victim of a malicious cyber security attack. In the middle of an investigation, that is as far as I’m willing to go," DMEA chief exec Alyssa Clemsen Roberts told a public board meeting, as reported by a local paper.

    Continue reading

Biting the hand that feeds IT © 1998–2021