Micro UIs: Microservices Are Visual, Too

Stop Conflating Microservices With APIs

Too often in client conversations, Forrester hears the terms “microservice” and “API” used interchangeably. To make your architecture and design patterns stronger, separate the two. Draw a hard line of distinction between them. Specifically:

• “Microservice” is a packaging and deployment concept. At its core, microservice strategy aims to create technical agility by decreasing the size of and deployment dependencies between the components of an application. Thus, with mature practices for DevOps and continuous integration/continuous deployment (CI/CD), smaller changes can more quickly move between development and production.
• “API” is an access and sharing concept. At its core, an API strategy aims to provide common mechanisms for accessing cohesive units of work as defined by a contract — i.e., the API’s interface definition. At its most strategic, an API strategy creates business APIs: units of work that mirror the major business capabilities of an enterprise (i.e., its core business transactions and queries). Other types of APIs are technical building blocks, but business APIs provide business building blocks. They insulate API users from the applications and technical details by which business capabilities are implemented.
• The two, of course, may be used together. An API may be backed by any implementation whatsoever, so long as it provides the functionality and quality of service promised by its contract. And, along with APIs backed by monoliths, integration servers, low-code, software-as-a-service apps, and many other styles, an API may be backed by a microservices-based implementation.

Extend Your Microservices Thinking Beyond APIs

There’s another major reason to not conflate APIs with microservices: A microservice might easily provide something other than an API. It may provide an event source, an event sink, a stream, or a data interface, and it may even provide a visual component that returns a block of HTML. Furthermore, it might not reside on a server the way an API typically does — it could reside on the client or run in a browser.

Forrester recently came upon an excellent example of this in the user experience (UX) architecture of Infosys’ Live Enterprise Suite. Here’s the idea:

• Make UXes highly role-based. Each different user role — service associate, field support, financial analyst, consultant, and so on — has a UX tuned specifically for that role and its behavioral profile. The organization, navigation, and functional content of a role-based UX are designed and laid out to make the role engaged and effective.
• Allow UXes to share common but customized parts. There’s a many-to-many relationship between roles and functions. This means not only do multiple roles need to share whole functions, they also must share parts of functions — think “individual screen widgets or groups of widgets” — and these parts may need to have slight variations across roles.
• Use Micro UIs to enable composable UXes. The Infosys Live Enterprise reference architecture unbundles the user experience into “micro UIs.” Each micro UI is a separately designed and built UX element that may be composed in different ways for different roles. Further, each may support parameterized configuration to tweak how a micro UI functions for a given role. Micro UIs may also be composed in different ways to meet the needs of different contexts for a single role.

Key Concepts For Micro UI Architecture

Five major concepts form the key structures of Live Enterprise’s micro UI architecture:

1. Composable, event-based client-side UX. Each micro UI element has its own client-side component that implements display and input of data and transactions.
2. Client-side event and state management infrastructure. This function coordinates between multiple client-side micro UI elements. Telemetry features of the client-side infrastructure can observe user activity and trigger deeper personalization of the UX.
3. Server-side contextual control. A controller on the server side coordinates across and between the actions happening in each of the micro UI elements. Think of this component as the lowest layer, architecturally speaking, of the UX layer of a Live Enterprise application.
4. Server-side processing. Each micro UI element has a server-side microservice to handle data retrieval and submission, along with any features or special processing that require server-side interaction.
5. Downstream microservices. The contextual controller does the actual work of the application by handing off transactions and queries to an underlying layer of business APIs and events (which in Live Enterprise have microservice-based implementations).

Infosys’ Live Enterprise Extends Microservice Architecture To The UX Layer

This type of architecture demonstrates why developers and architecture should not conflate APIs and microservices. It also points the way toward much more flexible and agile UX architectures that meet the demands of business agility and digital transformation.