Category Archives: 5 Critical Insights

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 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.


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


Previous: Welcome to Mobility Insights