Responsive Systems STRAWMAN

Document overview

Goal: Create an abstract model of an ideal system designed to survive and thrive in a rapidly changing world. A model that could be applied to any and all aspects of life from Software Architecture to Digital Strategies to Government and beyond. While specific use cases, technologies and techniques are used as examples, the model itself is intended to be timeless.

Revisions

Date

Edited by

Notes

Dec 1 2012

Chris Saad

Draft 1 Created

Feb 14 2013

Chris Saad

Fleshed out details for creating a Responsive System

Feb 25 2013

Chris Saad

Fleshed out more details for creating a Responsive System

March 2 2013

Chris Saad

Fleshout more details for creating a Responsive System and added examples to each section

April 30 2013

Chris Saad

Added an Introduction/Context

Jun 2 2013

Chris Saad

Minor Polish Review

Jun 6 2013

Chris Saad

Added Biological Analogues. Moved ‘Governed’ to the top of the list. Renamed ‘Four Dimensional’ to ‘Context’


Table of Contents

Document overview

Revisions

01. Introduction

Document Architecture

01.  Introduction

02. Definition of Responsive Systems

03. Examples of Responsive Systems

04. Details of a Responsive System

05. Concrete Examples

Overview

In summary

The rate of change is increasing

Current Systems are inadequate to handle change

Introducing Responsive Systems

The example of social media

Purpose of this document

02. Definition of Responsive Systems

03. Examples of Responsive Systems

Responsive Design

Responsive Software

Responsive Support

Responsive Education

Responsive Offices

Responsive Content

Responsive Governance

Responsive Capitalism/Economy

04. Details of a Responsive System

General

People & Education

Governed

Vision

Mission

Guiding Principles

Laws

Pruning

Roadmap

Situational Awareness

Analytics

Communication Processes

Context

Past: Record Keeping and Research

Present: Bandwidth Monitoring

Future: Trend Analysis and Prediction

Low Latency Feedback Loops

Democratic Input, Accountable Execution

Iteration

Live Updates

Service Orientated

Core patterns

Application Layer

05. Concrete Examples

Responsive Software

General

People & Education

Governed

Vision

Mission

Guiding Principles

Laws

Pruning

Roadmap

Situational Awareness

Analytics

Communication Processes

Context

Past: Record Keeping and Research

Present: Bandwidth Monitoring

Future: Trend Analysis and Prediction

Low Latency

Democratic Input, Accountable Execution

Iteration

Live Updates

Service Orientated

Core patterns

Application Layer

Responsive Companies

Responsive Government

Responsive Marketing


01. Introduction

Document Architecture

01.  Introduction

High level description of Responsive Systems.

02. Definition of Responsive Systems

Describes the broadest possible, most abstract view of ‘Responsive Systems’. While some examples and case studies are included, it is intended that these descriptions are use-case agnostic and timeless.

03. Examples of Responsive Systems

Explain the various ways the abstract Responsive Systems model applies, in very broad terms, to specific systems found in the real-world.

04. Details of a Responsive System

Explains how the characteristics of Responsive Systems might break down to specific, actionable techniques.

05. Concrete Examples

Exploration of how the abstract Responsive Systems model applies concretely to specific use cases like Software, Government and Education. Again specific technologies and techniques will be used as examples that may change over time but the way in which the general model is applied for the specific use case should hold true over time.


Overview

In summary

Responsive Systems is a model for designing and implementing systems (E.g. software, governments, companies etc) that survive and thrive in a rapidly changing world.

The rate of change is increasing

It’s clear that the rate of change is accelerating. The inexorable path to singularity is self-evident. If rapid change defines our personal and professional lives then it should be no surprise that systems that understand and respond most efficiently to change will be the systems that survive and thrive.

Current Systems are inadequate to handle change

It seems, though, that every new system (be it a piece of software, a government department or a new corporation) tends to re-invent or re-discover core principles that make a system respond efficiently to their environment. Also, established systems that survive for any length of time (like old companies) accrue legacy debt and bad habits that slows innovation. The problem gets worse when new technologies and techniques (like social media, mobile, big data etc) tend to throw systems into periods of turmoil as stakeholders try to understand how these new tools fit into or change their organization.

Introducing Responsive Systems

Responsive Systems is a term used to describe, in extremely abstract terms, an idealized system that is highly adaptive, consistent, innovative and thrives in rapidly changing environments. This model is designed to be applicable to a wide range of concrete use cases.

