Avoiding the Pitfalls of Low-Code - Read the Report

Low-Code Mobile App Development and Data Integration - LANSA

Low-Code >> High Control

Build web and mobile apps faster, easier and more affordably

"LANSA provides a very good base system and flexibility to customize it to our business needs... We can build apps to suit our processes."

Infosys Manager, Kawasaki

Learn how Kawasaki builds apps faster with LANSA >

Business Innovation Without Limitation

Low-Code Platform

LANSA's low-code development platform accelerates and simplifies the creation of enterprise apps while making your development team more productive. LANSA puts you back in control.

IBM i Modernization

LANSA is the only low-code development platform to natively support IBM i. You can build new apps and modernize existing ones - with native web and mobile support

Mobile Development

LANSA makes it easier than ever to take your apps mobile. Build mobile-first apps as easily as web apps using a single platform.

Enterprise Integration

LANSA offers powerful integration choices for your web and mobile apps. We support a range of options to make integration fast and easy.

Digital Transformation Through New Apps

LANSA’s low-code development platform impacts every area of the business, delivering company-wide innovation, productivity and control.

For IT Managers

LANSA lets your team create apps up to 10x faster than usual, reducing the time- to- market for new apps and helping clear your application backlog.

For CxOs

LANSA equips your IT team to innovate and deliver new apps in the time frame the business needs. Your team becomes more productive and responsive.

For Developers

LANSA’s low-code platform allows you to become a full-stack developer delivering web and mobile apps faster and easier than ever before.

For ISVs/SIs

LANSA’s low-code platform helps build easy-to-maintain apps for your customers, reduces time-to-market, and makes your team more productive.

“With LANSA we can help our customers be more agile and responsive to new business requirements. That's extremely important in the transportation industry. Enhancements and customization are now simple and fast, meaning that we can respond quicker to customer requests.”

“With LANSA we can help our customers be more agile and responsive to new business requirements. That's extremely important in the transportation industry. Enhancements and customization are now simple and fast, meaning that we can respond quicker to customer requests.”

“With LANSA we can help our customers be more agile and responsive to new business requirements. That's extremely important in the transportation industry. Enhancements and customization are now simple and fast, meaning that we can respond quicker to customer requests.”

Glenn Gundermann, Application Development Manager, Nulogx

“Our ERP system happens to run on IBM i, which is often and mistakenly earmarked as a legacy platform. Using LANSA and with a renewed focus on our existing ERP system, we have proven to be more flexible and productive than a packaged ERP like SAP ever could be.”

“Our ERP system happens to run on IBM i, which is often and mistakenly earmarked as a legacy platform. Using LANSA and with a renewed focus on our existing ERP system, we have proven to be more flexible and productive than a packaged ERP like SAP ever could be.”

“Our ERP system happens to run on IBM i, which is often and mistakenly earmarked as a legacy platform. Using LANSA and with a renewed focus on our existing ERP system, we have proven to be more flexible and productive than a packaged ERP like SAP ever could be.”

Arnold Hendriks, Application Development Manager, Bidfood

“The LANSA portal is a crucial part of our digital strategy and plays an important role in remaining competitive. It offers a new way to add value to our services, above and beyond just selling a product.”

Michael Hall, Head of Digital, Elders Rural

previous arrow
next arrow
Slider

Trusted by thousands of organizations worldwide

Go Faster with LANSA

LANSA has been speeding the productivity of professional developers for over 30 years. We help you deliver enterprise-grade applications faster than before because you can build mobile, web, cloud, and desktop apps from one powerful platform.

Application Modernization

Top Ten Reasons Application Modernization Projects Fail

Guest Blogger: Paul Conte, President PCES, is a leading Application Development Strategist

Are we done yet? With “modernizing” our applications, that is?

It seems so long ago that someone came up with the clever concept of application “modernization” as a response to how outdated AS/400 applications looked by comparison with graphical Windows applications.

But now, even after years of screen-scraping, “refacing” and crash courses in Java, there still exists an unfathomable mountain of monolithic RPG applications that – dolled up or not – simply don’t serve modern business needs.

Why have so many attempts at “modernization” failed to deliver? Herewith are my own “top ten” reasons, listed somewhat in the order I’ve seen them occur in many IBM i organizations:

1. Focusing just on the user interface

Of course the 5250 interface was the most visible evidence that AS/400 applications were dated, but even the best efforts at “refacing” can’t deliver the application integration, “anywhere/anytime” access and the multitude of other capabilities a truly modern application needs to deliver.

2. Trying to solve the problem with “better RPG”

So let’s fix the code then: Switch from RPG III to ILE RPG, start using SQL for database I/O, use procedures to increase modularity, even code routines for a web server to provide a browser interface.

Efforts of this sort can seem promising at first, especially to top-flight programmers whose work environment lets them get enough time away from critical maintenance tasks to learn and apply new skills. But this approach soon falls behind the demands for supporting new business needs, including expanded functionality and  support for new technologies.

The problem is that ILE RPG serves such a small community the language hasn’t kept pace with more, yes, “modern” languages in terms of capabilities, procedure libraries, code frameworks, training and the peer support provided by a large, talented community of developers.

