Cyber security – the stamp of approval

cyberCyber security is never far from the news, and as an organisation which specialises in enterprise-wide application development and modernisation projects, we are delighted to announced that we have achieved the ‘Cyber Essentials‘ standard.

It’s a Government-backed scheme which shows that we are following a range of controls to prevent cyber security incidents.

Certification involved an in-depth independent audit of the our IT systems to make sure we were complying with best practice which protects us and our clients against common cyber-attacks.  This was backed up too, with a vulnerability test, and certification lasts for 12 months.

As a business, we see it as a really positive move, and if you’re considering getting certified, we’d be happy to share our thoughts on the process with you.  While we’re here, if you ‘re looking for application development or IT recruitment services, we’d be happy to help with that too!


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.

New YouTube video: (Part 2) Are you really doing agile software development?

The second video in our series of “Are you really being agile” is now online.

This bitesize video follows on from our successful first agile development video, in which Doug Michael analyses ways in which organisations may misconstrue the agility of their projects.

It also offers advice on how to make projects truly agile, and the benefits this brings.

If you’ve not seen the first in the series, please view this first as its better to watch them in order.

The video is now here…

If you’d like more information, please contact us – and do feel free to comment on the video and share your thoughts on this topic.

Agile software development – it’s more than just sprinting and scrumming (Part 2)

Agile thumb

Watch the content of this blog on YouTube

Welcome to part two in our series of blogs about whether organisations are REALLY following the agile methodology when they claim to be.  In the our first blog (read here first, if you’ve not already) we looked at two of the scenarios in which agile techniques are misapplied.  Remember, you can watch all this in our YouTube video available here.

In this post, we look at another two.  Next time, we’ll look at three more, but for now…

Misconception 3: Scrums and sprints define Agile

1Agile 2.2

A familiar diagram

One of the most well-known features of an Agile project is the daily scrum meeting.

We have encountered several organisations which claim to be ‘doing Agile’ solely on the basis of having implemented the scrum meeting technique into their process.  But of course Agile is about much more than this.  Scrum meetings can take different forms but in the most common we ask three key questions:

  • What have you done since yesterday?
  • What are you planning on doing today?
  • What  –  if anything – is stopping you from achieving that?

The purpose of these questions is of course to make sure that everyone knows what everyone else is doing and to ensure that blocking issues are dealt with.  This is essential for an agile application development project with a fixed timescale.  The scrum meeting is very useful, but it’s important to recognise that it is just one part of the Agile process.

Misconception 4: you can use it as an excuse

Often, Agile can be seen as an excuse NOT do a whole host of necessary processes – for example:

  • not writing a proper specification
  • not writing documentation
  • not using the appropriate tools
  • and not sticking to plans
Agile 2.2

Agile is not to be used as an excuse for not doing things properly. Watch the video for more.

It can be viewed as a bit of a free for all – but at Jumar, we believe that all the above are necessary. Just because the Agile methodology allows you to change the scope during a project doesn’t mean that you don’t need to know what you’re building when you start or that you don’t need close, formal control.

When you start an Agile project, we believe that you should have a clearly defined scope, a specification and a detailed plan.  The difference with Agile is that you EXPECT change during the project and the approach accommodates for it.

Next time: user demonstrations, testing and priorities

We’ll be publishing our next YouTube video very soon covering these very topics.  Watch out for the blog version too, coming over the coming weeks.

Like to know more?

Please contact us here.

Agile software development – it’s more than just sprinting and scrumming (Part 1)


Agile – is there REALLY a lot of it about?

If you Google “Agile Methodology” you’ll get just short of three million results.  There’s clearly a lot of it about.

Well, actually, there’s a lot LESS than first impressions would have you believe – and there are a lot of people who think Agile is something that it simply isn’t.

And that’s the problem.  Lots of organisations claim to be ‘doing agile’ when, in reality, very few are.  Many are doing something they consider to be agile software development, but which could not be further from the truth.

Agile thumb

Watch our YouTube video for more on this subject

This blog post covers some of the points raised in our recent YouTube video “Are you really being agile?” (which you can watch here) – and is the first in a series of blogs covering common misconceptions about Agile.

