3 Key Objectives for Digital Transformation: Part 1
By: Stuart Milligan
Posted on May, 18 2018 on rest4i.com
Part Index:
The Right Architecture
Drawing upon our own experiences and lessons learned in the global field of digital transformations over the last 5 years, this three part article covers three key objectives that any organisation needs to include in their Digital Transformation strategy/plan.
When comparing the early adopters and the slow starters, according to Forrester, the arms race for digital transformation already has some compelling statistics: 57% improvement in product quality versus 6%, and 40% cost reduction versus 8%.
A common strategy in IBM i IT shops is to focus existing resources on building a modern UI over a legacy application, in the belief that this is a cornerstone of digital transformation. This strategy contains seriously flawed assumptions:
- Any user interface of any type built over all the IBM i data by the IT Department, will be the responsibility of the internal IT Department.
- UI Development creates an almost instant and ever growing technical debt, and as such places a financial risk on the organisation.
- While the constantly changing UI development takes place key development resources are locked in, and so other digital integration opportunities are stalled.
- There is a multitude of open standard, modern UI development technologies and resources available in the market. Conversely there are a seriously limited number of IBM i programmers who understand the legacy data.
- Limiting the Mobile App or UI design to a small group of legacy skills and resources completely contradicts the commercially proven models of open source and the digital enterprise.
Using Systems of Engagement (Twitter, Facebook etc), and Systems of Insight (IBM Watson, Analytics etc), create a competitive advantage to any organisation, large or small.
Opening IBM i Systems of Record for optimum digital integration for all potential internal or external integration, unlocks the full potential for digital growth and breaks down the destructive force of Silo’d data mentality in organisations.
Microservice Architecture
Microservice architecture is a collection of loosely coupled services, which implement specific business capabilities. Microservice architecture enables the continuous delivery/deployment of large, complex applications.
By far the most dominant and successful approach to implementing microservices is using the REST API standard. The two main reasons for this are the mainstream adoption of REST (AWS, IBM BlueMix, Azure, Twitter, Facebook, EBay, OpenBanking, PSD2, IOT etc), and the common standard for all mobile development is using backend REST API’s.
Implementing REST API’s over the IBM i data, opens the opportunity for more productive, cost-effective long-term UI modernization. It's also a more secure, quicker response, flexible I/O approach for all UI's
RPG REST Microservices over a structured RPG Framework are lightening quick and easily maintained. Testing is faster, and it’s easy for new developers on any platform to understand and consume self-service API’s. Fault isolation provided by small, loosely coupled, microservices avoids system-wide downtime, while developer productivity is higher and code reuse optimised. Each microservice can be exposed either directly or via a cloud gateway as REST API’s.
There are proven RPG frameworks that provide all of the above as standard.
Wrapping existing 5250 or batch RPG programs to produce JSON output is not REST architecture. It won’t achieve digital transformation, and it won’t ever make continuous delivery possible. It defeats the objectives of modular architecture, which are agility, flexibility, robustness and optimum reuse.
A structured, and standardised approach to microservice development is critical when facing the inevitable scaling of complexity, performance or increased numbers of API’s. Choosing the right RPG framework and experienced partner to implement a microservice strategy, will shorten the initial delivery cycle, and also avoid costly rethinks, reworks and delays once you start to scale or broaden the scope.
Once customers and partners taste success of an IBM i microservices strategy, demands tend to grow quickly as opportunities are realized. An organized start and structured early approach will make you ready for this.