Lightweight Architectural Design Process (LADP) Phase 2

This article covers stage 2 of the Lightweight Architectural Design Process; the present system and constraints (the as is phase).

The IT manager continued on from the business overview with the Sysop (Systems Operator) and Sysprog (System Programmer) providing detailed information about the present systems and the ideas about the future systems.

The key element at this stage is to delve into just sufficient detail to understand what the detailed technical issues might be but no more. If too much detail is exposed then everyone gets swamped; if too little then vital problem areas may be overlooked. This is where a good architect will know where to drill down and where to gloss over in safety. So for example transactions and locking always should be looked at in some detail to ensure that there is the minimum impedance mismatch between systems. Similarly key generation and security are areas that should be understood. This is not a comprehensive list and indeed the specific areas will change from system to system.

So in the example system all the present business functionality was running as CICS Cobol on an IBM mainframe which was outsourced for operations. All the functionality except the pricing element had been implemented using an automatic CICS Cobol generator (Visual Age). All the data was held on a DB2 database which was being used simply for data storage (e.g. no sp’s). The applications and data structures had been ported 10 years before from a hierarchical VSAM database and so the schemas and structures were not relational and fairly convoluted. The pricing system was implemented in CICS / Cobol which had been hand written with a linked style using the COMMAREA.

There were some additional systems that the business wanted to be able to interface in the future which were asp based applications running on SQL Server and Oracle.

The business were not comfortable with a complete rewrite of all the applications in one go so a migration strategy starting with the contract bidding system and then moving on to the contract management system was the proposed approach.

So far so good. Normally I recommend interfacing to a system at the highest (transactional level) and applications written in a CICS linked style can be connected to easily using COMTI. However in this case the use of Visual Age was a concern. Whilst Visual Age does generate linked style applications the code generated is very unmanageable and difficult to follow (ok, so hideous!). Additionally it was not clear that rerunning the generator would provide the same COMMAREA format. Further investigation was required and so we retired to a 3270 emulator to call up some of the code modules. Superficial examination convinced everyone that we should not touch the COMMAREA and so an alternative separation and integration strategy was required.

An alternative for integration is at the data layer and it appeared as if this application could be safely split at the database; alas the schema for the database was long lost (if it ever existed) and looking at the table structures was little help. The mainframe DBA was called into the meeting and the various application screens for the contract bidding and management systems were run through. It transpired that the database was implemented as a single set of tables for both the contract bidding and management systems however there was a single flag in the row which differentiated which system the data was being used by.

 

The trick with splitting databases is to realise that you have multiple different tables with different uses and whilst this can make the task look very difficult there are typically two main uses of the tables, reference data and core data. The reference data can be snapshotted and loaded across as a trickle or batch feed very simply by SQL Server (even against a mainframe DB2 database) so the only tables that have to be examined in detail are the transactional ones. Typically there are not many of these and in this application, due to the rather tortuous history of the database, there were only two that had to be copied over and managed. A look at the schema of these two tables soon convinced us all that it would be possible to split off a contract management and a contract bidding version of the database very easily. This approach had the added advantage that it would be easy to move the management system across in the future. The downside was that were propagating the rather unpleasant database format for the future, still life isn’t perfect either!

 

We also had a quick demonstration of the system from the user’s point of view and mapped and discussed out a few key use cases and activity diagrams, focusing in on the areas where the business needed to change things. This was in things like Euro support and some bid management functionality. We also had a quick overview of the things that the business did not use in the present application and so should be removed.

The only other area of concern was security and in particular single sign on. Investigation showed that the customer had a Windows active Directory based system with a RACF implementation on the mainframe. There are a number of solutions for this scenario so that needed no further investigation.

So we now had a good understanding of the present systems and application and the detailed interface points and use cases. On to stage 3.