All we dream about simple architecture. Everything you always wanted to know about Complexity article described an approach to measure how complex our architecture is. The next question is to find the simplest solution in a multi-variable situation, which usually called project. This article shows an approach which ensures that all functions you implement will be on the best place from overall complexity point of view for greenfield cases, while we will discuss about brownfield situations also.

Before going into the details I suggest to read the article linked above, because we will use the knowledge you can collect there!

Having no exact method to reach simple solution all of us who is responsible for designing solutions using the strong faith, believing that our result is the best. Sometimes it is true but sometimes not - and no one knows what is the current case. The complexity measurement referred above helps to evaluate a given situation and its alternative options, but the next question is if we really evaluated all the potential options? This generates the next problem. Ensuring that we evaluated each option we have to know how many exists. Luckily it has the mathematics, which helps us. Let's run through an example!

The situation is, that you have to design a solution to service OTT supporting solution (OTT stands for over-the-top services. It is the definition by telco companies for the ones like LinkedIn, Apple Music or the well-known Spotify) integrated into the life of a telecommunication company. The OTT solution has to have the following capabilities:

• User registration
• Registration request arriving from OTT providers
• OAUTH based authentication
• Delete profile
• Profile delete request arriving from OTT providers
• OTT provisioning of customer orders
• Customer care functions
• Context sharing between online pages or apps
• Context query of the used services
• Consumer/customer record query
• Service authentication request
• Service charging

The task is to implement the functions above on the way that is the least complex, while some of them should be included into existing applications. Using other words, we should find the best way of boxing them. How many options we have to do it? The answer is the Bell number which counts the possible partitions (referred as boxing before) of a set.

The picture above shows, that 5 elements have 52 different partitions, while 8 elements have 4,140! Our example contains 12 functionalities to implement, which means 4,213,597 alternative options. It is impossible to calculate all of their complexity. We need a guideline, which drive us to the simplest solution! This is SIP - Simple Iterative Partitions invented by Roger Sessions. Reference materials about Roger's work is linked to the Everything you always wanted to know about Complexity article.

What should we do with this large number of options? Practically nothing but we have to recognise the hunger for a method which does not cause exponential explosion of resource needs as the set of functionality increases. The algorithm is nothing else but the automation of the similis simile gaudet by other words: like attracts like. In the course of designing architecture  we tend to collect functions that are similar (equivalent) to each other - the challenge is the meaning of similar, we are going to come back to it.

Let's see an example, where the task is to group the similar colours together. The initial set of colours, representing business functions to implement are the following.

We did not collect colours before, therefore we do not have "containers", applications, functional modules, etc.. The first step is to select on coloured box from the set above. What we will do, to look around if we have any existing container and if there is no one (since we just start) define a new one and drop the box into it.

The next step is to get the second box and check if there is any existing container. We will find the Orange one, but as it is not blue, we cannot use it (not similar!)  therefore a new one is needed.

Continue the process on the same way, we will define a green container at the third step. Reaching the fourth box and checking the existing containers we will recognise that we already have one which contains similar element(s) then the that box should be included also.

We have no other task no to continue the pick, search compare, include process till the end of the initial set of boxes, which will result the following architecture.

Recognising that one colour is similar to each other seems to be simple in the example, but if you try to imagine the full colour-spectrum we will agree that it can that hard as sometimes defines the best place of a new functionality in the architecture. Turning back to the business functions listed above the solution using SIP is the detailed in the following drawing. The light blue container is the new application, while the light-grey ones are the already existing applications. There is one dark-grey box in the SSO application, which represent an existing function, the SSO session handling which leads OAUTH and context sharing to be taken there. OAUTH is a "sign-on" function and context sharing between apps require similar kind of session to handle as SSO.

CRM provisioning application handles each kind of service provisioning towards network elements, OTT services are just the same as anything else from this prospective: best place found. OTT apps have to handle profile registration and delete and the authorisation to access the given service there. Context query is about the actual service use that means it is "equivalent" having the tight relation to other functions here.

This approach works fine either having small or large amount of business functions to place. The difference on workload is linear, means the double of requirements is the double of resource to allocate. It is fine. The problem will be in large programs on the other hand that the collection and finalisation is a never-ending story. Assuming that everything will be collected in a waterfall approach is the sure-to-fail method. Luckily having enough requirements collected covering the whole spectrum of the project/program, the process guarantees that you will start implementing the right architecture! What can happen if you recognise a new requirement? There is only two cases:

• it will fit into an existing "container"
• a new container will be defined to solve.

You never have to remove or split containers, either to move one function to another place! Never ever! Anyone who face restructuring of an inappropriate architecture any time rather in the middle of a running project will appreciate it!

The challenge and the conclusion

Declaration of similarity is still challenging, but I hope the examples above show that this challenge is nothing else but to decide simple and exact yes/no questions! There is no reason to fight about different high-level architecture drawings with never ending linear warfare fronts. The collected business requirements have to go through the process above and you will have the best-fitting architecture with the lowest possible complexity!

Enjoy!