We regularly hear people saying that agile doesn’t work – or it’s not appropriate for a particular situation – when in fact it’s just not being used effectively.

And that could mean missing out on the many benefits that a truly agile project can bring.

Before we look at the misconceptions – a recap

First – a small trip back to the drawing board, and a look at the biggest differences between agile and ‘traditional’ methods of software development (waterfall seems to be the most commonly quoted).

The three key elements of a project are:

  • time
  • resources
  • scope

In the ‘traditional’ model, it is the scope and resources which tend to be fixed.

Agile 1.1

Traditional methods mean scope and resources tend to be fixed – with time as a variable

Any change in the project which increases the scope means it’ll take more time.  Quite understandable then, that change is feared in this scenario, as it will add delay.

In the Agile model, however, we have exactly the same parameters, but it is the TIME and resources that are now fixed.

Agile 1.2

Agile approach: Resources and time is fixed, so high-priority items are included, and lower priority items form the next project.

Scope is, therefore, the variable – and it makes provision for the fact that change is EXPECTED. This methodology, therefore, allows for change – and in fact, encourages change.

Misconception 1: Agile automatically works for everyone

So – back to the plot.  How does this relate to misconceptions made by organisations claiming to ‘do agile’?

Agile 1.3

Manage expectations: ensure all stakeholders buy in to the agile concept

The first issue, surrounds ‘people’ – and by this we mean the entire team of stakeholders involved in the agile process.  We know that the time is fixed – as are the resources.

So, when feedback leads to new features being introduced, it is inevitable that lower priority items will no longer fit into the timescale, and will go onto a wish-list for a future release.   Everyone involved has to accept this – and unless there is buy-in for this concept, it could be viewed as a negative.  And this regularly happens, as users who are familiar with the traditional approach, expect the new features AND the old, and are unwilling to let anything drop out of scope.  If one gives into this pressure, the project is no longer agile.

We combat this by always holding detailed upfront sessions with users to make sure they are familiar with the benefits of agile – especially the fact that it allows a predictable timely delivery based on prioritisation of features.

Misconception 2: It takes all sorts

It’s vital that the correct personalities are involved in an agile project.  This includes not just the techies, but also the non-IT stakeholders.  For agile projects to be really effective, they need to be staffed with individuals who want to prove something, and who thrive on the challenge of working to produce the best possible result to well defined timescales.

It’s simply not for everybody.

Next time: Misconceptions 3 and 4

In the follow-up to this blog post, we look at scrums, sprints an excuses.  Following that, we’ll go on to discuss failures to manage user demonstrations, and ways to get quality feedback.  We’ll examine problems with prioritisation and failure to build testing into the process.

Want more?

In the meantime, if you’d like more information about any aspect of Agile, please contact Jumar.

Legacy modernization software has a new look – Project Phoenix gets a makeover

Phoenix box device small

Project Phoenix’s new look

Always keen to practice what we preach, we have modernised our modernisation software, with a brand new look.

Project Phoenix (Jumar’s legacy modernisation and re-platforming suite of software) is a collection of automated tools and services which enable legacy applications to be re-used if the business rules are still valid.

Project Phoenix itself is constantly evolving to meet new and more complex challenges, so as part of this, we have given it an all new look and brand image.

For more information on  how Project Phoenix…

  • Automates modernisation of systems
  • Supports new application styles , interface and architectures
  • Reduces time, cost and effort
  • Reduces testing cycles through increased accuracy
  • Allows accurate project planning and estimating
  • Harvests existing knowledge and functionality

…please contact us.

CA Gen trends for 2013 – Jumar’s predictions

Now that we’re a month into 2013, and the dust has settled after the annual whirlwind that is January, we thought we’d take stock of what’s in store for the rest of 2013. We have, therefore, polished our CA Gen crystal ball to see what the future may hold.

future button from ms word

To do this, we’ll start by reflecting on the last few months, which have been significant for Jumar and our customers. Our expansion into Asia-Pacific is continuing to gather pace, and a number of exciting new projects are beginning, with many getting underway in the first few days of this year. A good basis on which to start our prediction.

First – a little look back

