Agile Headless — Maturity Model
Join the DZone community and get the full member experience.Join For Free
Headless has been there for quite some time now. It has surpassed the traditional model of building centralized and monolithic applications. With the augmentation of the need for digital experience, enterprises are moving towards more modularized, containerized, decoupled, and distributed computational architecture. When we look at how Headless has evolved over the last few years, the journey is fascinating. There are many facets of headless's transformation and transition model. We will discuss the evolution journey of headless and bring the notion of a maturity model in this context.
You may also like: Keep Track of Your Project the Agile Way Using Microsoft Project
In the early days, the applications are built more classically. This means functionalities are built within a COTS or custom platform, but horizontal decomposing of the functional/technical capabilities was not a priority.
For example in an online digital experience platform where customers can buy any product or service, typically the application is built from the angle of content, commerce, experience, and marketing. This means the customers' journey starts from getting an offline campaign and from there customer lands on a specific product offer page and buy the product if that meets the requirement. The final application is an amalgamation of how experience is devised, contents are managed, commerce is integrated, and marketing is encompassed to provide a personalized user journey.
In a typical application architecture, these functionalities can be built over traditional content or commerce-based platforms which normally provide content, commerce, and a bit of marketing support within the single platform. The enterprises can use a single platform strategy; many times, product vendors like SAP, IBM, Adobe provide a single platform strategy to build the digital experience platform. This often brings the notion of "monolithic" application architecture which is difficult to scale, maintain, and manage for the larger proposition. This can often work well for one area but may not for all the different feactes of technical capabilities across content, commerce, experience, and marketing.
The idea of Headless came into existence to play the role of "LEGO Blocks", means divide the application's main building block into isolated systems and then use API based communications to connect each other. This means a digital platform can consist of an experience platform as independent as a content or commerce platform; where commerce and content can be decoupled completely as well. The birth of "Headless Commerce", "Headless Content", and finally "Headless Digital" starts from there.
Once the Architecture moves to Headless, API becomes the key factor in how systems connect. All the services are built as API for that system to be consumed by other layers in the architecture. REST is the prevalent way of connecting through the API model. Depending on the maturity of REST and API economy, the Headless gets its flavor of maturity.
Maturity Level One
In this case, some core systems of concern are moved into the Headless model rather than multiple systems interact in a Headless way.
Example, Headless Commerce or Headless Content. This means move the Commerce into Headless mode for interaction with API while other systems of interaction like content, experience or presentation layer, marketing, etc. still work traditionally.
Maturity Level Two
In the case, Full Headless is used which means most of the system of concern will expose API or facilitate to connect over the Headless model.
For example, all layers including commerce, content, and presentation connect in Headless way only. API becomes the main lever to expose services from each layer, which in turn get consumed by another layer(s).
The headless paradigm goes beyond this system landscape to other systems like Headless PIM, Headless Marketing, and so on.
How Agility comes to Maturity is defined below:
The definition of Agility is measured by how the connections are fluid, adjustable, and adaptive. Many times, this agility defines the maturity of a system landscape. The more agility is needed, the equation becomes more complex to manage. Therefore, it is the responsibility of the organization to decide what extent of maturity level and agility to be enforced in the architecture.
The building blocks in the Agility of Headless maturity model can be of the below possibilities.
API plays the biggest role in how the Headless model will be devised. The management of API gives the power of agility. Therefore, API gateway becomes an important tool in the architectural landscape. The gateway manages the access control, authentication, authorization, and viscosity of the API in an omnichannel. The diverse channel to be supported, the friction to build an API economy for headless paradigm becomes more. This means the API management is the key enabler there.
REST — the Level of Maturity
REST comes in different levels of maturity. The Richardson’s maturity model defines the level three is the more granular and singular block of how endpoints are iterated over for the state of an entity.
When defining API often the REST's level of segregation to denote an object/entity is ignored and not many applications are built keeping in mind the HATEOS style of REST gives a step-by-step flow to access the deepest root of an object and its path, but Level Three comes up with its nitty-gritty, getting there needs careful design of REST services. Level Three gives the flexibility to handle REST in a more micro-layers way.
GraphQL — Client Control
Often the Headless API may become a monolith especially when access through multiple devices under the omnichannel scenario. The purpose of Headless is to give the access of services to every touchpoint, API becomes the glue, but in the end, service becomes fatter and integration with multi-devices becomes a challenge in several aspects. Performance becomes a big issue in low-bandwidth devices, API response becomes an overhead across multiple channels; in this scenario, the selective response from the client is of utmost necessity.
GraphQL gives that flexibility to the client to query the API for its specific needs. Instead of consuming one single monolith and fat response the client can choose and retrieve the required dataset from the server only through API.
Most of the times the definition and purpose of an API become critical for the client and application developers become a concern. Open API Specification (formerly Swagger) or RAML are the ways the APIs can be documented for consumption more seamlessly and efficiently.
APIs need not be monolith but fits for purpose with some defined responsibility for a domain object. The independently scalable, manageable, programmable, and traceable instance of API is what a micro-service model defines. When building a Headless way to connect systems, the organizations need to define and design how the APIs will be built and deployed.
Conway’s law states that the organization's designs are copies of the communication structure of that. Therefore, many times these can become a key factor in how these API services are laid in the enterprise architecture.
Overall when defining, designing, building the Headless paradigm of any enterprise architecture the maturity fused with agility become the key decision-makers. The Enterprise and Technology Architects along with the business team and product owner have an equal responsibility to architect the end-state solution.
This to-be architecture can be done in a step-by-step way to ensure the minimum-viable-product (MVP) solution is built first and then keep adding more functionalities along with adjusting the architectural building block to the final state.
Opinions expressed by DZone contributors are their own.