I’ve read somewhere a long time ago that the secret to success is to always start visualizing it in a great many details before thinking about how to achieve it. Otherwise, we risk losing sight of the end goal and wasting time and resources fighting windmills. Sure, we’ll still get somewhere, and with some practice can even convince others that this is exactly the result we’ve planned for all along. How does it apply to IBM i modernization initiatives? Before diving into discussions about modernize vs migrate, RPG or SQL, screen scrapers vs RPG Open Access vs JavaScript, DDS or DDL etc, let’s pause for a moment and think about what would the modern IBM i application look like if it were built now, with all the knowledge accumulated over the years of maintaining and enhancing it. This would be our golden standard, very helpful when deciding on the best architecture or technology choices.
The emerging application model favours a network of smaller agile components that address specific business capabilities, can evolve rapidly and are independent of other components, communicating through a common integration fabric. In this article, I will share my thoughts on the traits of such a modern IBM i applications.
Business Capabilities
Let’s start with the obvious – the modern IBM i application must support specific business capabilities. This seems to be self-evident and not even worth mentioning – aren’t they all? However looking beyond the initial release, the business processes and underlying software systems change at different speeds. Sooner or later they become significantly misaligned. Business and IT can, to a certain degree, compensate with workarounds, often at a price of increased process overhead, impacting the business outcomes. This brings us to the next most important characteristic.
Speed of change
The modern IBM i application must be evolved at a speed of business to continuously align the functionality with changing business needs. There are two key features that support this requirement. The application must provide easy access to key application data and business logic via APIs, enabling the business and development community to deliver their own projects. Internally, the application team should be able to release new versions easy and often. These features influence our choice of delivery methodology and tools, architecture, team responsibilities, and technology choices.
Integration
The modern IBM i application must be architected from the ground up around integration requirements so it could be easily connected to the application network, providing an access to data and business logic and consuming external processes through APIs. The integration platform, such as Mulesoft Anypoint, enables API governance, and security, streamlines discovery and encourages reuse. As a result, we can rapidly connect this modern IBM i application to other nodes and easily compose new processes and channels using APIs as building blocs. The integration layer also insulates other components from internal changes, shortening the time it takes to catch up with business demands.
One interesting thought that I will later explore in a separate post is to use API first approach with RAML and API Notebook for rapid prototyping, documentation and functional testing of the modern IBM i application.
CI/CD
It is essential to have proper CI / CD tools and processes to support the high speed of change. Basic requirements are:
- Confidence in the source code version and build process
- Automated testing with appropriate functional coverage
- Automated repeatable deployment process that supports pilot, phased and full rollout and roll-back
There are a number of vendors that offer application lifecycle management tools in IBM i space. Last year or so I am entertaining the idea of using git as a source code repository, and Jenkins for running the builds, automated tests, and deployment pipelines, but this is a whole different topic.
Size matters
The application must be just the right size, fit into business context boundaries, and be owned by a small agile DevOps team. There is no single recipe for determining the right size. In practice, it should be small enough to implement a specific business capability or a set of closely related functions, yet large enough to hide the internal complexities from the rest of the application network.
Database
Next on the list, our application must have a modern database model that is normalized, adequately reflects the business domain and enforces data quality and integrity. The database ideally should be logically isolated, used by the application, and not directly accessible from the components outside of our application boundaries. This keeps the data within a bounded context and provides greater flexibility to refactor the data model without impacting other applications.
The common data validation and integrity rules could be implemented close to / as part of the database layer, for example with the use of triggers and stored procedures. This approach encourages clean, compact and expressive program logic code that is better aligned with the business processes being implemented.
User Experience
It goes without saying that the modern IBM i can’t exist without an intuitive and easy-to-use user interface. It must support multiple clients such as web and mobile and ideally use low code languages, frameworks or tools to constantly evolve the user experience. A good practice is to avoid direct access to the database and business logic programs in the UI layer, and instead rely on APIs for interacting with data and processes.
Monitoring and Alerting
Last but not least, in order to achieve high levels of operational efficiency, our modern application must include Monitoring and Alerting functionality. The exceptions and operational metrics such as transaction status and processing time are asynchronously streamed to the activity monitoring tool such as Splunk or ELK. Similarly, the application includes a business events firehose for ingestion into Big Data clusters such as Hadoop.
Conclusion
To recap, the modern IBM i application has some of the following characteristics:
- Delivers business capability
- Can be continuously evolved at the speed of business demands
- Automated CI / CD tools
- Manageable size
- Designed around APIs and integrated into the application network
- Modern database model
- Modern UI built on top of APIs
- Monitoring and Alerting support
Armed with this insight, we can now begin charting our way through IBM i modernization minefield, figuring the implementation languages for each component etc while continuously ensuring that these architectural and design decisions are moving us toward the desired end state. The likely rewards are increased rates of success, focus on positive outcomes, a sense of control, and an overall rewarding experience even for the most challenging projects.
I would love to hear your feedback!
Recent Comments