The Mobile Enterprise: Part I – Composite Mobile Apps

Five years ago the enterprise was a much simpler place.  Web applications only had to support one front-end (IE), UI design was straightforward (if not the most elegant), and users were blissfully unaware of of the limitations web applications placed on their “user experience”.

How time flies…

Now, thanks to Steve Jobs and Apple (with some competitive nudges from Google and Microsoft), the enterprise exists in a much different world.  Instead of one front-end, enterprise applications have to support dozens, if not hundreds of platform permutations; users are in open revolt because they see alternatives to the status quo; executives are sorting through the hype trying to figure out where Cloud fits in; and just as web investments start paying off along comes the push into mobile.

So why (except for pointing out the obvious flaws in 5-year I.T. roadmaps) is this important?

Over half of Americans own a smartphone, another 35% own a tablet; and 35% of these use an app before they even get out of bed in the morning.  It’s not just that people are mobile, it’s that they are connected… all the time.

Welcome to the world of Connected Mobility.  And in this world, a Mobile Enterprise isn’t an option.

But how does a company get to a Mobile Enterprise while leveraging their investments in the web and without massive new I.T. expenditures?

The answer is Composite Mobile Apps.

Composite Mobile Apps – What Are They?

Composite Mobile Apps are enterprise-class applications that have a single Enterprise Core supporting multiple front-ends (iOS, Android, Windows Phone, Mobile Web Apps, etc.).  They are assembled from component parts (mobile apps, web apps, enterprise services, enterprise databases, etc.) into an enterprise application that functions as a complete whole.  They combine all types of mobile apps (native, hybrid, and web) with new or existing enterprise applications.

Composite Mobile App vs. Mobile App

Although mobile apps come in multiple flavors, every mobile app has one thing in common: they allow the user to interact with the app from their mobile device (smartphone or tablet).  But where the app is actually running is another thing.

With mobile web applications all of the app is executing on the backend, with content (as HTML pages or encoded streams) served up to a browser running on the mobile device.   (**Note: Although the browser is running on the mobile device, it is not a part of the app.  It’s just a container for content served up by the app.)

Native mobile apps are just the opposite: most of the apps’ functionality runs natively on the mobile device.  They may or may not have back-end components supporting the front-end, but if they do the back-end functionality is specific to the native app.

Hybrid apps are nothing more than mobile web applications packaged to run natively so they can take advantage of mobile device capabilities (GPS, Bluetooth, camera, microphone, etc.).  Core application functionality still runs, and content is served up from, back-end components.  A small slice of functionality is native, but most is on the back-end.

All three types of mobile apps have (or may have, in the case of native apps) back-end functionality.  But all this back-end functionality has one thing in common: it’s specific to the mobile app.  Take away the mobile device and the back-end has no purpose.

Composite Mobile Apps approach mobility from an enterprise perspective.  “Mobile Apps” aren’t something that stand alone; they are simply one component in a broader enterprise application.

Composite Mobile Apps are characterized by a single Enterprise Core supporting multiple client platforms: native mobile (iOS, Android, Windows, etc.), hybrid (HTML/CSS containers running on mobile devices), mobile web, web, and even native OS clients (Windows, Mac OSX, Linux).  Core functionality is then shared across client platforms.

Dual MVC Design

Composite Mobile Apps are structured around a dual MVC design, with a localized MVC design for native apps and a master MVC design for the overall application (including web) – with the native apps themselves part of the master MVC architecture.

Within the master MVC design, native apps define the “View” layer and the Enterprise Core contains the “Model” layer.  The “Control” layer is shared across local and master MVC structures: localized controllers within the native app (part of the local MVC design) handle application control on the mobile device; they interact with local controllers on the back-end, which in turn delegate control to master controllers in the Enterprise Core (local and master controllers are part of the master MVC design).

CloudSmart

