How to Deal With Continuous Migration

Today telecommunication companies are scrambling to support many new products and services-and overhaul their billing systems in the process. "Green field" development would be wonderful, but is rarely possible because of the intricate maze of current revenue support systems. On top of that, new changes are required before the previous set of changes have been finished. This situation is leading all carriers to an unexpected development crisis.

Definition of the Problem

No matter what kind of new billing system you are developing, your legacy systems environment will continue to play a key role in your future. A new billing system will always interact with part of your existing legacy environment, no matter how comprehensive your new billing system solution. In addition, some portion of your legacy systems might be an asset you will want to leverage as you transition to the new environment. (Often, legacy system and subsystem reuse actually helps improve your time to market and can reduce your overall costs.)

In this environment, the largest problem you face probably will not be evident at the beginning of your new billing project. The biggest problem is that your billing project is inevitably a large one and will take a long time. During this time, business does not stand still and new requirements arise continuously. Halfway through, you might be redirected to add even more features and functions to your new system. If the project is large, you may be redirected again before you can complete the first redirection. To cope with the increasing acceleration of change, a new strategy is to plan for continuous change and, therefore, continuous migration.

The Architectural Approach

In view of the complex environment you will create with your new systems additions, it is often useful to refer to an old architectural maxim in the construction industry: Always design a thing by considering it in its next larger context-a chair in a room, a room in a house, a house in a development, a development in a city. The implication of this maxim in the billing world is to never design your invoicing system without first understanding in detail your order entry system, your customer care system, your receivables system and your many executive reporting systems. They are all interrelated and mutually constraining. With this in mind, let's consider your dilemma when planning to support a combined set of services that spans multiple areas such as long distance, local, wireless, cable broadcasting and Internet services. After considering the thousands of requirements for your new convergent billing environment, the optimal technical solution to the overall revenue stream architecture usually boils down to something that looks like the illustration in Figure 1. In the ideal architecture, the capture of call records and other business events has an extremely high performance, telemetry-based design. The billing system itself provides for parallel channels of product processing leading to a sophisticated cross-product aggregation scheme. The customer-facing applications all operate from a huge common customer profile. Above all, all products, services, and pricing arrangements are created and referenced through a highly flexible "product catalog." The usual next step after creating the conceptual architectural model of the new environment is to evaluate useful technologies available to meet both the functional requirements of the new system and the architectural technical constraints. The technology evaluation must include not only new developments but also the potential modifications to the legacy systems. Both the legacy systems processes and the data components must be examined because the data might very well be more valuable than some of the code. You must also address many challenges with this implementation besides the complexity of introducing new products. There are tradeoffs between efficiency and flexibility. There are new complexities in maintaining control over the quality and accuracy of your blended offerings. There are many new internal and external interfaces between systems. There are new systems and support infrastructures to put in place. Last, but not least, there is a myriad of internal and external organizational constituencies that must be balanced all along the way.

Enter the Migration Challenge

It is usually at this point that the real dragon begins to emerge. As the technologies are evaluated and the architecture is refined, the emphasis of the project begins to shift to the interfaces required to connect the new system to what was formerly considered the "external" legacy systems. What emerges at this stage is the realization that the legacy systems, in whole or in revised components, are an integral piece of the puzzle.

The typical early temptation for the migration is for a flash cut to the new system. However, the complexity of special arrangements for individual customers or small subsets of customers usually makes the flash cut too formidable to complete at one time. So the plan usually involves converting groups of customers according to function sets ranked from easiest to hardest to implement.

The incremental migration becomes difficult to achieve as the complexity of the data synchronization needs becomes better understood. Invariably, the philosophies of what data values mean can differ greatly, and there may be no easy mapping of one set of data to the others. With half the customers in the old system and the other half in the new, confusion begins to mount.

There is also usually a major synchronization difficulty surrounding the legacy release schedules that may be staggered in a way that defies simplicity of testing and cut-over. You will probably need to form a "super integration" team to deal with the complexities of the subsystem builds and the structured testing during the integration process. This will also help deal with social clashes caused by the meeting of disparate teams, each with different goals and an intense spirit of local optimization. Often, the whole project might need to be reassessed at this point.

The truth is there are both "one-time" conversions of customers to a new environment and the need for continuing interfaces for synchronization purposes over the length of the migration. These synchronization interfaces might need to be in place for a very long time-perhaps even years.

When customers are converted a few at a time, both the legacy and the new systems must run side by side. On a customer basis, you need to know who owns the customer-the legacy system, the new system or both (during parallel testing). This juggling act usually requires that some type of three-state indicator be maintained so that legacy systems, your new system and the plumbing all know who owns the customer today. But do you store this indicator in the legacy systems or the new system?

Even after all customers are converted, some lingering legacy features might need to be synchronized with data in the new systems. The data representations might be different, so mapping rules need to be in place to maintain data integrity. For instance, you might be replacing your billing system and even the companion order entry, but retaining your provisioning system. The language of codes that describes services and features must be preserved so your provisioning system will understand your orders and your billing system will know what has been installed. Yet customer care personnel need to see a consistent picture of what is going on throughout the process. Some artful shadow mapping tables are needed to maintain synchronization.

The Incremental Approach

Michael Brodie and Michael Stonebraker have offered an alternative incremental approach to migration planning in their book, Migrating Legacy Systems-Gateways, Interfaces, and the Incremental Approach. Their generic plan calls for a focus on incrementally analyzing and decomposing the legacy IS structure up front. Their technique is to develop, in parallel, the incremental design of the interfaces, applications and databases of the target system. The target environment is incrementally installed, in parallel, and the necessary gateways are created and installed (more on this later). Then the legacy databases, applications and interfaces are incrementally migrated to the new environment. Finally, the old components are dropped in incremental fashion.

