Adventures in Application Rationalization Part 5: Tying It All Together
Foreword
Application rationalization is a crucial aspect of the business and IT lifecycle, and a topic we have covered previously.
Ferroque Systems has teamed up with Stephen O’Grady; a trusted colleague to our team, application rationalization expert, and IT management veteran from the UK for a series of guest posts. These articles deal with application rationalization and its importance to the modern organization.
Series Articles:
- Part 1 – Fragmentation
- Part 2 – Resistance to Change
- Part 3 – Reorgs, Mergers & Acquisitions, and Migrations
- Part 4 – Rationale and Approaches
Over the last few weeks, we have looked at the promise and pitfalls of application rationalization, why it is important, how it can work, and how it can go oh-so-wrong.
I make no apology for starting this final part by reiterating that communication is key; business needs to communicate its needs properly, and IT needs to articulate the art of the possible in fulfilling those needs, and both sides (although everyone should be on the same side) need to come to a mutually agreed position.
The People Factor
In order to find this common ground, the role of the now-less-common Business Analyst should be seen as vital. A good BA is fluent in both business and IT speak, not that you would necessarily want them to be processing financial transactions or coding in C++, they’re more of a highly skilled translator with an eye for detail, and a deep understanding of processes, data, and above all people.
It is also important to view any sort of rationalization as a business project, not an IT project. In rationalizing it will be necessary for both the business and IT to make changes, which will be:
- Changes to process
- Changes to governance arrangements
- Changes to applications, hosting, data storage or communication networks
…and almost certainly a combination of most if not all of these. The crucial point is that it is a change to the business, in particular a change to ways of working, so must be addressed from the business change angle with IT change in support of that, not the other way around.
Certainly, one can take the view that IT may have to change for reasons of compliance, licensing, emerging technical constraints or some other similar factors, but this will result in a change to the business. And as we looked at earlier, people don’t like change because they don’t like change. It is therefore far better to address the business side of the project and make IT match the requirement, even if the reason for the business project is that IT needs to change, rather than running an IT project and asking the business to conform (and I think we all know the likely reaction to the latter approach). After all, IT exists to support the business, and meet its needs through implementing and managing the necessary technology.
At this point, it is worth a brief diversion into the world of the BA, and the cost of quality. There are tools and approaches, such as Lean Six Sigma, which focus on business improvement and reducing the cost of quality, and these approaches can play a significant role in rationalization as the business change resulting from this sort of analysis can be used as a fulcrum for the lever of supporting IT change. By taking this sort of approach, where the change is initiated by and expressed in the language of business rather than IT, it is at least more likely that the business will understand what is needed, and it is even possible that if addressed in this manner the business will become the advocates for change rather than oppose it.
In making changes, we must never lose sight of the fact that whatever the reason for the change, it always presents an opportunity.
Rationalization should always be an instinctive consideration in modern IT. As discussed earlier, the vast majority of enterprises now have a fragmented IT landscape, and rationalizing to reduce cost, increase efficiency, and (for IT) increase supportability should always be the target, and there will never be a better time to rationalize than when some other change is required.
And, it will always be better to engage with the business, engender a spirit of participation and ownership, and work together to make the best possible change. That approach has far greater chances of success than it would be to seek to impose change for what may seem like abstract technical change on an unwilling business, who are likely to take the view that nothing is wrong so there is no need for such a change.
Once again, the role of the BA comes to the fore, as it is they who should be articulating the business benefits of the change and in doing so getting the business onside.
Supportability
A prime mover for change on the IT side should be supportability, as the cost of supporting an application can, over time, far outweigh the initial procurement.
This is where having a properly articulated application architecture, overlaid on a fully developed technical infrastructure architecture becomes vitally important. The application architecture cannot exist in splendid isolation, but should always be a supporting element of the enterprise architecture, and should act in support of the business’ operating model.
To my mind, the key considerations for IT supportability are usability, availability, compliance (in all senses), and interoperability.
As I have said before, the ability to maximize supportability by maintaining usability and compliance gives a higher likelihood of good interoperability and crucially gives technical control to the IT professionals tasked with ensuring the system delivers as intended.
This is where another element needs to come into play, that of procurement.
IT procurement for any new application must take into consideration the supportability, interoperability, and ability to change and conform over time for any proposed solution. It is all too easy to buy a “best of breed” solution, only to find that it is the perfect fit for one part of the business but is poor from the viewpoint of interoperability and therefore a suboptimal solution when looked at from the enterprise architecture level.
So, How Do We Get There?
No-one’s saying it’ll be easy, but if a job’s worth doing…
The first thing to recognize is that rationalization is unlikely to work as a “big bang”. It is all about convergence, about setting the framework within which the business can make a convergent change to move to and maintain a rationalized application landscape. This change can only happen over time, at a pace that both the business and IT can cope with, but this could span anywhere from weeks to months; if it looks like it will take several years then it may be that there is some further analysis required, as any plan that runs beyond 12-18 months will always be so susceptible to change that it is hardly worth bothering with.
In this context, there is an old saying in project management (well, one that I have heard and used at any rate), “in order to eat the elephant, first cut it into bite-sized chunks”. If a plan for rationalization appears to require a business to eat an elephant whole and without chewing, it is not a plan but a recipe for certain failure.
A good plan will have sufficient detail wherein everyone can understand what is expected, who will be delivering what, and in what order, and in particular where the dependencies – internal and external – can be found, but should not be a multi-year task-level schedule of activity which would be almost impossible to manage, and therefore impossible to deliver as well.
How Can We Change the Mindset?
The whole essence of rationalization, indeed almost any IT-enabled business change project, is that it’s all about finding the middle ground, which is easier said than done.
It’s difficult for staff at the local level to take on board the bigger picture of the IT challenges facing senior management, and it’s difficult for senior management not to be dismissive of the very real needs of the teams at the local level.
As previously mentioned (several times!), the key to success is clear communication, but learning these essential skills takes time, especially in people who are used to just doing their own thing.
What can help speed up this learning process is the setting of realistic targets and the introduction of financial incentives for achieving these because that’s the language everybody understands!
The business and IT worlds need to achieve a meeting of minds on numerous factors, such as:
- What is meant by “currency” in applications – e.g. defined as at no more than one version behind current and with a target of always being current;
- The procedures for choosing which method of staying current – e.g. containerization (although preferably not!), migration, rationalization, etc;
- The financial incentives for the local department for doing so – e.g. the amount saved by not having to support the old system;
- The penalties for the local department for failing to conform – e.g. becoming liable for all support charges of the old application, including relevant staff costs across the board;
- How to ensure that senior management can allocate sufficient budget for equipment, software, and training to achieve these targets.
Hopefully, this will go a long way to helping your company stay current, stay safe, and thrive in an ever-changing world.
In Conclusion
I have probably made the situation sound worse than it is in many organizations.
That said, I have also probably sugar-coated it a little for some others.
If I have sounded alarm bells and caused panic, I apologize for the panic but not the alarm bells.
Too many organizations have allowed their application landscape to fragment towards unmanageability, and have enormously increased their business risk as a result. This is almost certainly not an intentional action, but rather a “sin of omission, not commission”, to be slightly theological for a moment.
Interestingly, risk behaviours often involve doing nothing so as not to make a wrong move, and as an unintentional consequence increased risk, which is an example of that type of behaviour (or more correctly absence of behaviour), but that is probably for a different article some other time.
The good news is that none of this fragmentation is irredeemable. As D:Ream (with Professor Brian Cox on keyboards) once sang, “Things Can Only Get Better“.
With a proper analysis of the business’ needs, a properly articulated application architecture, and a convergent plan for rationalization, any organization can, over time, move to the sunlit uplands of a fully rationalized application landscape, with all of the efficiency gains that brings.
I have seen real-life examples of all of the pitfalls I have outlined in this series, or possibly real dying examples might be a more accurate way of putting it, but I have also seen good work in various places which has seen real improvements.
My professional colleagues at Ferroque Systems have also seen all of this before, and have a real depth of expertise to help any customer plan and migrate their way out of the fragmented swamp and onto the Elysian Fields of rationalized applications, and a real enthusiasm to do so.
Finally, always remember, communication is key!
-
Stephen O'Grady
Stephen is a UK-based IT professional with over thirty years of experience, currently a programme manager focused on business and technology change. He has a keen understanding of IT market dynamics and offers valuable insights on how businesses can better utilize IT.