The Land of Misfit Applications
BPM Development, BPM Strategy, Development Strategy
Congratulations! You have spent years navigating the waters of bringing BPM into your organization, building your proofs of concept, launching your first applications, and building a strong and dedicated program. Throughout this time, you have defined standards and procedures that guide the smooth development of further applications in your ecosystem while simultaneously ensuring greater reuse to speed future development efforts. Your Center of Excellence is thriving!
… but somewhere in the dark recesses of your server racks, in the Land of Misfit Apps, there be monsters.
Legacy applications on a given technology, built before the establishment of centralized governance or best practices, built perhaps even as part of a shadow IT effort to prove out the efficacy of the technology, eventually arise as a concern for any organization. After all, they are in production and being used with no sense of decency whatsoever! The class structures are a mess, and they don’t conform to the principles and practices you have defined to ensure consistent delivery execution across the organization.
Many a meeting has passed with a wringing of hands and pulling of hair at this conundrum, but the answer can be sorted out with just a two simple questions.
Is it causing support and maintenance problems?
If the application is a source of consistent maintenance outages or support tickets, then it is already costing you money well above and beyond the initial investment. This means that addressing issues will be best for you in the long term, and in most cases the support team can tackle the most impactful issues with the new principles in hand.
This approach is more of a phased refactoring that will not likely elevate the application to the full potential of its strategic glory, but will at least put in place more of the best practices that help stabilize the environment.
Do you anticipate future development efforts of reasonable size and impact?
This is the big one. If your application is in steady-state and there is not a planned development effort on the horizon of any major scope, nor excessive support issues left unresolved by (1), leave it be. It rarely, if ever, pays to refactor something that isn’t broken, and that is what you would be doing in this case. While your black sheep application may be out of step with the rest of the organization, it’s working and working well.
If there is further, major development, and especially if that development overlaps with the existing functionality, then you can consider a re-write, but do so only with the greatest of caution. You have to be able to recoup most or all of the expense incurred, either through lower support and maintenance costs, accelerated future development, or (hopefully) a combination of both.
Left in the Wake of Excellence
“But it doesn’t conform!!!” you will hear some say, and that’s ok. If the end result won’t justify the cost, then let the numbers do the talking. Sure, some of the early applications will be misaligned with the overall strategy, but if they’re not costing you money then leave them be and acknowledge their differences. If you can answer the above questions in the affirmative, then it is just a question of the scope of change and risk mitigation in future releases/updates.
A robust set of best practices conceived as part of building a successful COE represents a long term effort with a strategic evolutionary focus, and not something you can establish in full overnight. This means any application being built even right now, is one that will more likely than not become non-compliant post-facto as your standards evolve and mature. While it is easy to look at these applications as “less than,” it should be resisted. What they truly represent, in comparison to your current state, is a measure of how far your organization has evolved since that application was built. It is an indicator of progress.
Those applications represent your past. You have grown. Move forward.
Colin Campbell is CEO and Principal Consultant at Stratosphere Technical Consulting, which provides business process management and architectural expertise for Pegasystems applications across a number of industry verticals.
Let us know your name & email and we will get back to you in 1 day to see how we can be of help in your PegaSystems efforts