Why IBM i and the low-code development environment LANSA are a winning combination
This article was originally published on the IBM blog in Japan (https://www.ibm.com/blogs/systems/jp-ja/ibmi_lansa_isv/) and was contributed by Tetsu Nakamura, CEO of LANSA Japan Limited, which provides solutions that operate on the IBM i platform.
The increasing complexity of systems is the largest hindrance to the ongoing advancement of digital transformation (DX).
As we continue to expect more and more from our systems, they expand to support a wider range of functions, and it becomes more difficult to gain a comprehensive understanding of the entire system. At the same time, legacy components and new components exist alongside one another, which further contributes to the increasing complexity of systems. Although an increasing number of technological options is a good thing, we cannot deny that this increase in the number of options leads, in its own way, to an increase in complexity. Under these circumstances, today’s systems are becoming more and more complex. And we can easily imagine that this increase in complexity will continue to accelerate for the foreseeable future.
I believe that this increasing complexity is the root cause of all hindrances to IT. As the population has started to decline and we are faced with labor shortages, the ideal situation would be for one person to study many new technologies, and use those technologies freely to combine and assemble systems. To achieve this, we would need some kind of “superman,” but resources like that are not easy to find. As a result, engineers become “siloed” according to the component technologies they specialize in. End-user companies, too, must think about which business partner they want to entrust with which technology if they are not able to handle the necessary technologies themselves. Although they understand that insourcing and agile development are factors in the success of digital transformation, the construction of such “technological silos” is a major obstacle.
Utilizing citizen developers for localized no-code or RPA-based development can be effective, but I think it is still too early to think that, in the near future, all systems will be developed by citizen developers, or that those systems will be able to stand up against external services.
Of course, you can counter that by saying it isn’t necessary to have a good grasp of the entire system, but the above situation will make it difficult to understand the overall state of your systems, which will in turn make it difficult to optimize them for your businesses in a timely manner—in other words, to implement DX.
Learn more about how your organization can attain technology independence in this related article: “What is a IBM?”
Simple, sustainable, and robust IT infrastructure leads to success in DX
The increasing complexity of systems means that, despite the declining population, the number of persons involved in system development is increasing, which makes communication more difficult and makes it extremely difficult to gain a comprehensive understanding of an entire system. Although it is difficult these days to avoid the increasing complexity of apps, technologies, and environments, I also think that selecting as simple an environment as possible is becoming an even more important criterion.
Another important point is whether you can continuously implement DX. With systems, what often happens is that you replace A with B, and consider that to be the end of that step. But by its very nature, DX requires you not to completely replace A with B, but to continuously make maximum use of your existing usable assets while having small teams make continuous flexible additions and changes according to your needs. I think we can even add an “S” for “sustainable” to the abbreviation “DX” and call it “SDX,” because whether you can simply make continuous transformations is key.
Therefore, to continuously evolve your systems, your infrastructure needs to be simple, sustainable, and robust.
By “infrastructure,” I mean the hardware, OSs, and development environments used for your systems.
Know which solutions to integrate and how to enforce them on your systems in this article about IBM i Disaster Recovery.
Simple but highly functional, highly secure, and high-performance IT infrastructure
From a hardware and OS perspective, some of the most valuable aspects of IBM i are the fact that the OS, database (table), and security functions are centrally managed, and that mutual compatibility is guaranteed for version upgrades. Many users also praise its strong and unfailing robustness. One of my clients even told me that for the seven years before they retired, they did not experience any system stoppages due to failure. With regard to security, the OS has never been hacked to date, and thanks to the Power chips developed by IBM, performance is continuing to advance according to Moore’s law. When you think about it, using IBM i as your system infrastructure ensures mutual compatibility, which greatly decreases the burden on the engineers that use it, and you could even say that it’s the simplest and most sustainable platform for both on-premise and cloud use.
While IBM i continues to greatly evolve, including all industry-standard technologies and making it possible to implement DX initiatives at any time, it also requires familiarity with many programming languages and related peripheral knowledge. If you use it incorrectly, it could actually hinder your DX initiatives.
So, can we overcome this situation by simplifying the development environment?
Achieving simple, no-code app development
Thinking about past development environments, I think AS/400 (IBM i) was particularly good for its simplicity. Those of you who were working as programmers when AS/400 was in wide use will already know this, but at the time, we could leave session control up to the OS, and it was possible to make full use of the environment just by using BPG, CL, and DDS. Even that was tough, though, and I remember thinking how much easier it would be if we could do everything with only CL.
Now, I’d like to explain how LANSA (https://www.lansa.jp/) has been working to realize that dream for the past 30 years.
LANSA started by creating apps that could be run simply in a Q&A format. Or, to put it in modern terms, no-code development. The apps that were created were written in a language provided by LANSA, and could be flexibly customized in a low-code environment. LANSA’s programming language was actually based on CL syntax. Over the next 30 years, LANSA’s language developed into a language similar to FF RPG, which can be used both for client side (including logic and UI expressions) and server side coding for 5250, client servers, web apps, native apps, and progressive web apps (PWA). And even apps that were coded 30 years ago can be compiled and debugged in their latest version, and edited in the latest version of our editor, with no need to perform code conversion.
Whether you use a no-code tool or a low-code tool, detailed customization of the RPG, C++, Java, JavaScript, HTML, CSS, or other generated code beyond what can be done with the tool generally requires the code to be edited directly. However, this means that even if you are able to improve the efficiency of initial development, several “engineer silos” will still need to be involved in later processes.
With LANSA, on the other hand, although our language does generate RPG, C++, Java, JavaScript, HTML, CSS, and other programming languages where they are needed, there isn’t a user in the world who analyzes and edits that source code. Debugging can also be performed by using the language provided by LANSA.
There is currently no other tool in the world that has achieved such simplicity and sustainability.
Learn more about how the easy-to-use AS/400 has changed in complexity over the years from this article on IBM System i.
LANSA and IBM i: A winning combination to support DX
As I previously explained, the IBM i OS includes a mechanism that enables central management of software infrastructure, and offers an exceptionally simple platform for continuous support for apps that were created in the past. I’ve also explained that LANSA, as well, is a simple platform that supports continuous maintenance, operations, and renewal while also incorporating new technologies. By combining these two simple infrastructures, countless companies have seen their information systems divisions, which have a tendency to become passive, take the initiative in proposing business process reforms.
[image]
DX at client companies who have chosen IBM i and LANSA’s low-code development environment
Let’s look at the example of Tatsuuma-Honke Brewing Co. Ltd., a Japanese sake brewery headquartered in Nishinomiya City, Hyogo Prefecture that is well known for its Hakushika and Kuromatsu brands of sake.
This brewing company, which has around 200 employees, migrated from a mainframe system to IBM i in 2004. They developed their IBM i business logic in RPG, and their client-side mission-critical screens in Visual Basic 6 (VB6). After the end of support for VB6, they had difficulty determining the causes of failures, and whether they had occurred on the server side or the client side.
However, by continuing to use the IBM i platform and introducing LANSA, they became able to develop, operate, and maintain their systems in a single environment by using a single language. Currently, by using LANSA, they are even able to have available resources from other divisions work on the system division’s tasks. As a result, the division name has changed from “System Management Office” to “Management Office.” This example shows how management work and the work performed by system divisions are two sides of the same coin, and is also an example of a small team achieving DX.
In conclusion
With the idea of reaping even greater rewards from the efforts of system personnel, I’ve explained how IBM i and LANSA can be effectively combined from the perspectives of avoiding over-complexity and ensuring continuity. If you’re hearing about this for the first time and think you’d like to give it a try, please contact us via the following form to request a demo or PoC.
Tetsu Nakamura, CEO
LANSA Japan Limited
