Content Copyright © 2014 Bloor. All Rights Reserved.
This blog was originally posted under: The Norfolk Punt
If there is a hot topic in Enterprise development today, it is probably the development of mobile applications for businesses—both for eCommercial and eBusiness customers and even for internal business applications. This comes with certain issues:
- Everybody expects a bang-up-to-date experience on all and every mobile device they have—or aspire to have—and the standard is set by simple but whizzy native apps they can download from an App Store;
- Just getting an ‘installable app’ into an App Store can waste time and reduce agility;
- Performance and responsiveness from an end-user-experience PoV is vital and the standard is set by native apps built for individual platforms;
- Most mobile devices contain a rich (and differing) set of hardware and software gadgets (cameras, GPS, barcode readers—and even barometers);
- No business can afford to build mobile native applications from scratch for every device. They need to develop in one codebase and deploy any- and every-where and they need to re-use existing application assets and data structures.
Every up-to-date vendor of developer tools seems to be telling me that it is addressing these issues—see Embarcadero’s FireUI here, for example. And there are different approaches for different development cultures.
One approach I particularly like is to write as little code as possible, but to model the business, which frees developers up to think about the user experience and business logic and automate the production of the executable system, with generators or runtime environments. Then, if you maintain a strong separation between the business logic and presentation layer (good practice anyway), the automation can handle most, probably all, of my requirements list, above.
Of course, the models must not restrict what you can do and the compiled code (or runtime environment) that makes the app executable must perform fast enough for the end users not to notice, but that’s just an implementation issue. It doesn’t even invalidate the approach if you find one function that has to be hand-written in C## or Java, as long as that is an exception. The main issue is that model-driven development works—if you measure productivity in terms of the time and resources required to deliver working, production, business systems and factor in the cost of maintaining them as the business changes.
If you don’t take a holistic view of development productivity (leave out the design effort, perhaps; and the rework when systems don’t do quite what is needed; and the cost of maintenance), then you can make the sums look different, but that isn’t realistic. There are developers who get real pleasure out of writing and re-writing code and hate talking to those pesky users; don’t seek their advice about how best to build productive business systems, productively (if you are measuring ‘productivity’ in business terms).
If you do take a holistic view of development productivity. you might be looking at OutSystems Platform. The latest release, OutSystems 9, adds a couple of very interesting features to what is already an effective PaaS development tool—as well as explicitly addressing the points I’ve already raised (although this isn’t the place for a full review).
Of course, OutSystems 9 is concentrating on providing a compelling (“beautiful”) Mobile user experience, with powerful HTML 5 Widgets, REST integration, lots of cloud connectors and a rather nice Visual Data Charting tool, which lets developers build attractive visual analytics into mobile applications, without coding. After cracking the code generation problem, OutSystems is now attacking the SQL generation problem; I suspect that generating better SQL than many developers write from scratch won’t be too hard.
A lot of this is very useful but not that new. OutSystems 9 now integrates well with on-device hardware and software (GPS, camera, barcode reader, phone, contacts database etc.) but that’s just a requirement for a modern mobile development platform. However, its OutSystems Now app struck me as a real innovation for OutSystems developers. This is about “your applications on your device”. OutSystems Now is an installable app, which you can find in the appropriate App Store, which acts as a shell for the apps you develop yourself. It provides a native shell or bridge to your own Enterprise App Store, which is a single location for all your enterprise apps. What this means is that your business apps are first-class players on your employees’ smartphones but you can change them immediately without having to go through the App Store QA procedures (OutSystems Now is the installable app), control their availability—and single sign-on is provided to enterprise resources. I think Enterprises moving to Mobile may like this.
What is really clever, however, is that OutSystems Now is fully open-sourced. What this means is that an innovative company can build its new killer app on OutSystems Platform, customise OutSystems Now (removing all OutSystems branding if it wants to) and have its own installable app it can start selling through the App Store without all the faffing about that building an installable app and having it accepted for the App Store would otherwise entail. I can’t help feeling that it can’t be as easy as that, but I also can’t think of a real issue with it and OutSystems tells me that Apple, for example, seems to be happy with the idea. The benefit for OutSystems is that its PaaS is now on a level playing field with anything else for building installable apps—it generates compilable code and HTML5—and it expects to win any productivity shoot-outs.