How to slice the elephant Monolith2Services

 

Slicing the elephant, while talking about software, usually means the transformation of old style monolithically designed solutions into better maintainable pieces of software.

Why should we always strive to have good sized pieces of software components? 

Why not sticking to the monolithically designed software solutions? 

They have advantages too. Yes they really do! 

From a customer point of view there are many actually.

• You get it installed and (hopefully) up and running with a single effort.
• If you have problems with it, you have (hopefully) a single contact. 
• You pay one piece and (hopefully) get it all.
• If you need extensions, again one single contact, and (hopefully) only on payment.
• If you don't need it anymore, you can just deinstall or deactivated it. (hopefully)
• I could extend this list further ...as long as you come from the customer side.

If you are a single developer or at least there are only a few responsible for this piece of software, you also might find some advantages.

• You have all your code closely together.
• You feel at least you can extend you complete software pretty fast. This already implies you have at least a good structure within your monolith. This is absolut possible. No question. 

If you come from the enterprise architecture side, from software architecture side, from the service and support side, even if you call yourself DevOps, the picture is not so clear.

Whit all the advantages what are now problems with such monolithic systems?

• extensibility 
• changeability 
• adjustability
• reusability

Those are key words within this context.

Staying with the image of the elephant. This is an animal with great usage, for us as humans, in certain situations. But what if it should relocate faster? What if it is too heavy for the ground? What if it needs too much food? What if it is too large for a certain task? What if the trunk is too big or not flexible enough for a specific task.

Changing a monolithic system can take a whole evolution cycle. And the question is, if the elephant needs to get lighter or eat less is it later also capable of doing the tasks from the beginning? Probably not.

Slicing it is difficult. There are many ideas but I guess there is no fixed rule. As always, it depends. So we can not really slice an elephant but we can always slice monolithically designed software solutions. In my opinion a good first step is to look at the capabilities or functionalities but also the requirements of those. Of course there are always requirements: functional and non-functional. Some of them are clear to us some of them we would actually not care but they are also on the table. Those are often dependencies to other systems, administrative or organisation circumstances. Requirements from other departments where we often think; Do we really need this in our special case. e.g. Security requirements, infrastructure or network realities, strategic decisions of the company. But also, speaking with manufacturing background, there are often clear requirements from the business side on topics as availability, responsiveness or latency requirements of communication with classical manufacturing hardware like PLCs. And as always; data governance is often an important topic as well. Not everyone is allowed to see or handle all data, some data need to be stored for certain time or even need to be deleted in certain timeframes. Here play sometime legal reasons a role.

So you need to structure by capabilities and by data. And you have to pay attention to legal, to organisational and strategic circumstances, to business requirements and sometimes even to infrastructural realities.

Looking again at the elephant, what would it be?

Capabilities

• it can move
• it can lift
• it can push

Data

There are different kind of data. Mainly within a manufacturing environment we are usually talking about two major types of data. Process and product related data. Process data is everything necessary to or emerging from the process itself. Product data is necessary to manufacture a certain product as needed and while and after the process it contains data about the product. e.g. quality data.

Process Data (input)

• elephant size
• elephant age
• hearing
• seeing
• sex
• how long does it need to work
• how much can it lift, push, move
• how many task are required
• etc.

Process Data (output) 

• performance indicator
• work status (tired, hungry, thirsty) 
• how many tasks are done
• did the process went well (worked correct) 
• etc.

I just see that using the elephant as an example was maybe not the best choice :)

Product Data (Inbound)

• one truck
• 15 logs on the edge

Product Data (outbound) 

• truck with 15 logs

This might be a little a corner case (as always :)) but for real software solutions within production you probably find product data. If not, then at least process data.

Based on those corner points you would slice the elephant probably in pieces like the following:

Capabilities

movement: feet

lift: trunk

push: trunk, tusks

Data

sensors: ears, eyes, hairs (yes maybe parts of the skin?! but more likely the hairs on it, I am not a biologist ) 

energy: food, water

body: age, sex 

Back in software constructs you would have the first indicators how to split you monolith.

You would create one module which is responsible for movement, one to coordinate sensors. You might separate between processing and product related data and also what are input data and what are just result data. 

Input data are necessary to start the process and the creation of a product. Output data might be interesting to confirm the completion but also the quality of the product or the process. They might be also necessary as input for the same process or processes behind this one.