3. Trying to solve the problem by switching from RPG to Java (or C# or PHP or …)

Some IBM i organizations saw Java as the answer, and who can blame them given the sweeping promise of this new language and the supporting infrastructure? But early adopters were burned by the steep learning curve, gaps in critical capabilities necessary for business applications or performance problems.

Java and associated technologies are now mature enough to run serious business applications, but two problems remain. First, for IBM i shops, maintaining both ILE RPG and Java skill sets is difficult and the two languages don’t interoperate in a natural way.

The other problem is that Java remains a complex language and environment to use for business applications. Despite being a genuinely more modern language than ILE RPG, Java applications still require developers to be responsible for a lot of “plumbing” code. Similar considerations apply to C#, PHP or the other popular language choices.

4. Not capitalizing on the value of current application assets

Despite the obstacles that coding in ILE RPG and/or Java present, some organizations have hired the necessary staff and consultants to grind out the code for a new application or a relatively independent addition to an existing application. There are many success stories of this sort, especially when you consider the many applications that have been written in “plain old Java” for platforms other than the IBM i.

Yet, when you examine the results within IBM i shops, this approach doesn’t generally produce integration among the old and new applications and is often practical only for a fairly limited set of applications because it’s too expensive and risky to “rip-and-replace” the entire “legacy” application set.

5. Developing without an application architecture in place

Many of those IBM i organizations that evolve this far seem to then hit a wall at which point efforts to deliver truly modern, well-integrated applications stall for lack of a practical strategy for agile, productive and reliable application development.

My view is that organizations who get stuck at this point have failed to lay out a suitable enterprise application architecture.

An application architecture describes how a set of building blocks and principles should be used to design, implement and adapt applications that fulfill the enterprise’s business objectives. A well-thought-out application architecture not only provides a conceptual structure to guide developers; the architecture lays the foundation for a corresponding framework and tool set that can automate much of the application development effort, an essential prerequisite for greater agility, productivity and reliability.

A sound enterprise application architecture can take many specific forms, but there are eight “pillars” I believe should always be in place. The architecture should:
Pillar #1 – Be based on a framework
Pillar #2 – Provide an application repository
Pillar #3 – Provide automation and developer guidance
Pillar #4 – Be based on a service-oriented architecture
Pillar #5 – Support multiple platforms
Pillar #6 – Support multiple application interfaces
Pillar #7 – Integrate legacy applications
Pillar #8 – Manage application evolution

My white paper “The Eight Pillars of Enterprise Application Architecture” contains more information on the application architecture topic.

6. Not following a business-driven approach to goals and priorities

I’ve seen numerous successes when an organization puts in place a sound application architecture along with supporting tools and training. But some modernization projects still fail due to reasons that apply to almost all business application development.

The first of these is that the IT group sets its goals and priorities based on technical, rather than business, drivers. Every significant development undertaking, whether it’s maintenance, “modernization” or brand-new development, should have a sound business justification and a business sponsor.

Otherwise, you build the wrong thing; or you build the right thing, but no one cares.

7. Not delivering real value early and often

Other than Warren Buffet perhaps, everyone these days seems focused on short-term risks and returns. If you want to keep the support of your business sponsors, don’t plan to deliver them twenty-five “units” of value in a year – deliver then five “units” every quarter. They get less by the end of the year, but I guarantee you they’ll be much more content as they see your organization delivering real value continually and consistently. And, in just one more quarter, your “customer” will get the other five units anyway.

8. Not using an iterative and incremental project structure

There’s only one real “silver bullet” for managing risk in application development projects, and that’s to use an iterative and incremental approach. Basically you repeat a “plan, deliver, feedback” cycle to deliver working versions of applications that add functionality in smaller increments, rather than as a one “big bang” near the end of the project.

This approach lets you deliver value early and often. It also reveals “what you don’t know you don’t know” as early as possible so you can adjust your targets and/or methods, thereby greatly reducing risk of failure.

9. Ignoring interoperability

Interoperability is one of the hardest problems to deal with in application development because which other applications your applications must interoperate with, and how applications interoperate, changes constantly. Thirty years ago “interoperability” meant procedure calls in the same language on the same system, today “interoperability” requires communication across languages, platforms and disparate devices using evolving protocols.

A sound application architecture must provide the ability for data and service exchanges up and down the software stack from simple method calls to long-duration transactions. Building on this foundation, enterprises can realize significant benefits through faster, more effective interactions with trading partners, as well as through the efficiencies and service improvements that can be gained from enterprise workflow automation.

Failure to plan ahead for pervasive interoperability will severely limit the ultimate success of any modernization effort.

10. Not getting the right people on the bus and in their right seats

And finally, it all comes down to the people. As Jim Collins’ advises: Get the right people on the bus, the wrong people off the bus and everyone in their right seats.

For many IBM i shops, the key is to make sure the “right seat” is available for your most productive and reliable developers. That means putting in place a solid strategy, beginning with an enterprise application architecture and providing the tools and training to enable your staff to maximize what they produce.

As to getting the wrong people off the bus, don’t feel too bad. There’s always another IBM i shop down the road that still thinks “application modernization” means screen-scraping and who’ll be looking for programmers who’ll be satisfied with that approach.

Author:

Paul Conte, President of PCES, a consulting and educational service company in Eugene, Oregon. Paul has been a software developer and consultant for more than 20 years and is a widely published expert on application development, programming languages and database systems/design. Paul's articles have appeared in System iNEWS, DB2 Magazine, Database Programming & Design, and numerous other publications. Paul is a well-known speaker and author or co-author of seven books.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.