Traits of Modern IBM i Applications
Traits of Modern IBM i Applications
Looking to modernize IBM i for your project? See how you can integrate it effectively while keeping an eye on DevOps, quick changes, and reaching your end goal.
Join the DZone community and get the full member experience.Join For Free
The Future of Enterprise Integration: Learn how organizations are re-architecting their integration strategy with data-driven app integration for true digital transformation.
I read somewhere a long time ago that the secret to success is to always start visualizing in detail before thinking about how to achieve your goal. Otherwise, we risk losing sight of the end goal and waste 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.
The emerging application model favors a network of smaller agile components that address specific business capabilities and can evolve rapidly and independent of other components, communicating through common integration fabric. In this article, I will share my thoughts on the traits of such modern IBM i applications.
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. Which 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. Applications must provide easy access to key application data and business logic via APIs, enabling 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.
The modern IBM i application must be architected from the ground up around integration requirements so it can 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, 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 blocks. 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 an API-first approach with RAML and API Notebook for rapid prototyping, documentation, and functional testing of the modern IBM i application.
It is essential to have proper CI/CD tools and processes to support high speed of change. Basic requirements are:
- Confidence in 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. For the past year or so, I have entertained the idea of using git as source code repository and Jenkins for running the builds, automated tests, and deployment pipelines, but that is a whole different topic.
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 application network.
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.
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 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 efficiently, 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-event firehose for ingestion into Big Data clusters such as Hadoop.
To recap, the modern IBM i application has some of the following characteristics:
- Delivers business capability.
- Can be continuously evolved at a speed of business demands.
- Automated CI/CD tools.
- Manageable size.
- Designed around APIs and integrated into 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 the IBM i modernization minefield, figuring the implementation languages for each component 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, sense of control, and overall rewarding experience even for the most challenging projects.
I would love to hear your feedback!
Published at DZone with permission of Dmitriy Kuznetsov . See the original article here.
Opinions expressed by DZone contributors are their own.