The intention is that the model is so abstract that it acts as a framework for thinking about problems in a wide range of use cases, at different levels of granularity and throughout the advancement of technology, techniques and cultural trends. Throughout these various scenarios the model itself does not change. The only thing that changes is specific tools and the resulting latency of responsiveness.

This model should help systems digest day-to-day change or fundamental disruptions in a methodical way ensuring that new tools and data inputs are put into the right context and leveraged as part of a system wide process.

Interestingly the ideas in this document are not necessarily new. In fact it might be noted that the characteristics of a Responsive System (as described in the section ‘Definition of Responsive Systems’) are actually the basic biological functions of receiving sensory information (through eyes, touch, taste smell etc), routing them through a decision making process (the brain) and triggering nerve impulses and actions in the real world. With this in mind, biological analogues are included along side each of the Responsive Systems characteristics listed below (“Definitions of a Responsive System”).

The value of describing the system in these abstract terms, then, is not to invent some new systems model, but rather to make explicit existing, best practices for systems in terms that can be discussed and put into action across many fields (E.g. Government, Corporations, Software etc) and over the course of time (irrespective of changing technologies or techniques). By doing this we can...

  1. Understand that most systems follow much the same patterns.
  2. Establish a common dialogue when discussing the systems in our world.
  3. Extract and share best-practices across all fields.
  4. More quickly jump to better answers when designing new systems or refactoring old ones .
  5. Quickly and correctly understand the best fit for new technologies or techniques that might improve the responsiveness of a system.

The example of social media

A good example of these challenges and opportunities in the real world is the emergence of Social Media and its disruptive effects on business and relationships. Upon its emergence and rapid rise to popularity, trying to digest the tools and techniques of Social Media introduced a wide range of new challenges and opportunities for organizations of all types and sizes.

In response to Social Media, companies were reinventing the wheel, creating new departments and making poor investments in shiny new objects that were ultimately abandoned. Countless books and blog posts were then written trying to clean up the craze explaining how Social Media was ‘just a tool’ and should be part of a ‘strategic communication strategy’ etc. To this day the proper place and purpose of Social Media is not well understood by agents of many companies.

Using the Responsive Systems model, these organizations can better understand how Social Media can provide meaningful (yet surgical) contributions for appropriate areas of the system (E.g.  ‘Situational Awareness’, ‘Low Latency’  and ‘Service Oriented Architecture’ - explained in detail later in this document) without going through the highs and lows of the hype curve.

This pattern has repeated over and over throughout history and will continue unabated into the future - from the invention of publishing to the advent of mobile, wearable computing and increasingly bioengineering and new energy technologies.

Purpose of this document

It is hoped that this document, and the Responsive Systems model described herein, will help system architects and participants better identify and respond to change by:

  1. Articulating the characteristics of a Responsive System in their most abstract and timeless form
  2. Providing a more detailed description of these characteristics with specific tools and techniques that might be used to implement them
  3. Concretising these abstract characteristics into specific use cases and examples

02. Definition of Responsive Systems

Responsive Systems have the following characteristics...

  1. Governance
    Biological Analogue: Need, Want, Moral Compass, Rational Thinking
    Responsive Systems use smart governance to ensure focus, gracefully handle exigent circumstances and enforce accountability for bad actors. The governance model must include a mission, vision, guiding principles and laws. Some of these might be imposed by the environment, others might be defined at inception. They must always be subject to review and refinement based on the principles outlined above. Responsive systems are democratic.
  2. Situational Awareness
    Biological Analogue: Eyes, Ears, Taste, Touch and Smell
    Responsive Systems are observant of changes and patterns in their environment - changes that are both subtle and gross. They track with the state of the art and extrapolate based on current trend lines. They identify and measure the right things in real-time. They create meaningful and causal inferences from the measured data. They make that data available to as many appropriate stakeholders or subsystems as possible. Most recently this connects to trends in Big Data and Mobility.

  1. Context tracking
    Biological Analogue: Memory, Mental models, imagined future states
    Responsive Systems are observant of past patterns and lessons, respectful of todays constraints and, most importantly, embrace the potential of the future. Calculations are optimistic. Most recently this connects to trends in Social Login and Open Standards.
  2. Low Latency Feedback Loops
    Biological Analogue: Nervous system, muscle response, hand-eye co-ordination
    Responsive Systems make decisions and execute actions (including changes to the system) with minimal delay and in an experimental and iterative fashion. At each iteration, Situational Awareness provides insights into success or failure. The cycle then repeats. Feedback Loops, however, are always in the context of future proof strategy and an awareness of the overall Service Orientated Architecture that stays consistent over the long term. Most recently this connects to trends like Mobile, Real-time and Agile/Lean development.

  1. Service Oriented
    Biological Analogue: Hands, Legs, Opposable Thumbs and any other multi-purpose body part
    Responsive Systems are based on Services. Common or ‘Primitive’ patterns are baked into baseline capabilities that are drawn on by domain or project experts at the ‘application’ level to achieve day-to-day tasks. Services have defined APIs that encourage an ecosystem of value creation on top. Most recently this connects to trends in discrete Cloud Services, PaaS, BaaS etc.

