The disruption from the iPhone and iPad continues years after Steve Jobs started the revolution in smartphone technology. Due to demand by customers, enterprises serving consumers must consider how to provide that audience mobile applications that interface with their otherwise internal enterprise systems. Some examples of this from the financial services industry include Credit Suisse’s Onyx Touch, Merrill Edge for iPad and Bank of America’s Research Library.

It’s important for the enterprise architect to understand how each outward-facing application affects the infrastructure, so that he or she can plan for the big picture dealing with design, reuse, automation, integration, security and more. To get a thorough understanding of the issues involved, I recently spoke with a developer who has built multiple consumer-facing iOS applications with enterprise access for a Wall Street financial services firm. I was surprised at what I learned that affects my own work — and you may have the same reaction.   

The first thing I learned is that perhaps we architects are too concerned about the scalability demands created by a more mobile consumer audience. The developer with whom I spoke  explained to me that if you have architected your back-end systems to scale to support consumers accessing Web apps from their PCs, those systems are ready to perform for mobile visitors, too.

It’s in the area of security that what you’ve done for your consumer-facing Web apps differs from what you’ll need to do for your consumer-facing mobile apps. (But you probably guessed that, didn’t you?)  

Insecure About Security

Let’s break the issue of security down a bit further, to examine the not-so-obvious consumer/enterprise issues, such as:  

• local storage
• encrypted communication
• session management
• remote data wipe

“The biggest concern with our mobile apps [deals with] locally stored data,” said my source. If a consumer is using a mobile app to access data that is owned by the enterprise or another entity, such as one of its partners, it’s too risky for certain businesses to provide an option [that lets] the user locally store that information or any operations he conducts with it. It opens the door to problems for the business if the consumer’s device is lost or stolen.  

“You need to view it as though you’re lending the data to look at. You need to stop common operations such as copy/paste,” according to the developer. A seemingly valid consumer user may in fact be a rogue employee trying to steal data. Or, since it is a consumer app, you may not be able to even identify the users at all.

Obviously, there are some industries and/or mobile apps where local storage isn’t necessarily a problem. There’s not much at stake, for instance, if a user can store the ranking stats for an entertainment company’s mobile multiplayer game on his iPad. Where corporate data security is a concern, could strong local encryption make a difference? Yes, and it’s an area where the enterprise architect also must help set standards. “The data accessed by mobile apps needs to have stringent security requirements, based on those from the enterprise data group,” my source said. Strong encryption is necessary when communicating over cellular or Wi-Fi networks, for starters, and even temporary files need to be encrypted to guard against accidental exposure in case the application crashes.

For consumer applications that give users optional access to privileged systems and/or data for a fee, strong session management should be on the enterprise architect’s standards list, as well. “Where I work, we need to support at least three types of time-outs,” said my source, for free and stepped-up levels of access. They are:

1. Inactivity based time-outs.

2. Time-outs that occur when the time between Web service calls is too long.

3. A maximum time limit for an open session, regardless of activity. This ensures that if an unauthorized party breaks into the system, the amount of time on the system is limited.

Should an issue arise about compromised enterprise data, the architect must ensure that there’s a way to deal with information existing in a local state on a consumer’s device at the time the security issue is detected. You have to make sure there is a facility for remotely wiping the data resident in local memory, along with the entire application, on the mobile device, while leaving all else on the device intact.

Another difference for enterprise architects to consider, which lies outside the security realm, is providing as much functionality as possible offline. “You should minimize features that work only when the device is connected [to the Internet],” the developer told me. The result is that users can get to features right away, without having to wait for a mobile device to boot and a network connection to be established. That’s one reason, he says, that his firm’s iPad app was preferred to competitors. (You also should read our recent feature, How to Architect a Successful Mobile Strategy for additional information on security and other requirements for mobile apps.)

In many ways, the instant-on, instant gratification offered by mobile applications at our fingertips (like the one you can read about here) lends itself perfectly to a world that demands access to critical data as quickly as possible. The real question is: What took us so long to realize this? Let us know how you’re driving a successful consumer-focused mobile strategy at your enterprise.

A few weeks back I wrote about the benefits — and challenges — of a federated architecture. In that blog I wrote that such an approach helps the enterprise architect organize the efforts of disparate groups to avoid duplicate software project silos, but also that the approach won’t get far without buy-in and cooperation from business users, data owners and various other stakeholders. (For a more detailed refresher, see the original post here).

I mentioned there that I’d be following up the post with another to discuss a project I’ve been involved in to tie disparate financial systems into a federated portal, which included taking mobility into consideration early in the design process.  I know you’ve been waiting for it, so sit back and enjoy as I delve into the how of architecting that federated effort! I hope my experience will help prepare you for issues that may arise with federated systems in your own enterprise, regarding security, deployment coordination and user interfaces, which is where we’ll start.

Dressing for Success

