Initial structures for Service as Software
Having written the last post. I feel like we need a “map” for our target. A visual way to indicate which part are we discussing about on a given post. I’d say at this point we have the following initial setup for the service:
That doesn’t look cool yet. But it indicates that our Model T is performing a generic IT service with agents running actions to a target software. Software is there to give structure and maintain a level of predictability for the underlying process. From here we would drill deeper and update the figure as we go.
At the same time I feel like this first figure misses some key points that we should emphasise at the beginning. In order to clarify more on “what will change” compared to our benchmark (human operated service). Let’s approach the situation from a capability point of view. This is something I learned quite recently from my colleagues (and I love the approach). So, a capability is something that an organization is “able to do” in order achieve its goals. A combination of People (Skills), Processes (Business/IT Workflows), Tech (Apps, Infra..) and Information (Data, Knowledge).
On a high level the capability structure of our bechmark would look something like this:
People are the ones performing the actions using their skills, according to their roles, by leveraging the existing information, tech and processes. What we are changing in this equation is the people part. To put it bluntly: we aim to automate the “traditional IT work” part of “People” as much as possible. I truly belive we are also trying to make work better as in, to remove toil and make work more “sensible”. I know, this is a bit idealistic, but more on that later.
Our new Service as Software company’s capability structure would resemble more of the following:
We are not touching other pre-existing parts of the current business capability. Other parts would keep static at this point. “But wouldn’t the agents go under “Tech” part of the capability?” Well, yes they would. But not today, as we are making a point. So, the idea is to keep everything as simple as possible and change one variable at a time until we get our bearings. When we understand the structure, we can easily re-do and optimize the approach.
Not changing the application layer might be unfashionable at this time and hour. When everyone is looking into the possibility of genering code in a large extent. Those are interesting approaches, not without their challenges. Still a similar approach to ours, applied only on a different layer. So, I am predicting that applying a similar (more controlled?) approach on the service level is where the true value resides. If I were to provoke, I’d say your Jira license is not that costly, and you can optimize that part later. But that could be a over simplification and maybe even a different discussion.
On an other thought. One could go even “higher” and ask why don’t we let agents just reason the most optimal process, skip the software layer all together and depend purely on reasoning? As in, a situation where one would be really bullish on AI and its capabilities. Well, because we’re not tossing coins here, as in leaving everything to odds. But rather to build structure, reliablity and observability. I did write observability but I meant “human readability”. As to when “shit hits the fan”, a person is able to easily follow up on what has happened on all levels: agents, business processes and so on. Then solve it and let the service carry on.
And now the question, as raised in Clarifying the target “is this even possible?”. Can we automate human skills and roles like this? Most definetly yes. It’s more about service scope and service variability. What really has changed, is the cost of doing this… and more on that later.
I do trust that the market will provide us with answers and examples sooner than anticipated. I assume most companies to be currently planning something like this, or atleast they should? There are probably multiple pre-existing “service as software” companies with varied degrees of automation out there now and growing. Let’s follow and study them as they emerge.
What are your thoughts? Please share your views on my linkedin feed. I’ll be posting “Initial structures for Service as Software - Part 2” in one month.
