We recently held a webinar that addressed a rising trend in the use of declarative development styles, and one of the main themes cited by guest speaker, John Rymer, VP, Principal Analyst at Forrester, was the increasing popularity of using low-code solutions to build enterprise applications.
Declarative development is a spectrum of techniques and tools used to create applications, and there are numerous vendors in the market. Some of them provide tools that eliminate the need for code. Some mix visual development and coding, where you might develop in low code and exit to JavaScript. Still, others offer a code-behind approach, where you can work in declarative views but also in the code behind those views, switching between a visual representation of the software you are building and the representation in code.
There certainly are lots of variations, but all are OK. Your development choice depends on the business you are and how your developers choose to work. Sometimes it can be faster to write code, but sometimes it’s faster to use a declarative tool.
But the trend toward low-code development solutions can’t be ignored. Half of developers are now using or are planning to use low-code platforms, according to a survey of professional developers. The level of adoption will only continue to grow.
That’s because declarative development, moving from code to a more visual representation of defining elements and drag-and-drop workflows, can significantly increase productivity. And while the speed of development is undoubtedly the foundation for the choice to use low-code platforms, businesses also choose low-code because they:
- Have a healthy appetite for growth and innovation
- Want to use technology to improve the customer experience and increase revenue
- Are looking to decentralize app development talent
Too often, critical development resources are tied down maintaining a state of legacy applications and they don’t have time to work on projects that drive business growth, or businesses are rethinking how they organize development and are looking to empower business units to serve themselves as citizen developers. This democratization of application development means business users require more accessible development tools, ones designed for their skill sets.
But it’s also the types of apps that low coders are building that’s really interesting. It’s not just web applications, customer-facing apps, and apps for automating business processes. Developers are using low code to modernize core business applications, such as ERPs. That’s because many of these mission-critical business apps are old and require more flexibility for today’s business needs, and low code is being leveraged to modernize and automate these key technologies.
Keith Arteaga, IT manager for Brunswick Bowling, joined the webinar for a Q&A to talk about the low-code approach Brunswick took in modernizing a critical quote-to-cash application, an app that supported one of the most complicated and biggest revenue-generating parts of Brunswick’s business. And this critical tool was created using the LANSA low-code development platform.
[sc name=”low-code-hype-vs-reality-white-paper”]
Q&A with Keith Arteaga, IT Manager of Brunswick Bowling
Give us some background on Brunswick Bowling.
Brunswick Bowling is a global company that’s been in business since the 1800s. We are a small to medium-sized business with a wide product line. And that makes it a very complex business. We sell equipment — so there’s contracts and installations involved. We sell parts and supplies, and we also sell products like bowling balls, bags and shoes to consumers, which are very different kinds of business processes. And we sell and distribute everywhere, from Pakistan to the White House.
What was the major use case that prompted you to look at low-code software solution?
We had a quote-to-cash system for capital equipment business. It’s one of our most complicated and highest revenue parts of our business. It managed all the interactions over long sales cycles — sometimes up to 18 months — between the sales force and the customer, contract managers, freight, credit approval, etc. The app was built in Microsoft Visual Basic on an old database, so it wasn’t really a relational system. But the developer who built it left the company, and the other developers weren’t that familiar with developing in a Microsoft stack. It was an application critical to our business, but it had to be rewritten. It wasn’t supportable in its state.
How did you approach the project?
We couldn’t collect revenue and grow without this application, and we wanted to make sure we didn’t make the same mistake of having a one-off application. We wanted an environment multiple people could use and one that was data independent. We also wanted it to be web-based so we didn’t have to distribute software to our people all over the country and even out of the country. So, we had this list of needs that we had to go shopping for.
When you tackled this — before settling on LANSA — did you look at an open-source strategy?
We did. We had a team member experimenting with web-enabling some of our legacy ERP applications. He had cobbled together some open-source libraries that we had embedded, and it worked for the most part. But when we tried to teach people how to use it, they raised a lot of concerns about standards, maintainability, and longevity of the application. They were concerned that this approach was too loose for this critical app and for some of the other projects needed in this area of our business.
How did you discover and adopt LANSA?
Probably a Google search. LANSA has a lot of experience with the IBM i, one of our back-end technologies. LANSA jumped out at us for that reason, and LANSA stood out with what it had with its visual framework. LANSA brought people into our office to do a free proof of concept, coding up part of our use case to show us how it works. It was a nice little workshop with our developers in the room. When they were done, our guys just said, “Yeah, LANSA meets all of our requirements.”
Were there specific requirements you required?
We really wanted a single platform. My team is older and not accustomed to client/server-type development or web development. So, we wanted one platform to handle the UI as well as the back end, and LANSA checked that box. They also had some frameworks we could use, so we didn’t have to build out menus and security from scratch. LANSA had a prebuilt structure that fit the project and helped build out the framework. We also wanted a vendor that has good technical support, with a person to call when we need help. And finally, we needed mobile support. LANSA demonstrated a vision that enabled our legacy ERP guys to build apps that you can actually use on a phone.
Were you able to deliver the app on time? Tell us about what you were able to accomplish.
We were able to deliver an app. It was a very complicated app, with 40 or 50 screens, covering many business processes — uploading/downloading documents, sending emails from the app, etc. But once our guys spent some time learning the toolkit and doing online training with LANSA for a few weeks, we launched the app with 100% cutover. It was well-received, very few issues, and it brought all that information into other existing IT processes — business intelligence, automated file management, and workflows we do with other systems. We even had a guy who wasn’t an app developer, who was more of an infrastructure guy. He picked it up very quickly and is now part of our team working in the LANSA environment.
You had a number of people you had to serve with this app. Did you prototype it and get feedback?
Yes, we used LANSA along the way to demonstrate screenshots and flow, and different use cases. We met with users every couple of weeks to ensure we were on the right course and that they could get behind it. It worked out well.
Did you deliver this application faster than the open-source approach you were looking at?
Yes, our developers were productive after just a little training. Using LANSA was faster when we were showing stakeholders along the way, making changes, and course-correcting the product with users. And after we launched, being able to fix a bug and add functionality are not only faster, but the team now prefers to work in the LANSA environment. We also did an add-on to the application to enable our field service team to schedule their work. They’d been using various spreadsheets for scheduling, and we replaced that approach with a lighter app … using the Google Material Design framework from LANSA. We just showed our users how to use it on their phones. We wanted to get the functionality down to the phone, and the framework from LANSA made it very easy.
Do you have any advice for an IT leader looking at low code?
You have to think about the business, and that means maybe you let go of some control of the development environment. Developers tend to spend way too much time on details and sometimes just have to accept what the tool has to offer. After all, you’re trying to deliver business value. There’s still a bit of learning the low-code solution at first, but that’s because LANSA offers a very robust toolkit. Our old dogs learned new concepts relatively quickly though. And also, your vendor has to invest in the platform and communicate its vision. And LANSA has done that, consistently innovating and adding new functionality.
Learn more
Delivering a complex core application is never easy, but Brunswick Bowling did just that using LANSA. Brunswick took an existing core-business application and used LANSA to modernize it so the app could more efficiently serve the business. You can read the full case study of how Brunswick Bowling built its full-stack, enterprise-grade app using LANSA here.
To learn more about LANSA’s low-code development platform and how it can help increase developer productivity and reduce costs, visit www.lansa.com.
