Published on the 27/07/2016 | Written by Beverley Head
Smartphone users knows how easily apps bloat up – for enterprises the situation can be just as dire, leading to significant operational inefficiencies…
Delegates attending Gartner’s application architecture, development and integration summit in Sydney this week were again advised of the need to rationalise the number of applications that they operated, and to appoint an applications “undertaker” responsible for beating the bloat.
According to Gartner, in the four years until 2020, IT organisations will decommission more than three times the number of applications they have decommissioned since 2000 as they look to streamline operations.
It’s a real challenge for big business.
Speaking at Pegaworld earlier this year, ANZ chief operations officer Alistair Currie noted that one of the bank’s “dirty secrets” was that “All the time we have been using computer systems we have developed core competency in adding more.
“We have around 2,500 apps and software systems – many of them duplicates,” he said.
Gartner first advised companies to start rationalising their applications portfolios eight years ago, but it now claims that the issue has become critical and that they need to adopt a bi modal approach – keeping the lights on legacy, but separating future development.
That’s what ANZ, which is on a modernisation journey, is attempting. According to Currie; “What we are doing is to decompose the full stack, upgrade the elements we need and must do, particularly integration to make it more flexible…and in a sense isolate the remaining questions about the core books and records…having derisked and removed the components around it.”
Andy Kyte, the Gartner vice president and fellow, who has led the charge to beat the bloat and opined on it recently right here on iStart, also warned software developers this week that when it came to any new development, they needed to take an applications lifecycle view of success rather than maintaining the current project focus. He said that project owners often steered the agenda in one direction, which often overlooked the need for the eventual application to be useful over a long period of time.
“It’s not about the wedding – it’s about the marriage,” he said, noting that it was of little consequence if the software project was successful when the application was awful across its lifecycle. He said control needed to be wrested from people with a project focus, in favour of people with a clearer vision of all the stakeholder needs.
Kyte recommended that in early design meetings to discuss the application, the team have placecards at the table for “low visibility stakeholders” such as the business users of the system, the software maintenance team, and the group that would one day have to change the application to meet shifting business needs.
He also recommended attention be paid to the international standard for software development – IEC 25010 – and its eight sets of requirements addressing the eventual application’s security, functionality, usability, reliability, compatibility, efficiency, maintainability and portability.
Kyte said that; “From my perspective – functionality is the least important feature of an application… functionality is about a relevant to the application as the colour is to a car.”
Instead software developers should focus on its “’analysability’, changeability, stability, testability, and maintainability/compliance.”
