Federated Core underlines agile evolution – UX Collective

After a delay of few weeks due to travels and festivals I am back to continue writing about the concept which I had introduced in the story

and then continued with the chapter on interaction aspects

In this chapter I would focus on a concept which I term as the FederatedCore — a loosely coupled set of distinct offerings or micro services which serve a unique purpose individually and together enable different complete end to end processes in various constellations.

In the conversation we started in the story titled “The Suite Always Wins or does it?” I outlined the need for the suite of today to be dynamic in order to keep pace with the rapidly evolving business needs of the modern customer or the user.

Traditionally, systems have been built by carefully analysing a particular business domain, time tested business processes which need to be automated, typical roles which need to be enabled digitally etc. and that in my opinion is still relevant. Any solution needs to be built to address real problems. However what fails now is the finite nature of the solutions. A system which is hard wired to solve a particular business problem and that one business problem alone is archaic in my opinion.

For example — every business has the need to manage business travel of the employees. A solution which can cover the business travel of the employees but then is unable to support business travel by a consultant working for the business for 2 months is archaic and cannot be the system foundation of any modern business.

It is a very simple example but it shows how as businesses evolve they expect their technical foundations to evolve with them or even faster. Here is where the concept of a collection of encapsulated services with well defined interfaces makes so much sense. Taking the above example forward we can define some core processes — Budget management, Travel Planning, Expense Management, Employee On-boarding, Contingent Hiring Management etc. and service enable them. Now in the beginning the system can “go-live” with the services which make the employee travel happen but additional modules can be activated when the consultant process kicks in. Having an encapsulated module with well defined interfaces also ensures that within the modules or the services, enhancements can be done without impacting the end to end flow allowing for even more flexibility. It is a very simplistic example but I am sure you get the idea. Does it make sense to you? What other thoughts come to your mind?

I believe the ability to dissect the business processes into smaller chunks and then shape these modules in a way that they make sense individually and collectively is challenging and comes with experience. But this is essential for creating a meaningful portfolio of usable services which need to confirm to the following criterion —

Model and create process steps which are granular

Granularity of the services needs to be defined on the basis of self sustainable business functions

The technological foundation of each step can be different provided —

There is consistent interaction paradigm based on SOAP / oData web services

There is a holistic user experience which is offered irrespective of UI technology used through a library of UI components

There is a stable deployment methodology following agreed upon delivery timelines and DevOps models

Scalability and performance of individual components as well as the bundled scenarios is ensured by building the applications on a mature Cloud platform

It is imperative that the services work on the consistent and same data representation requiring a proper data governance and harmonisation policies

Addition of new services needs to follow a strict governance process based on —

Architecture guidelines

Programming models

Data models

Etc.

What are the additional criterion you can think about?

The service based approach allows freedom to model business applications without tying into an unified technology stack. There are multiple advantages to this —

As long as the services follow certain rules its a strong paradigm to exploit the strengths of the various technological standards. If I visualise this I would do it this way —

Federated Service Portfolio leading to multiple Application Solutions

However, there comes the next critical aspect, isn’t it? Who defines the rules which make the service definitions consistent and usable? I believe a well defined framework can really help here. A framework to be considered as well-defined needs to cover multiple dimensions —