Coming Attractions: The IBM i App Dev Multi-Platform Show

November 13, 2017 Dan Burger

Multi-platform development is more vision than reality. Application development is still a siloed environment as programming work remains more isolated and less collaborative than visionary thinkers wish it to be. Therefore, the existence of multiple programming environments within an organization seldom reaches the goal of operating as a team. Much of the potential benefit of teamwork lingers out of reach. Instead of a single team with common operations, there are individual teams with individual operations.

The good news is that it’s better than it used to be. Still, the fabric of multi-platform unity and the efficiencies it would bring to the development process provokes skepticism based on a track record that is less than exemplary.

That’s all water over the dam, right? We’re more comfortable in our heterogeneous world than we were just five years ago. Actually, comfort probably has less to do with it than a heightened threat alert because enterprise computing is changing and adaptation is a better choice than extinction.

Multi-platform development is just one way enterprise computing is changing. Decision makers, pushing the right buttons, have adjusted their IT plans to manipulate upticks in productivity and reductions in costs based on a variety of choices.

The shrinking of specific app dev teams is not new. Attrition seems to be the leading cause of this disease, accompanied by much wailing about the dwindling access to skilled workers. That’s another story — one that IT Jungle has written volumes. Consequently, we see the consolidation and coordination of multi-platform teams becoming more widespread.

As programming challenges become more complex, organizations will be creating multi-platform development teams based on key performance indicators and addressing the gaps in the current operating model that solves business problems in the traditional siloed fashion. Targeting organizational structure and legacy technology in an evolutionary world. Many of the technical and business constraints from 20 years no longer apply and technical capabilities, in particular, have expanded beyond what was imagined just a few decades ago. The businesses landscape has been transformed putting pressure on established organizations to keep pace and stay competitive.

Along with change, however, comes entrenchment – a belief that what’s in place is superior to “the next best thing” and a wariness that technology is routinely hyped with promises that later prove unreachable. There’s also a pattern of software sales cycles emphasized to the point where businesses are distrustful of the upgrade treadmill. In the extreme, we’ve seen organizations push upgrade cycles out farther resulting in deeper entrenchment sometimes becoming stuck with only difficult and costly options to advance.

Resistance to change and preservation of status quo are formidable barriers. In many cases, it’s the first and last barriers to change. But as operational efficiencies are put under the microscope, traditional organizational boundaries are being erased in the quest for better economies of scale and logical workflow processes.

Often overlooked as transitions take place is the investment in employees. Change doesn’t occur without the acquisition of new skills and the dissemination of information about the transition. Knowledge of how to do the job more effectively as individuals and as a team doesn’t just happen. A culture of training and education needs to be in place before people are open to sharing responsibility and producing positive results. When barriers to success show up, they won’t disappear by pretending they don’t exist or will melt away in time.

Large enterprises, as they often do, lead the way in deploying multi-platform code and controlling it from a single central point. They are utilizing standardized tools and methodologies for managing all code whether it was created to run on IBM i, z/OS, AIX and other Unix OSes, or all the open systems.

What we’ve seen so far is multi-platform consolidation has taken hold to a much larger degree outside of the core IBM i community. In some cases, these are organizations with IBM i in the mix, but not in a dominant role. Regardless of the role, the IBM i environment becomes part of the multi-platform mix. This is also the scenario where IBM i and open source development are most likely to cross paths. The lessons learned will surely be applied in organizations where IBM i has a dominate role.

RPG, by a wide margin, is the programming language of choice for IBM i development. However, other languages such as Java, .NET, a few fourth-generation options and a growing list of open source options led by PHP make multi-platform development in IBM i environments an inspection station for potential collaboration.

Most IBM i programmers believe that RPG is the best language for writing business apps. Even those who know multiple languages choose RPG for business apps more often than not. Developers that come from backgrounds outside RPG have their own tools and procedures; some are closer to RPG than ever before, which makes cross-platform development easier than it once was. IBM’s RPG roadmap has narrowed the gap between RPG and other languages and this trend is expected to continue. Support for open source software on IBM i has been a point of emphasis and a growing and active community has taken shape.

Automation is a major asset as it replaces manual processes in multiple development environments. Development from the first line of code to the final deployment is ripe for automation and an efficiency upgrade. The days when development with trial and error testing after deployment are inefficient, reckless and will be fading away soon. Multiply the old, error-prone ways by the number of development environments working independently and it’s not difficult to discover operational weakness and cost leakage. Improved testing and integration, along with impact analysis that applies to multiple platforms are a few examples of benefits that will change the way development is done.

Nevertheless, there are challenges to putting together a team made up of parts that are unconvinced that unity for the sake of unity is a worthwhile goal when each is capable of operating independently with results that if not entirely efficient have not been disruptive.

However, maintaining status quo is not likely to show major progress on any organization’s commitment to operational efficiency, which will not go unnoticed by executives much longer.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search