Last week we heard from Eric Rawlings, CTO of Digital Risk LLC, the largest independent provider of risk, compliance and transaction management solutions – and number 122 on Inc 500’s America’s Fastest Growing Private Companies. Rawlings and Mendix VP, Adam Clay, presented an engaging question and answer session that covered topics ranging from technical challenges for the fast-moving financial services innovator, why the Mendix App Platform was chosen over BPM (Business Process Management) tools, and how they’ve used Mendix to support rapidly changing business and compliance requirements in the mortgage industry.
Check out some highlights from the question and answer session below, or watch the full webinar on-demand here.
Adam Clay: First off, and to set the stage, could you give us your perspective on the industry or technology dynamics that have impacted your approach to application delivery in the past few years.
Eric Rawlings: There are a lot of fast-past changes driven by regulatory reasons, risk, and we’ve found that our application development customers need to have working solutions and they need them now. So waiting several years or even six months, is no longer acceptable from a business standpoint.
Adam Clay: What’s your perspective on this trend, certainly that we see, away from traditional development methods say, building applications on a platform like Mendix. What are the key drivers for you and other organizations like yours?
Eric Rawlings: I’ve been a software developer myself in the past for many years, and I get some flak for saying this, but I honestly believe that for the vast majority of us that are developing custom business applications; that custom development is going to fall away over the next five to ten years. And I say that for a couple of reasons:
Custom development simply can’t keep up with the business, not easily. I constantly hear the business and our clients saying “We need application capabilities; we need you to enhance and empower the business with these applications, these applications or their development can’t slow the business or limit the business in its growth potential.
Technology itself is quickly changing. That’s always been the case, but there are new dynamics. Globally, platform as a service is the next step in a long evolution of advancements within application development. Some of us remember the transition from C++ to Visual Basic. Then you have some of the database development applications that sped development – PowerBuilder, Foxpro, Microsoft Access. In fact it’s amazing to me how many of these tools you still find today in organizations because in their day, that was the fastest way to make business applications. And then later you had the ERP, CRM application space, that in recent years have turned more to business process management applications. And so, I look at Mendix as an application platform to be the next generation of those BPM applications. And remember at the source of all this, as IT leaders and service providers – if we can’t align ourselves with the business in a lock and step manner, and produce what the business needs when the business needs it – we really serve no purpose.
And finally, from a technology standpoint I think that there’s a couple of drivers here too that are worth mentioning. As application developers we constantly find ourselves worrying about browser applications, but now we have flavors of smart phones, tablets, and smart televisions. All of these things drive complexity in the application landscape where hiring developers that have all these skills, is no longer as valuable as it once was. I can’t have an army of 20, 30, 40 developers with their own specialties to produce one app that needs to be delivered in multiple channels. Even if I could produce them that way, as expensive as they may be, our applications need to be supportable. Like business rules that we find in all of our apps need to visible, understandable, and documented. Custom development platforms, with their embedded business rules that seem to be hidden, are basically problematic. So when you’re talking about application development using something like Mendix, I believe that a lot of those challenges have been removed from that space and we’re allowed to concentrate on the core reason we develop which is serving our customers, both internal and external clients, as opposed to the nuts and bolts of how all that goes together.
Adam Clay: How would you contrast an application platform based approach to application delivery, with say, something like a classic BPM tool. I know that lots of organizations we work with get hung up on teasing out the differences between the two.
Eric Rawlings: I get asked that question a lot. In fact when we evaluated Mendix originally, we had some folks who were obviously familiar with BPM tools. I tend to segment BPM tools into a space I call BPM applications. There are some key differences between BPM applications and a tool like Mendix. One of them is the fact that with Mendix there’s as little application overhead as necessary for the application design. If you’re faced with a business challenge that needs to be solved with technology, and you have a BPM application to use to solve that problem, you have to ask yourself: How much of the application suite would I have to fire up to make a simple “hello world” application? And when I look at pretty much every BPM application I’ve ever seen, there’s a lot that goes into doing that, meaning there’s a ton of overhead.
The other thing you don’t always get with a BPM application, is full control over the execution speed of the app and the look and feel of the application. When you’re dealing with mobile applications or cross browser applications, sometimes the BPM applications have forced you into a box, and if you conceive your applications exactly how the application developers that developed the BPM application saw you using the application ¬– you’re fine. But one of our concerns when evaluating some of those tools in the past, is that our business is constantly throwing challenges at us. If we encountered something that the developers that developed the BPM app didn’t consider – then we may be stuck in the same cycle of waiting six months to a year or more to get that feature added, and we just can’t have that. So we have to have what I call a full application development suite, with Mendix.
And when I say suite, there’s really a lot more to it. It’s not just a development tool, but it provides full featured functionality. Things like code control repositories, team development, full change management tools and traceability, ways very quickly within the application to get user feedback and factor that back into the development lifecycle so we’re able to hear what customers are saying and quickly act on those things, and get them deployed. I think that’s really a key difference; it really is a full featured development platform as opposed to a narrowly focused BPM application.
Adam Clay: How does the ability to change or adapt quickly figure into your business and how is that driving the technology decisions you make today?
Eric Rawlings: We’re always going to have business challenges thrown at us, and some of those are foreseeable and some of them are not. And as I mentioned earlier, whether it be a business need due to regulatory reasons or risk management compliance reasons, we have to be able to provide what the business has asked for. I consider Digital Risk as an ‘outsourced service provider’ for the financial services industry. We’re in fact in competition with our clients own IT department. The reason they’ve come to Digital Risk is that there’s a need that’s not being fulfilled, and if my answer to the need is that I need six or twelve months to deliver a functionality – if their IT group can produce that in the same amount of time, there’s really no benefit from a technology standpoint to working with Digital Risk. We have to stay one step ahead, I’ve got to be able to make those changes quickly, and whatever tools we choose to build our application, I’ve always got to keep in mind to expect the unexpected and be able to safely provide application advancement with sophisticated tools that might not be present at our client in order to give them a benefit to partnering with Digital Risk.
One of the things we’ve learned with Mendix – and I never would have thought this was possible, was that prior to Mendix we had a change-cycle of about a month to once-per-quarter depending on the application. I actually foresee a day with the Mendix applications we have today, where we could actually safely do that on a weekly basis. I don’t know of any companies that would say “I’m going to produce weekly releases of an application – safely.” Certainly you can do it, but there’s a lot of risk in that, and I honestly feel like with the amount of comfort we’ve gained with Mendix over the last year, we’re already once every two weeks or so, and we’re going to pull that in and support even up to a [change-cycle per] week. And that’s certainly very different from six months.
Adam Clay: What are the most important ROI drivers for you when it comes to application delivery?
Eric Rawlings: In the past, I’ve heard software development really looked at with a black box mentality. You throw a bunch of money in, and requirements in, and you hope that at some point you get some value out. Typical budgets have included things like infrastructure, hardware, software, developers, the management of that process, and as a product and services company you have to measure ROI in ways that are non-IT ways. Meaning, there’s certainly an opportunity cost to developing an application that takes a year and possibly losing a market space or losing out to a competitor because it’s taken a year, or in our case, losing out to our client’s own IT department, so I have to look at opportunity cost. If a loan underwriter can close a loan faster using one of our applications, that value can be measured. It’s not measured in number of IT hours necessarily, but if I can close that faster – what’s the customer benefit of that based on me being able to adapt the application or quickly make a change required. Or if I can speed up the job of a forensic underwriter so they’re completing their job ten minutes faster, times 800 or 900 underwriters doing that job – that’s easy to measure.
But there’s another cost that’s not so well understood sometimes, and that’s really the cost of change itself. Change can work for the business, or it can work against the business. We’ve certainly had our share of missed opportunities or mismanaged development where we produced a change and it either doesn’t meet the approval of the business or it has a bug that impacts the business – so application delivery to be truly effective has to be reliable and predictable. It really has to be a win-win for IT and the business. So in choosing an application framework, rapid application development and agility are great things, but it’s also important that we understand how to quickly make change – safely, cost effectively, otherwise we’re back to square one with the business, back to where we’re irrelevant. So there’s different ROIs that factor into application delivery as opposed to just looking at IT as a cost center, like it historically was.
Adam Clay: Do you have some benchmarks of how this approach [Mendix] has sped your time-to-market?
Eric Rawlings: Sure, this is actually the most exciting thing from my standpoint about Mendix that we’ve observed. We’ve been using Mendix for just over a year. We’ve completed three Mendix applications in that year. The most recent Mendix-developed product that we released was developed over 300 percent faster than what we had quoted the development to be in Microsoft .NET. And what’s more amazing about that story is that the application that we had quoted the change to be made in, the .NET application, it was an existing application – it wasn’t something that we were creating from scratch. So we, in fact, re-developed the application with Mendix, duplicated all of the existing functionality within the existing .NET app, added all the new functionality, and still completed it three times faster than the quote was for the modification to the .NET application.
Some of the other benefits that we’ve observed: We’ve really found that there’s less [quality control] time being spent. There’s really just less chance for errors. Some of the common stuff we see over and over in .NET regardless of how much testing and code reviews that we do, we’ve seen go away with Mendix. We’ve also found that our requirements engineering phases have become more streamlined. There’s actually less upfront documentation required, and more collaboration between business analysts, business engineers, business leaders – it’s really bringing IT together with the Business. I think that that’s probably the best example. The tool itself has proven to really speed up the requirements process, and really get to the meat, which is building and releasing the app, as opposed to just planning to do it.
Lastly, when you factor in the cloud hosting – so it’s very easy to spin up an application that you’ve developed, or spin up a test environment to test the application – that’s certainly helped our cost situation from the standpoint of developing the apps. Overall, I’d say our approach has become more supportable, the business is more competitive as a result of using this, and we’ve saved a ton of hours in development time.
To listen to the full webinar, click here.