Designing controlling infrastructure of any complex system

Designing controlling infrastructure of any complex system

In this section we will try to understand how a controlling infrastructure of any complex system is designed to work.

To explain the same , I will discuss the case of designing the controlling infrastructure of an product line architecture like SAP.

When a client purchases a SAP System , he basically deals with the top level SAP System.

First lets remember a golden rule, whenever we draw a system boundary or a sub system boundary the next thing which we should usually draw is the controller or the sub controller of system because there cannot be a well designed system/subsystem without a controller.

So we need to draw the boundary for the SAP system along with its controller

Figure- Figure

As SAP as a system is basically made of the ERP Subsystem, SCM Subsystem and the CRM Subsystem .. so we need to draw its corresponding boundary along with its subcontrollers.

Figure- Figure

Each of these subsystems can have multiple subsystems within it for example ERP Subsystem will have other subsystems like Sales, HR, Finance, Marketing etc. Similarly SCM Subsytem and CRM Subsystem will have other subsystems within it.

So we need to draw the boundaries along with the sub controllers for these subsystems.

Figure- Figure

Although each of these subsystems can have other nested subsystems within it… but let us consider for the sake of simplicity that this is the last level of granularity and will not have any other subsystems within it. We know each of these subsystems like sales will expose/offer a large number of behaviors and we know for every behavior we will have a control entity for each behavior. As we know control entities will hold the business logic for a particular behavior.

The rectangular boundaries shown in red depicts the control entities.

Figure- Figure

As we know whenever the request comes to the base SAP system, the top level controller should intercept the call. In the preprocessing cycle of the top level controller , we should usually have all the logic that should be performed before the request is propagated to other subsystems. This is where the logic for authentication , authorization and personalization should come in and hence we will have the authentication module, authorization module and the customization module. When the request comes to the top level controller, if the request is the first request from the client, the controller will first interact with the authentication module to find out whether the user is authentic or not. If he is not successfully authenticated, he his sent back from this level. Once the client is successfully authenticated, the controller speaks to the authorization module to load his authorization settings after which the controller speaks to the customization/personalization module which does any kind of personalization. From here the request has a free fall and the request can be forwarded to any of the subsystems it is authorized to access. Each of the controllers are connected to the subcontrollers using unidirectional communication which in turn might be connected to other subcontrollers or control entities which in turn are connected to domain entities unidirectionally. If we remember control entities are responsible for controlling a single behavior and control entity keeps a reference to various domain entities unidirectionally.

Figure- Figure

Notice the unidirectional communication between controllers – subcontrollers and the control entities right from the top level controller to the lowest level control entities.

This is how the controlling infrastructure of any complex system is designed to function wherein the controllers and subcontrollers are accountable for the individual system and subsystem while the control entities are accountable for the single behavior offered by a system. In a nutshell controllers provide Macro level accountability while control entities provide micro level accountability within a system.

This pattern has been named by different people differently over a period of time. It has been called as the Controller/Manager/Front Controller/Façade etc.

This pattern along with its characteristics play a very important role in the success / failure of any systems. Most of the times, whenever we have a problem of a system completely failing … there is a good amount of chance that one or more of these characteristics might have accidentally violated causing the system to fail.

In the next section we will discuss some real world problems which has direct correlation to this pattern or its characteristics and just because most of the people are not aware of these characteristics, they fail to understand the problem and its solutions.

Hemant Jha
Founder - VPlanSolutions
Researcher, Trainer