03. Examples of Responsive Systems

Responsive Design

Designs that refactor themselves organically around the available screen real-estate and form-factor.

Responsive Software

Software that is designed for rapid iteration and interoperability. It allows for a mix of ‘off-the-shelf’ building blocks with extreme customization and custom development. Service oriented architecture.

Responsive Support

Support that assists customers with planning a long-term strategic success path, collaborates with tactical deployment/execution and ensures life long learning and improvement. Support that is proactive about finding faults using monitoring (both technical and social monitoring).

Responsive Education

Education that teaches students to be responsive and creative by example and curriculum. Curriculum frameworks that are allow for the rapid development and delivery of new courses in niche subjects as things become relevant. Teaching how to think vs. what to think/know.

Responsive Offices

Offices that act as co-working spaces for customers, partners and colleagues. Open, multipurpose plans. Hotelling. Multiple physical spaces might be connected via telepresence. Street frontage, Open door policy.

Responsive Content

Content that change as the underlying dataset changes - no need to refresh the page. Content that is personalized (by friends and interests). Content that allows for social engagement. Aka: Real-time and Social.

Responsive Governance

A version of democratic decision making that allows every stakeholder to participate to their fullest desired ability.

Responsive Capitalism/Economy

An economy that is build on responsive systems whereby prices and products find their level without artificial tariffs or subsidies. Where inefficiency is vacuumed out.

04. Details of a Responsive System

General

People & Education

Since any system is built and run by people, each of the characteristics of a Responsive System needs to be part of the core skill sets of every stakeholder. Ideally, these skills might be instilled via training/education program as a prerequisite to participation in the System. This must be the first step to any successful design and implementation of a Responsive System.

While clear examples of education in society (schools, colleges) and professional environments (professional development) exist, typically they lack a focus on the why and how the given system works and instead focus on rote repetition or outcomes. An emphasis on teaching the principles of Responsive Systems specifically will change outcomes dramatically, as all stakeholders begin to understand how the system works and how they might improve it.

Governed

Vision

Every Responsive System must have a vision. A clear statement about how it sees its environment today and how the environment will change over time.

Mission

Every Responsive System must have a mission. A clear statement about for how it will change its environment as a result of its input and output process.

Guiding Principles

Every Responsive System must have guiding principles. A collection of statements describing its core beliefs and assumptions about the world and its operation within it.

Laws

Every Responsive System must have laws governing the behavior of its stakeholders, sub-systems and services. Some laws are imposed by the environment, others are inspired by the vision, mission and guiding principles and imposed from within.

Pruning

Every Responsive System must be aggressive about reducing redundancy, refreshing outdated approaches and pruning any aspect of itself that no longer serve its stated vision, mission, guiding principles and laws.

Roadmap

Every Responsive System must have a living roadmap that assists internal and external stakeholders to predict its trajectory over time. The further out the time slices the more susceptible to change the roadmap items might be, however even a rough sketch is better than nothing.

Situational Awareness

Analytics

Identifying the key performance indicators of a system and then finding ways to accurately measure those KPIs in real-time is critical.

For example a new government program would include KPIs (as well as, perhaps, indicators for potential unintended consequences) and a review process by which those KPIs are evaluated on an ongoing basis.

Another example would be a piece of software that measures performance, uptime, rate limits, number of clicks to complete a task etc will result in better software.

Communication Processes

Once measured, objective issues revealed by underperforming KPIs or subjective insights ‘on the ground’ need a clear, crisp and effective way of flowing into and out of relevant stakeholders. The methodology must include real-time updates as well as a way to pool and prioritize items for regular review.

In government this might include continuous reporting to responsible departments and, most importantly, to the people being served by the program. In software this would include monitoring for uptime, capacity and/or changes data being propagated in real-time vs. in batches. In companies this would might manifest  in real-time dashboards rather than weekly or monthly reports.