Composite Mobile Apps assemble an end-to-end enterprise application from component parts. One of those components can be (should be?) cloud storage for content shared across multiple client platforms.  And with a dual MVC design, content can be shared across mobile and web clients.   (Learn more about how to make your app CloudSmart)

Composite Mobile Apps – Why Are They Important

Composite Mobile Apps are critical to an enterprise for several reasons:

• Mobility is viewed from an enterprise perspective, not from the perspective of individual mobile applications.  Mobile apps are aligned with existing capabilities and not just dropped into an organization.
• I.T. shops can leverage their existing investment in web technology.  Composite Mobile Applications extend and enhance web solutions, they don’t replace them.  This significantly lowers the cost of standing-up a Mobile Enterprise.
• Composite Mobile Apps are easily adaptable to new mobile technologies and new ways of applying these technologies.  A lot of mobile apps lock you into a solution, Composite Mobile Apps opens up the enterprise to technology advances.
• CloudSmart.  Mobile Apps and the Cloud are components of an enterprise app, not point-specific solutions.  This facilitates collaboration and sharing of content across mobile devices and between users.
• Mobility isn’t as risky.  Solutions are assembled from parts that are already working, with development isolated to net-new capabilities.  Don’t carve out the enterprise for individual mobile apps.
• Quicker paths to a Mobile Enterprise.    There’s less to build and what needs to be built takes less time.

Parting Thoughts

Composite Mobile Apps represent the fastest, least risky path to a Mobile Enterprise.   Other elements contribute to getting there (e.g. a winning mobile strategy) but Composite Mobile Apps should be in every I.T. organization’s toolbox.

-Mike

Advertisement

5 Critical Insights for Scaling Apps in the Cloud – Part I

As of this writing the “Obamacare” web site remains fodder for late night comedians and armchair pundits.  Much as been written about the debacle that is Healthcare.gov and the quotes are simultaneously damning and terrifying:

One specialist said that as many as five million lines of software code may need to be rewritten before the Web site runs properly – NY Times

The basic architecture of the site, built by federal contractors overseen by the Department of Health and Human Services, was flawed in design, poorly tested and ultimately not functional. – Time

The site’s front end… doesn’t look too bad, but it is not coping well with whatever scaling issues the back end (account storage, database lookups, etc.) is having. – Slate

The jury is still out on a number of issues, but what seems to be clear is the end-to-end system was never designed to perform even under the most moderate loads.   The front-end processing may have been able to handle the expected traffic, but it takes a lot more than putting a load balancing router on the front-end to make an app scalable.

So, what does it take to make an app scalable – especially in the Cloud?  A number of factors come into play, but the five most critical insights driving scalability are:

1. Isolate Complexity
2. Partition You App
3. Replicate and Load Balance
4. Dynamically Provision
5. Instrument You Application

This post addresses isolating complexity.  Subsequence posts will address the remaining four insights driving scalability.

1.  Isolate Complexity

Simplicity is the goal of any well designed application, but “simple” often isn’t an option (like when you have to orchestrate multiple government agencies and private companies to offer health insurance).   Complexity by itself isn’t a bad thing, but it must be isolated.  Otherwise, required complexity in one area infects and corrupts an entire system – even those components that are relatively simple (like front-end page generation).

At Egen, we use a three-step process to isolate complexity:  1) Separate and Isolate; 2) Aggregate and Orchestrate; and 3) Coordinate and Collaborate.

Separate and Isolate

One of the fundamental principles of system design is separation of concerns (SoC).  Essentially, SoC looks to segregate a system into distinct parts, such that each part addresses a distinct, non-overlapping element of the solution (a concern).

Within our iBlock Architecture, we separate concerns into logical assets and then isolate these assets through encapsulation.   Assets are a powerful abstraction that bound distinct parts of the problem space.  They represent the building blocks of a system.

Assets vary in scope and internal complexity, but this complexity is always isolated from other assets.  Examples of assets include: legacy systems, third-party services,  database platforms, shared resources, internal & external devices, message channels, and all or part of a Controller or Model layer.

