Modernizing Application Modernization

The transformation to a digital business is causing many organizations to place a higher priority on modernizing legacy applications and replacing outdated packages with modern, adaptable solutions. Many organizations are faced with a difficult dilemma – how to modernize legacy applications that run the business when 75% of available funds are devoted to keeping these systems running and the processing they provide cannot be interrupted. In the past it was common to see modernization efforts take a back seat due to insufficient funds or lack of priority. Or, the efforts failed because the task was so complex that costs escalated uncontrollably. However, organizations are now finding that the legacy maintenance and enhancement cycle is not able to keep up with the pace of changes they face – be they from regulatory mandates or market pressures.  And, when combined with digital business pressures, modernization becomes a critical business need. 

IT organizations are now looking for ways to roll out new business capabilities to their customers and stakeholders that leverage the data embedded in the legacy systems.  However, these are hardened, mission-critical systems that provide the core processing for the business – and are resistant to change. As a result, they are recognizing that they will have to retire them and replace them with much more flexible IT capabilities.  The caveat is that this must be done in a manner that does not jeopardize the daily business operations the systems support.  

Too often, modernization has meant wholesale replacement via a lengthy, expensive and disruptive “big-bang approach which failed to meet expectations.  Today’s modernization approach is radically different from conventional application modernization which replicates yesterday’s architecture in a new technology. Today’s best practice:

·        Modularizes the functionality and delivers a set of services that map directly to the business model

·        Separates business rules from code

·        Uses enterprise-level Agile and Lean practices that allow rapid delivery and continuous improvement

·        Uses a factory framework that standardizes all nonfunctional and common code in a design platform that radically improves cost, quality and delivery time

·        Deploys as a series of incremental releases that may be vertical slices (areas of functionality) or horizontal slices (end to end processes for specific types of processing, such as application types, claim types, financial transaction types, etc.).  

Rather than converting code (where the resulting codebase represents the same tangled mess in another language), the approach replaces the legacy application with a layered, modularized architecture based on the principles of Service Oriented Architecture (SOA). In the past few years SOA has become the default architecture for modern applications to support the need for flexibility and continuous integration/deployment.

To achieve this, legacy applications must be understood from the perspective of the business and technical capabilities they provide.  Business rules must be harvested from legacy applications (or new ones derived where the requirements have changed).  Transition planning must define release points that include existing functionality (e.g., wrapped transactions) as well as new services.  During the transition, legacy interfaces must be preserved or replaced to maintain operational continuity.  Ultimately, the modernized application should reflect modern IT best practices and patterns, such as maximizing the configurability of the system via parameters (moving change points out of the code) where flexibility is desired.  Examples of these best practices include the implementation of software services, business rule management (rules engines) and business process management (BPM) tools. 

Everware-CBDI’s Service Oriented Application Modernization (SOAM™) methodology is a comprehensive approach that combines multiple leading edge, but proven, techniques to deliver flexible modernization.  Key features include: incremental evolution of capabilities, modular architectures to limit the impact of change, and separation of infrastructure platform and data stores from functional code so that each may evolve independent of the other. We combine the modularity of SOA and the rapid development and stakeholder feedback from agile development with automated techniques to efficiently produce, test, and deploy code. We have developed an end to end process that minimizes the gap between when business requirements are identified and when the functionality is deployed into production.  A key component of our approach is our project-configurable Agile Service Factory (ASF) which standardizes and accelerates the task of specifying services and automates the transformation of those specifications into fully-open, industry-standard code targeting popular platforms and frameworks.  Combining this with a DevOps capability closes the loop in rapidly delivering needed functionality.

The result of this approach for application modernization is the ability to incrementally modernize legacy systems that is rapid, priority based, and lower risk.  Ultimately, this approach enables the IT organization to move from a maintenance focus to continuous modernization.

Architecture Owned Code

Much has been made of the rift between agile developers and IT architects, especially enterprise architects.  Agile development has turned the solution implementation world on its head, eschewing traditional architecture and all other attempts to define things in advance.  But the agile world has evolved to the point where an architectural foundation is recognized as necessary to implement agile on a large scale.  Without architecture to hold things together, you may well have a dozen agile teams moving in completely divergent directions – rather than building a cohesive product.  But this doesn’t take us back to the world of big design up front (BDUF) – architecture has to evolve as well.  The key is to develop the architecture in parallel with the agile development.  Very much like agile planning (where you create a high level plan, but only produce detailed plans for the next increments – on a rolling basis), agile architecture starts with a high level superstructure and detail is added as needed to support the agile teams.  Architecture decisions are pushed down and deferred until as late as possible – so that refactoring is minimized when decisions are modified.

