First I presented an age profile of our applications which showed many of our more strategic systems were over 20 years old. Our more integrated systems are written using the IDMS database and ADSO/COBOL. Our more siloed applications are written using the ADABAS database and the NATURAL language.
The mainframe is costly and inflexible environment. It is hard to find developers who know IDMS and the software vendors don’t provide much support for this database technology any more. It is not as agile as a relational database management system. The same is true for our ADABAS applications. It is difficult to find skills. There is at least more of an upgrade path provided by Software AG to move onto newer technologies.
I presented a slide of a plan that was developed more than 4 year ago. It is illustrated here.
The above slide depicts moving from a mainframe environment to a transition stage consisting of an environment where we have some mainframe applications and some J2EE applications accessing mainframe data. The business logic layer is going to be moved off the mainframe leaving applications accessing mainframe data using SQL adapters. The next step is that we move completely off our legacy databases onto relational databases.
This is still the plan. We have made some progress, but progress is slow.
On the right hand side we had n-tier J2EE applications. Now we hope to target a Services Oriented Architecture. This will give us good integration to other agencies and good integration to national bodies. It will assist us to break up the legacy applications and migrate bits of them to newer technologies. It will assist SAPOL to be more agile in its development of software changes.
There is a flaw in this diagram though. This is meant to be a gradual process. We are not going to rewrite a whole suite of applications quickly. We do not have a big budget to break the back of this work. We do not want to risk a huge project that takes years to implement.
Where is the business logic in the old mainframe environment? It is on the mainframe.
Where is the business logic in the co-existence? It is all in the newer technology (blue) areas. What we are finding is that there is so much we have to move to the newer area before we have our first significant application. The step to the transition stage is too big and too risky.
Version 2 of our transition to legacy is illustrated here. Here we have repeated the transition stage and the new environment stage. There is not much difference in the New Environment stage. Except we have encapsulated our business logic and data access in services.
The main difference in the transition stage s that Business Services that are depicted as sitting on the mainframe.
The hope is that we can feasibly wrap up all the mainframe logic in services and reorganise it in custom written business services and combine it with services already written in the new environment.
We would have to make some compromises about what these services might look like, and this would drive a bottom up process in the lower levels of the architecture. But this means that we gradually move our business services over from mainframe to the new environment without having to write huge amounts of business logic at once.
This is done at present using some custom built techniques that duplicates some of the business logic in the mainframe. This is probably not sustainable for rewriting all of the mainframe business logic. Another solution is to encapsulate with more automation. This can be done according to vendors (Neon and iWay). We can encapsulate our existing green screen forms into services without much fuss according the vendors. In actual fact these service adapters cost an arm and a leg and installation and configuration is agony, but that is a familiar story.
The full quote in the title of this posting is
It is up to us to live up to the legacy that was left for us, and to leave a legacy that is worthy of our children and of future generations.
We look forward to making the most of a legacy environment and providing something better for those that follow us.
Reference:
The above quote is from Christine Gregoire, Governor of Washington State, USA in her Inaugural Address, January 12, 2005
2 comments:
"Another solution is to encapsulate with more automation. This can be done according to vendors (Neon and iWay)... In actual fact these service adapters cost an arm and a leg and installation and configuration is agony, but that is a familiar story."
I have experience with iWay adapters, confess I didn't enjoy it. However for the Natural programs at least, the Software AG EntireX product should allow for fairly straightforward implementations. I work in support for EXX - ask me anything ;-)
Thanks Douglas
We had a look at EntireX some time ago but were not ready to take it on. The time may be approaching when we will need it.
Antony
Post a Comment