Tom Graves has published an excellent blog post on migrating from edge to backbone today. Tom argues that it may well be appropriate to change and evolve services on the edge of the (service) network in an agile or even fairly casual manner. On the other hand, services at the other end of the spectrum, i.e. services in the backbone, may well have to be developed in a much more controlled manner. To me, these edge services and the backbone seem to (loosely) map to pods and the platform in Dave Gray’s vocabulary.
Both concepts leave us with an image of a network or web of services. This is good and useful, but sooner or later every self-respecting architect (well, this probably doesn’t hold true for real architects) needs to talk about layers. So here it goes:
In Mapping the Enterprise (Graves, 2010, p. 35) Tom distinguishes four types of layering (while acknowledging there can be more), i.e. layers of:
- reporting relationships,
- decomposition
- separation, and
- abstraction.
Services on Tom’s edge-to-backbone spectrum could then be re-interpreted as services in different layers of criticality, with the backbone having the highest level of criticality. (OK, this could also be interpreted as layers of separation with self being one of the backbone services with the highest level of criticality.)
For my own work, I can see these layers of criticality ease some discussions with respect to the development and run-time use of services in corporate environments. These services are often technology services, but such discussions also need to be held with respect to teams delivering non-automated services.
Reference
Graves, T. (2010) Mapping the enterprise: modelling the enterprise as services with the enterprise canvas. Tetradian Books.
On Service Design 