Blog

Gartner Gets It Right with MASP (Almost)

Written by Terence Bennett | July 6, 2018

We have been a Gartner subscriber here at DreamFactory Software for quite a few years, and they provide a great service to help companies understand technology trends and customer needs. I have watched with interest as they have refined their recommendations for mobile application development in the enterprise. They started out with vertically integrated stacks and moved to loosely coupled client-server configurations thereafter. Along the way, they changed the name of the platform a few times, including a Mobile Application Development Platform (MADP), a Mobile Enterprise Application Platform (MEAP) and then finally a Mobile Application Integration Platform (MAIP). They produced quite a few different architectural diagrams as well.



But earlier this year, the Gartner analysts hit the mobile development nail squarely on the head. The new "Mobile Application Services Platform” (MASP) is exactly the right message for building mobile applications in the Enterprise. In fact, their new diagram matches very closely the architectural diagrams that we have been using to explain the DreamFactory open source REST API backend for years. Here is their new picture, followed by our old one. As you can see, they are advocating a middleware platform in the blue box hooked up to backend data sources at bottom. The client applications are loosely coupled with API interfaces on the top of the picture. The legacy stack of “existing apps” is somewhere off to the right.

Their description of this diagram is also similar to the language that we have been using. For example, they are recommending that companies should “build a flexible mobile app integration framework, and use it for all new app projects... and cleanly separate the need for front-end development from back-end services.” This is from their report “IT Organizations should focus on Middleware to Enable Mobile App Development,” released in June 2015. At DreamFactory we call these "reusable" services instead of "flexible," but otherwise you get the idea.

Close, But No Cigar

And while the flattery here is no doubt sincere, there is unfortunately a big, big problem with this recommendation. Read the first sentence again, the one recommending that companies “build a flexible mobile app integration framework, and use it for all new app projects.” The problem is right there in that first word: “build.” Because a company cannot possibly know how to build a reusable REST API platform until AFTER they have built a large number of applications on top of it. In fact, I suggest that most companies would probably have to do this incorrectly at least four or five times before they understand how to build a general purpose REST API platform. Or at least, that’s how many times we had to rebuild DreamFactory from scratch over the past ten years in order to get it right.

What actually happens is that a company does it wrong, over and over again, for each new application, with different developers and frameworks, on different pieces of infrastructure, until they end up with a serious backend complexity problem that is impossible to scale, port, or secure. And by the way, they have to spend millions of dollars in development costs and hundreds of man-years of hard work in order to achieve these bad results. In many situations, the API services they build are not fully documented. I have talked with customers that were not even able to identify all of their endpoints. And there is no way that they are going to throw it all away and start over, because these applications are in production.

There is another problem with this recommendation. Lets say that companies around the world actually were, for some reason, willing to throw away all of their REST APIs and start over again in order to build a reusable platform. Eventually, they would converge on a flexible and standardized REST API that would support long-tail software development for a wide variety of mobile applications. But, if that happened, wouldn’t all of these companies be independently arriving at pretty much the same destination? Wouldn’t they all be spending millions of dollars building what turns out to be a very similar piece of middleware?

What really needs to happen is that a hard working team of software designers and domain experts should go through the difficult process of building a perfectly reusable, scalable, and portable REST API platform that could be used by enterprise companies everywhere. Even better, they should release this platform as an open source project so that any developer can download the software for free, instead of reinventing the wheel, over and over again. This is exactly why we built DreamFactory and released it under the Apache License. Version 2.0 was released a few months ago, and it is even better.

So I really appreciate the hard work by the analysts at Gartner. They have completely nailed the problem. But in my opinion, their solution leaves something to be desired. Because building your own REST API platform is a bad idea. And you can get the solution that Gartner is describing right now, for free, and install it on any server, or in the cloud. The DreamFactory website has easy to use installation packages available at the link below. Now there’s a recommendation you should definitely follow.