Service design? Think of the three “S”es

So, you need to design a service? That’s great. If you’re a student of traditional application design, however, you’ll find that service design is a bit different. Okay, very different. Indeed, most application developers are struggling with this issue, and many services are created with a bad design and thus are not leveraged. Don’t be one of those guys.

Consider the three Ss: Scope, schema, standards.

Services need to be simplistic in scope. This means that services are not applications; they’re more like functions, and thus you need to keep the scope of the purpose of the services very specific. Application developers have a tendency to create services that are far too complex, and coarse-grained. The most valuable services are simple, serving a single purpose. If you need to do more complex things, you mix and match services. This gives those creating composites more flexibility, and makes the services more valuable.

The information managed by the service needs to be well defined, and part of a larger strategy or schema. Many service developers build the schema on the fly, and there is no notion of adherence to a common data model. That’s a huge mistake. The fact of the matter is that services should have a well defined, designed, and documented schema.

Services should be created with standards in mind. This means that most of the people and systems consuming the service should be able to do so without close coordination with the producer. This goes well beyond the REST vs. SOAP stuff — it’s really about understanding the lowest common denominator as to how consumers are leveraging producers. From there, you adjust your services accordingly.