North American manufacturers have faced years of intense, globalized competition. This onslaught compelled them to modernize their manufacturing processes to compete effectively. The result has been that many plants have become models of efficiency and agility. This modernization allowed manufacturers to more quickly adjust production to address shifts in demand and business goals.
This drive toward modernization was built on information. The cost, risk and value of aging machinery were evaluated to determine whether it should be retained or replaced with more modern equipment. In many cases, aging — but still productive — machinery operates in conjunction with state-of-the-art equipment. After all, what matters is whether the machine is operating as expected and as efficiently as is required by the business.
Similarly, manufacturing processes were assessed to determine where unnecessary or nonstandard steps could be eliminated to minimize dependencies between steps. Adjusted processes were put into place, integrating existing and new machinery with better formulated production plans. All the while, rigorous measurements were established to identify flaws in processes and machinery to drive further efficiencies.
Not only manufacturers, but all industries face a related opportunity. A key part of “production” for, say, a bank, is its ability to process interest payments, balance transfers and other financial transactions. The “factory” that processes these transactions is a network of sophisticated applications. The bank — or insurer or any major organization — must modernize these factories to ensure that it can rapidly adapt to address new business goals with low cost and risk.
How Do You Choose a Modernization Path?
Modernization for the manufacturer required information. For instance, how manufacturing processes could be improved and where machinery should be replaced. Our bank must also start from a position of understanding. It must determine the structure and behavior of its application portfolio and how it can be made to support the priorities of the business.
As outlined in previous articles, understanding requires both technical analysis of the application portfolio (e.g., which programs relate to which data stores) and the ability to view applications through a business lens. By overlaying business groupings, like business process, geography, service provider, IT initiative or other context onto our applications, we can understand how these systems are architected from a business perspective.
For instance, we will want to understand how the order management system depends on the product catalog and client management systems. Or perhaps we will want to understand how software managed by one development team connects to that managed by a separate team. Minimizing dependencies between logical groupings can be a smart modernization strategy to lower risks and communication challenges. This understanding can also have a significant impact on the modernization path that we select.
By linking these logical groupings with your organization’s key performance indicators, we also gain a valuable tool for modernization. If our bank values the availability of its currency trading system, then measures of its risk and uptime will matter. If the CIO is concerned about adaptability, then comparisons of its complexity and software quality against standards will be relevant.
For instance, we may see that a highly customized application automates a proprietary investment banking process. The value of the system and its frequency of change may lead us to incrementally modernize it. While a core banking application that changes infrequently and has a commoditized set of functionality may be a candidate for replacement with a packaged application.
Managers can better determine modernization priorities through application portfolio management dashboards that present these cost, value and risk trends.
What are the Modernization Alternatives?
There are many modernization options available to a CIO. Now that we have determined what the priority areas are within our portfolio, we need to determine the path to modernization. Choosing the right path will depend on factors like cost and risk of modernization, available skills and future plans for technology environment. Here are several of the primary options:
- Incremental rearchitecting to service-oriented architecture.
The applications that run your business contain highly customized logic. This logic represents years of adapting business processes to new requirements. Reusing this logic, leveraging it as a service or integrating it with other applications are ways to leverage its value. This strategy is particularly compelling, as it can be performed in stages with relatively little risk to the stability of the application portfolio. Once understood, the logic can even be leveraged in an SOA/BPM (business process management) platform.
However, it requires that existing logic can be located, understood and isolated into fine-grained, reusable components. Relying on subject matter experts and documentation is very beneficial. However, too often expertise and documentation is missing or incomplete. Looking at how the applications themselves behave provides a solid foundation for understanding the true logic of a business process. There are technologies and methods on the market to speed this activity.
In parallel, organizations may opt to rearchitect other aspects of their systems. This is because applications’ architectural layering and structure tends to erode under the pressure of frequent changes.
To correct these issues, we need to apply our “ideal” architecture against the actual architecture of our applications. Determining where our software has diverged from this ideal architecture allows us to determine how we should adjust our systems.
This requires that we understand how our software is architected from multiple angles — for instance, from a geographic, business process, or user interface/logic/data access view. We can then rearchitect to improve adaptability and reduce risky dependencies.
- Redevelopment of applications.
Some businesses may choose to redevelop an application into an environment that is more flexible or more in line with corporate standards. However, it is imperative that how the business operates is not lost in the transition. Too often, redevelopment activities rely on outdated or incomplete requirements. This can lead to applications — and the business processes that they automate — that do not behave as expected.
To confront this risk, it is important to locate and understand the business rules and processes that reside within existing applications. By mining this logic out of a system, especially within the appropriate business context, organizations gain control over how their applications run their business. This understanding provides the foundation for creating functional specifications that guide the structure and behavior of the redeveloped application.
- Packaged application replacement.
Alternatively, a business may replace an application with commercial off-the-shelf technology, like an ERP (enterprise resource planning) package. This may require understanding integration points between the package and the rest of the application portfolio. That is, to understand where our other software consumes inputs or provides outputs to the package. Without a solid understanding of the boundaries of our portfolio, we could disrupt our existing processes.
A further consideration for packaged application replacement is to understand the gaps between our current or ideal state and the standard function of the package. This involves mapping our existing business logic and determining what will need to be adjusted within the package to provide the functionality we expect.
- Outsourcing and divestiture.
When a particular system no longer fulfills a core business need, or managing it can be achieved more efficiently by a skilled third party, divestiture may be an option. This could involve retiring an application wholesale, or moving its management to an outsourcer. We likely will come to this conclusion during the application portfolio management stage, as we compare the value of a system with its inherent costs and risks.
However, application portfolios are highly interconnected. One system may rely on inputs from another, often in unexpected ways that are seldom accounted for. As a result, the organization must ensure that the logical boundaries of the targeted application are understood.
This activity traces impacts between the group of software assets and other entities. If we group our software into logical units, as discussed above, these linkages will become instantly apparent. This provides a to-do list for the development team to tie off loose ends before divestiture unintentionally breaks other systems.
- Refinement for continuous improvement.
Modernization can also take the form of improving software quality. Over time, software tends to lose its adherence to coding standards as time pressures escalate, complexity levels rise and dead code enters into systems. To eliminate software quality issues that cause complexity, we look for artifacts that don’t adhere to our requirements. Querying technologies exist that can inspect software to locate constructs of interest, such as security threats, dead code or inefficiencies.
A valuable twist is to locate violations of standards based on the business groupings that we defined. For instance, how data is handled may be especially critical in software that has been grouped into, say, the secure area content. Once we have identified these weaknesses, we can eliminate them from our applications.
Continually Assess Application Portfolios
Modernization is fundamentally about returning applications to best support the needs of the business. This requires that we locate which systems are most misaligned with our key performance indicators, and prioritize realignment activities based on their value to the company. If software no longer serves a key need for the business, then replacement or divestiture should be considered. Much as a manufacturer may shed unnecessary or inefficient steps.
For those systems that are deemed core and should be retained, modernization must play another role. We must take advantage of the business value that has been embedded within these systems. This may involve isolating and reusing logic in an SOA, or a newly developed or packaged application. It could be by eliminating inefficient architectures and code that have led to inflexible and risky applications. This is like our manufacturer assessing how the production process currently is, comparing it to the ideal, and making adaptations to improve agility.
Lastly, modernization is not a “one-off” activity. We must continually assess our application portfolio to locate trends that are eroding its ability to support the business. New priorities for modernization will emerge, and we should be ready to allocate resources accordingly.
Charles Dickerson is senior vice president at Relativity Technologies, a provider of enterprise application modernization solutions. He has 20 years of product marketing and product management experience in the software industry.
Loading ...
I think I saw a writing from you on other website (ZDNet I think) as well on the same subject. This one is better than the other one.
I have also put together some thoughts on the subject. Please feel free to comment.
http://hubpages.com/hub/Application-Rationalization–Modernization-Strategies-for-Investment-Bank-IT-Division
Anusheel