CA Gen to Java: Benchmark confirms Jumar quality

One of the most frequently asked questions when discussing our automated migration of CA Gen to languages like Java and COBOL is: “how maintainable is the migrated code?”

assessmentWe’re now able to demonstrate this with an ‘A’ rating for software quality in an independent benchmark test.

Our philosophy towards migrating CA Gen portfolios (in all or in part) to other technologies is that the delivered code should be…

  • functionally equivalent to the original
  • free from any CA Gen dependency
  • performant
  • hand-maintainable

Recently, as part of a CA Gen to Java migration programme, this was put to the test when Jumar’s client commissioned a SQALE assessment of the code produced by Jumar MAPS – our world-class suite of automated CA Gen transformation software.

Impressively, the code attained an overall rating of ‘A’, raking it in the highest category for maintainability, efficiency, usability and other characteristics.

There’s more detail here – and you can find out more about SQALE by visiting our website.

However, there’s no substitute for seeing this for yourself. To arrange a demonstration of how our generated code is higher quality and more maintainable than hand-written code, please contact us, and we’ll arrange a demo.


Jumar news: New partnership with Fujitsu

We’re really proud to announce our latest partnership.  We’ve teamed up with Fujitsu to complement their Legacy Modernisation services with our specialist experience in CA Gen.

All the details are in our press release here…

NEWS RELEASE: CA Gen modernisation offering expands with partnership between Jumar and Fujitsu

Fujitsu logoUsers of the enterprise-level software development platform CA Gen are to benefit from a new global partnership between technology specialist Jumar Solutions and leading system integrator, Fujitsu.

Jumar has today announced the alliance, which will allow its specialist modernisation and migration services to be seamlessly integrated into projects across Fujitsu’s portfolio of international clients.

CA Gen has been used widely since the 1980s to develop and maintain strategic, mission-critical applications in large organisations.

The new partnership combines Fujitsu’s expertise in legacy modernisation with Jumar’s specific skills in CA Gen supported by its unique suite of automated software.

The use of automation can accelerate modernisation projects by up to six times, while saving end-users millions of pounds over the equivalent project conducted manually.

Jumar’s automated tooling can also significantly enhance the migration of an organisation’s CA Gen estate to newer technologies, by adding repeatability, accuracy and predictability while reducing risk and cost.

The partnership with Fujitsu allows CA Gen-using organisations to fully explore the options available to them through Fujitsu’s Application Value Assessment (AVA) programme. The AVA analyses every aspect of the applications from entire portfolios, down to single applications. This is complemented yet further with Jumar’s CA Gen model assessment software which provides specific insights into the CA Gen elements of a modernisation exercise.

Jumar’s Managing Director, Wendy Merricks, welcomes the news saying “We have a long history of working with Fujitsu in this space, and it’s fantastic that we now have a formal partnership with which we can expand the reach of our specialist services to Fujitsu’s clients.

Our expertise in CA Gen is probably the most extensive of any service provider anywhere, and coupled with Fujitsu’s track record in Legacy Modernisation, we are confident that we will significantly enhance any organisation’s CA Gen related project.

Whether they are committed to the platform, and want to continue developing and maintaining their applications within CA Gen, or have taken the strategic decision to migrate away from the technology, together we can deliver a world-class, robust solution.

Join us at the watercooler. The CA Gen community is here.


The watercooler – the place to be

Picture the scene.  The watercooler in the corner of our CA Gen development centre bubbles away, as four or five of our team members take a break from their development work – coincidentally all at the same time.

The topic turns from Christmas shopping to last night’s “I’m a celebrity…” (for those outside the UK, this is a TV show, you’re probably glad you’ve never heard of).

A few more people join this ‘watercooler moment’ and – as you’d expect – the topic of discussion changes again.  One of the team members reveals they have had a ‘eureka moment’ with a CA Gen modernisation project.  The conversation then becomes frenzied and work-related, with all discussions about Christmas shopping forgotten.  This has become a classic ‘watercooler moment’ and shows just how valuable these informal work get-togethers can be.  Everyone gets back to their desk, encouraged by the fact that someone has achieved something above and beyond their normal remit, and given the customer much more than they’d expected.

pouring a glass of water

More than just water. The watercooler is the hub for office banter.