Encapsulation “wraps” the asset into a software component that hides the internal implementation from other assets and provides a standard interface for its use.   Essentially how an assets works (it’s state, low-level interactions, and how the asset is managed) is isolated from how it gets used.

An example of an encapsulated asset would be a Java Connector.    The connector encapsulates an asset (e.g. a legacy system or device) into a Java object with a known interface.  Other parts of an application would interact with that asset using this interface.   Everything else is hidden within the implementation of that connector.

Aggregate and Orchestrate

Assets often encapsulate the API of the component they represent and then make this API available to other assets though their interface.   Unfortunately, these APIs typically define low-level access points to the component and using the API to accomplish a task can be complicated.  So even though the asset has isolated the component itself, the complexity of its usage has been distributed to the rest of the system.

To solve this problem, we take the additional step of aggregation and orchestration.  Rather than exporting the API for a component, we aggregate the API into higher-order services that orchestrate the low-level API calls.  It’s these higher-order services that define the interface for that asset.  Using an asset is simplified (with a handful of services) and the complexity of the API is isolated within the asset.

Coordinate and Collaborate

In virtually every system there is functionality that relies on, or affects, many parts of the system and can not be isolated within an asset (e.g. security, memory management, status monitoring, transaction processing etc.).  This type of inter-dependency is often referred to as a cross-cutting concern.

Without appropriate structuring, cross-cutting concerns can significantly add complexity through scattering (duplication of behavior) and tangling (hardwired inter-dependencies).  To solve these problems, Egen identifies cross-cutting concerns as either a problem of coordination or one of collaboration, and then isolates the concern accordingly.

The essential purpose of coordination is to maintain order.  In system design, this means assets are aligned to the same policies, follow the same rules, and behave in a consistent fashion.  Examples of coordination are security, logging, memory management and status monitoring.

At Egen, isolation of coordination is achieve through aspects.  Aspects are modular components which encapsulate the rules that are joined to assets (advice) and the structural components needed by other assets to implement the rules (inter-type declarations).   Aspects are a powerful tool for isolating complexity.  Too learn more, visit here.

Collaboration, on the other hand, is about assets working together to solve a problem.  Examples of collaboration are transaction processing, persistence, and synchronization.

Isolating collaboration is simply a matter of encapsulating control and orchestration into a separate asset.  But the techniques for using this asset to manage collaboration are varied.  A few of the most common approaches are shown addressed below.

• Registration.  The asset managing collaboration defines rules & structures for the collaboration and the assets which are part of the collaborative task implement these rules and structures and then register with the managing asset.  An example of a registration approach to collaboration is a transaction manager.  Registration is a good approach for separating highly complex collaborative behavior into a single asset, but it also inserts a high-level of usage complexity into a system (because assets involved in a collaborative task must adhere to specific rules and structures defined by the managing asset.
• Collaborative Service.  The asset managing collaboration hides the collaborative details (including the assets used and how they coordinate) and then exports a service for the collaborative task.  An example of a Collaborative Service is a data access service.  Collaborative services are great for minimizing the usage complexity of collaborative tasks, but they are task-specific with limited flexibility.
• Rendezvous.  With a rendezvous, assets involved in a Collaboration interact with the collaboration manager to synchronize behavior across assets.  An examples of a rendezvous asset would be a queue manager.  A rendezvous asset is perfect for synchronizing complex behaviors.

Conclusion

Scalability requires replication and replication requires isolation.  You can not build a scalable, multi-component, end-to-end system without isolating complexity.   It doesn’t matter if you are using clustering, OSGi bundles, or good-ol-fashioned router load balancing, unless you’ve isolated complexity – both internal and usage complexity – your system will breakdown under high loads (and sometime not so high).

Up Next:  5 Critical Insights for Scaling Apps in the Cloud – Part II (Partition Your App)