Components

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.

Filed under: principles

by

TL;DR I can audit the design of a service to prevent or predict systemic failure, using a proprietary method called 16F I make intractable problems, tractable by reframing them. I then design solutions that won't create problems elsewhere, now or in the future. The solutions are in the form of services. I focus on system-level structures that give meaning and purpose to the design of lower-level constructs such as processes, interfaces, and interactions. I've spent the last 10 years obsessed with the questions: What are services? Why do they fail? Why do they exist? I'm now writing a book. Design is my dogma. Curiosity is my doctrine. Industrial engineering is my discipline. @mxiqbal

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s