J
Jared Douglas
Guest
An article I read last week has gotten me thinking again about the role of IT in today’s application development space.
The gist of the article is this: today’s service-oriented architectures (SOAs) aren’t equipped for the emerging mobile application market. Because SOAs are lacking some essential capabilities, development teams end up having to pick up the slack by ad-hocing features like security and data services. This creates some obvious problems, so it’s best to let IT manage all of those things through a mobile app server.
But why not turn to a PaaS, too?
The Mobile Problem
The issue with mobile devices is that they are, well, mobile. As anyone with a smartphone can attest, battery life and data limits are a constant struggle, so you can’t require applications to remain open and active or to transfer large amounts of data at a time. Also unlike traditional applications, mobile apps are not guaranteed to have an active internet connection at all times.
If you are working on a BYOD policy, there are another host of challenges that must be addressed. I still think BYOD is great, but you have to consider potential security risks when asking employees to use their own devices for work. These devices are, for the most part, out of your control. Users may accidentally download spyware or other malware that could gain access to the data handled by your business app. Occasionally, your users may hand their phone to a friend or child to play with. They may misplace the device, and who knows who could pick it up later? Unauthorized access to business data, even if it is accidental, is a major issue to be addressed.
Simply put, if your SOA is built with the assumption that there will be one user per device and that device will have constant, unlimited network access, it is not equipped to handle mobile applications.
Getting PaaSt the Problem
There’s actually a simple solution to all of these issues: a mobile app server that can handle authentication, sync with mobile devices as they come online and go offline, and take care of the heavy computational lifting of business logic and data management so the device doesn’t have to sacrifice its own battery and data limits. There’s still one catch—you have to build all of that and integrate it with your existing SOA. . Oh, and your server will need to support many users at the same time, and the number of users you need to support will likely change over time. That’s a big job for an already overworked IT department
That’s why, in this instance I’m a strong advocate for PaaS. Monitoring and management platforms like Modulus™ are designed with mobile apps in mind, built with multitenancy support and made to be infinitely scalable. Throw a PaaS like Progress® Pacific™ on top of that to handle your data integration and business logic needs. Pacific has the added benefit of a visual programming interface that allows you to adapt your SOA to the demands of the mobile world and push your apps out faster than ever.
Author information
Jared Douglas
|
Continue reading...
The gist of the article is this: today’s service-oriented architectures (SOAs) aren’t equipped for the emerging mobile application market. Because SOAs are lacking some essential capabilities, development teams end up having to pick up the slack by ad-hocing features like security and data services. This creates some obvious problems, so it’s best to let IT manage all of those things through a mobile app server.
But why not turn to a PaaS, too?
The Mobile Problem
The issue with mobile devices is that they are, well, mobile. As anyone with a smartphone can attest, battery life and data limits are a constant struggle, so you can’t require applications to remain open and active or to transfer large amounts of data at a time. Also unlike traditional applications, mobile apps are not guaranteed to have an active internet connection at all times.
If you are working on a BYOD policy, there are another host of challenges that must be addressed. I still think BYOD is great, but you have to consider potential security risks when asking employees to use their own devices for work. These devices are, for the most part, out of your control. Users may accidentally download spyware or other malware that could gain access to the data handled by your business app. Occasionally, your users may hand their phone to a friend or child to play with. They may misplace the device, and who knows who could pick it up later? Unauthorized access to business data, even if it is accidental, is a major issue to be addressed.
Simply put, if your SOA is built with the assumption that there will be one user per device and that device will have constant, unlimited network access, it is not equipped to handle mobile applications.
Getting PaaSt the Problem
There’s actually a simple solution to all of these issues: a mobile app server that can handle authentication, sync with mobile devices as they come online and go offline, and take care of the heavy computational lifting of business logic and data management so the device doesn’t have to sacrifice its own battery and data limits. There’s still one catch—you have to build all of that and integrate it with your existing SOA. . Oh, and your server will need to support many users at the same time, and the number of users you need to support will likely change over time. That’s a big job for an already overworked IT department
That’s why, in this instance I’m a strong advocate for PaaS. Monitoring and management platforms like Modulus™ are designed with mobile apps in mind, built with multitenancy support and made to be infinitely scalable. Throw a PaaS like Progress® Pacific™ on top of that to handle your data integration and business logic needs. Pacific has the added benefit of a visual programming interface that allows you to adapt your SOA to the demands of the mobile world and push your apps out faster than ever.
Author information
|
Continue reading...