Context

Past: Record Keeping and Research

Maintaining documentation about past system behavior/outcomes, collecting documentation/outcomes of similar systems and evaluating that collective dataset when making decisions is critical to optimizing future behavior. History (The facts, patterns and metaphors) repeats.

In government, examples might include observing what other countries or departments have implemented that has worked well. In companies a study of broad market trends and patterns is essential to predicting the future and picking a winning strategy. In software, common software patterns are often times used to ensure architecturally sound choices even at prototyping stage.

Present: Bandwidth Monitoring

Constraints are often times creative forcing functions that impose efficiency through focus and prioritization. Therefore carefully measuring the available bandwidth of every component of the system is essential as well providing mechanisms to (when appropriate) allow for autoscaling.

While constraints might constrict throughput, they should never be an excuse for a lack of process (which in fact leads to waste) or executing an action that is outside the vision, mission or laws of the system (further detailed in the ‘Governed’ section). In the long run a lack of process or an ill-conceived action will always cost more in soft and hard terms.

Examples in government might include scaling a program based on available revenue vs. arbitrarily setting goals that latter need to be funded. In companies, building departments and processes that are thoughtful about limitations but are designed as building blocks to a larger play ensure that the business can scale as market traction hits. With software, designing clean abstractions, throttling mechanisms and implementing good patterns ensures that new features and scalability can be built in later with minimal breaking changes.

Future: Trend Analysis and Prediction

Perhaps the most important function of time is it allows for the evolution of technological and cultural realities to unlock economies of scale, change minds, open markets, create new efficiencies and drive demand. As such, Responsive Systems must factor in the trajectory of current trends and idealistic projections to catch opportunities as they crest.

Low Latency Feedback Loops

Democratic Input, Accountable Execution

In a Responsive System, all stakeholders are welcome to provide input. This might include stakeholders that are outside what might be considered the traditional decision making circle.

While all stakeholders can provide input, a small executive process must ultimately be relied upon to make the final decision and manage the execution. This executive process is accountable for successful execution.

In government, this might include a broadening of the democratic process to include real-time polling of the electorate while the President and her team are responsible for execution. In companies this might include involving all staff and even customers and partners in the decision making process while the CEO and other executives are ultimately responsible for execution.

Iteration

Responsive Systems deliver value as early and often as possible and iterate quickly. It’s also critical that changes to, or outputs from, the system are tested in the real world. As such, actions taken by the executive process are chunked into release stages over time.

Each iteration is influenced by the Situational Awareness, Four Dimensions and Service Oriented Architecture characteristics of the system. In other words iteration does not mean ‘hacks’. Effectiveness of each iteration are measured, the iterations are future proof and they are designed as shared services.

In startups this is known as ‘Lean’. In software, ‘Agile’.

Live Updates

As iterations are released, all stakeholders are notified live so that they can make the best possible decisions at any given time.

Service Orientated

Core patterns

Each system eventually establishes recurring patterns or ‘primitives’. These are core characteristics of the overall system that have become regular, predictable and occur across many applications or use-cases.

A good example of such a primitive in Government is the post office. While the post office in the United States of America is, in many ways, faltering, it is a great example of early Service Oriented Architecture that served the system well for a long time. It was seen that ‘messaging’ between people within the society was a common requirement capable of clean abstraction and delivery with a simple API - stamps and addresses. In many ways Government itself is a kind of ‘Primitive’ of society at large allowing for group action for the common (shared) good.

Had this service kept up with modern messaging technologies such as online identity, email and instant messaging then the Post Office would continue to provide a valuable service as a or ‘Service’ of the ‘US Government’ fulfilling the ‘Primitive’ of ‘message delivery’. Other government services exist, of course, including the Military, FBI, CIA and more.

In software, a great example of this include Amazon Cloud Services, Twillio and Echo. In families the shared bank account and car. In companies the common kitchen and break room.

Responsive Systems use this methodology liberally and have pro-active methods of detecting, defining and formalizing this primitive patterns as ‘Services’ that are consumed through Application Programming Interfaces. The services must be discrete and undergo a continuous cycle of refresh (and pruning) as the needs of the system and available technologies change.

It’s important to note that this is a reductive process. The intention is to identify and operationalize the fewest possible services with broadly useful functionality. As one moves up the ‘stack’ (towards the application layer) these services and processes become more specialized.

