North Patrol is a consulting firm specialized in the design of digital services and information systems. We shape ideas into a vision and service concept, find the best architectural and technological solutions, design a functional user experience, and compete to find the ideal partner for implementation work. We do not sell implementation projects, nor do we sell licenses; we are genuinely on the side of the customer.
This article is a part of CMS selection article series by North Patrol.
North Patrol helps customers to make smart technology decisions and find the best implementation partners. Typically, we facilitate prestudy projects and evaluate vendors and proposals. Most of our clients are large companies headquartered in Finland.
All online services are built by customizing
The term "customized solution" is becoming increasingly difficult to define, and, perhaps even, a bit outdated. Today, no online service is created without some degree of customization. Instead, we should talk about solutions based on composable architecture. In these, the entire online service is typically implemented by combining various, even very independent components.
For example, online service can be built in such a way that one application takes care of content management, another handles raw data storage, a third enriches the data, a fourth provides search functionality, and a fifth handles the presentation layer visible to the end user. Traffic between these components is handled through modern programming interfaces, such as REST.
Popular composable technologies
In the bidding proposals submitted to North Patrol's consultations, more and more often there are at least some elements based on the composable model. The traffic between different parts is usually done through REST API calls. Also, solutions often utilize pre-built services offered by popular platform ecosystems such as Microsoft Azure, Google Cloud Platform, and Amazon Web Services, which can be combined to build a solution. However, it is typical to stay largely within one ecosystem.
Below are some of the technologies that we frequently come across. Solutions are always customized to fit the specific needs and systems that are best suited for the situation.
There are plenty of familiar products available for content management
The most common solution for content management is still quite traditional, usually WordPress or Drupal, but headless solutions are also clearly on the rise. Contentful is currently the clear number one for headless solutions in the Nordic countries, but Prismic, Sanity and Strapi are also popular.
Using JavaScript for building the user interface layer
Even if WordPress is offered as the content management system, various JavaScript-based components are often integrated into it. The user interface layer, or part of it, is then usually built so that it is based on either the React or Vue software framework, which is supplemented with various libraries and/or frameworks for building the user interface.
MaterialUI and React Bootstrap are commonly used user interface libraries/frameworks with React. Performance, scalability, and security, on the other hand, are improved with solutions such as Gatsby or Next.js. For Vue implementations, similar solutions are offered by Bootstrap Vue, Nuxt.js, and Gridsome. Quite credible business has also emerged around the most advanced extensions. A good example of this is Vue Storefront, which has packaged an entire storefront presentation layer and offers it as a service to e-commerce platforms produced with different technologies.
Integrating backend systems based on need and careful consideration
Integration of backend systems into a larger system always requires careful consideration. Not all systems offer modern interfaces, and modifying interfaces to meet specific needs can be unexpectedly laborious. It is also often the case that the data stored in the backend system cannot be used online as is. In such cases, it is necessary to consider whether the data can be enriched in another system, whether modifications need to be made to the backend system, or whether something entirely different needs to be developed to meet the needs. These considerations must always be made on a case-by-case basis.
SaaS services are typically easier to integrate, as they usually offer flexible interfaces by default. For example, search services are such solutions that you can read more about in our earlier article, SaaS search solutions in Finnish websites in 2023.
Our clients also frequently use various event management or booking systems, such as Lyyti, which can often be easily integrated into the larger system. There are also many different chat solutions, both large and small, such as NinChat, Giosg, and Rocket.chat, which are readily added to the system. Elements such as Paytrail, Shopify, or Lippu.fi may also be included for online payment needs.
More challenging cases involve actual business systems, such as customer relationship management solutions or backend systems used for product information management. Their data models are often designed from the perspective of running a business, rather than presenting content on a website, which may require more effort to extract the right information. Nonetheless, it may be worthwhile to do the work.
The composable model sounds modern and functional, doesn't it? Why wouldn't all online services be built this way, then? Let's consider the pros and cons of the model for a moment.
Benefits of the composable model
One undeniable advantage of the composable model is a certain degree of flexibility. Not all the eggs are in one basket, and individual functional entities can be developed independently of one another. The blocks can be tested independently, which speeds up development work and facilitates quality assurance. Entire blocks can also be replaced with others as needed, and if something is not readily available, the block can be created in-house.
Technically, the model also enables a clearer and better role-based overall architecture for the online service. Clear role-based architecture is particularly important in situations where the online service is built around various backend systems, such as a product database, booking system, or customer relationship management system. The visible part for the customer is often only the tip of the iceberg, a thin surface layer that contains only a little of the actual operational logic.
No technology guarantees success yet
The composable model is often justified as providing a more unified customer experience, better performance, agile development, speed, and many other arguments, but their realization depends heavily on how well the implementation is planned and executed. In these matters, not only the supplier but also the expertise of the client's organization is emphasized, as different systems need to be able to communicate with each other.
Even good architecture can be made into a complete mess.
The challenges of compilation
Because parts of the whole entity can be developed independently of each other, sometimes even in different organizations and without knowledge of each other, special attention must be paid to change management. Unexpected changes in data structures or interfaces may cause compatibility problems with the building blocks and, in the worst case, paralyze the entire service. All parties must keep each other constantly up to date.
Another consequence of the separateness of the building blocks is that service administrators often have to shuttle between several different systems to achieve the desired result. The user experience may not always be what they are used to in the maintenance of, for example, communication websites. This also creates challenges for training, among other things.
The use of headless services also requires more technical expertise than average. If something goes wrong, adequately skilled technical support must be available very quickly. Especially with JavaScript-based libraries, updates are constantly coming in, and their release, compatibility, and effects must be continuously monitored, and they must also be able to be updated in existing systems without problems.
One consequence of this is an issue that may not be thought of so often; in composite solutions, it is often the large amounts of work and costs in the maintenance phase that are surprising. The whole solution typically requires more constant care and maintenance than a monolithic solution. Even if the first production version is created in an agile and fast manner, the life cycle costs of the whole can be several times higher than for a more monolithic solution.
A solution for larger entities
Composite solutions are typically best suited as a platform for such large services that involve complex processes, require the combination of data streams from different sources, and aim for a long life cycle. In such cases, the visible part of the service for the end-user is only a small part of the whole. An example could be B2B e-commerce where product data is in the organization's internal systems, and personalized branding is desired, but there is no suitable solution available in ready-made e-commerce platforms.
However, to ensure a long lifespan, it is always necessary to ensure that technical expertise is available in the future, and that there are euros in the back pocket for long-term maintenance and further development.
Composing is not a silver bullet that suits everyone or all types of services. Even small web services can be designed according to the composable model, but often there are more cost-effective and user-friendly solutions available for those needs. Therefore, it is advisable to plan the architecture already in the early stages and carefully weigh the advantages and disadvantages of different options.
(This article has been translated from the Finnish original.)
