Arguments for Incremental IBM i Modernization
The IBM i is often maligned as outdated. The basis of this argument is frequently that the platform, with its character-based UI, cannot support modern applications and tools. But the argument is not grounded in fact as there are a large and robust set of tools available to modernize existing applications. And, IBM i’s support of more popular languages and open source can augment or replace existing RPG and COBOL code. These modern languages like Java, PHP and Ruby on Rails offer truly modern development environments supporting the latest graphical screen presentations.
So, when contemplating modernization, whether your organization is thinking about maintaining your current platform or migrating away from IBM i, there are several considerations:
Retaining valuable existing business logic contained in the RPG/COBOL code base is often the most cost-effective approach. Years of institutional knowledge and continual refinement of business logic are likely imbedded within existing applications. So, while the UI may ‘appear’ dated, the core code logic may be based on sound business principles that have been customized to business requirements and refined over time. This logic may be difficult to replace.
Accurately extracting business logic for replication to a replacement application is difficult and off-the-shelf software may not offer the flexibility your organization needs without significant customizations.
Supported by IBM’s long-term commitment to the platform, the existing applications retain their value as well as providing a stable foundation for future enhancements. Said simply, it may be more productive to maintain core business logic, enhance the UI, and use new programming languages for future enhancements. IBM i has committed that legacy code will be supported in the future along with the modern technologies and continual enhancements your business requires.
Incremental improvement to a stable platform is generally a low risk approach. Sure, the big bang approach of ripping and replacing is enticing, but the risk associated with a full-scale replacement of complex business systems can be overwhelming and often easily burst budgets and timelines. A well-planned incremental approach can eliminate a great deal of the risk...and the cost, yet still result in a gradual, less disruptive migration to modern systems which are inherently tailored to your organization’s needs. What’s more, with an incremental approach, you control the development of resources/personnel who have the skills to support these systems long term.
This of course assumes the organization has ready access to RPG and Cobol talent. Much has been written about the graying talent pool and the difficulty finding developers proficient in these languages. In a recent Tree Line blog, IBM i Skills Gap: Where Do We Go from Here?, we review this issue and offer ideas to bridge this talent gap. What’s more, enhancements such as RPG FREE are making the language more familiar and accessible to IT professionals with a desire to learn the environment. As well, our firm and others like it provide programming resources that can supplement existing staff or fulfill all your programming needs.
It should be noted that the maintainability of core business logic is all possible because IBM i technology has supported and will continue to support backward compatibility. So, what is seen by some as a weakness, the age and longevity of the platform, is truly its strength. When looking across the IBM i install base, it takes very little effort to find 30+ year old software that is still in service. This is both impressive and concerning, but IBM’s commitment to backward compatibility means that the investment in business applications can be justified in terms of decades of use. Undoubtedly a good thing.
Backwards compatibility also supports the practicality of incremental modernization as an IT roadmap.
It allows for modernization to be implemented on a manageable project scale. Biting off manageable sized projects can reduce the complexity and improve the probability of success over big bang implementation of replacement systems.
As well, projects can span OS versions and hardware upgrades with little concern about compatibility.
The concept of incremental modernization is not new, nor is it unique to the issues faced by companies running on IBM i; it is however worth consideration when reviewing options when existing systems are not meeting the needs of the organization. Incremental modernization is not a panacea for all modernization circumstances, but it does offer a pragmatic, manageable strategy for companies interested in preserving the substantial investment made in the systems that have served them so well over time.
Can Remote Workers Really Benefit Your IT Team?
Having worked from a home office for the better part of 20 years, and a large corporate environment prior to that, I’ve thought often about the tradeoffs between working remotely versus onsite. There are certainly pluses and minuses to both. In this post, I’ll share several observations regarding the advantages of working remotely. Also, I’ve been in the IBM i space most of my career and, while not a programmer, I’ve interfaced and worked closely with many technical folks throughout this time. As such, consider these ideas uniquely skewed towards the remote IT programmer/developer.
Focus – This may not be intuitive to everyone, but programmers need uninterrupted, focused time for detail-oriented work. It's heads down work that requires concentration. One developer told me each interruption could cost him a 5%-15% productivity hit based on the complexity of the work and how deeply he was engaged. Many office environments can be huge distractions for developers with interruptions like meetings that always seem to run long, office scuttlebutt, and challenging commutes. These distractions can leave little time to get actual work done while at the office. Additionally, this usually means developers must work way more hours than necessary, which can undermine productivity and morale. Remote workers have the benefit of a controlled work environment where they can often fend off unnecessary interruptions. This can mean more focus and greater job satisfaction.
Productivity – Productivity could certainly align with focus; however, I choose to segregate it because of its significance. The remote worker productivity boost is driven by a multitude of new technologies that have gained widespread acceptance in recent years and are enabled by the general availability of high speed internet throughout the country. I’m referring to highly reliable tools such as skype, slack, video conferencing, screen share and online whiteboards, along with the advent of powerful desktop computers and cloud computing. With these tools and many more readily accessible to remote workers I contend that productivity is at minimum equal to, and more likely exceeds that of onsite workers.
Flexibility – This involves life/work balance; however, a company can benefit by the workers willingness to work additional hours or off-hours when necessary because they do not have to deal with a commute and because they can do so from the comfort of their home. In turn, the worker is given some degree of flexibility to deal with personal issues throughout the day such as appointments or child care. Workers appreciate this level of flexibility which means greater job satisfaction, company loyalty and a willingness to adjust their schedules to meet the needs of the business.
Expenses – Office overhead including desks, workstations and associated infrastructure can add up to big savings for a company. Typically, the worker has very few additional expenses related to working remotely that the company is responsible for other than high speed internet.
Access to larger talent pool – When IT departments embrace the idea of remote workers, they expand the available talent pool from local candidates to a broad range of qualified personnel across a wide geography. This means the company often finds a better fit for the skills needed.
While discussing remote workers I should include mention of consultants and programmers for hire. Consultants offer additional advantages such as:
Commitment term – One of the underrated benefits of consultants is the ability to bring in additional help, in the form of an expert, who can hit the ground running without long term commitment and the associated costs involved with bringing on a new employee. You may really need someone with these skills and experience immediately but need someone with a totally different skill set in a few months and contractors provide this flexibility.
Cost – If you find the right consulting shop, rates can be similar to or sometimes more advantageous than the cost of a full-time employee when taking into account all expenses such as benefits. And again, you maintain the flexibility to change hours as business demands dictate.
I hope this brief review provides some perspective from the point of view of a remote worker. Please reach out if you have any questions or if you feel I missed the mark.
Considering Contract Programmers?
Our business is built around contract programmers. In fact, for more than 20 years Tree Line has provided contract programming services to AS/400, iSeries and IBM i companies. As a result, I approach this topic with some level of experience and understanding of both the benefits and complexities of working with contractors. I hope these thoughts provide some degree of value if you're considering looking outside your IT team for additional help.
I'd expect most folks consider it obvious that comparing the qualities of different individual programmers can be very challenging. It's difficult because everyone possesses different skills and traits including technical, analytical, communications, organizational, and more. These skills, along with a person’s experience combine to affect the ultimate quality of what they deliver. So, when considering talent it's often more about value per dollar spent than hourly rate.
Consider, for example, the cost of a senior level developer with, say 25 years’ experience versus a junior programmer with 5-7 years under their belt. While the hourly cost differential may be 25-30%, the depth of knowledge, time to productivity and results will likely far outweigh the hard dollar savings. Of course, the equation could shift in the opposite direction depending on the individual. When it comes to the proposition of using contract programmers these qualities can be even more important.
Here are a few areas to focus in on when considering contract programmers;
Programming skills: I’ll just call this a prerequisite, but it’s not trivial. Today, not only must a developer have up-to-date skills, they also must be aware of outside systems and interdependencies with those systems, along with trends and developments in tech. Most every system today has some form of integration with other systems and/or data outside of the entity. Long gone are the days when programmers worked in a controlled, isolated environment. Be sure the person or group you work with maintains current technical awareness.
Business analysis: Does your project require strong analytical and business analysis skills? It’s often assumed that a programmer brings with them these skills. However business analysis skills and programming skills are distinct from one another. While there are programmers that are adept business analysts, the skill cannot and should not be assumed. What’s more, if the project is not well thought out and does not consider the effect changes will have on the business it’s likely results will deliver far less value than anticipated. Take the time to determine the overall needs of the project - it may require more than a great programmer.
Communications: The process of software development, from start all the way through to deployment, is a communication intensive, iterative process. Results depend on active, ongoing, two-way dialogue throughout the process. Find an individual or team who understands the value of active communications.
Breadth of experience: It’s a good idea, but often overlooked, to consider how past project experience applies to your needs. Have they worked on similar projects? Are they adept at the key trends and practices needed for the project? Certainly important topics to explore.
Industry skills: Does your project necessitate the need for industry knowledge and industry concepts to be able to communicate with users and to recommend and debate the merits of various approaches?
Ability to keep project moving/work independently: Some projects demand project leadership. When a hurdle, bottlenecks or the inevitable mid-stream change occurs, that person or team knows how to push through, re-configure and keep on task. They are comfortable and experienced working within time constraints and under pressure. Depending on how much control you intend to exert over the project will play into how strong of a contractor is required. If your team can manage the project and keep tasks on target, then this may be less of a concern. If not, focus on references and understand performance under pressure and the ability to meet deadlines.
Quality: One of the bigger issues with consultants can be the quality of the code developed. How can you be sure of what you are getting? Maybe the best way is to find developers or teams that stand behind their work. Again, references and candid dialogue is the best approach to vetting candidates.
The process to find the right fit is not perfect and is different for each IT project and IT department. As with most endeavors, I've found that the more we put in by way of research of an individual's background and experience, the more we benefit with selection of the best fit. I hope these concepts can help you when considering contract programming.
IBM i Skills Gap: Where Do We Go from Here?
For the better part of 20 years, I've read reports about the “IBM i Skills Gap”. Not that I need to remind you, but for those new to the concept - The IBM i skills gap is generally defined as the shrinking of IBM i professional skills in the market, namely RPG, due to large numbers of boomers retiring and lack of new talent backfilling to replace them.
The common thought throughout our sometimes-insulated IBM i community is that this skills gap is solely an IBM i issue. In fact, it’s not an IBM i thing at all! Rather, the issue is more broadly an “IT” skills gap. That is, a lack of “IT” talent across all IT disciplines and industry sectors. Technology moves rapidly, as does the need for skills to support it. In fact, IT enrollment, and more importantly IT graduations, have been declining year over year on a percentage basis for quite some time. You may recall Jim Buck’s 2008 report from Wisconsin Technical College System that noted enrollment in IT courses declined by nearly 43 percent and graduations declined by 26.5 percent from 2002 to 2007 and with it there have been proportion decreases in IT curriculum's offered. While a bit dated, this trend remains today. You can find details and more up-to-date information from Jim here. What’s more, needs of the Digital Enterprise will continue to drive increased demand for IT skills across the board. This is exhibited by very strong IT job growth across IT disciplines and industries hovering at roughly 5 percent in 2017.
But, our interest is on IBM i, rather than the broader IT market, right? So, what makes our situation unique and how did we get here?
One opinion is that IBM was a key contributor. That’s right, while an unknowing participant, IBM designed a powerful system in the AS/400 and its successors and one of its primary concepts may have been a factor. This concept offered very important advantage to applications that ran on predecessor system – upward compatibility! Upward compatibility allowed companies to continue to run existing application code on new hardware and follow on operating systems, without the need to rewrite. The capability made a lot of sense and saved companies a great deal of pain and budget, but I suspect the idea was to provide a path to new systems with the thought that these older workloads would be enhanced over time, not maintained without change. Then miraculously 30 years later RPG II and III were perceived to be old. Go figure!
My belief is that upward compatibility contributed to a level of complacency not only with the older versions of code but also with the skill sets required to support the code. And, while IBM continued to bring new languages and interfaces to our platform, too often folks were complicit in staying with the tried and true. That’s ok for a while, but eventually it can catch up with us. Many companies that rely on the IBM i now face a great deal of IT Debt to support and update those less current application environments, and with it a skills debt as well.
IT departments may not have pushed hard enough; we may not have clearly and forcefully stated the case to remain current and as a result IT shops fell behind. But it’s not all doom and gloom, not at all! In IBM i, we have a platform that is modern and has bright future. As mentioned above, IBM has continued to deliver new, open and modern programming options such as Ruby, Python, PHP, Java, Node.js and RPG FREE!
The IBM i platform is still one of the best business computing platforms available. Its reliability is renowned and its capability to handle business workloads is unparalleled. What’s more, it’s a modern, secure platform. Leverage it, invest in the future of your systems and commit to your IT strategy as a strategic advantage in your marketplace! It’s time to upgrade, to modernize at a controlled, thoughtful and calculating pace.
Ok, enough of one person’s opinion regarding how the gap may have come to be - and of course there are a variety of factors that have contributed to today’s position, but how might we begin to bridge the gap?
In a word, Training.
While IT can be a great career choice, fewer students graduate with IT degrees each year as noted earlier. So, perhaps companies need to consider taking on the challenge. In his article, “The Skills Gap is a Myth,” Peter Cappelli, a George W. Taylor Professor of Management at Wharton’s Center for Human Resources, contends that company-provided training is decreasing and has been declining since well before the Great Recession. Employers are looking for plug n’ play workers because they can’t afford to train new workers, but at the same time they say they’re unable to pay higher wages or find the money for sophisticated recruiting.
Think back to how many RPG programmers got their start. I’ve heard quite a few stories about individuals in key roles outside of IT having an affinity to programming and eventually becoming the “guy or gal” who understood the business, the systems and how to make it all work together as the IT guru. Perhaps one of the keys here is to develop from within or hire younger individuals who are interested in learning the business and along with-it IT.
And training need not be for new employees alone. All employees should maintain currency with new trends, new technologies, and modern concepts to broadens their knowledge base and strengthen company competitiveness. Training should be a continuum rather than a once every 3-year event. And, isn’t training just another form of “professional development?” As such, it should be the responsibility of each employee as well to seek out opportunities to learn and expand their knowledge both on their own and on the job.
It’s a long road to make this happen, but the work is vital, and the rewards will be many. The transformation cannot be done overnight, so rely on key partners. Find partners who can help you get there; who can bridge the skills gap; who can help you begin the modernization process; and who can assist in developing your competitive IT strategy for the Digital Enterprise!