In manufacturing, simplification, standardization, and reuse have made possible very sophisticated systems from relatively simple parts, as it’s that much easier to specify the design of components and subassemblies. The more widely used a type of component is, the greater the chances for standardization in its design, specification, production, and use. Metal fasteners based on the standard specification of the V-thread is one of the earliest examples of a standard component.

We see standardization in the services sectors such as card payments, GPS navigation, container shipping, and telecommunication protocols. But one problem is the notion that services are intangible, hard to define, and of no particular shape. But what if that no longer needs to be true. What if there is a way to define every single service, macro or micro, using a standard format equivalent to a TCP/IP packet?

Software as we know it today would not exist, if not for object-oriented programming languages that allow teams to unleash their own creativity and imagination, and build on the work of others. Similarly, the design concept of a service should be object-oriented like LEGO bricks, so a library of components may exist, from which we can build with a new level of sophistication for new architectural challenges. Components foster innovation.

The more complex a system, the faster it can adapt and evolve, but only if it has modularity through a plurality of standardized components that are wide in use through other systems. The system then has the ability to learn from each such component.

A component specializes in doing ‘one thing really well’ allowing its design to simplify. The simple design makes the component efficient and reliable in producing its special effect, making it more likely to be included in the design of the next solution. As the component proliferates across new uses, its design has greater opportunity to learn from more instances of failure, and more types. The component becomes even better at getting the job done. We’ve seen this in manufacturing. We’re seeing it in technology-driven micro services such as payments, storage, computing, mapping, routing, and messaging.

Componentisation requires simplification and standardization. We should be able to map and reduce any amount of extensive detail on any service to a design concept that consists of the same few finite elements. It would then be possible to have both simplicity and sophistication, by minimizing or hiding the rich but superfluous detail. Representing design concepts in standard format based on a few universal parameters is necessary for comparing designs through analogical reasoning, to avoid similar failures and to mimic success. We can transfer knowledge between designs of services that are apparently different, but quite the same.

Simplification, standardization, and reuse can transform entire industries. Componentisation, modularity, and integration made it possible to build amazingly compact and powerful devices we carry around these days in our pockets. Services and their underlying designs should be interchangeable, replaceable, and reusable like electronic components and software code. Such a library of components would be a public asset for use not only by government agencies but also by private enterprises.

In the world of manufacturing, components are electrical, chemical, mechanical and even biological, which defines how they connect, interface and integrate with each other to produce an overall effect. We often see them as containers, connectors, pipes, conduits, filters, sensors, actuators, displays and indicators. It is conceptually possible to think of the same with services, though it requires a bit of playful imagination. Each component is to be imagined as a cube with a special effect. For this, the cuboro marble track system is useful aid.

It is useful and necessary deconstruct customer needs into more basic components for constructing the concept of a solution without duplicity or excess. That requires a scaffolding or framework for problem representation and solution construction. You can start with macros and explore what claims or value propositions you can construct, which then leads to your decision (strategy) to make those claims and offer the services. You can take complex value propositions and break them down into a set of macros.

As new challenges emerge, we can design solutions by drawing analogies between problems (“This is like that!”), and make use of design that’s already been proven to work. The long-term benefit of sharing knowledge codified in the form of design would be to help make services deliver far more for far less, without compromise. Design in an open format would truly transform the discipline of service design, the way open source code has for software development.

Posted by:Majid Iqbal

TL;DR I bring clarity to the concept of a service.