This happens everyday in companies across the world  – so why are we obsessing about it here?  Well, during our most recent ‘watercooler moment’, the conversation inevitably turned to the topic of the CA Gen community.  It’s a phrase used widely – and, as you’d expect from such a legacy system, very affectionately.  Which started us thinking; if we could get the entire CA Gen community around our watercooler, what would everyone talk about.  The need for more cups, obviously, but it became the subject of a heated debate.

With no consistent agreement on the big subjects, we decided to find out – in the only obvious way. We’d ask.

So, if CA Gen forms a part of your remit (no matter how small), we’d like to invite you to our virtual watercooler for a a brief chat.  (It’ll only take you a few minutes, and it involved nothing more than clicking a few buttons – certainly with no typing required!


Get involved…

Join us at the watercooler here 

and take our quick three minute survey.


We’ll publish the results (but not individual replies) in a forthcoming blog – so we’d really appreciate you taking the time to participate.

Thanks in advance for taking a brief break from the grind of daily life.  There’s nothing like a break at a watercooler for helping you to recharge!

If you’d like more information about our CA Gen modernisation services, please contact us.

CA Gen model corruptions: deal with them now before they halt your project

JJ for blog

Jeff Johns: Principal Consultant

This month, Jeff Johns tackles errors and corruptions in CA Gen models, and looks at how they can be identified and fixed.

The vast majority of users will know that CA Gen (also known as COOL:Gen) models can contain potentially harmful errors and inconsistencies. We usually refer to these as model corruptions and they are found in the majority of CA Gen encyclopaedias.

It’s not hard to find them (CA Gen includes an option to run an Encyclopaedia Validation Report) but what do you do once you’ve found them? Do you actually need to do anything? Also, not all types of corruption are detected by this report, so how can you be sure you’ve found them all?

eraser and word error

Model corruptions: deal with them before they become a problem.

Most organisations, when they find such errors, frankly tend to ignore them. And that might be fine for a while if the model isn’t actively being maintained. But that all changes when those errors start to rear their heads and cause problems during development (“missing mandatory association” anyone?), code generation, deployment or, worst of all, at runtime. Now, they can’t be ignored. In this blog, we look at how these corruptions – which can have potentially expensive and damaging consequences – can be dealt with once and for all.

To begin with, let’s explore how they originate.

At a very low level, CA Gen has an underlying schema which contains all the objects it needs to define an application – data types, logic statements, UI controls, flows, etc. All of these objects are interrelated, and the schema keeps track of these relationships.

Corruptions happen when, for whatever reason (usually through hardware or software failure), the rules that define the schema are broken. For example, there may be an association missing that the schema expects to be there. It can’t therefore link these objects to one another. There may be an Attribute that’s not associated with an Entity Type, or a Logic Statement that’s not associated with an Action Diagram. Or the corruption may be more complex – perhaps the Attribute is associated with TWO Entity Types when the schema requires that it is associated with one and only one.

The more a model is worked upon, or the more version upgrades it undergoes, the more scope there is for these errors and corruptions to creep in.

Prevention is – in this case – much easier and quicker than cure

In our experience, users tend not to run Encyclopaedia Validation Reports regularly, and most tend to only discover them when they have problems with their models. Most CA Gen users adopt the mentality of ‘it doesn’t seem broken – so why fix it?”. It’s simply not a priority in their day-to-day business.

The problem is that these errors, when they do present themselves, always do so at the most inconvenient time – when you are trying to create a new version of an application, whether as part of on-going maintenance or some modernisation or replatforming exercise. Corruptions can stop a project in its tracks, while everyone wonders what to do. This abrupt halt usually results in, at least, a small panic.

This tends to be the point where we are contacted – and there’s usually, not surprisingly, a sense of urgency.

So what can be done?

Whether being carried out before or after the situation becomes critical, the process is largely the same.

The first thing is to look at nature of the errors. To do this, we have developed our own Schema Tool, which allows us to look at the ‘nuts and bolts’ of the CA Gen model at a very low level. This allows us to see the vast number of objects, and examine all of their properties and associations, just as the Gen toolset does.  However, our tool provides us with the deepest level of information, presented in a meaningful and structured way, allowing us to capture the inter-relationships within a model and between models.

Schema tool

Jumar’s Schema tool is used to examine the contents of a Gen model at the lowest level, allowing the user to navigate around the model’s objects and display their properties and associations.

We can therefore see where things are missing, and where there are invalid properties or associations where they shouldn’t be.

It is very common to discover that there are associations missing – and we are left with orphaned objects. Usually these can simply be deleted using the Schema tool. Alternatively, if we decide that an orphaned object should be retained and we can find out which other objects it should be related to, we can reinstate those relationships.

If there is a large number of corruptions in a model we will usually want to apply automation to apply fixes in bulk and we have created a dedicated tool for this purpose. Additionally, it’s not unusual for us to write one-off pieces of automation to fix unusual or non-standard problems. To do this, we have to find a pattern within a group of the errors, and let the automation carry out a consistent process of correcting them.

It’s also worth asking yourself at this point, ‘am I sure that I have detected all the errors?’ As previously mentioned, the validation report doesn’t necessarily detect all types of corruption. It’s quite possible to have invalid scenarios in models which do not actually break the rules of the schema. Because of this, we have created additional reporting tools to check for some of these other types of corruption.


Identifying, and then removing the corruptions makes for a smoother project.

Looking at the bigger picture, when we carry out any type of modernization or upgrade activity, we always strongly advise that an error correction process is carried out at the start. It makes sense to fix these at the outset to prevent potential project hold-ups, and because if we’re using automation to modernise a system, we don’t want that automation to be operating on invalid source information. So we run the validation reports, fix the errors that in our experience actually have an impact (there are some harmless ones that we may leave alone), and then run the validation reports again to satisfy ourselves and the client that the errors that we fixed have really gone.

We’re very proud of this capability because there are very few people who can do this. Even the most sophisticated CA Gen users tend not to work at this low level. They’re used to using the toolset and the functionality it offers – whereas we’re 100% familiar with the API and schema where problems like this can be identified and remediated.

Why not try running an Encyclopaedia Validation report on one of your key models and see what you get. You might be surprised. If you’d like to talk to us about the results – or any other aspect of your CA Gen portfolio – please contact us.

Why has CA Gen stood the test of time?

By Andy Scott, Client Director, Jumar Solutions

The minute a technology gets labelled ‘legacy’ (rightly or wrongly), it can begin to inherit a stigma that it is old, outdated, unattractive to young IT specialists and less relevant than its more modern-day counterparts. We’ve been working with CA Gen (also known as COOL:Gen, AllFusion Gen, Advantage:Gen and IEF Composer) since the late 1980s – a time when in the UK, a pint of beer cost less than one pound , and in the USA, a gallon of petrol cost slightly less than a dollar . For most of the intervening period, the ‘legacy’ label has been firmly attached, but in our experience, the stigma of being out of touch with reality could not be further from the truth.


Not all legacy technology from the 80s has survived.

In this blog, we look at one particular aspect of CA Gen which should be enough to convince even the most hardened of sceptics that this so-called legacy technology still provides considerable flexibility – and with that, comes significant cost savings.

Consider the traditional legacy situation of CA Gen applications running on a mainframe – with the high licensing and operational costs associated with that mainframe environment. Most CA Gen organisations that are using the mainframe will have probably considered the option of moving to a less expensive hardware architecture, whilst retaining CA Gen and the significant investment already made into the CA Gen applications that are supporting the business.

Exploiting the opportunities that modern mid-range platforms offer, with comparatively (much) lower associated cost seems to be an obvious attractive prospect, however for many mainframe using organisations migrating from the mainframe is, of course, technically challenging. The flip-side is the potential cost saving, with some hardware manufacturers estimating cost reductions in exceptional cases reaching as high as 70-80% over that of its mainframe counterpart – with similar, or even better, performance.


CA Gen: A thriving legacy technology in a a modern world.

The challenge of replatforming is, however, considerably less difficult if CA Gen has been used to design, develop and generate the applications. With everything already defined within the model-based development environment, the code can be easily be generated into other target platforms just by switching the generation options. Of course, there are difficulties when it comes to objects outside CA Gen such as External Action Blocks (EABs) – but these can be overcome relatively easily and are definitely not a showstopper. We quash any fears over that later in the blog.

Had the code been manually created and generated, then the task of re-platforming it could be huge and highly labour-intensive (unless it is to be ported to another platform using the same development language (potentially with support from 3rd party solutions such as those provided by Micro Focus)). But, with CA Gen, you can deliver the same application functionality – on an alternative platform – with much lower ongoing costs of ownership. Coupled with this, CA Gen is one of only a few CASE tools to have this flexibility, allowing 100% of the model content to be ported across automatically.

This trend is something we’re seeing more and more of as organisations look to drive down operational costs. We’re working with a number of large CA Gen organisations who have identified the potential savings to be realised by replatforming, and who have many application models within their CA Gen portfolio. Instead of generating COBOL/DB2 (CICS and/or IMS) into their mainframe environment, we have worked with them to generate C or Java into their platform, using CA Gen’s ability to package the code into a load module which can then be generated for execution on that new lower-cost platform. This exercise, as you would expect includes all the necessary elements of the solution; the business requirements, action diagrams, business rules, database accesses and user interfaces. CA Gen also makes light work of the new middleware challenges and complexities.

'Worth' highlighted, under 'Value'

It’s all about maintaining the value in the application portfolio, while making savings

The only noticeable difference is that the application portfolio is now running on a platform which is cheaper and which does not necessarily have any negative impact on performance for that reduced cost. It’s quite possible that performance can be improved, but behind the scenes, the code has been generated in C or Java, for example, using Tuxedo middleware with data in an Oracle database rather than DB2.

Earlier, we mentioned the issue of EABs (and other external objects required to deliver the solution such as batch job JCL) – and the difficulties they may cause. This user-defined code, written outside CA Gen and specific to the target environment, requires specialist treatment, and organisations considering a replatforming exercise may be, understandably, put off by having to deal with, potentially, a large volume of work associated with the migration / rewrite of these EABs.

The solution is not as difficult as some may think. Jumar has automation tool support which will help to accelerate the re-write of the external logic, for example from COBOL to Java, or from COBOL to C.

By using our highly-automated approach, development time is greatly accelerated, and it opens up an opportunity to carry out further improvement initiatives in conjunction with the replatforming – for example, removing model corruptions, cleaning up models (e.g. to remove unused or redundant objects), the opportunity to improve the architecture of procedures, and other improvement tasks which add value and could prove highly beneficial to future maintenance.

AS for web

Jumar Solutions’ Andy Scott. Tel: +44 121 788 4550

This ability to switch generation options targeting alternative hardware and software platforms goes to demonstrate one of CA Gen’s biggest strengths – its platform independence. It is because of this that applications written, by programmers drinking 95p beer and driving for a dollar a gallon, are still of considerable value today but ported to more modern and cost-effective platforms. There aren’t many legacy systems which let you ride these wave of technology change with such comparative ease.

If you are planning, or have even started, a replatforming exercise in which CA Gen is involved, please feel free to drop us a line to discuss the options available in terms of automation, best practice, dealing with external objects, the potential for further modernisation, or just to find out more about our experiences. We’ve gone through this process with our customers many times, and we are confident that we can add value to your re-platforming initiative and can help you realise those significant cost and time savings.

For more information, please contact Andy or any member of the team on +44 121 788 4550 or drop us a line.

Why are you suspicious about automation software?

Andy Scott, Client Services Director, Jumar Solutions Limited

It's all about speed. Automation can save considerable time and money. There's no need to be suspicious.

It’s all about speed. Automation can save considerable time and money. There’s no need to be suspicious.

The simple answer to that question is: that you have good reason to be. The phrase ‘too good to be true’ springs to mind when being told that a complex CA Gen transformation project could be carried out in a fraction of the time compared to traditional development methods.

The scepticism tends to manifest itself in two ways; suspicion over whether using automation is viable – and suspicion over whether it is genuinely possible.

In this blog, we’ll attempt to address those questions – but if you want the short answer it is, respectively, ‘probably’ and ‘yes’.


With any complex modernisation or transformation task (be it CA Gen or another technology) there is a tendency to think that your particular circumstances are so unique and complex, that no automation software could possibly produce the desired results. Over many years we’ve seen dozens of such environments, and can confidently say that there is no such thing as a ‘standard’ set of circumstances; we have, however, seen a diverse range of implementation styles and ‘standards’. Systems have typically evolved over time, they are often business critical and they may follow standards to greater or lesser degrees. Despite this, highly-tailored automation is a perfectly viable option for modernising and/or re-architecting legacy and ‘tightly-coupled’ systems. The best way to ascertain if this really is the case, would be to look at three basic elements included within the preparation / planning phase for the project.

  • What does the system look like now?
  • What do you want it to look like in the future?
  • What steps are necessary to achieve the desired outcome?

Scenarios where an organisation can create a well-defined set of required transitions, based on a full understanding of the existing ‘as is’ configuration, best lend themselves to the application of tailored automation. But that’s not to say that more complex scenarios don’t. More on that, later.

Tightly coupled systems

Tightly coupled system? Automation could still save you considerable cost.

Scale is also an important factor to consider here. Much of the investment in tailored automation is done upfront – and if there are, say, thousands of in-scope objects to be processed, then that upfront investment is effectively distributed across that large number of objects. The implementation of a risk mitigation strategy to approach the project in a logical phased manner (which is where the majority of our expertise lies) and the resulting economies of scale should help to mitigate any fears or suspicions over the viability of using automation in these circumstances. When projects are done on such a large scale, we are effectively industrialising the process and supporting the required transitions via automation, which provides greater predictability and high quality resulting in cost effectiveness for the client as the time and cost to process each in-scope object reduces dramatically.

We’ve touched on this before but, vital to understanding the feasibility of using automation, is to understand what you currently have. In our experience, only a very small number of organisations know EXACTLY how their system is set up (and how it has evolved over the years following original development), and the majority don’t. (It’s nothing to be embarrassed about – read our previous blog for the reasons why). Even on occasions where an organisation DOES know exactly what they have, it is still important to carry out a comprehensive model analysis exercise to confirm / validate the ‘as is’ situation, hence ensuring that the automation, when tailored and executed, absolutely delivers the desired result.

Model analyser

Jumar’s Model Analyser software quickly ascertains the ‘as is’ situation.

This understanding of the target ‘to be’ scenario needs to be thoroughly defined, in order to determine the transition steps that are candidates to be automated. It’s not unusual for organisations to have defined the target architecture and supporting technologies, but without specific knowledge of the capabilities of automation software, there is a danger that opportunities are overlooked or dismissed as they are not considered viable when implemented using traditional techniques. Our approach encourages clients to stop and take a methodical approach to the process. Only now can the viability of automation start to be considered in earnest and a cost-benefit justification be prepared. However, as a general rule, in our experience, in the vast majority of cases where the scope is large – it is viable.

Possibility (scepticism)

Now, we look at the second major area of scepticism. Is it really automated, or simply outsourced to a low-cost high-capacity development shop perhaps located on a different continent?

Phoenix box device small

Jumar’s Project Phoenix automation software

We can’t speak for other organisations that offer automation solutions, but at Jumar, our automation software does exactly what it says on the tin (read more about our automation tools and Project Phoenix), and we can prove it with strong customer references from complex “real world” CA Gen projects. All automation actions are recorded and documented in a comprehensive execution log report – where the speed of completion of each action is blatantly so fast and the number of objects processed so large that it’s simply not possible that it is being done manually. It is only when looking at such a report that the magnitude of the savings made by using automated methods really becomes clear. Imagine how long it would take (and how much it would cost) to do it manually, or to introduce a change at a late stage in the process. Not to mention the very real risk of introducing manual errors and inconsistencies. Highly tailored automation is fast, consistent, predictable and reliable – operating across the entire implementation as specified it can subsequently be adapted and re-executed as required.

Degrees of automation

One final thing before we draw to a close on the subject of automation – it may be that ‘degrees of automation’ need to be considered when defining the transformation roadmap and the approach to be adopted. There have been occasions where we have been faced with a particularly complex situation where a degree of pragmatism comes into play. For example, when supporting a customer with a migration from a very tightly coupled implementation to a new functionally isolated “n-tier” architecture. Upon further investigation, separating the application into its constituent tiers may show that, in practice, even with automation software, it may be viable (and cost-effective) to automate most – rather than all – of the task in hand. In a recent case study, the tailored automation software effortlessly dealt with 80% of the required transformations, but it was decided that the remaining 20% would be tackled manually. The net effect was still a considerable time and cost saving over 100% manual work. Where automation is not viable (and cost-effective), there’s no way we would recommend it.


Andy Scott

If you have a CA Gen – or a related legacy technology – transformation project (planned or underway), I’d be more than happy to discuss the benefits that automation could bring to your organisation.

Just drop me a line and we can talk some more.

I’m more than happy to attempt to lay any suspicions to rest once and for all!

Legacy modernization: How to avoid fumbling in the dark

_MG_0565Jeroen Wolff continues his analysis of issues faced by legacy modernization professionals in this latest blog post.

In our previous legacy system modernization blog, we focused on the importance of understanding exactly what your legacy system does, and how it does it – before planning your route to modernization.

This seemingly obvious process, like the subject of this particular blog, is often not given the priority it deserves.

And that takes time, as well as increasing frustration and delay.

Today, we’re talking about documentation – and the importance of creating and maintaining both user and support documents. It does sound obvious, doesn’t it? And you’d think it would be done as a matter of course. But, as we’ll see, that can sometimes not be further from the truth.

Files on bookshelves

Missing documentation – it’s not helpful

Consider the software engineering tool, CA Gen, where we have specialist expertise. The whole idea was that, being model-based, the documentation effectively WAS the model. This was a fundamental principle of the IEF, the forerunner to CA Gen. In theory, any competent person, involved in any part of the life cycle – from analysis to implementation – should be able to pick up the model, and understand how it was encoded. However, there are a number of reasons why the reality differs from the theory.

  • The theory still requires the developers to enter descriptions and annotations where necessary. Developers are, of course, not writers. They like to code, and the need to add those descriptions gets put on the back burner and ultimately become “forgotten”. After so long, it simply gets overlooked as the path of least resistance becomes a little more trampled.
  • Development methods inevitably move on and the development tools lose their synergy with the method. For example, whereas CA Gen had full support for information engineering methods, it is less suited to support current trends like UML and analysis methods of writing user stories
  • There are many people with an interest in the documentation who don’t necessarily have access to CA Gen or the skillset to find the relevant documentation within it.

The impact of all this is self-explanatory. As discussed in the previous blog, you find yourself looking at a legacy system, scratching your head as to where to start. Had there been a mindset that documentation was maintained (for both users and support staff), you’d have a much better idea of how to begin.

Tools like Jumar’s Model Analyser and Model Reporter can be used to automate the analysis of the ‘as is’ state of the applications, but having documentation to complement this means you can make even more educated decisions at the start of the process.

What, therefore, can be done?

The solution can be boiled down to a three-step iterative process, comprising improvement, extraction and monitoring:

Documentaion diagram

  • Improve the information that is within the model. Tool like Jumar’s BulkUpdate allows for descriptions and notes to be added quickly and efficiently, using Office tools. Other Jumar tools can be used to extract information from various different development tools and bring it together. For example, Jumar has experience linking different development tools (IBMs Rational, CA ERwin Data Modeler, etc) with CA Gen and vice versa, thus allowing for the full life cycle coverage once again.
  • Extract as much as possible from the models. Automation tools like Jumar’s Model Reporter and Model Analyser greatly help here. The first allows for automatic generation of User and support documents in different formats. The latter extracts all important model information to a local database where it can be queried easily. It also allows for complexity reporting so that you know where the focus of the documentation should be. It can also help in terms extracting certain business rules and problematic code constructs.
  • Monitor for quality purposes. Once the documentation is up to date, ensure it is maintained by setting up appropriate QA processes. Again, tooling can help to carry out QA activities. Especially important when supporting a system which is only updated every so often or when quick production fixes are applied.

A word of caution though; using Model Analyser and Model Reporter can be a ‘quick fix’ – but it’ll be much more cost effective for your organisation if they are used as the starting point for a concerted, on-going plan to improve documentation.

While we’ve touched on CA Gen as an example here, this is true for practically any legacy system, but is a warning that we see repeatedly going unheeded.

Case study


The old adage. Which would you rather be? Especially when assisted by automation.

In a recent client assignment we undertook here at Jumar, one of our experienced legacy experts took six weeks to complete the documentation of a system which should have been done by its previous custodians. Six weeks may sound like a long time, but it was dramatically accelerated by the use of automated analysis tools – and this investment in time ensures that any future development within that legacy system can take place at a fraction of the time and cost than it would have done without those robust documents.

So, what is our advice to alleviate the problems caused by a lack of documentation? Quite simply, you can AUTOMATE your understanding of the system. By ‘automate’, we do genuinely mean that the process is not a manual one. There is an understandable suspicion towards claims of automation – with many thinking that there’s a low-cost development shop somewhere carrying out intensive tasks which vendors claim to automate. But the tools described here (and others within Jumar’s Project Phoenix suite of software) ARE genuinely automated – and we can demonstrate this. This will form the basis of next month’s blog – but for now, we hope this latest post shows the importance of documentation, and why now could be the time to grasp the nettle and get on top of the issue in your organisation.

We can help make it cheaper, faster and less stressful – just get in touch to find out exactly how.