I have been fortunate to attend many events and conferences throughout the years, several on an annual basis. These gatherings bring together industry leaders from all over the world to share their expertise and knowledge about the IBMi and open source ecosystems. I have gained a lot of insight about the changes happening in our industry that can truly affect how a business can continue to run effectively and stay competitive.
My first exposure to the term DevOps was four years ago at an IBM Rational event called Innovate, now known as IBM InterConnect. That conference really enlightened me as to just how niche the IBM i community is from the majority of open systems developers. IBM i could almost represent “Isolated” as opposed to “Integrated”. A good portion of the blame can be attributed to IBM i’s legendary reputation for security and reliability in handling the planet’s workload of transactions. It is a great technology. Why fix it if it is not broke! I wish I had a dollar for every time I heard those words. Are they words of wisdom or an excuse that we have harbored for way too many years? What has this mindset cost the IBMi community? We are now seeing businesses once loyal to this platform considering and choosing other high risk options. Shouldn’t the mission of IT be to serve the business first and foremost while accepting the responsibility of keeping the data flowing and secure?
Many companies today are launching web and mobile initiatives and campaigns looking for new and innovative features or services to sell more products and engage more customers; in other words, gain a competitive advantage. This has been happening for many years but really dominating the IBM i landscape today. Classical Darwinism of “survival of the fittest”, “change or perish”, are dominating the strategic discussion. Born of the web, companies started to exploit the new landscape and take down the T-Rex’s of the world. Companies like Kodak, Blockbuster and many others have indeed perished from the face of the earth.
It was four years ago that I heard the term two-speed IT in a DevOps session. Today we call it variable speed IT. In simple terms, we have hybrid teams of development and they work at various speeds and often with different requirements and metrics. We have the innovation teams looking for a quick responsive feature or function and the legacy industrialized core team looking at stability, compliance and security. All of these are relevant goals in the end but can your existing processes and tooling manage this evolving landscape? Another important question is can your people accept this cultural shift? Do you have the needed feedback loops to know if we are producing and selling more product and services efficiently? So how can you manage these projects with the necessary visibility and insight to all the stakeholders including the business in the development life cycle? That is DevOps!
In the past several years, I have heard of many companies leaving or planning to leave the platform, the forever evolving eventual (5) five year strategy of moving off the platform and plan that was started 8-10 years ago. This drastic and highly risked-filled strategy has cost many companies significant time and money with little to marginal success. I would suggest reading a previous blog from Philippe Magne, the CEO of Arcad Software on this topic of Evolution, not Revolution.
The good news is there has been a shift in the strategic wind. The pain of change for companies is often less now than the existing pain of status quo. There is a price to maintaining a walled fortress–you may have heard the term “technical debt”. Modernization, revitalization, formally called reengineering of the code, the database and user interfaces is providing the much needed extensibility of legacy functions and reliability to the business. In addition, modernization will allow disparate development teams to take advantage of the DB2 database utilizing SQL and data centric programming practices without sacrificing your security or recovery strategies on the IBM i.
Use Agile methodologies so teams can succeed or fail quickly before costs and time get applied where the benefit is not being realized. Provide automation, a principal tenet of DevOps, to facilitate a reliable and repeatable process to eliminate waste and rework. Speed and agility to change could have saved the dinosaurs. Bringing DevOps to your IBM i today, should allow you to continue using what has provided your business advantage today and in the future while paving the way for the next evolution of business applications.
REQUEST A DEMO
Let’s talk about your project!
Speak with an expert