The enterprise architect’s first challenge will be getting agreement on a unified presentation strategy. Without standardizing on a single presentation technology, you risk a user interface (UI) that looks disorganized and disjointed. Equally bad, you lose the ability to share design patterns and code across software projects, and developers remain in silos, jeopardizing the agility that can occur when they are free to share their talent with, or even move to, other development groups to create added value. Technical problems, such as OS resource competition and varying data refresh rates, are bound to arise as well.

The Web-based portal I’ve been focused on building is for a set of applications — involving multiple development groups — in the banking space. Being Web-based, HTML makes up most of the UI. But because the portal is to be a rich Internet application, we had to get agreement on which more complex UI elements we would leverage for displaying dynamic data (financial market data in this case). Ajax, Silverlight or Flash technologies were in the mix, but trying to combine them all adds up to a sloppy presentation. As the enterprise architect on the case, it was important to listen to the arguments on all counts, and in addition mobility features had to figure heavily into the final verdict. Flash is a good cross-platform, cross-browser choice for dynamic UI development, but even better, it’s turned out to be a real star in the world of mobile devices.

Just Log In

Another area of focus in federated architecture is user authentication. It’s absolutely necessary to build a single sign-on (SSO) solution—not necessarily one based on SAML (Security Assertion Markup Language), but one that’s web-proxy friendly—that unifies the login process for your internal applications. But it’s just as important to enable access from external domains, such as those of your customers and business partners, seamlessly and without sacrificing security.

Solutions such as those in CA’s Identity and Access Management suite, provide capabilities that can work in your enterprise, across the Web, and even extend to the cloud. A single sign-on product, such as CA SiteMinder®, is specifically built to solve this problem, as shown in Figure 1. 

Figure 1 - How Single Sign-on Works (Illustration credit: CA SiteMinder Product Brief)

Here’s how it works:

1. The user accesses a protected resource.
2. The user is challenged for credentials, which are passed to a secure SSO agent, such CA SiteMinder.
3. After passing through another layer of network security, the credentials are passed to a policy server.
4. The policy server securely authenticates the user against the correct data store.
5. Entitlements are passed back to the policy server where access is granted.
6. The user’s profile data is passed to the appropriate application(s).
7. Appropriate application content is provided to the authenticated user.

Remember, in a federated solution, all of your organization’s secure applications need to be unified within a single SSO solution, and all of your user authentication must be accessible within a single set of data stores. 

Deployment Demands

Another critical task facing the enterprise architect who drives a Web-based federated effort that runs well on mobile devices is the deployment and administration of services within the cloud. In my case, this involved a private cloud.

The main goals were to enable lifecycle and operational independence. The first mistake of some of the groups participating in the effort was that they placed their enterprise software components into the cloud as one large component. This quickly led to problems in the areas of scalability and ease of deployment.

As a result, I began an effort to break down all software components into sets of basic services with discrete tasks. We designed a way to easily deploy and dynamically execute these services across servers, both physical and virtual, according to a core set of capabilities and prerequisites. For example, information such as average transaction time, network bandwidth needs, dependencies on other services, and external resources and storage needs all are factors in deciding how many instances of each service are started, and where they’re located.

That’s why the system now can manage itself to a degree. However, administrators still can control individual services, migrate them across servers if problems arise, and roll out individual service updates without interrupting the entire federated system. In the end, the entire system and process is more agile, with limited dependency on specific developers’ expertise, or custom frameworks that duplicate deployment and administrative tasks. In summary, less human interaction equates to more efficiency, and reduced duplication equates to reduced costs and greater shared value.

Looking Ahead

If you’re interested in moving your enterprise toward a federated architecture, you must understand that you’ll need to constantly engage in forward-thinking and proactive planning, since unification efforts take a great deal of time and need to be flexible. That’s especially true as new development groups come on board and various databases need to be consolidated.

But as most enterprise architects learn early on, a good architecture is never complete. It just continues to evolve over time. We’d love to hear about any of your own evolutionary experiences as an architect.

According to Apple’s quarterly reports, more than 74 million iPhones and almost 15 million iPads were sold as of the end of 2010. Google’s Android and RIM’s BlackBerry are close behind in terms of market share, according to Nielsen’s State of the Media report for 2010.

There’s power in those numbers. Smartphone users — which include just about everyone in your company — can’t be ignored when they come clamoring for ever-increased access to more core applications across a broad range of devices.

That means that managing users’ demand for tools to do their jobs more efficiently and while they’re on the go is a huge priority (see related story) . So, in this blog and the next, we’ll explore what you need to be thinking about as it relates to architecting security and management infrastructure for multiple mobile devices; creating efficiencies across multiple platforms; and planning your physical architecture solutions to ensure capacity, clustering, security and so on.

Mobile Device Management (MDM)

Your first architectural consideration should be the management and provisioning of mobile devices in and across your enterprise. You need to consider the en masse provisioning of devices (ensuring that proper applications and security settings exist); how applications and updates are distributed to the devices (often via over-the-air distribution); and such other issues as remote monitoring, diagnostics, backup and restore, and asset tracking.

