Your search did not match any results.
We suggest you try the following to help find what you’re looking for:
by Jürgen Kress, Berthold Maier, Hajo Normann, Danilo Schmeidel, Guido Schmutz, Bernd Trops, Clemens Utschig-Utschig, Torsten Winterberg
Part of the Industrial SOA article series
Abstract: Any place, any time: the old promise from the dotcom age has never been more relevant. With the release of the iPhone, Apple set off a huge amount of hype. Many people now have a laptop with broadband Internet connection and/or WLAN or UMTS Internet access. Yet these devices are still too large, too awkward, and take too long to boot up to be usable at any time. On the other hand, almost everyone has a smartphone these days, making them more mobile than ever in today's economy.
Smartphones are enormously practical and are becoming more and more powerful. They are generally very easy to operate, can be used almost anywhere, and the mobile web is becoming both faster and cheaper. App stores are shooting up everywhere and new functions can be installed with a single click. As the saying has it: "There's an app for everything."
The use of built-in sensors provides for entirely new possibilities such as Google Maps integration, location-based services, augmented reality, etc. Built-in cameras are becoming more and more powerful and are often used as a second compact camera. Video telephony is becoming more common—not just on Skype, now long-established, but also through Apple Facetime. The speed of innovation is tremendous.
A very high percentage of apps are games, followed by information systems that are mainly of interest to private users. These information systems are making increased use of the built-in functions on the mobile device. For example, the system identifies my location via GPS and can provide me with information via a personalized localization. Using the integrated camera one can scan a barcode and run a price comparison through the system. Previously unthinkable "Star Trek" technology is now (almost) a reality. Soon we will have combined tricorders/communicators/tablets in a single device. More and more companies are viewing mobile solutions as a means by which to accelerate processes, incorporate external partners more easily into processes, and lower their own process costs. We are already using numerous examples for B2C services such as booking flights by cell phone, tracking packages, and finding out delivery dates and opening hours. To optimize these functions for your own company, creative ideas are required: How can I increase customer loyalty? While B2C applications are already spreading very rapidly and probably represent the core business of all non-game apps, B2B is developing only slowly. One of the central questions here is how additional services can be offered to the business partner. According to Gartner, top growth areas include location-based services, social networks, mobile search, mobile commerce, mobile cash, context-aware services, object recognition, mobile instant messaging, mobile e-mail, and mobile video.
Possible architectures for the development of mobile apps vary greatly. There are very different approaches for bringing mobile solutions onto cell phones. One approach uses the option to run a browser on the mobile device. A mobile app is a web application optimized for the mobile device. For enterprise software developers, this is initially the easiest method. Control remains with the central application, there is no need to download or update software on the mobile device, and, perhaps most importantly, apps continue to be developed in the same way as before. We are dealing here with the same "good old web development," just for smaller screens. Alternatively, native applications can be created directly on the relevant target platform. Since this requires individual components to be developed for multiple platforms, costs increase. For this reason a number of interim solutions are already beginning to arise such as interpretative runtime environments, cross compilers, or MDA approaches, which take on this problem and generate applications from a uniform code base for diverse target platforms (PhoneGap, Titanium etc.). We cannot say yet which trend will win out. The app concept is currently growing fast, e.g. by being anchored in the Mac operating system, in Windows 8, or via a wide range of new app marketplaces (Amazon, etc.). By contrast the benefits of web-based solutions are apparent on "normal" interfaces that can be developed rapidly. They do not need to be deployed, nor does a distribution platform or similar need to be selected. Whether or not a general decision is now made in favor of Web-based solutions or for native apps will depend, as always, on specific requirements. Should the solutions be sold or merely offered? Are subscription models necessary? In this regard Android is generally more open than Apple, which is also the reason why the growth rates for Android are so high. The drivers here are new use cases that today are still not quite conceivable. Imagine for example the following scenario after a car accident. The victim starts up the insurance app on their smartphone, through which the location of the accident can be immediately located by GPS, the insurer could be immediately sent photos of the damage and, using the speech memo, a description of the accident recorded. The insurance company would then have all of the documents required to deal with the claim. How can this be developed as generically as possible for different smartphone platforms? The different options must be evaluated and the best one implemented for the customer.
Almost every platform has its own programming language or a development environment with proprietary rights. But what are the most common approaches?
With Objective-C on iOS, Apple has its own language, as does Microsoft with.NET on Windows Phone 8.x, though the future is not clear here either. If market analyses are to be believed, in purely numerical terms the Android open-source operating system is currently enjoying the greatest growth (how this will be reflected in the business fieldremains largely unclear). Symbian continues to enjoy a major market share with feature phones, though they are becoming less and less important in our field, and RIM (Blackberry) still has a stronghold among smartphones; nonetheless, both are declining strongly. Google, one of the key players, started the Java-based Android platform and continues to play a key role in its development.
What do mobile solutions change in our architectures? Not much, at least not directly. Technically, REST communication and the exchange of JSON structures appear to suit the mobile environment better than SOAP services and XSDs. The enormous increase in mobile use cases means that investments in a company's own service-oriented architecture will make its benefits felt far more quickly. This surprisingly innovative environment leads to the realization of a huge number of new, business-relevant application cases, at a speed that would have been unthinkable just a few years ago. The flexibility of an SOA landscape will be paid back in full here, because it will make it possible to implement new opportunities very quickly. For example, an ESB is very easy to use as a protocol converter if an existing back-end "only" speaks SOAP but the mobile client needs to be connected via REST.
Figure 1: Architecture of a classic web application
Figure 2: Architecture of a single-page web app
Mobile solutions are a major driving force behind process automation solutions. In this environment there are no new technical options for mobile use. But a wide variety of options opens up merely by enabling processes to receive input from people on the move, resulting in much faster throughput times. The advantages range from preventing the need to take notes on paper to simply being able to approve something while sitting through the coming attractions at a movie theater. (This article does not discuss the influence of this technology on the private lives of these persons.) The possibilities are very wide-ranging, especially since the mobile devices' new sensors can be used: geolocation, card-based information, cameras, barcode scanners, or movement profiles, all of which improve process support. The ideas list in the "Possible Uses of Mobile Solutions" box provides a long but far from exhaustive list of use cases. With regard to BPM, understood here as process automation, the following options arise concerning use of mobile end devices.
In all these use cases, the aim at the highest level is to increase business efficiency by integrating the user into process flows earlier, more rapidly, or simply better. "Mobile BPM" does not however mean using lightweight process engines on the mobile devices themselves.
In his blog, Max J. Pucher, the mastermind behind the BPM discipline of adaptive processes, discusses a potentially problematic development in this connection due to the increased use of mobile applications. Pucher's train of thought was triggered by a lucky entrepreneur who managed to buy a great app developed for very little money. Nothing wrong with being a lucky entrepreneur. But what happens if, due to this one person's success, more and more "small" apps are developed, all of which are cheap and fast? In the medium term, joy might turn to sorrow once we start thinking about how to maintain this type of application landscape. Due to the UIs and the high number of small apps, there is a risk that our flexible SOA back-ends that were once loosely coupled would have to be tightly connected again in the absence of a suitable provision. Modifications would then be possible only very slowly or not at all, as it might necessitate ten different service providers or freelancers to make changes to their apps all at the same time in order to accommodate a process change. This state of affairs, which we will call the hell of maintaining a "Lots of Cheap Apps" architecture, should be avoided. As described above, sensibly applied SOA principles represent sensible countermeasures.
On the front-end side, the technological future certainly belongs to HTML5, where we are witnessing a lot of new developments and innovation. New architectural patterns such as the single-page web app must be added to the architectural toolbox. However, there would be no point in coining the new term "mobile BPM" since there are no technical differences compared to other output channels to justify doing so. There are however a huge number of use cases that would benefit from a mobile implementation such that consideration of mobile solutions appears to make particular sense in the context of SOA and BPM. For BPM in particular, mobile use cases could become real drivers for development since smaller projects can supply a faster ROI on presumably expensive and complex central process engines. The mobile solutions environment therefore represents a genuine opportunity for IT to move away from being a cost center and towards being a value-creating business enabler, creating new business opportunities via technological innovation.
Practical use cases for mobile solutions which, taken in isolation, produce a ROI quickly, are extremely diverse. The objective is always to exploit the possible new benefits of being mobile in order to optimize existing processes or create new ones. Here we must search not just in the core value creation processes: the point is to identify those "leverage points" in all company processes that promise disproportionate benefits due to mobile support.