Clarifying the target

Our target is to build Service as Software. In this case an IT service with a similar service level compared to a traditional IT service operated by humans. A service similar to any other, but ours just happens to be automatic and running mainly on code and LLMs. Feels like a daunting task at this point, as we have no predetermined plans, little to no industry best pratices, examples or guide books. So, let’s begin by setting up some ground rules.

Ground rules:

• We are not here to debate “is this even possible?”, but rather to think how could we make this be possible? And at what depth?
• We are not aiming for 100% automation. Let’s think of our future service as a “lights out” factory. Is it fully automatic? Yes… well… until the maintenance people arrive. As in, we would avoid automating tasks that do not provide sufficient value to justify the investment.
• We believe that increased productivity has positive effects on employment and wellbeing, while understanding that the transition periods can be painful.

There are a thousand different questions between us and our target. Like the one above: “is this even possible?”… Well, I believe it is… but we’re here to find out together. What I’m trying to say is, that there will be a lot of unaswered questions initially. “How to make this secure?”, “How will humans operate these?”, “What is left for humans?” or “What framework should we use?”. Things will unfold as we move along and there will be a lot of compromise. Details are way down the line. First we need a vision or a high level plan.

Benchmark and scope discussion:

Our “Benchmark” for this scenario will be a generic human operated IT service. Looking at the market for IT services, Grand View Research estimates its value at 1,50 trillion USD (2024) with projections reaching to 2,59 trillion USD by 2030. Given the size of the market, I bet there’ll be some big players with similar plans. So, we won’t be alone.

How about the service type and our service offering? Having presented such grand numbers above. I think we need to manage some expectations. As the thing with IT services is, that an established IT service company would have a huge variety of different service to different customers with different contracts and service levels. So, If an established IT service company were a factory, it wouldn’t be producing a single “Model T” from its production line, now would it? No, but rather a vast variety of different modular products in all sorts of colors, models and forms. We’re not benchmarking Capgemini or such, but rather some small IT service startup. And, I wouldn’t want to define the service type or the offering yet. Let’s just agree that it is a “generic” IT service for now?

Scope:

• A single service. Our beautiful “Model T”.
• Benchmarking a generic human operated IT service

Then what makes a service company? Service is a broad word and varies depending on the context. I feel the urge to define a “service company” really well, but let’s just simplify and state that for us, being a service company means: we will be following industry best practices on how to structure for service delivery. Which is easy on paper, but rather complex in real life. Luckily we will be working with agents that do not tire and which can easily scale to our needs.

And now, I want to digress for a bit and I know we are getting ahead of ourselves. But I feel this is rather important. Almost a defining principle: Our main challenge will be to limit complexity. And I’m willing to extend this as far as to the service structure itself. As, how does complexity usually occur in IT? Usually each spesific tool, solution, script or an application is fairly simple on its own. Smart people have spent time designing them and doing their best in order to reach a good solution for a given requirement. Then complexity occurs from having hundreds or thousands of such solutions side by side and on top of each other with different life cycles, dependencies and skill requirements. The same goes for service companies, but on a higher abstraction level. One would package different such solutions into service offerings and modify them according to customer requirements.

The ones that manage this complexity well, have a considerable competitive advantage agains the others. We all identify the frictions that come with technical and/or structural unclarity. Still, such companies that manage complexity well, usually occur only in consulting powerpoints and are rarely seen in the wild.

What I am trying to say is, that the tech involved is new. IT services on their own are complex. I recall one definition of “complex” to be such: that a system is complex when one person is not able to undestand it as a whole. One needs multiple experts to have a combined understanding of the system. Now we are combining new technology with a “complex” area. So, it is clear that we are biting off more than we can chew. Which is why we need to try and keep it as simple as possible. On all levels and lean on to existing best practices. And just keep chewing.

Scope addition:

• We will build proper service structure from the beginning.

Our current target scope:

• A single service company providing a tech service called “Model T”.
• Benchmarking against a generic human operated IT service.
• Proper service structure from the beginning.
• Aim for a high degree of automation, not 100%.

Last point:

As the last point for this post. I feel I need to clarify this blogs relationship towards AI. I have a nice picture on the front page that states “Exploring AI”. What do I mean with that? My intention with this blog is to apply AI capabilities to enable productivity through automation. Not to “develop AI” or to be an expert on it. Its more about understaning it enough to reap the business benefits it enables.

Thank you for reading. Next time we’ll jump into the “actual” content.