The good thing about the incremental approach is it has a chance of succeeding. The bad thing is that the migration gateways will be in place for a long time-probably longer than anticipated. Gateways that are developed quickly, under the illusion that they are temporary, often have designs that squander system resources. In addition, as business requirements change, further adjustments will need to be made. This is more reason for planning for continuous migration rather than considering it a rare event. The sophistication of the system of gateways turns out to be the key to the dilemma.

If continuous migration is inevitable and the incremental approach is the only one that appears feasible, we need to return to our architectural rendering and reexamine our premises. We need to recast our architecture to account for possibly continuously straddling old and new systems. We need a more graceful way to do this than trying to hide from the interfacing issues.

A more contemporary approach to tackling the eventual migration from a legacy environment to the new environment is to create a rather sophisticated gateway we'll call a "lens" between the customer-facing agents and the dual information processing environments.

This gateway allows more gradual migration of the data and system components from the old to the new. In addition, the gateway turns out to be much more useful than just a migration tool.

The "lens" Gateway Strategy

The lens is really a transaction processing mediation mechanism between the old and new environments. For performance reasons, it maintains its own copy of the combined product/service profiles and the customer profiles. It can use its own data storage structures and take advantage of the newest technologies even when the legacy and new systems cannot. It offers opportunities for workflow automation that might be beyond the scope of the old or the new order processing and provisioning systems. Some of those who have employed the lens technique found it makes the existing legacy data more valuable. It works alongside current relational databases and maintains the shadow data mapping. It can be optimized for high performance and can provide excellent navigation across market segments. It is also a good place to maintain the three-state migration indicator discussed earlier (so that both the legacy and the new environments know who owns the customer).

The lens gateway tends to reduce the number of interface combinations. It can provide an incremental integration of new schemas even when maintaining a master data dictionary proves difficult. Finally, some who have used this technique found it provides an easier implementation of Internet-enabled applications because the data is separated from the legacy systems.

Implementation of the Lens Gateway

Due to the nature of implementing a gateway between a new system and the usual complex of legacy systems as a single event, you may not have found a implementation of the lens concept in a product form. Each situation seems to have unique requirements.

You should consider many requirements for the lens during the design process:
Scalability. The lens must not only be able to accommodate your normal growth, but must also allow for the possibilities of mergers and other types of rapid growth acquisitions.
Multi-system restart/recovery. The gateway itself must participate in a complex scheme for backup and recovery that synchronizes with both the legacy environment and the new environment.
Consolidated customer profile. The lens must house the OLTP version of your consolidated customer profile to simplify the navigation to all customer data, both new and old.
Consolidated product and service catalog. This database must support the important definitions and distinctions between your products and services.
Workflow management subsystem. This mechanism manages lists of things to do and the rules subsystem that oversees the customer facing environment.
Multi-product balancing controls. This mechanism assures that the data that flows through the lens is accurate and irrefutable.
Continuous schema evolution. Choose database technology that allows for continuous schema evolution. Regression testing environment. A mechanism for automatic regression testing changes made to the overall complex is essential. The complexity of the emerging information processing environment will defy any attempt for "manual" testing of changes.

Summary Recommendations

The migration process for a large operation can appear daunting. Here are some tips to assist with your planning.
• Always be requirements driven. Initially create an overall architecture to maintain the proper context and include the legacy components in your technology evaluation. Your expanded architecture should include your migration apparatus. Consider implementing the lens technique between your legacy and new environments.
• Consider using parallel processing operations to assure scalability. Review your restart/recovery and auditing systems in the context of multi-product integration.
• Include your legacy systems developers as critical members of your team. Above all else, plan for the legacy integration to be about 50 to 70 percent of your overall development costs.

10 challenges that Can Affect the Migration Process

Here are not-so-obvious events that may occur during the billing and/or customer acquisition process while going through the migration process:
1. New changes will be demanded before you can finish the previous set of changes. This can prevent you from ever going into production.
2. Over time, multiple distinct teams maintain different systems. An integrated system requires human communication and incentive systems that are rarely already in place. A synchronized integration schedule does not happen by accident. This usually results in reorganization.
3. Conversion of customers is usually incremental. The real architecture is not that of the new system alone. It's the entire environment and it's for a long time. Develop for efficiency, scalability and supportability or for years to come you will be infamous for squandering system resources.
4. Data mapping from an old system to a new system is rarely one-for-one. This will lead to significant changes to your new system and possibly even policy changes concerning your services.
5. You will find that calling the current system a legacy system (also known as the "bad" system) will generate alarming hostility and factionalism among half of your integrated team.
6. Your demand for data interpretation may be greater than your new system can provide during the elongated migration process. Your so-called gateways may become a permanent piece of your information solution.
7. Unless you have a universal point of reference for who "owns" a customer (legacy or new system), you will drown in an endless series of squabbles about how to process.
8. You may need to exercise new types of technology for data schema evolution for your customer and product profiles so you can keep up with your customer care and management and marketing needs during continuous migration.
9. Restart/recovery techniques only work if all of the dependencies are considered. You must consider the entire environment, both from process and financial control standpoints, in your continuous migration scheme.
10. Your workflow management systems are loaded with state transition dependencies that have hidden effects on your customer records and consequently your billing systems' accuracy. You need to consider them carefully in designing your recovery techniques.

John Reynolds is President of Integrated Architectures, Inc., a project-oriented technical consulting firm, for the telecom industry. He can be reached at 508-634-3200, Ex. 201.