In years past, architecture provided guidelines and directives (often in the form of a reference architecture) and developers either complied or they didn’t.  Governance was applied after the fact – certifying that a product was in compliance with the architecture (what a surprise – it almost always was!).  This, of course, led to architectural anarchy and situations where organizations found that they had more than one of everything (from platforms to coding styles) and many of some things (security implementations, for example).  This situation of maintaining multiple platforms, redundant applications, and poorly documented code has led to the high percentage of the IT budget being devoted to O&M, rather than new development to address new business requirements. 

So, what does this have to do with Architecture Owned Code (AOC), you might ask?  Well, at Everware-CBDI we have developed an approach that supports agile development at scale.  A component of the approach takes all of the aspects that you want to have consistent across the enterprise (such as deployment details, authentication, error handling, auditing, data access, messaging, common business APIs, etc.), creates models to capture these aspects and other design patterns to be applied across the board, and generates the code for this “common platform” that is  provided to the development teams to build upon. While this may include many low-level, utility services, it can also include access to common business services and COTS APIs, such as for credit processing or document management. Providing AOC automates governance and flips the perception of architecture as an inhibitor of development to an enabler of development.  We have found that most development teams accept this readily, because it lets them focus on solving the business problem rather than being blocked by wrestling with the intricacies of the technical platform.  The AOC base grows and is refactored as required by parallel agile architecture development teams. 

The result is that development proceeds much faster because the agile teams are able to leverage this common Enterprise-specific platform in much the same way they leverage provided APIs in many current products, frameworks and languages.  This approach has many other benefits as well.  For instance, the AOC is of higher quality than hand-produced code, is consistent across all development teams, and is able to more easily be modified or refactored.  As a result, the tendency of the code base to become more brittle as it grows is fundamentally reduced.  In addition, the refactoring exercises can be essentially invisible to the agile developers – performed in an architecture sprint, regenerated, and provided to the teams.   

Architecture Owned Code has the potential to revolutionize application development and fully enable agile development – at the enterprise scale.  To learn more about this new approach, please contact us.

Agile Estimation: Are We Asking the Right Question?

August, 2013 

 

There seems to be considerable debate and confusion surrounding the concept of estimation as applied in the agile world.  Many appear to argue that estimation has no meaning outside of the agile team, but sponsors and stakeholders need something to base their decisions on and estimation is a key component of it.  Perhaps we need to reengineer our definitions and objectives at the higher level. 

Typically, management wants to know how much X will cost and how long it will take to deliver before making the investment; where X is some bundle of deployed functionality with an associated business value.  Not an unreasonable request in a traditional environment where the application is the focus of attention. The investment decision is how much greater is the value than the cost (the ROI). Unfortunately, the estimation process is subject to considerable uncertainty prior to the initial stages of architecture and design (the uncertainty decreases with subsequent stages but does not reach zero until completion and deployment – and then the estimation of the O&M stage begins) – not a good foundation to base investment decisions on.  

If we change our focus from applications to delivering business capabilities and adopt an agile development process, the concept of estimation changes as well.  For example, in traditional (stovepiped) development much of the development is actually producing redundant functionality (in terms of delivering business and technical capabilities), but this is obscured by the focus on the app.  For example, all apps provide error handling and audit logging as well as security (authentication and authorization) – how many times have these been (re)developed?  The same applies to business-related capabilities.  If we can take a broad view of the capabilities required and identify sources for providing them, much of the development may be avoided altogether.  This, of course, is the benefit from adopting a SOA approach.  If we adopt an agile development methods and establish an agile team with an associated cadence, the estimation question should be something more like: how much value can we produce in a given amount of time?   Given that the team has a cost for a given period of time (say, a year), and each delivered business capability has a known value, we can still make investment decisions – what is the net value produced from the investment cost.  

Economics would say you should invest up to the point where the marginal value derived equals the marginal cost of producing the next increment of functionality (stories, capabilities).  From this increments perspective, we should expect the marginal value to be decreasing – because we are developing from the product backlog in order of priority – so we build the highest valued items first.  Marginal cost should be flat or decreasing as well – the cost of the team may be constant, but the cost of producing the next item may go down as we build up and consume more (pre-existing) shared services.   

So, the investment decision changes from: is it worth building this app?  to is it worth funding this agile development team for a year?  This approach can be applied to determine how big the team should be and even how many teams should we engage.  The value delivered should be maximized because the most valuable capabilities are delivered first (along with the capabilities they are dependent on).  This should hold even if the priorities change because the product backlog embodies those priorities.