It’s essential (and often overlooked) that the services are provided through simple, open and well defined interfaces and that any redundancies are avoided and that horizontal dependencies on peer services are either loosely coupled or abstracted from consumers.

Application Layer

In Responsive Systems ‘Services’ are implemented in the ‘real world’ via ‘Applications’. Applications consume and combine the primitive functionality of services and offer either permanent, reusable or bespoke combinations that fulfill use-cases in user-friendly, value creating and innovative ways.

In society, Government provided Roads, Police, Mail etc are used to to build Businesses, Families and successful personal lives. In software the use of Amazon Web Services to build websites or mobile applications. In families the use of the family car to create routines to the park or basketball practice are all ‘Application Layer’ use cases of services.


05. Concrete Examples

Responsive Software

General

People & Education

Rather than allowing engineers to work in a vacuum, it’s essential that a concerted effort is taken to sync all participants in a software project(s) on the various moving parts, patterns and use-cases. This might take the form of weekly or monthly meetings to take a new look at the current and high-level landscape of the system in question.

These meetings are also a great opportunity to define and refine the analytics KPIs, Communication Processes, Trend Analysis, Iterations, Core patterns, Vision, Mission and Laws of the system as detailed below.

These regular syncs (not just about the work, but the system and process) provide a formal opportunity to sync implementation decisions with all aspects of Responsive Software.

Finally, teaching the principles of Responsive Systems generally and Responsive Software specifically, will ensure that all stakeholders understand how to implement its ideals at all levels (in their department, in their code, in their user interface etc).

Governed

Beyond the general recommendations of a Responsive System described above, the specifics of your Software governance is dependant almost entirely on your project. It’s only essential that the following questions are considered and answered to define the constraints of your software system.

Vision

Writing software takes time. What you know of the world now will possibly change by the time your software drops and/or during the lifecycle of your software’s iterations and use in the wild.

It’s essential then, to give some consideration about the future inside which your software will live so that what you deliver will not be obsolete on arrival, limit your upgrade path or fundamentally become irrelevant within too short a time period.

Mission

Given your vision of the world, what is the mission of this software. Questions like these become essential to defining the mission:

  1. How will it affect the world or solve a real problem.
  2. What is the core proprietary value of the software being built? This is especially important when understanding what to build, buy or partner on.
  3. How can it co-exist with other pieces of software or business systems?

Guiding Principles

It’s essential to set high level principles that create consistency across the software project by asking and answering questions that are give clear guidelines to the engineering and design team.

For example...

  1. Is this team a build, buy or partner team?
  2. Is this an easy to use tool for the mainstream or a sophisticated tool for power users?
  3. Are the use of open standards helpingful?
  4. What are the coding, documentation, release, versioning and naming conventions?
  5. What are the user interface design language and interaction models used?
  6. How are the techniques of Responsive Systems expressed in the architecture and the user experience of the software?

Laws

  1. What are the operating tolerances of your system?
  2. What are the rules of the system?
  3. What is the trust model?

Pruning

  1. Rather than adding a new feature or checkbox, how can an existing feature be modified to be more generally useful.
  2. How can existing features be pruned when they are no longer necessary.
  3. How can unnecessary UI clutter be removed to help the user focus?

Roadmap

It’s important to have a living roadmap that assists internal and external stakeholders to predict the trajectory of the softwarever time. The further out the time slices the more susceptible to change the roadmap items might be, however even a rough sketch is better than nothing.

Situational Awareness

Analytics

Identifying the key performance indicators of the software system (both as it relates to performance and business goals) and then finding ways to accurately measure those KPIs in real-time is critical.

Performance, uptime, rate limits, number of clicks to complete a task, A/B testing etc are all essential to influence systems design based on quantitative data.

Communication Processes

Once measured, it’s essential that these software and business indicators are communicated to the relevant stakeholders in real-time.

System performance should be reported not only to engineers and ops personnel, but directly to subsystems responsible for auto-scaling.

Business performance should be reported to all stakeholders in the business all the way up and down the org chart.

Context

Past: Record Keeping and Research

In software, there’s nothing worse than inventing a new data format or technology when an industry standard exists. When evaluating a data format or API the decision making stack must follow this list of questions. Each is terminating.

  1. Can this use case be fulfilled using an existing open format/protocol? Use it.
  2. Can this use case be fulfilled using an existing extension to the format/protocol? Use it.
  3. Can this use case be fulfilled using a well known microformat or emerging pattern? Use it.
  4. Is there a generic way we can describe the data or handle this transaction? Invent it and propose it as an extension. Where possible the extension should try to follow established naming conventions and implementation patterns.
  5. Is there no existing open standard or generic approach? Clearly define it as an Echo proprietary extension and document the exception. This should be considered a failure state and should be slated for re-evaluation by the strategy team and our developer community who might have new/different ideas.

 