In 2012 Jumar undertook major CA Gen related projects to:

  • transition a European Government finance body’s IT architecture to allow it to exploit the latest technologies
  • facilitate one of the world’s largest companies’ plans to migrate from CA Gen to COBOL
  • upgrade a number of global organisations to CA Gen v8.0 (including Government departments, a major telecoms provider and some of the UK’s biggest household names). Its approach to automation not only saved many (sometimes thousands of) hours compared to a manual process, but its assessment service also allowed that upgrade to take place with maximum confidence
  • provide training to Government and corporate organisations (across all levels from basic CA Gen training to regular specialist academies)

…and that’s just the start of it. We’ve also helped an international insurance organisation to transition .NET and other applications, delivering on-time and in-scope using Agile development techniques. Another significant project was a web-based java project for a governmental transport body.

We could go on – but this is supposed to be about the future, not the past.

Futurethinking from ms word

So what are our CA Gen predictions for 2013?

As our portfolio of CA Gen-related services continues to expand yet further, we find ourselves deploying them into new sectors and territories globally – particularly Asia Pac. But just what sort of CA Gen activity do we expect to see over the next twelve months?

There’s a lot of value in CA Gen systems The over-riding buzz we get from the community is that many users are still very much pro-CA Gen, and we’re seeing a significant upturn in customers modernising their CA Gen portfolio. This allows them to continue to exploit the benefits which already exist in their existing systems – and the trend seems to be to use re-platforming as a way of modernising their environments. Whilst each organisation has its own motivations for modernisation, these typically include:

  • business demand for better user interfaces. A common scenario we see is the organisation retaining CA Gen for the server side – where its greatest strengths lie – and moving to some other technology for the presentation layer.
  • the need for better integration of hitherto ‘silo’ CA Gen applications – often within a Service Oriented Architecture
  • downsizing of infrastructure to save money. For example moving off the mainframe or moving from Host Encyclopaedia to CSE

Too many people still believe that it is too hard to do these types of modernisation with CA Gen: splitting block mode into client-server; creating web UIs, componentising, re-platforming, migrating. We disagree and have projects in progress now around the world doing all of these things.

DoitrightA lot is possible – if you do it properly The other popular trend, which we expect to continue to increase in 2013, is the recognition among CA Gen users of the benefits of automation techniques to achieve results which would otherwise be impossible, if reliant on manual methods. We’re seeing a large number of clients who are embracing tools in the Project Phoenix suite of software, which opens up a wealth of possibilities, maximises budgets and saves time and frustration.

The types of modernisation listed above can all be achieved using a largely automated process. The beauty of CA Gen is that the model holds the definition of the application. Each type of modernisation requires changes to the model and the cost of making these changes manually can be prohibitive. Jumar’s approach is to automate what can be automated – which is often 100% of the changes needed. For example, we can convert old block mode applications to client-server 100%, allowing the previously hidden business logic to be exposed and integrated using any of the popular modern technologies.

direction form ms wordWhen the time comes to migrate, ask for help  As we said above, each organisation has different motivations and alongside the CA Gen modernisers we also expect to continue to see some companies taking the strategic decision to migrate away from CA Gen – to other platforms. We appreciate this is not an easy decision to make, but for those companies which have chosen to do this Jumar – as experts in CA Gen – can help. We offer a range of consultancy, outsourced and technical services to support migration initiatives. Our proven track record in migration speaks for itself, and is backed up by our world-class automation tools, but to find out more, please contact us.

So, our main expectations are threefold: more organisations maximising the value of their core CA Gen systems through modernisation and integration, more organisations using automation to push the boundaries of what’s possible, and more organisations taking the strategic decision to migrate.

Whichever of these categories your organisation falls into, it’s pretty much a foregone conclusion that Jumar has already ‘been there, done that’. Our new clients in the Asia Pacific region are already benefiting from this extensive experience, and their roadmap to transform and improve the business value delivered by their CA Gen portfolio is now more than just a vision.

Over to you

So, we’d now like to hear from you. What are your predictions for CA Gen in the coming year? What are your plans for the coming year – and what difficulties are you facing, or expecting to face? What level of support do you need? Jumar can help you understand the scale of the task, and the resources you will require. Have you made strategic decisions regarding the future of your CA Gen applications? Are you going to modernise, downsize or migrate? Again, we have the know-how to support you in this change.