Skip to main content

Types of Transformation

Printer-friendly version

There are as many different kinds of transformation projects as there are companies considering them – every project has its own special issues based on the state of the application at the start, the business drivers, and the desired goal. But, we can make some broad categorizations in order to understand something about some broad categories of approach.

Two approaches are characterized by modest, short term investment and focused goals.

Spot Changes: In some cases, the application as a whole may not need transformation, at least not immediately, and one can resort to a sharply focused solution. A spot change will not modernize the application or gain the agility benefits of a modern architecture, but can be a pragmatic, short term solution to an immediate problem. Spot changes are not appropriate for general architectural shifts, but can be used when there is an isolated function needing new capabilities. However, such localized modifications only perpetuate any architectural issues which exist and may even make them worse. One example of a spot change is adding an isolated web services component without moving the application to a message orientation in any other way.

Stepwise Transformation: Alternatively, one can consider one of several types of stepwise transformation in which a general architectural goal is determined and then applied on one problem area at a time, typically beginning with those having the highest ROI benefits, but continuing systematically until much or all of the application has been transformed over a number years. One variation on this approach might involve secondary transformations of selected subsystems when a significant number of the components have received their initial transformation, e.g., stepwise transformation to a Service-Oriented Architecture and then creating a new user interface technology for a subsystem when it is largely converted to services. This approach requires a higher budget commitment than merely continuing with normal maintenance, but as the application is gradually modernized, the maintenance benefits of SOA are gradually realized.

There are two primary strategies for a more complete, short term transformation:

Single Focus Complete Transformation: In this approach, some key element needing transformation is identified and the application undergoes a major rewrite to transform this one area, possibly with secondary attention to other areas. The result can be a substantially altered application, e.g., moving from a character to graphical interface, but the system has not been fully modernized or re-architected since it is basically a component for component transformation. In full modernization, the components of which the application are composed often change significantly from that in legacy applications, not just in internal implementation, but in overall packaging.

Full, Model-based Transformation: Alternatively, there is full model-based transformation in which one extracts business rules from the existing code, supplemented with traditional Object-Oriented Analysis and Design (OOAD) techniques, to create a full OOAD model of the application and then one generates a complete new application from this model using Model-Driven Architecture (MDA) techniques. The result of this transformation is fully modern in all respects and provides a mature, top quality application which can continue to evolve rapidly based on the model driven approach. While it is the most extensive change of any approach, it has the potential for significant efficiencies and leveraging through the use of tools and thus potentially can take less effort and time than a single focus transformation.

Obviously, there are many variations on these basic categories. One might point to a project in which the UI was replaced and separated into its own layer and SOA features were added and ask how can that be considered a Single Focus Transformation. But, in response, one can ask whether the data access layer was also separated, whether the SOA changes were as complete as one would have done with a “from scratch” design, and whether the components are largely equivalent between the two or have been rethought based on modern principles. In most cases, there are still significant compromises in the result of a single focus transformation compared to what one would have produced designing the application today according to modern principles and that is the reason I make the contrast. This compromise is understandable since such transformations can be extremely expensive and each company has to make its choices about what changes are important for its business drivers. But, I also think it is important to recognize that the optimum design has not been achieved.

These four broad categories cover a very wide range of expense and complexity. They also cover a wide range of the degree to which the application becomes transformed from a very local change to near re-invention. Each applies to a particular type of business need and capability and each has a different impact. Thus, one must select a strategy which fits the business drivers, level of need, type of need, budget, available skills, long term goals, and many other factors.

UPCOMING: Next time I will talk about some of the ways in which can choose amongst these options.