In all cases the bias should be to using the standard, even if it isn’t an exact fit. The benefits of leveraging (and contributing to) existing work far outweigh the perceived costs of sticking to someone elses format.

Further, evaluating implementation and UI patterns that have worked in the past (including software pattern) are essential to make architecturally sound choices even at prototyping stage.

Present: Bandwidth Monitoring

While development constraints might constrict the pace of development, they should never be an excuse for a lack of process (which in fact leads to waste) or implementing too many hacks. In the long run a lack of process or a short term hack will always cost more in soft and hard terms.

Designing clean abstractions, throttling mechanisms and implementing good patterns ensures that new features and scale can built in later without breaking changes. Avoiding hacks means that investments in time are never wasted and outcomes are more predictable. It also avoids inevitable hacks on top of hacks.

Future: Trend Analysis and Prediction

Building a piece of software that’s good enough ‘for now’ is essential for quick prototyping and MVP however even at this stage of development there are ways to build a UI and use-cases that are forward leaning.

In the most recent cycle building social, streaming and mobile software over static, desktop web pages (early) was a good example of leaning into future trends before they became obvious to most. Think Instagram beating Flickr by leaning forward into emerging trends.

At later stages of development, the need for future-proofing the UI, UX and Architecture choices of your software based on the latest technology and interaction trends ensures that by the time your work ships (or by the time people discover it) it will be relevant and durable.

As technologies evolve and mature over time, it’s also essential to keep an eye out for custom built innovations that become commodities in the open market. It’s essential that your team identify these early and cannibalize internal/proprietary subsystems as soon as appropriate. An alternative approach is to make open source your subsystems so that they become the commodity.

Low Latency

Democratic Input, Accountable Execution

Development: The ultimate democratic software development is open source. Short of this (or perhaps in concert with it), however, it is desirable to democratize the process of bug fixes and feature requests using real-time polling of stakeholders while a benevolent dictator, product manager or CEO are responsible for execution.

User experience: Discovery is driven by user engagement and personalization. Actions are logged and displayed in human readable stories for users to see. Stories are social.

Iteration

Development: Agile development is an established software development model that addresses the need of Responsive Systems to be iterative. It’s essential, however, that each iteration is influenced by the Situational Awareness, Four Dimensions and Service Oriented Architecture characteristics of the project. In other words iteration does not mean building hard coded features based on proprietary formats that are ‘good enough for now’. Iterations must be done right vs. done quickly.

User experience: Outcomes are visible in a side-by-side preview pane. Administration tasks are possible from the front end without having to switch to a heavyweight ‘administration’ mode. Rollback is possible.

Live Updates

Development: Checkins made into public code repositories, clean and clear inline documentation and thoughtful release notes are essential to involving all stakeholders in the development process.

User experience: All changes to underlying data sets are propagated to all clients in real-time - no need to refresh the page.

Service Orientated

Core patterns

Development: Each piece of software utilizes core patterns. Not merely software design patterns, but common business entities or application capabilities. It’s important to identify these core application primitives early and often and build them as (or better, leverage existing) core services.

For example, on the web these are best delivered as ‘Cloud Services’ via APIs. It’s not enough to make an API through which your back-end can talk to your front end, however. Instead the software architect must ask themselves questions like:

By developing all aspects of your software system as a series of discrete, loosely coupled services, your software becomes more reusable, more broadly useful, more fault tolerant and ultimately easier to scale as various sub-systems are improved individually.

User experience: How might you provide the user a central UI metaphor around which other features of your app rotate. This core pattern or UI element ensures that users don’t get lost. If possible the core UI metaphor is repeated with clear landmarks used along the way so that the user is always clear what entity or process they are engaged in.

Application Layer

Development: Your services, then, are implemented in the application layer. Applications consume and combine the primitive functionality of services and offer either permanent, reusable or bespoke combinations that fulfill use-cases in user-friendly, value creating and innovative ways.

This technique also helps to better balance between productized work and implementation time customizations. Common application scenarios can be developed as shrink wrapped applications while specific customizations for customers can be novel implementations of the cloud services.