Enterprise middleware's role as mediator is being replayed these days in the fast moving world of mobile services development. There, mobile middleware is assuming the mediator's role.
That is a good thing, because the mobile space is full of diverse platforms and devices. There are Androids, iPhones, and BlackBerrys, just to name a few. For most organizations, re-writing back-ends to talk with each mobile device is hardly an option. An abstraction layer of middleware can help deal with complexity, but it is a big job as new versions of device hardware and software keep coming. A host of vendors now offer mobile middleware development services to address that problem.
Middleware has a role in both native and HTML5 mobile development strategies. It can help to bridge the gap between different device form factors, and the native hardware for things like geo-location, barcode scanning, and local storage capabilities. Most importantly good mobile middleware can help an organization to reuse the same back-end logic, and businesses process in novel ways that add the most value to the end user, while keeping development costs down.
“You have to think about a way you can develop an information architecture in which whatever is served can be called generically whether via a service,'' said Scott Schwarzhoff, VP of marketing for Appcelerator, a mobile middleware provider.
''If, every time you roll out a new implementation, you need to make a round trip through your organization, new services will be difficult to roll out,'' he said. ''These services need to be realized as components or reusable modules, and this stack can get added onto a flexible platform for mobility.''
Schwarzhoff said, “The best practice is to figure out what is common, and what can be centralized and managed, and not just think about it on the back end, but also on the front end on the client side. Then you need to roll this up into business level discussions you can have with the internal business units.”
This kind of service based thinking can prevent the proliferation of point solutions that are challenging to maintain said, Bryan Whitmarsh, Mobility Product Manager, SAP Mentor, Sybase, An SAP Company. “If you can stay standards based, you can leverage the energy you have invested in your infrastructure and future proof it.”
“A good middleware platform can provide drag and drop functionality,” said Rashid Khan, Founder of Chatty Solutions. “It will let you create mobile applications for the enterprise across platforms, whether they are native, HTML5 or a mixture of those without any programming, scripting, or macros.”
HTML5 and mobile middleware
Moving towards HTML5 seems like a very valid strategy. Companies do not want to incur the cost of developing the front end several times over, admits Rashid Khan, founder of Chatty Solutions, maker of a rapid development environment and runtime offered as a software-as-a-service (SaaS) for cross-platform mobile application integrations. But it is not a cut-and-dried decision.
"Since the HTML5 spec has not been fully developed, you cannot make a truly rich application yet,'' cautions Khan. ''HTML5 will make sure the application runs on various platforms, but it does not help you in terms of form factors. You still have the challenge that Apple has the iPod, iPad, and iPhone, and each has a different form factor.''
The good news is - if your firm has a basis in Web services architectures - it is easier to develop apps on different platforms, he says, ''because you can keep the business logic on the back-end servers.'' The challenge is that, in the Web services arena, different mobile OS platforms are using slightly different flavors of SOA to develop a Web services architecture, he notes.
An enterprise cannot just deploy Web services in such a way that any application can call them. For example, the Apple platform still cannot support SOAP. So the enterprise has to develop a REST-based version of their service, or wait for Apple to support SOAP.
A middleware platform solves this issue by letting you create an HTML5 or native front ends that can be cross platform - and the back end will talk to Web services, whether SOAP or REST based. This could be particularly a challenge for a company with 30 Web services that would then need to support REST and SOAP for the different platforms. Middleware provides a layer for managing the differences between devices. Middleware will also allow you to ensure the application is running on different screen sizes.
The drawbacks of middleware are the financial and maintenance cost associated with the middleware, says Khan. There are other issues associated with the reliability of the software, and the quality of the vendor in addressing problems, he said.
His analysis holds that middleware has a role in both native and HTML5 development strategies. If you decide to focus natively on just one platform, it is not as important, but you might lose in terms of competitiveness if demand spreads beyond your chosen target.
Conserving software development resources
Gaining adequate development resources is definitely a challenge today. In a desktop world, you could say, 'we are Windows or Microsoft based.' ''You cannot do that with mobile device,'' comments Bryan Whitmarsh, Mobility product manager at Sybase, an SAP company, which was among the first to provide mobile enablement for computer applications.
''IT centric departments are cost centers, which makes it difficult to staff. If you have iOS, you need an xCode developer, if you have Android, you need specific Android and specific Java expertise, and with Windows Mobile, you need Windows mobile and C# expertise,'' he said.
Which mobile applications are ready for mobile? ''There are a ton of low hanging fruits out there, such as simple business processes that get slowed down because we are not always at our desks,'' Whitmarsh responds. ''When you can speed simple purchase orders and travel requests, you can save time and make the process more efficient and cost effective.''
He advises mobile development newbies to start with a simple workflow process that is within the organization. Pick one that can be created using a standards-based hybrid approach that does not require it to use the native features of the various devices.
''If you don't want to end up with a bunch of point solutions that satisfy a few user cases, you need to standardize on a platform that can satisfy all of the use cases of mobile requirements,'' he said.
Fragmentation haunts mobile development
With mobile services, you need to think about how to deal with fragmentation that is at least four levels deep, said Scott Schwarzhoff, vice president of marketing, Appcelerator, which offers the Titanium mobile cloud development environment and runtime. He counts platform, device, skill, and cloud as the relevant levels.
At a platform level there is fragmentation between Apple, Google, and Microsoft. On the device level, there are different form factors such as an iPad, iPhone, or iPod. At a skills level, you have fragmentation between traditional Web development skills such as HTML, CSS, and Python, and Objective C, Java, and back end programming languages that date back 30-years. At the cloud level, there is fragmentation between the type of enterprise cloud you may have, and all of the cloud services that might be external to your organization such as AWS, Facebook, Paypal, Apple's iCloud, and Microsoft Azure, says Schwarzhoff.
That affects your approach to architecture. ''You have to think about a way you can develop an information architecture in which whatever is served can be called generically whether via a service on the device, on the cloud, or from someone else's cloud,'' he says.
Using a mobile middleware service can provide a flexible service layer. ''Now you can be far more agile in the relationship you have with your customer, or internal brand managers,'' said Schwarzhoff. He pointed to Appcelerator customer NBC, which built an app for comedian Jimmy Fallon that is reusable. It runs on iPad, and looks nothing like another PC-based version of the application. But the back-end architecture is similar, and uses the same connectors, analytics, and video services.
Both consumer and enterprise oriented apps have the same challenges, he added, and will need an architecture than can deal with that fragmentation both in the cloud, and on the device.
Applications can be pared down for the mobile space, he said. ''You don't want a Swiss army knife designed for everything,'' he advises. ''A mobile app has one or two features, which is the reason they call them apps and not applications. They are small and lightweight and designed to provide the right functionality at the right time.''
Mobile middleware services have been percolating over a number of years. The enterprise that turns to this approach must consider lock-in and other issues. But, when facing an expanding number of devices and software – not to mention update versions of software and devices – it is an alternative that will likely be examined.
This was first published in October 2011