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.

Composite Mobile App

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

Advertisements

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)

 

5 Critical Insights Driving a Winning Mobile Strategy

According to a recent survey of by telecommunications equipment maker Ericsson, 35% of mobile phone owners use apps such as Facebook before they get out of bed in the morning.

Pause a moment and let that sink in.

These are the same people that buy your products, view your ads, work in your offices and lead your departments, and over one-third of them use an app before they even get out of bed in the morning!  

This is the reality of Connected Mobility.  It represents a fundamental change in how we do everything and your consumers, suppliers, employees and competitors are already tapping into this shift.  A winning mobile strategy isn’t a nice-to-have anymore; it’s a necessity.

But what does it take?

At Egen, we use a simple but comprehensive One Page Mobile Strategy plan to guide business and I.T. leaders in the creation of mobile strategies.   Underlying this plan are 5 critical insights driving success…

1.  Define Your Mobile Center-of-Gravity

A strong Mobile Center-of-Gravity is the foundation of every winning mobile strategy.  A lot goes into defining this – and you will have to do your homework – but it’s worth it.

Mobile COG

Mobile Maturity

Your organization’s Mobile Maturity identifies your current mobile capabilities and measures where you are right now and where you want to be against a standard maturity index (0=No Capabilities; 1=Limited or Tactical Mobile Presence; 2=Mobile Enterprise; 3=Consumer-Facing; 4=Customer Intimacy; 5=Strategic & Innovative).  It is a self-assessment, but it creates a clear picture of where you are and where you are heading.

Competitive Landscape

The Competitive Landscape defines where your organization fits into the larger mobile eco-system.  It addresses the current sate of mobility (Industry Snapshot); where things are heading (Mobile Trends); what your competitors are doing (Competitor’s Top 5); and opportunities to fundamentally change how things are done (Potential Game Changers).

Strategic Objectives

Every winning mobile strategy starts with the underlying business objectives and then aligns these objective against specific mobile goals and desired capabilities.  The focus of this center-of-gravity component is to identify the business objectives driving mobile and then define goals and capabilities aligned with these objectives.

Master Business Case

The Master Business Case defines the value of mobility – to the business and to the users – and defines this value in terms of monetary “Table Stakes” ($ value of mobility; target spend; recoup horizons; and 5 year ROI) used to make strategic decisions.

2.  The Right Solution Matters

Native vs Mobile Browser; hybrid or pure-play; how to handle device proliferation; Cloud ready or self-hosted;  performance & scalability… these are some of the critical design drivers for a mobile app – and getting them right is critical.   So how does an organization ensure their mobile strategy drives towards the right solution?

Ask the right questions.

10 Questions Driving Mobile Solutions

  1. Will you be supporting one target device or multiple devices?
  2. Native app or web (or both)?
  3. Self-contained or will the apps have a backend component?
  4. Is the backend self-hosted or CloudSmart?
  5. Standard devices or BYOD?
  6. Device constraints?
  7. Able to function without internet connectivity?
  8. Apps need to scale?
  9. High availability and/or DR?
  10. What are the key app KPIs for success?

3.  It’s All About the UX

An app with a lousy user experience (UX) is worse than no app at all.  There’s nothing worse than building an app that no one uses.  The best way to ensure your organization doesn’t make the same mistakes as these folks is to address the key UX drivers in your mobile strategy. Many of the UX details are app-specific, but several elements span an organization.  As a minimum, your mobile strategy should address the following areas:

  • Purpose.  What’s the driving purpose (or purposes) behind your mobile strategy?  How will these be addressed as part of the UX?
  • Target Audience.  What types of users will your apps target?  How will their needs be addressed in the UX?
  • Context.  How will your apps be used across broad scenarios?  How will this drive the UX?
  • Customer Experience (CX).  What type of CX are you looking for?  How will this drive customer intimacy?
  • Branding.  How will the UX enforce a consistent brand and image across all apps?
  • Design Language.  Will there be a common Design Language defining a consistent UX across devices and apps?
  • UX Design Process.  What is your organization’s process for creating world-class user experiences?
  • Constraints.  Are there any constraints impacting UX design?

4.  Talent Drives Success

When it comes time to execute on a mobile strategy, talented people make all the difference. But the mobile strategy itself needs to identify the type of talent needed – and where to find this talent.    The last thing you want is a budget that doesn’t include the cost of the talent you need.

5.  Don’t Forget Security and Privacy

Mobile devices come with all sorts of interesting features that tend to drive IT departments crazy: cameras, microphones, geo-location, bluetooth, etc.   And then there are the apps themselves – wonderful little nuggets of uncontrolled mayhem downloaded directly from some app store without direct IT department oversight.

Complicating everything are the users themselves.   There may be information we’d like to use, but how do we ensure we protect a user’s privacy?

The mobile strategy must address both of these areas.   Detailed solutions aren’t required, but the strategy needs to identify the Critical Security Concerns all apps must address and the Key Privacy Policies they will support.

Putting Everything Into Perspective

Connected Mobility is changing everything.  If you want to know why a winning strategy is important, just take a look at this.

Up Next: Leveraging Your Web Investment in the Push to Mobile

-Mike
@mobilebizguru

Previous: Welcome to Mobility Insights

Welcome to Mobility Insights

On January 9th, 2007 Blackberry was riding high, the economy had not yet fallen off a cliff, the Junior Senator from Illinois was contemplating a historic run for the Presidency, and Steve Jobs promised us a revolutionary new product that would change everything.

I think we can safely say his promise has been fulfilled.

If the later part of the 20th Century was the information age, then the early decades of the 21st Century represent the age of Connected Mobility.  In just a few short years we’ve gone from cell phones and text messages to devices that manage virtually every detail of our personal and professional lives while allowing us to stay connected to the world around us.  We wake up in the morning to music playing on our phone and go to bed after a night out at a restaurant or club we reserved from our phone.  Who we know, the music we listen to, where we get our news, the entertainment we watch, dozens of simultaneous text conversations, and the tools of everyday existence are all conveniently available on the same device.  And oh yeah, we make an occasional call or two.

It’s taken awhile for some businesses to catch up (and many are still finding their way), but Connected Mobility is a reality that isn’t going away and corporations must adapt or risk falling behind.  So welcome to Mobility Insights.

The purpose of this blog is to give business and IT leaders the critical insights needed to survive in a world driven by Connected Mobility.   Whether you’re dealing with broad mobile strategies, fine-tuning the performance of a mobile app, or just trying to build an app that somebody will actually use, we have the insights to guide you.   And if you want to learn more about how we use these insights in our own business, visit us at our web site – http://www.egeni.com

-Mike
@mobilebizguru

Next Up: 5 Critical Insights Driving a Winning Mobile Strategy.