The App Dev World According To Gapp
June 5, 2017 Dan Burger
Somewhere in the tangle of business requirements and IT capabilities is the elusive goal of developing applications that perform well regardless of the device they run on. Can IT provide the user experience that meets the ever-changing business needs and users’ expectations? The answer, in many instances, is “not exactly.”
The evolution of business applications has created many distractions, disruptions, and dissatisfactions. In some organizations, the evolution is ignored – nothing changes. In other organizations, shadow IT worms its way into departments that operate outside centralized control creating disparate degrees of lunacy and sorrow. Steve Gapp has seen it all and his speculations carry some weight.
The world of application development in IBM i shops as well as app dev in other environments is fluid – efinements, revisions, and even revolutions are part of the scenery. At the COMMON Annual Meeting and Exposition last month Gapp spoke with IT Jungle about several factors affecting software development.
“At the conferences I go to, Shadow IT is in the top two or three concerns,” says Gapp, the president of LANSA, an IBM i application tool vendor known for its integration of IBM i and Microsoft Windows environments. Bringing a level of control to enterprise architecture and security with Shadow IT occurring outside the realm of IT and without consulting IT is problematic, he says.
“Companies that are trying to do better in that regard are focused on agile development and best practices. They are often the ones that have taken DevOps to heart and have used continuous integration, but a lot of companies struggle with this,” Gapp says.
“In many instances, there are different stacks running different apps. There are acquired businesses in the mix. The IT infrastructure can be really complicated. The senior IT folks are being pushed by the business side to shift workloads from on-site to cloud and it’s not always for the right reasons. The general, high-level reasons are because the business is not getting the expected level of service from IT. It takes too long to deploy and the cost is too high. More often than in the past, we are seeing IBM i shops that we’ve known for years migrating to cloud.”
There’s a certain inevitability that comes with migrations to the cloud because some organizations can’t keep up with the pace of IT metamorphosis. Many are lured to the cloud to shake the IT responsibilities and because of cost reduction seduction. However, Gapp warns that decisions to move to the cloud with expectations that it will save money can be erroneous. Cloud-based projects that begin with one VM and a couple of users are inexpensive, but when the goal leads to hundreds of users and many VMs, the costs can easily reach unexpectedly high levels each month.
“When you see requirement lists that are longer than what has been achieved, and the business is pushing them to do more with less, then you see a struggle to get a coherent development plan,” Gapp says. “There is nervousness about whether to stay on the i and develop Web and mobile apps, or sometimes legacy .NET apps are a factor, and cloud is being talked about without a real strategy for new development.”
Regardless of the reasons that cloud discussions are brought to the table, Gapp believes the topic of changing platforms can actually benefit the IBM i platform. When the discussion includes producing modern applications while remaining on the platform, a light goes on. In many cases, it is presumed that modern applications cannot be accomplished on the platform. Realizing that it can be done puts another option in the deliberations.
“The i is its own worst victim,” says Gapp, the president of LANSA, an IBM i application tool vendor. “One comparison that I’ve come to see that past few months – because I go to a lot of CIO and non-i events – is that the brilliance of the IBM i is that it still allows System/36 code to run. But with human nature being what it is, nobody does a damn thing unless they have to. And with new executives coming in to a lot of shops, they look at what they have and decide they will bring in a system they know (Microsoft) or bring in a cloud system to replace i. Even after a decade or 15 years of modernization tools available for IBM i shops, not a lot has been done.”
When you look at 15 years of modernization tools, a great deal of progress becomes evident. The degree of automation is a big improvement. Many of the features and functions that once required hand coding are now built into the tooling. LANSA, for instance, uses templates and widgets and includes rules in its code repository that provide short cuts that formerly caused duplicated coding efforts. The coding encompasses business logic and what make the application unique for certain industries and specific companies or organizations.
The term “low code” is now widely used to describe tools used for enterprise application development that is distinguished by its reusable components that make it possible to add functionality by modifying existing applications, creating composite applications and adding new user interfaces.
Low code application development tools are defined by software tooling with drag and drop and visual capabilities. They minimize the hand-crafting of applications and simplify the configuration of data models and data integration. When customer feedback dictates changes be made on a daily or weekly basis, low code speeds the process.
“Low code is a recognized area and there are myriad competitive tools in the space,” Gapp says, while pointing out that Visual LANSA is a good example.