Application Modernisation – ‘Characteristics of Modern IBM i Applications’.
Part 3 and the final section – taken from a white paper written by KFA’s Technology Manager, Stuart Bramley.
We have broken the white paper down into three sections:
Part 1 – Highlights the risks, benefits and strategies.
Part 2 – ‘Modernisation Patterns’.
and Part 3 – Is here…
Characteristics of Modern IBM i Applications
Historically, the computational cost of activating programs was high. As a result, the best practice was to do this as little as possible, which meant that all of the logic necessary to perform a given task was included in a single program object.
Programs with thousands and thousands of lines of code were not uncommon. The database access, business logic and presentation code were tightly coupled into a single executable. Logic would be reused by copying it into other programs meaning that a change to the logic would have to replicate wherever it had been copied.
Thanks to IBM’s policy of maintaining full backwards compatibility in every release of IBM i, many of these programs are still in service today. Whilst this underlines the safety of investment in the platform, the modern IBM i is able to support very different ways of architecting applications in order to meet the needs of the modern business and IT environment.
Built in smaller blocks
Modern applications are comprised of smaller, highly cohesive, loosely coupled functions. A function has a clearly defined task which is reflected in its name. In IBM i applications this means that code is written using the full capabilities of the ILE environment. Procedures are written into service programs, with program objects themselves acting as workflow controllers.
Underpinned by SQL
Modern IBM i applications use SQL to both define and access data. The days of defining databases with DDS are – or at least should be – gone. The modern DB2 database has vast capabilities which can only be utilised when databases are defined with SQL.
Using SQL to access data not only improves performance and adds functionality – it also removes the dreaded “Level Check” error and the need to recompile programs when tables change.
At V7R3, RPG programs can pass SQL results sets between them meaning that the same data access program can easily be consumed both as a native RPG program and a stored procedure.
Loosely coupled
Unlike most languages, RPG has native access to both the database and user interface available without requiring the use of a library or API – JDBC is required for Java to access databases for example. This gives RPG many advantages in performance and function –at the expense of good design. The historic RPG program is likely to tightly couple the business logic to both the database and the presentation layer – be that a 5250 terminal display or a printed report. That valuable business logic cannot then be reused elsewhere without copy and pasting it into the source and cannot be made available to other systems.
A modern application design divides the application into different tiers with distinct responsibilities – e.g. presentation, data access, business logic, process control are common tiers or layers. Calls are made between the tiers but they do not access the resources that the other tiers manage directly – presentation layer code will not directly access the database and vice versa.
Tested automatically
When code is written in smaller, discrete blocks with well-defined inputs and outputs it then becomes much easier to test than the monolithic programs of the past. Unit tests of these functions can be automated which enables suites of regression tests to be performed whenever code is updated to ensure that software continues to function as expected.
Coded verbosely
RPG is now fully free format with the ability to have long variable names, procedure names and database column names – all of which mean that code can be written in syntactically expressive ways which bring it ever closer to natural language and make software more and more self-documenting.
Built automatically
The disadvantage of having smaller, discrete blocks of code is that the build process becomes more complex. In the IBM i sphere, a suite of programs may have dependencies on multiple service programs and these may need to be compiled and linked in a particular order. Assistance is needed to ensure that the software is built in the same way each time, with the same settings and the necessary dependencies fulfilled.
Automated builds with tool support help manage this process and ensure that errors do not arise as a result of missing dependencies or incorrect compilation settings.
Founded on open-source
IBM has taken huge strategic leaps to enable more and more open source code to run on the IBM i platform. Languages like PHP, Python, Ruby and Node.js all now have native implementations on the server – and it’s been made easier and easier to compile and build open source projects to run on IBM i. With the Java 8 JVM that also enables the use of any language that will run in the JVM, technologies like Scala, Kotlin, Clojure et al can be leveraged on the modern IBM i server. In the front end, whether it’s a web application using a CSS framework like Bootstrap or LESS, JavaScript frameworks like React.js, AngularJS or JQuery, or a mobile device framework like Ionic – open source software is enabling us to deliver the most modern of applications to business.
Integrated with API interfaces
Our key business functions such as creating orders, generating invoices or registering customer accounts need to be accessed from all sorts of different channels. We’ll have the main user interface to the application of course – and then a website, possibly mobile devices; the business may sell its products through third-party auction sites or portals like eBay and Amazon – but we don’t want to reproduce the business logic to create and fulfil our orders for each channel.
By coding the business logic in a discrete unit that is not coupled to any given interface we can then expose it via an API that these interfaces can consume – so no matter where the order comes from or how the customer registers with us the same logic will always be used and when the time comes to maintain that code it’s only done in one place – whether it’s called from a local user, initiated via messaging middleware or a web service.
Developed with modern tools
The old tools for IBM i application development are no longer up to the job and IBM have stopped maintaining them. When code is written in smaller blocks, with expressive free-format syntax, a modern development environment is needed to allow developers to see more of the source code at once, to quickly read, understand and move between source files and assist them in being more and more productive. The modern RPG application is developed in Rational Developer for i – which also allows tooling to be added on for many of the other languages that are now available on the system. A full-stack developer can code both an RPG back-end and the front end of an application in the same toolkit – whether that front end is Java, PHP, AngularJS or pretty much any technology they need to use.
Presented with a modern user interface
Whether delivered via the browser or mobile devices, the workforce is changing and maintaining staff satisfaction and productivity requires a modern interface to our business applications. Whilst the presentation code for this executes locally on the user’s device, the IBM i can deliver this code to them and provide the same high-performance, highly scalable, ultra-reliable back-end service as this platform and its predecessors always have.
Download the full white paper here KFA Connect White paper – Application Modernisation
Interested in how KFA Connect can help with Application Modernisation?
Get in touch with our friendly team!