Mobile Needs A Four-Tier Engagement Platform
Posted by Ted Schadler on November 20, 2013
- 63Recommendations
- 2 comments
Michael Facemire, John McCarthy, and I recently published a clarion call to the technology industry: It's time for a new architecture! The aging Web isn't designed to handle mobile apps or sites. And it certainly can't handle the real-time demands of connected products.
Here's how we summarize it:
Mobile is pushing aging web architectures to the brink. The three-tier architecture built for a browser-led PC world can't flex, scale, or respond to the needs of a good mobile experience or the emerging requirements for connected products. Mobile's volatility and velocity of change require a distributed four-tier architecture that we call an "engagement platform." The engagement platform separates technical capabilities into four parts: client, delivery, aggregation, and services. The new requirements of modern apps will force content distribution networks, application server vendors, mobile middleware vendors, platform-as-a-service suppliers, a myriad of startups, and enterprises to coalesce around this four-tier architecture. CIOs need to start planning immediately for the migration from three tiers to four.
It's time to throw out the old notion of a three-tier architecture -- presentation, application, data -- and replace it with a four-tier engagement platform that can handle the new demands:
An engagement platform suppports a distributed, four-tier architecture natively engineered to deliver compelling experiences, excellent performance, and modular integration on any device over any network at Internet scale.
Figure 1 The Four-Tier Engagement Platform Makes Delivery Its Own Tier
How the four tiers handle the load:
- A client tier accounts for the unique attributes of different devices. This presentation layer insulates the unique capabilities of each app and device — desktop or mobile, browser or dedicated app — from the services that back-end applications deliver. This boundary allows developers to create back-end services like flight status and shipment notification independent of the mobile app that will consume them. Creating this clear boundary drives productivity for your developers without an onerous maintenance challenge; it will be critical for a fluid business partner network.
- A delivery tier handles special middle- and last-mile challenges. This element uses intelligence from the client layer to determine the optimal way to deliver contextually appropriate content. The delivery tier accomplishes this by using over-the-wire content transformation — as opposed to protocol-based conversions at the next aggregation layer — and leveraging edge-of-network cache functionality for increasingly dynamic data. CDNs such as those provided by Akamai, along with delivery optimization solutions like Instart Logic, application delivery controllers like Riverbed Stingray, and on-premises in-memory database caches, fulfill this today.
- An aggregation tier integrates internal and external services and transforms data. This API layer has two brokerage roles, providing discoverability between app requests and services and bidirectional translation between client requests and back-end or third-party services. This makes composing the underlying data and services easier and enables relatively simple real-time translation to the appropriate data format. The service composition becomes more dynamic with the addition of business intelligence, analytics, and role-based access, which occurs in this tier.
- A services tier spans internally and externally provisioned data and functionality. This final architectural element dynamically composes data and business processes through a set of continuously deployable services. This tier provides data to the layers above without concern for how that data is consumed; the other layers can exist behind the corporate firewall or externally — or both! This allows for the ultimate flexibility in the consumption and dynamic composition of services, whether leveraged by apps or by the evolving partner ecosystem.
Plotting The Path Forward
Question: If engagement platforms are the future, then how do we get there? Answer: Disruptively at the architectural heart of the technology industry. The three-tier architecture long heralded by IBM, Microsoft, Oracle, and Akamai is already being hollowed out by an emerging four-tier approach used by Netflix, Kinvey, and Salesforce.com.
It's time for vendors, investors, enterprise architects, application developers, and CIOs to begin a thoughtful technical and business discussion about how to build and operate an engagement platform. Engagement platforms will handle the complex, contextual, real-time demands of mobile experiences and connected products and drive these disruptions:
- Firms will rely on a ecosystem of providers to deliver engagement. You're not going to buy an engagement platform in a box. And it won't all run under your direct control. Instead, you will assemble -- or rely on a provider to assemble -- a set of engagement capabilities loosely coupled and able to scale to the demand while remaining flexible and able to handle continuous delivery.
- HTTP traffic on Nginx will surpass the traffic on Apache. If you don't know what those things are, don't worry about it. If you don't but think you should, then see the last chart here and learn about it here and here.
- IBM, Oracle, Microsoft, SAP, and Salesforce.com will rethink their middleware products and architectures. Adding mobile app lipstick on an application server won't solve the delivery challenge by itself. These companies will slowly overcome their reluctance and begin to operate in a four-tier, ecosystem-dependent platform. But it will take five years for that to happen. Microsoft Azure is the farthest along, but still tentative in its strategy and execution.
- The content delivery network industry will accumulate content and performance optimization services. Akamai, Limelight, and Amazon CloudFront have done good work for the Web. But new approaches from Instart Logic and rumblings from Akamai point to the delivery-tier future.
- Platform-as-a-service providers like Amazon, Google, IBM, Microsoft, and Salesforce will grow many new platform services. For example, services in the aggregation tier loosely coupled with an intelligent delivery tier will handle notification at scale, including personalized messages, open-message analytics, and device and network customization.
What say you?
Facebook
LinkedIn
Twitter
扫一扫
973
到【灌水乐园】发言
Comments
Ted - Great points and
Ted - Great points and definitely something to think about. It’s interesting that before the proliferation of mobile and the “internet of things”, the traditional three-tier architecture was designed and built for content consumption in very standard ways. This worked great, but with the proliferation of mobile devices of all shapes and sizes, the content consumption needs of today require customized and optimized delivery at the edge per device, per user, per context, per location and more.
As we leverage our Mobile Enterprise Model (MEM) to assess the ability of a client’s existing architecture to support mobile, we see that mBaaS solutions, in particular, attempt to solve the problem of seamlessly connecting mobile technology *back* into existing network architectures. This is an accelerated way of offering mobile end points, without a heavy investment of retooling enterprise-level architecture. That’s just the beginning, though. As the internet of things proliferates, with an always-connected nature at its core, we see many challenges and therefore opportunities for new startups and technologies, as consumers and devices demand always-on, customized experiences from anywhere at anytime.
Re: next generation distributed systems thinking
Hi
I like the figure 1 four tier engagement model – notice the contents of each layer .. look familiar?
In my research on a variety of things, a few observations have surfaced in understand that might be worth figuring out how to answer.
1. How does ERP , CRM relate to the “basket of 5”: Cloud, Mobile, social, Big Data, IoT. A chalenge is that many people are in the ERP space e.g. GNX B2B linking to SAP multiple ERPs but we use the basket of 5 as a list of what next ?
2. How does legacy systems move to and from Open Platform 3.0 ? A challenge is I see is related to governance and lifecycle refresh management we have not touched yet with our tiers of static layers. It would be useful if a Systems framework like TOGAF had a Lifecycle model of some sort
3. How does second or third level integration work in IoT and social networks. This point is more subtle to explain but in summary is a systems view that SOA may need a second or third tier of integration for systems “outside” the normal scope of integration of an enterprise such as remote mobile systems, social networks and IoT Device meshes. These don’t fit neatly into a Tiered Architecture. This area is related to “modularity” a concept that is not service encapsulation but of whole appliances and device encapsulation , or “in a box” that fits a different type of architecture paradigm. The RFID-Smart Retail / NL example is very much about this universe for example crossing between modular systems and platforms; not just a tiered platform perspective I’ve seen from some quarters of speakers. I saw the evolution of a SOA 2.0 idea with APIs from a re4cent webinar by Randy Heffener from Forrester and Itel which is a step in this direction but not completely filled out yet.
The first question is particularly relevant if we use buzz words and Branded vendor names to describe architecture taxonomies. My personal preference is to reduce to a pure architecture nomenclatures that may include new abstracted artifacts. For example , Data in Big Data I see as a meta data level of encapsulation that acts like glue between social processes. Or Workspaces are virtual co-presence networks that form in the connections of social networks. These are real spaces that exist in digital virtual spaces represented by the meta data and relationships of participants coalescing and reforming or dissolving in real time. This is related to a proper definition of workplace technologies and the wider digitation of supply chain networks for example and the formation of new community structures. Again this does not currently in my view have an architectural language or notation beyond the SNO and social graph mappings.
Best wishes and seasons greets
Mark Skilton