Summa

Planning for application modernization projects frequently stalls because decision makers are frozen in their tracks by uncertainty around the wide range of options and approaches to replacing, improving, rehab’ing or reusing a legacy system.  Build versus buy; go fast versus  go slow;  good versus cheap; user impact; technologies to use (and not use); level of  reuse of legacy “stuff”;  historical data access; data quality  and IT skills are just a few of the considerations that boggle architecture decisions and confound planners.

Although sometimes dangerous (and aren’t most things that are worthwhile),  metaphors and patterns can help drive the flow of discussion, creativity, collaboration and consensus between IT, business, managers and customers about the feasibility and approach to a project. Outlined below are a collection of patterns that I have used informally to jump start discussions that have led to successful modernization projects. Please jump in and contribute your own thoughts and ideas.

Modernization Architecture Patterns

Architecture patterns listed characterize the approach used to modernize the legacy system. Frequently real projects are a blur and combination of these patterns. (Yes - I expect to get flack  for using “home building” metaphors.)

• Greenfield - this is not actually  a modernization project but a brand new system - perhaps there is an opportunity to reuse documented functional requirements and data models leveraged from its ancestor.
• Brownfield - the architecture and existing implementation of the legacy system is heavily taken into account and may be integrated as the new system is being designed, developed and deployed (more here).  Primary concerns are focused on user and data migration, integration and coexistence - but the resulting architecture is largely free from the reuse of artifacts from the ancestor system (i.e. old code, design, data.)
• Gut rehab - key aspects of the infrastructure, technology and facade are maintained, but significant new design approaches and frameworks may be applied for new UI, business logic etc. Perhaps the design maintains the programming language and database design, but updates the implementation with modern application frameworks, UI components and/or security features.
• Updated utilities - new plumbing and wiring, HVAC etc… For a legacy application, it may be an improved web application server/hosting, database design and connection management, or improved integration capabilities through web services frameworks. Frequently these projects are driven by the need to address key performance, security or integration issues.
• New siding (Application Moderne or “the facelift”) - the design may be a new user interface or the addition of external service integration interfaces (e.g. screen scraping). Sometimes this pattern is refered to as “lipstick on a pig” - where the legacy system is left largely intact, but a shiny new front end is welded on.

Modernization Strategy Patterns

In addition to considering the architecture approach, there are several project strategies that apply to the modernization effort. Like the list above, these strategies may be separate or combined for different aspects of an overall modernization initiative.

• Big Bang - develop the new system in parallel and throw a “big switch” when the new system go-live time arrives- this approach requires that data and user migration occur abruptly - sometimes systems must be run in parallel for a period of time with users keying information into both during the transitional period. Sometimes elaborate heroic “over the weekend” transition plans are required as well.
• Ship of Theseus (Wikipedia) -  replacing the timbers of the ship “as she sails.” Some projects may merit the cost and complexity of a full blown continuous gradual modernization approach. Planning, technology and deployment processes for a  continuous strategy is often more involved than people initially expect.
• Phased Incremental - like “Ship of Theseus” pattern, but performed in more distinct phased releases of incremental functionality sometimes based on technology, business function or organization/department boundaries. In other words planned dry dock time for the ship between phased launches.

Legacy System Anti-Patterns

To drive conversation around the justification for modernization, there are some legacy system anti-patterns to consider for colorful analogies to portray the issues with the legacy systems. Often, large enterprise applications demonstrate all of these anti-patterns at the same time.

• The Money Pit - A system that has very high costs just to keep it (barely?) running - typically evidenced by high support costs, high vendor maintenance costs, low-productivity development and complex (or non-existent) administration tools.
• The Rube Goldberg Dream Machine - A wonderfully overly complicated system that does something simple – its difficult to learn for users or maintainers - often the convolved work of dozens of disconnected (in time and space) developers, maintainers and magicians.  It typically takes staff 6 months to be productive with it and usage is limited by complexity.
• “Third Rail” Systems (”you touch, you die”) - IT staff only touch this system with a 10 foot pole, rubber gloves, hip-waders and a tin-foil hat.
  Sometimes also referred to as “House of Cards” - and nobody even knows where the server is physically located?
• The Boat Anchor - A system that drags everything else down with it…….
• Stonehenge - Ancient monolithic system that some worship, but no longer serves any useful business purpose. Any person who had worked on it went with the last ice age and …. it only “works” a few days a year.

Hopefully some of the ideas here may help you overcome some of the socio-political forces and communication gaps that exist in your organization.

For a more serious treatment of Summa’s approach to application modernization, see our whitepaper.