Don't forget to see the entry about Open World in Latin America!
So we pick up with Part Two...Mainframe Legacy Re-Architecture...and some of the technical considerations of this.
IT/Technical Drivers and Considerations
When the business considers re-architecting their entire platform there are a common set of drivers that are behind many, if not all modernization projects. Earlier in the book we’ve examined a few of the modernization options like SOA enablement and platform modernization. With the rearchitecture strategy, there are some key technical drivers that we are trying to accomplish that are unique to this method. Below, we will examine a few of those areas.
Get off the mainframe
There is a large push by organizations to get off the mainframe. This push is more often than not a function actual application that is running on the mainframe instead of the lack of ability in the hardware itself. As we observed previously, the IBM Z platform can run any open system technology that organizations are able deploy on a given white box Unix/Linux system.
The problem exists when confronted with the COBOL (or other legacy code base) applications. The architects and trusted advisors of the target architectures do not have knowledge or experience in the legacy mainframe environment. Combine the cultural shift with with the high costs of mainframe hardware, operating system and third party applications for things like tape management, monitoring and integration, one can see why this trend is continuing in many sectors. If an organization fully eliminates the need for Z/OS by creating a new architecture built upon say a J2EE architecture, it is much easier to find system admins who can run non-mainframe system, and if there are no more legacy applications that need to be maintained, then a build-out approach usually generates the lower TCO.
One of the main hindrances to leaving the mainframe up until this point has been one of Quality of Server. Traditionally, nothing could compare to the reliability and throughput of the mainframe. However, times have now changed. From the perspective of availability and reliability, products like Oracle’s Real Application Clusters can provide the availability off the mainframe across the computing grid. So, now with the off-mainframe option being able to deliver mainframe quality of service, we are seeing a larger push for this path.
Another push to get off the mainframe is when the organization faces a “burning-platform” situation. The mainframe system they are running is out of support, or coming off support in the near future. So, now we are again confronted with the actual problem of how to migrate off the platform.
Create a flexible, adaptable and 100% agile architecture
The idea of re-architecture implies that the system will be totally different from the original. Just as ain any ground up development effort, here we are looking to leverage the latest in technologies and development frameworks. The objective here isn’t to refactor, or remediate the legacy code and redeploy it in a polished up mode, but rather totally change the make up of the entire system. The only resemblance of the original is that we’ve leveraged the original business rules (that we desires) as well as legacy data, which has also probably been restructured as well.
The point here is the a modernization effort that is only doing a refactoring of legacy structure, but not leverage any new technologies or delivery platforms is probably not a true re-architecture. For example, let’s thing about an average Cobol program. Say this program is 50,000 lines long, does some data interaction, screen inputs, program calls and cleanup. It also probably contains some dead code, and code that was not very well written. The idea leveraging new technologies, would take this beyond transforming this simply into Java. I would even argue, that cleaning up the dead code, and abstracting data an screen logic isn’t enough. A true re-architecutre will examine the function of this code base. Determine things like if it is doing event orchestration, or business rule execution. If so, it would probably not be a good candidate for POJO (Plane Old Java), but rather BPEL, ESB’s or a business rule engine.
Advanced Development Tools
With the recent push of the open systems movement, there are a plethora of tools to enable organizations to develop and maintain applications. Users can take advantage of free IDE’s, open standard execution languages like BPEL and modeling languages like UML. With the pervasive and growing culture of open standards, this given the organization more choices. With choices comes competition of products and ideas. So, now, instead of only have one language, one set of tools and one cost model, we can utilize the growing and more efficient universe of Open Systems. Of course, it isn’t more efficient and cheaper by definition. We do need to apply thought and intelligence in how we choose to deploy. This is one of the compelling reasons for Re-architecture. We can now leverage a host of tools, environments and standards to take our legacy assets foreword into the futures.
Next Stop...REHOST vs RE-ARCH
