by September 24, 2013 0 comments

Enterprise software companies are facing multidimensional challenges in the marketplace, like pressure to control costs while retaining market leadership. It is because of the current economic conditions that the enterprise software industry is at crossroads today. The prospect of the software industry will be ascertained by their capability to manage technology disruptions like cloud computing, mobility, social media and their ability to leverage the new normal created by these disruptive forces.

It is easy to underestimate the intricacy of building enterprise products because the software itself tends to be comparatively straightforward to write. However, this obvious simplicity masks the complex underlying architecture on which most enterprise software run; developing and maintaining an enterprise platform is difficult to get right, especially when the technology starts to age and the vendor must reinvent its platform to avoid becoming outdated.

The enterprise architecture life cycle is satirical because just when the vendor realizes maximum adoption, their architecture is perhaps getting timeworn and may need to be refreshed. It can take years for internal product teams to build applications on a new architecture and for customers to buy and use these products. Therefore, vendors are  reasonably unenthusiastic to rewrite their architectural foundation unless necessary for technical or business reasons (such as competitive pressures). Nonetheless, most enterprise vendors do undertake periodic architectural refreshes; according to this measure. Pooled with high cost, which can be 22 percent of the license’s list price, enterprise software support and maintenance has a bad reputation, because vendors recurrently become unproductive to make the value proposition concrete; in addition, vendors sometimes do a meager job maintaining their own software, which makes matters worse. These factors can create unhappy customers for software maintenance.

Besides, enterprise developers who work in surroundings that hold BYOD need to be aware of the issues they might face relating to authentication, screen sizes, security, and more.

1. No Active Directory or Group Policy
One of the really nice things about working in an enterprise environment is that you can almost always count on Active Directory and Group Policy being there. Group  Policy in particular is fantastic because it lets the system administrators centralize settings and configuration. If your application needs to be added to the “Trusted Sites”  in order to work fine, just push it through Group Policy. If you require an obscure registry setting to be changed, Group Policy has an OS feature that must be installed for the application to work.

With BYOD, your application must work without any kind of centralized configuration or control, which means that end users need to be able to configure it on their  own. Maybe this means that you leverage DNS to help point users to a central configuration, or perhaps you use another configuration server scenario. You cannot count on Group Policy and Active Directory for management and configuration anymore.

2. Screen sizes
One of the joys of enterprise development has been that one already knew the one to three screen sizes used by the company. With BYOD, one can forget that. The application must adapt to different screen sizes with ease, which is a bit of work for a native mobile application if one wants it to look really nice instead of counting on the OS scaling it. With web applications, that is a lot easier.

3. Elevated expectations
There was a very long period when enterprise applications could get away with looking like a Windows 3.1 application or just be a bunch of screens with grids of data. Users have higher expectations now, and a successful BYOD strategy needs to meet those  expectations. Applications need to be much more usable. While appearance is not a functional requirement, ugly applications can be frustrating to use, and attractive applications make a good impression on the stakeholders.

4. Authentication
Even if the enterprise is installing devices that integrate with the existing authentication infrastructure, BYOD means that a company needs an alternate route of authentication. It will be tempting to just throw in a quick ‘n dirty application-specific authentication into the application – do not do this, because it just infuriates users as they encounter password and username sprawl. Instead, authenticate against the enterprise’s system. It will probably be less work, and it will make the users happy.

5. Reduced training
With traditional enterprise applications, one got used to rolling out something and having the users get trained on it. The training worked because everyone had the same experience. BYOD users expect to install an app or point to a URL and start working. And even when there are opportunities to train, users will have different  experiences because they won’t all be using the same device. Your applications must be usable without formal training, and have self-contained help, documentation and tutorials.

6. Networking
Lots of companies set up barriers to VPN like physical tokens and third-party applications. These setups are sold with the promise of increased management and reduced headaches, but in a world of BYOD, they shut most devices out of the VPN entirely, meaning that everything needs to run over the public Internet. You should be prepared for your application to run over the public Internet too, unless it is something that is entirely useless off-premises. You should expect all traffic to be HTTP (good luck getting the IT staff to open a different port just for your application), and plan to leverage the device’s built-in email capabilities if you need to send email.

7. Security
The networking concerns bring us to the topic of security. Your application absolutely must be secure. This means HTTPS for anything but the most innocent of traffic, for starters. Even then, you should consider encrypting sensitive data “on the wire” too to defend against manin-the-middle on public Wi-Fi. Any sensitive data stored on the device should be encrypted. You need to treat data from the device like you would treat data from a public-facing web site, and protect against SQL injections, cross-sitescripting, and other similar attacks. This sounds like a pain in the neck, but any good, modern development environment goes a long way in helping here.

8. Native or Web
Native or Web has been a giant question for mobile app developers for some time. Prior to BYOD, enterprise developers had the liberty to go with native applications  and know that, short of a massive rip and replace program, it was a harmless select, and that for every native application they wrote, that made rip and replace a little less likely. With BYOD, it is recommended that you go with web development, unless one has a ton of in-house native application expertise and resources waiting to re-develop the front end (or worse, the entire application, if one doesn’t use web services for the heavy lifting) for each device type out there.

 

 

 

 

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.

<