Jason's Blog on Oracle Modernization Solutions

Hey Folks:
Thought I would post about an event in Sweden coming up that we are doing with HP and Intel as a part of the Application Modernization Initiative (AMI).

The event will be 24 June, and will be in Stockholm, Sweden.

You can find details and the agenda here ->http://hp.se/evenemang/ami

There will be speakers from Oracle (me), Intel, and HP as well as industry analyst,
Phil Murphey.

Hey Folks,
I wanted to make a quick post before Open World LAD begins next week. If you are headed down, drop me a post. There are a lot of modernizations going on in that region, and I'm eager to see about helping keep that momentum.

There are a few partner booths to check out and speaking slots that will focus on legacy modernization. I have one, but don't know the session yet, and will post when i get those details.

Accenture, HP, XSeed all will be there and have done modernization projects...so seek them out!

I see over and over an ongoing debate regarding re-hosting the legacy platform and re-developing re-engineering it. The answer to that question is always, IT DEPENDS. Any of these discussions should not start with an particular approach (SOA Enablment, Rehosting, Re-arch, COTS...etc) but should begin with a business discussion.

So, given that caveat, i want to spend the next few posting to re-architecture and some thoughts behind what it means and how you do it. It isn't a straight rip and replace, or a pure ground up re-write.

What is Re-architecture
In Re-architecture, the strategy is to reverse engineers legacy applications to preserve business knowledge then forward engineers applications to modern architectures which take advantage of open and extensible standards. Characteristics of re-architecture include:
• Application Discovery - Understand applications and develop ‘AS IS’ models using legacy understanding tools.
• Mine and Extract - Mine and extract application business knowledge (business logic / business rules) into a platform independent model.
• Forward Engineer --Forward engineer applications and data to modern architectures using model based design techniques
• Accelerate -- Accelerate application generation for core J2EE application components
• SOA -- Develop and integrate application web services within a service oriented architecture (SOA)
The main point here is that this process is not manual, and it is not fully automated either. With the use of tools and sound process, you can greatly lower the risk, cost and time to market when re-developing legacy applications.
We will dive into these a bit more later in this chapter, and through a step-by-step example later in the book. Re-architecture is distinguished from greenfield development in that engineers utilize the existing application as the specification, and possibly a framework for future development. The promise of this strategy and the strength found in the ability to identify, untangle and isolate legacy business rules for future modeling, enhancement and development. Re-architecture is also distinguished from platform-migration, where tools are used at an automation rate of over 80%. As mentioned earlier, the platform migration method will often deliver code in a new technology (language) but it will
• resemble the legacy paradigm
• is usually unmaintainable
• is a one-to-one transliteration and almost impossible to add enhancements during the migration process.

Drivers and Considerations for Re-architecture
When considering what approach is best for your organization, it is critical to identify what the drivers are for the effort. These can be divided into two general categories of business and technical. We’ll review some common drivers for re-archticture with the objective to help identify when it is a correct choice to take this route. Also, along side mentioning some of the key drivers that make this a good option, we’ll also examine some of the considerations that need to be weighed in light of a re-architecture

Re-Architect starts with learning everything about an existing application (e.g. what it does, how it does it, why it does what it does) and then designing and rewriting the application to take advantage of newer technologies to be more portable, more agile and more scalable. The following are key drivers for a Re-Architect modernization effort.
• Mainframe costs high and continuing to escalate
• Utilization of standard platforms and more off-the-shelf applications
• Positioning applications for next-generation technology
• An IT infrastructure that is easier to manage, maintain and upgrade
• IT continues to increase in criticality to the business
• Current application architecture is not flexible and adaptable
• Reduced total number of applications & platforms
• Implement application changes in days not months
• Major driver is (additional) business functionality
All good IT organizations want to reduce total cost of ownership, increase their ability to react to business demand, and minimize reliance on legacy skill sets – all the while insuring that they are meeting new compliance demands. Forrester reports that 85% of CEO’s view their IT organizations as an inhibitor to innovation. So there is a great drive to allow business to do more than just sustain, but to react. Technology’s promise is innovation, and now it has become like lead boots on a marathon runner.
As we stated above, legacy modernization allows the IT organization to leverage the investment made in core IT applications as a springboard for future development, instead of just throwing it out. We can leverage these legacy assets to deliver a lower TCO business with an increased level of agility, and ultimately an an agent of innovation for the organization.
Of the different modernization options, re-architecture allows for the highest benefits in terms of increased agility, lowest cost and eliminating the reliance on legacy skill sets.

Platform Agility
What do we mean that re-architecture provides the highest benefit in terms of agility, TCO and reliance on legacy skills? To better understand this lets review the modernization options in terms of business benefits. The following chart is a compare and contrast of the Legacy Modernization options and how they impact the business with respect to costs, agility and human resources.

Human factors to consider in a Re-Architecture project
The objective to any successful modernization effort is to add clear business value. Many organizations begin these efforts for the wrong reasons. The force behind any modernization effort should be driven by the business.

The human factor is also a key business issue that needs to be managed properly for a successful modernization project. Some examples to consider include:

Table 1. Business Considerations for Modernizations

How IBM views re-architecture
Much of the messaging put out by IBM around migration and modernization centers around growing the Mainframe footprint. The story centers around application consolidation, open architecture and virtualization. Further, with Z/Linux, organizations can run their Java applications on the same mainframes that they are running their COBOL/CICS and batch applications. Much of the white papers and strategies of IBM on this topic focus on the reliably of the mainframe, the scalability of Linux on the mainframe and the TCO of the Z platform.It is important to note that this book it taking an agnostic view to hardware and address the problems around the pain centered on applications. While we think it is good for some customers to stay on their Z platforms, we are addressing what to do with the legacy applications. If an organization has determined they want to migrate their applications from Z/OS, we want to provide a road map of how to get there independent upon the selection of hardware.

Next Posting: IT/Technical Drivers and Considerations

I was recently visiting a customer in Latin America discussing what a target architecture would look like given that some of the code would migrate over 'as-is' in Cobol, and some new work would be done in Java, while at the same time, the 'new' system would need to integrate with existing mainframe technologies.

This is a combination of both WebLogic (for Java) and Tuxedo (for the rehosted Cobol) as well as our SOA Stack for integration and new Business Processes. Below is an excellent slide that Mark Rakhmilevich recently provided on what this target stack looks like.

You can see in this picture, we have the various layers all built on 11g Grid Technology.
The Oracle technology stack starts with the database grid, which is the cornerstone for data management. The next layer up is Application Infrastructure comprised of Oracle Tuxedo and WebLogic, which are two application platforms in OFM that host business logic – Tuxedo hosts re-hosted COBOL and C/C++ and WebLogic hosts Java for extended services, new components, etc. Both provide high degree of SOA capabilities and integrate with the Oracle SOA Suite technologies shown in the Services Infrastructure layer, and standards-based service networks. These technologies together enable re-host, expose, re-architect, extend, and re-use approach that we've gone over in this blog.

If you need to explore more on Oracle Modernization, you can search this blog or take a look at www.oracle.com/goto/modernization