Let business modernize IT, not IT
By Stuart Milligan
In a modern enterprise (a company that exploits both physical and digital growth opportunities) the business typically drives the specifics of all development.
While rarely explicitly stated, the implication in most IBM i shops is that modernization of code/system/database achieves real business value. For many years I partially believed that myself. DDS to SQL, modules and service programs etc are useful, but not as a business driver. Ironically there is actually a technological solution to allowing business to drive modernization for tangible business gain. And that is a digital transformation to a development approach that supports continuous delivery. A REST strategy can deliver this. In the IBM i shops that are already doing this, the business sponsors are rethinking the future of their IBM i legacy, as they enjoy same day turn-around on new or changed requirements.
"The generic business objective of modernization should be to achieve a globally accepted standard of continuous delivery. REST API's have exponentially proven the most successful proponent of that objective. You can start a REST implementation today and be live with an API tomorrow. Join the digital economy."
3 Key Objectives for Digital Transformation
The Right Architecture
Lightening fast, agile, well-designed REST API ‘s running natively on IBM i
Continuous Delivery via automated DevSecOps tooling to implement and govern secured REST APIs and Consumers
Self Service Model
Up-to-date API specifications and rich, self-service documentation unlocking IBM i data via partners, customers, and App building innovators
You don't need heavy SOA to achieve digital transformation. If you have it implemented, great! Does it work for your business?
So instead of making the assumption that low-level technological modernization is essential for business growth, ask the business what they want. Continuous delivery is more important than DDL, rapid integration is more important than RPG Free, and RPG is more relevant on IBM i than Node.js.
Start with an integration requirement that the business needs. That may be for a mobile app, a self-service API, or integrating with a partner. Build that API. Harvest from legacy what can be harvested to support that API. This gives business value and provides very clear focus (and funding) on what should/could be modernized.
Zenith. RCA. American Motors. Texaco. Polaroid. A handful of once titanic brands. Names that today are nearly forgotten. In their heyday, these companies were leaders of industry and an integral part of the business landscape. Yet since 2000, 52 percent of the companies in the Fortune 500 have gone bankrupt, have been acquired, or have ceased to exist. Why? Because digital has irrevocably changed how to compete.
Loosely coupled software components, built for a specific business requirement, have value today. Don't strive for a possible value in the future (the central tenet for building an ESB or SOA design) but now.
Following a proven, global standard (REST API's) provides potentially infinite reusability, anywhere by anyone, using a self-service model and is the central technology component of all digital enterprises. In this world, the value of legacy increases through reuse, rather than decreasing because of complexity.
"REST is basically the transportation mechanism of the Internet that helps people to open up resources, a catalog, an inventory, any resources that are asked and you are willing to provide. The business can make better decisions using real-time data from all disparate sources in one place rather than silos of data reviewed separately at different times. So it really is the communication medium of the internet. And if you open up your shop through the REST API's, people are able to order through the Internet in a standard way, that will be understandable for everybody and that will help you to get this information in the fastest way."
The other untapped value is using someone else's code just as easily as you use your own. Not just third-party software, but partners, governing bodies, customers and, why not, code from competitors. Why should you build a tedious telephone checking algorithm if you can ask for an online service? Or a tax calculation? Or statistical significance test? Focus on your cutting edge and tap in other resources for commodity functions, like sending e-mails. Build whatever UI is needed over that API. The beauty of this modern standard approach is that ALL relevant UI’s support a REST API. Host a hackathon to get the UI/Mobile/Web app built over your API. You will have talents, young and old, from everywhere, interested in your business. It will be competitive and relevant. Your partners and suppliers will love the fact that they can work with you in self-service mode.
How do we do it?
Remain Software and Thoughtmakers have integrated the software change management TD/OMS and an RPGLE Framework LXR for REST API Development and Security on IBM i. This enables you to expose your data through a REST interface and create the OpenAPI specification contract and RPGLE API in one fluent process. It has automation to accelerate development and deployment of REST services. Because its RPGLE it integrates with existing skills and development methodologies. As an IBM I native technology it harnesses the full capability of the platform. Basically, LXR handles all of the complicated API logic, so it simplifies the development of even the most complex and sophisticated REST API’s. Native means the IBM i job and process controls can be used to truly scale – a common hindrance in traditional IBM i integration solutions. LXR also has a Hybrid Cloud Solution called LXR Accelerator that provides tools for automation and administration of REST API development.
"You can create API’s from native i programs that are visible from the UI. Remain Software adds more functionality to LXR that helps RPG developers to create and maintain API from RPG programs or from scratch."