In this blog, we’re going to scrutinise a potentially complex issue faced by anyone considering a CA Gen modernisation or development project. We’ll look the importance of understanding the many models you may have within a CA Gen encyclopaedia.
So, where do you start?
Your applications may have served you well for years – and they continue to do so. But, if they need integrating with new technologies (e.g. the web) or if you’re carrying out a service orientated re-architecture, healthcheck or upgrade, you’re going to need to know how they work and interact – in great detail.
First – what is the context of your project? What do you want to achieve?
To answer this properly, you need to fully understand the ‘as is’ picture, as well as the ‘to be’ picture. That way, the CA Gen development roadmap can more easily be defined.
That ‘as is’ question is easier asked than answered, but if you COULD answer it, it would be much easier to estimate your project, and plan it, with a greater degree of confidence.
It would also help you to answer complex questions including
- What issues and tasks are involved?
- How many occurrences are there – and for each of those, where precisely in the models can we find them?
- Where, in the CA Gen encyclopaedia are the complexities?
- What are the impacts of the proposed changes?
- How much will they cost me – in time and money?
Sounds complicated; but it needn’t be. There is a solution. Fortunately. (Otherwise this would be a rather short blog post!)
We’ve seen this (literally) hundreds of times – and we agree it’s not easy. So, we decided to develop a way to make it much much simpler. Because we’ve ‘been there, done that’ and know how much of a pain it can be, we decided to try to make life less complicated for ourselves. And the product of that, is Model Analyser – which is part of our Project Phoenix suite of software tools, which is used on CA Gen development projects across the world.
At the risk of slipping into a blatant sales pitch – Model Analyser does exactly ‘what it says on the tin’.
We designed it specifically to answer the types of questions above, quickly and accurately. This means that any risk in the process is minimised, because it allows you to be certain nothing is missed. You can therefore estimate how much effort is involved and therefore what resources are required.
So what does it do and how does it work?
First, Model Analyser produces extracts of CA Gen models (hugely simplifying the complex CA Gen metamodel) – and then give you the output in an easily understandable relational database – in this case, MS Access.
You can load many models a single database – and that means you can run custom queries across either single models or a complete application portfolio.
It doesn’t take a genius to see how this could save weeks (or even months, let’s be honest) of manual analysis which is, of course, prone to errors. The bottom line: you can make considerable savings.
Consider a procedure in CA Gen, where each procedure step potentially has screen items and windows with controls. Model Analyser represents these in a form which any CA Gen user can understand and relate to:
When developing Model Analyser, we wanted to make sure that it could easily produce meaningful reports.
Example of complexity report output
It has an ‘Upgrade Impact Report’ which lets you know how changes between CA Gen versions can potentially impact on your project. There’s also the ‘Complexity Report’. This shows logic units with a set of corresponding complexity indicators – including number of statements (Note statements, Unique USE statements, READ statements – and more).
Armed with this, you’re a significant step closer to identifying where you need to focus your efforts – and where various skills and resources need to be deployed. On top of this, of course, you can also build this output into any future automation to make change happen.
You’re not just constrained to the built in reports. A simple bit of SQL, and – because the database has all the information in a simple form – you can ask your own questions.
Typical questions could be:
• Where have we used the Calendar OCX which now needs upgrading?
• Which action blocks use persistent views?
• Do we use Null Dates anywhere?
…and they regularly crop up before and during IT modernisation and upgrade projects. The answers could potentially have a huge impact on the project. Let’s look at the Null Dates issue. If we have to recode then, it makes a considerable difference if we’ve never used them or if we’ve used them thousands of times.
There’s another bonus here – in the form of a QA tool. The answers to these questions could demonstrate that your in-house development standards have been followed – and that there’s been a consistent approach followed in building the applications.
There’s lots more to Model Analyser than we can squeeze into a blog post – so if there’s anything that we’ve not covered here, please drop us a line.
We’ve put all this into a bitesize video which you can watch on YouTube here – or in our other post.
Don’t forget you can follow us in all the usual places: Twitter, LinkedIn, Facebook, this blog and by signing up for more information on our website.