Initial structures for Service as Software, Part 3

Continuing from our last post. Now to untangle the high-level structure of our Service as Software. We are building on top of our initial setup and the additions from our previous work on part2. Today we move on to the service management layer and try to identify some challenges to solve.

We’ll take a normal approach to the service management layer:

We have one service that we are providing to our customers. Our “Model T”, a shiny “State of The Art” IT service. For which we also need to provide a normal service structures, in order for it to be, well, a proper service. And for us to easily integrate into our customers operations. Our figure above describes this on a high level with just a few named processes as an example.

So, the picture would look something like this:

Our “Model T” running on top of required infrastructure to run the software and the automation. Agents only at the Tech Service and the Service Management layers. These could be the levels we apply agents at this point? Extending the layers related the Tech Service with the following figure:

And at this point our Tech Service has actually matured to a Business Service with a single Tech Service underneath it. As Tech Service would actually be better described as the DevOps level in the above figure. And now bulding to the actual point:

When there is an issue on any level of the service -> an incident would occurs. The generated incident would be directed to the agent/team reponsible of the affected area. Let’s say that the step 3 in the above figure is a “resolve” step in the incident management process. And as an example, some part of software would malfunction to cause an incident (e.g. orage box part of the figure) -> agent on the “business service” layer is now unable to complete their tasks. Thus the incident is identified and directed to the “DevOps” team maintaining the software to resolve the incident. As in, the assigned team depends on the “location” of the root cause. Step 3 is not actually performed by the the agents on the service management layer but where the “malfunction” occurs.

The point is:

Agent on Service Management layer govern the processes. Processes are shared and performed on all layers. They are the structure tying separate teams and functions together. There will be a hierarchy among the agents. Roles to implement and roles to govern and direct.

These are all still service and organisation basics. And they should be, as we are only trying to automate the key parts and keep it as “human readable” as possible. Following a “common languages” for service and leadership structures. Because, as you might expect, and where we are building the journey towards: Is how do we make decision in multi-agent and multi-team agent-organizations. How would an agent escalate an issue to a “management agent” and how would we define the decision making parameters?

Decision making structures

Over time, our organizations have strived to structure for best performance. Trying to find the optimal decision making structures in order to compete and perform on the market. This was for humans of course, but could it be a good place to start when trying to build something similar for agents? To follow a hierarchical structure for the decision making and leave some room for “expert level” decisions. As in, follow a hierarchical structure with role based distributed decision making?

Ofcourse, we as people do not always make good decisions. Is it due to our limited context? Or just that we haven’t had lunch yet? One thing the agents have going for them in this regard, is that personal egos wouldn’t play any part in the decision process. Would the best idea still win in our chosen structure? Or would our decision making parameters kill the best decisions while stepping throught our defined hieararchy? It will be interesting to see and to root out.

Agents also have a greate advantage on the context area. One could combine all the operational data with the financial data and apply them on the decision making stage. Even run parallel simulations for the decisions. But we do remember that agents still lack in a multitude of areas. Thats why we need to design our service according to the current technical capabilities. And of course, start with something simple. As, when our service would mature to a vast multi-agent and multi-service structure. We would expect to face things like state synchronization issues, communication errors, conflicting goals, all of which will be difficult to solve. Thus, we need to look into balancing priorities, hierarchy of agendas or decision making on competing agendas as we progress.

Is it even good to approach multi-agent design from a human point of view? As it might not be the optimal one, but I’d say it is the most “human approachable”. Human readability should be one of our main tenets and we did raise human readablity in “initial setup”. A point we should emphasise strongly.

I myself do not expect us to see such “deep decision making” on long running process for quite a while. One would certaily want to keep control and be able to intervene to make the high level decision for the service. On what level, will depend on ones risk tolerance, the maturity of the service as software and the quality of the knowledge associated. I would want to go on but let’s try to steer back to our subject. As a final remark on this point: It is clear that the risks associated and ownership of the configuration and thus the outcomes lie with humans.

Ending notes

There would be an organizational structure for the agents according to their roles and the defined decision making hierarchy. How it will actually work depends on how will we build this and possibly even what framework we use. We also know that there will be different teams of agents responsible of different functions. But the interconnections, shared memory, shared state, agent spesific roles, firing sequence, decision making parameters, etc, are all still unclear.

What we can identify is that this will be rather complex, but that’s also the beauty of it. As simply the stuff we have “ready on hand” like configuring the roles and access rights will require a lot of work. Not to mention the thing that are totally new. Would anyone happen to be looking for a thesis subject? Anyone? I’d assume there’ll be tooling and a whole industry built around this soon.

Next time we might touch the team structure a bit more. As we are only scratching the surface. Lets keep the “high level” picture at this stage for now. And then we could move onto orchestration which is almost as important as decisions making. Its like “when do you make decisions”.

I hope this got you thinking. Thank you.