Standards need to be set and enforced regarding which devices will be used and how they will be secured, of course. Each platform has its unique strengths and weaknesses. For instance, Blackberry devices can be managed by Blackberry Enterprise Servers, and Microsoft devices can be managed with ActiveSync. The device's carrier should also be considered during the standards setting process; i.e. what are the monthly costs, limitations, roaming fees, and international plans?

The point is, if the enterprise architect doesn’t set the tone here, IT can forget about actually creating alignment with business goals. All available time will be spent just trying to keep the architect’s head above water as more phones, and ever more-capable ones, too, enter the workspace from a plethora of carriers, manufacturers, and based on a number of technologies Or worse, they’ll be building one-off solutions that don't integrate with the rest of the corporate architecture, usually creating increased security risks and making standardization at a later date more difficult. This can result in costly duplication of effort and conflicting implementations.

MDM software can include many ofthe components for configuring an entire fleet of devices, managing application installs and updates, security settings and even remote OS upgrades. MDM solutions can also allow monitoring, and remotely controlling, devices through over-the-air commands sent as binary short message service (SMS) messages. A typical MDM solution can plug into your architecture as seamlessly as possible, as shown in Fig. 1.

Fig 1. Mobile Device Management Architecture. Illo Credit: Eric Bruno

On the left are the mobile devices to be managed remotely. These devices may have management client software installed on them directly, or may be managed with the devices’ built-in features. In the middle are the central components of the MDM system that communicate with the devices via a well-defined and secure protocol — perhaps implemented with binary SMS, or over Microsoft ActiveSync or other proprietary systems like the Blackberry Enterprise Server (BES) solution. The provisioning servers work with your configuration management and release system to handle software releases and updates for in-house software, third-party software, and the OS. The MDM authority interfaces with your existing LDAP systems to manage user rights and controls for the mobile devices and their provisioned software packages.

However, keep in mind that not all mobile platforms expose integration capabilities to third-party applications. For example, Apple’s iOS devices limit what third-party MDM solutions can do to their phones. Some MDM solutions are certified only for specific phones from specific carriers, rather than an operating system.

The Open Mobile Alliance (OMA) has created a device-independent specification and protocol for device management, called the OMA Device Management initiative. It contains formal specifications and protocols for the various pieces in Fig. 1. Most device vendors, including Nokia, Apple, Microsoft and Sony Erickson, have built-in support for device management, many are even implementing the OMA standards. For the others, third- party vendors provide solutions based on the OMA Device Management that can be installed on your devices, Howver, the mechanisms to deliver OMA standards-based policies still vary across devices from different vendors..

Other independent specifications include the OMA's SyncML initiative, which specifically focuses on device and data synchronization. For more on the OMA and its protocols and specifications for device management, read here.

Don’t Let Mobile Device Security Be the Worst of All Worlds

It’s a mixed bag when it comes to securing data on mobile devices and ensuring secure access to the device for your applications. Some mobile platforms, such as Android, offer little security besides what’s present to protect the built-in applications and the kernel itself. In contrast, Apple and RIM specifically provide software and tools to remotely locate, lock and even erase devices if lost or stolen. Thinking ahead about lost devices   should drive the adopting organization to test and implement specific procedures..

Again, the OMA defines protocols as part of its MDM standards that specify secure content exchange, secure remote identification (of devices, applications and users), and user-profile management. But what about secure enterprise data integration? To fully benefit the mobile workforce, devices should enable more than just remote e-mail access. You need to synchronize calendars, contacts and communication with ERP, CRM and other enterprise systems — securely.

In general, you need to guard against unsecured wireless access, mobile malware, unguarded sensitive data on the device, and unauthorized network access. RIM offers the BlackBerry Enterprise Solution, along with its Enterprise Servers, to provide secure access to remote data. This includes device authentication over the carrier’s network, encryption of data sent and received, and digital signatures along the way to identify users and their data.

Device-independent products include CA Technologies’ Mobile Device Management software suite. Besides offering all of the management features mentioned in the previous section (over-the-air provisioning, tracking, software installation and so on), it provides security features such as inventory tracking, device scanning, policy-based identity and configuration, and integration with enterprise client management solutions. Other companies with security solutions include:

• MobileIron: MDM solution for iOS, BlackBerry, Symbian, webOS and Windows Mobile
  
  
• SyncShield: MDM solution for iOS, Symbian, Android and Windows Mobile
  
  
• Microsoft’s System Center: for Windows Mobile and Windows Phone 7 devices, with a Software-as-a-Service      (SaaS) management solution
  
  
• Columbitech: to secure wireless communication over various transport systems
  
  
• Sybase iAnywhere: for secure mobile access to databases, e-mail, as well as on-device data protection

Next time, we’ll look at how your existing enterprise architecture and its implementation may be affected by your mobile workforce’s data usage.