Tutorials Oracle SOAAPA is only a part of IT approach known as Application Portfolio Management. While APA analysis is critical for any modernization project, APM provides guideposts on how to combine the APA results, business assessment of the applications' strategic value and future needs, and IT infrastructure directions to come up with a long term application portfolio strategy and related technology targets to support it. It is often said that you cannot modernize that which you do not know. With APM, you can effectively manage change within an organization, understand the impact of change, and also manage its compliance.
APM is a constant process, be it part of a modernization project or an organization's portfolio management and change control strategy. All applications are in a constant state of change. During any modernization, things are always in a state of fl ux. In a modernization project, legacy code is changed, new development is done (often in parallel), and data schemas are changed. When looking into APM tool offerings, consider products that can provide facilities to capture these kinds of changes in information and provide an active repository, rather than a static view. Ideally, these tools must adhere to emerging technical standards, like those being pioneered by the OMG.
Rearchitecting is based on the concept that all legacy applications contain invaluable business logic and data relevant to the business, and these assets should be leveraged in the new system, rather than throwing it all out to rebuild from scratch. Since the new modern IT environment elevates a lot of this logic above the code using declarative models supported by BPM tools, ESBs, Business Rules engines, Data integration and access solutions, some of the original technical code can be replaced by these middleware tools to achieve greater agility. The following screenshot shows an example of a system after rearchitecture.
The previous example shows what a system would look like, from a higher level, after rearchitecture. We see that this isn't a simple transformation of one code base to another in a onetoone format. It is also much more than remediation and refactoring of the legacy code to standard java code. It is a system that fully leverages technologies suited for the required task, for example, leveraging Identity Management for security, business rules for core business, and BPEL for process flow.
Thus, rearchitecting focuses on recovering and reassembling the process relevant to business from a legacy application, while eliminating the technologyspecific code. Here, we want to capture the value of the business process that is independent of the legacy code base, and move it into a different paradigm. Rearchitecting is typically used to handle modernizations that involve changes in architecture, such as the introduction of object orientation and processdriven services.
The advantage that rearchitecting has over greenfield development is that rearchitecting recognizes that there is information in the application code and surrounding artifacts (example, DDLs, COPYBOOKS, user training manuals) that is useful as a source for the rearchitecting process, such as application process interaction, data models, and workflow. Rearchitecting will usually go outside the source code of the legacy application to incorporate concepts like workflow and new functionality that were never part of the legacy application. However, it also recognized that this legacy application contains key business rules and processes that need to be harvested and brought forward.
Some of the important considerations for maximizing reuse by extracting business rules from legacy applications as part of a rearchitecture project include:
Eliminate dead code, environmental specifics, resolve mutually exclusive logic.
Identify key input/output data (parameters, screen input, DB and file records, and so on).
Keep in mind many rules outside of code (for example, screen flow described in a training manual.
Populate a data dictionary specific to application/industry context.
Identify and tag rules based on transaction types and key data, policy parameters, key results (output data).
Isolate rules into tracking repository.
Combine automation and human review to track relationships, eliminate redundancies, classify and consolidate, add annotation.
A parallel method of extracting knowledge from legacy applications uses modeling techniques, often based on UML. This method attempts to mine UML artifacts from the application code and related materials, and then create fullfledged models representing the complete application. Key considerations for mining models include:
Convenient code representation helps to quickly filter out technical details.
Allow userselected artifacts to be quickly represented in UML entities.
Allow user to add relationships and annotate the objects to assemble more complete UML model.
Use external information if possible to refine use cases (screen flows) and activity diagrams remember that some actors, flows, and so on may not appear in the code.
Export to XMLbased standard notation to facilitate refinement and forwardreengineering through UMLbased tools.
Modernization with this method leverages the years of investment in the legacy code base, it is much less costly and less risky than starting a new application from ground zero. However, since it does involve change, it does have its risks. As a result, a number of other modernization options have been developed that involve less risk. The next set of modernization option provide a different set of benefits with respect to a fully rearchitected SOA environment. The important thing is that these other techniques allow an organization to break the process of reaching the optimal modernization target into a series of phases that lower the overall risk of modernization for an organization.
In the following figure, we can see that rearchitecture takes a monolithic legacy system and applies technology and process to deliver a highly adaptable modern architecture.
