Metaphors & Mesh
The dictionary definition of a metaphor is “A figure of speech in which a word or phrase is applied to an object or action to which it is not literally applicable”. Aside from acronyms, if there is one thing that the software industry loves, it’s a metaphor. The company that I work for, TIBCO, has the origins of its name in such a metaphor. The Information Bus COmpany. Indeed it has the distinction of being both an acronym and a metaphor.
For the “B” in TIBCO, the metaphor is taken from the computer hardware industry. A data bus is the common communication channel, into which all other components such as graphics cards or disk controllers are plugged. The origins of this use probably date further back to the busbars used to distribute power in electrical installations. For TIBCO, the Information Bus extends that same metaphor to the software world, where it becomes the way in which software applications communicate with each other by sending and receiving messages.
Metaphors are a powerful tool in promoting the adoption of technology, even more so when the underlying concepts are complex. A metaphor allows the concept to be understood at an intuitive level and that understanding goes a long way towards removing that initial barrier of “where do I start?”. There are of course other ways to convey the vision but without a big picture to focus on the alternative is a painstaking examination of the detail from the bottom up and a reliance on building a mental model from scratch.
Such metaphors abound. Fabric, Cloud, Grid, Exchange etc. All are used to describe software systems being connected together with information flowing between them. The latest of these is Mesh. A service Mesh allows service functionality to be “plugged in” to the Mesh with control and access to data governed by the Mesh.
This Mesh metaphor inherently has the idea of an additional dimension, a plane rather than the single dimension implied by a bus. This plane can be laid across that other two dimensional metaphor — the “landscape” of data and systems across an organisation. It invites the idea that parcels of functionality can be plugged into the mesh in the most appropriate place; near to the data they use or next to the users that consume them or duplicated and spread across the plane so that they are universally available.
Metaphors are only useful if they work and in the cases cited they did. And when they do work they change the way that people think, certainly in terms of how to use the particular technology but also in influencing what comes next. The history of the software industry, young though it is, already has a sense of the evolution of such ideas. If they don’t work, well, they are cast aside. Hubs and Exchanges for example were useful then less so and now you rarely hear of them in the context of integration, except perhaps at a business level with B2B.
Metaphors, of course, take you only so far. There comes a point where the reality of the implementation diverges. It is important to recognise that this is not a reason to abandon them, there is too much lost by doing so. But practicality intrudes and you need to acknowledge this. Extending the metaphor too far is no longer useful. Nobody thinks that you can “fold” a data fabric or that sewing or ironing it have any real meaning (at least not yet, maybe I should speculatively register datairon.com!). The metaphor sets the vision and a mental model of how a technology should be applied but more is needed.
If we take as an example of a Service Mesh, TIBCO’s Responsive Application Mesh. This consists of a Vision, a Technology and a Blueprint. The vision is provided by expanding on the Mesh metaphor that we have spoken about already. That vision includes some principles for Mesh applications, that they should be cloud-native and event driven, be consumed through an API and adopt open platforms. None of these principles are intuitive from the Mesh metaphor but they are very important in taking that approach for the creation of a next generation application architecture.
Underpinning the Vision, of course, there has to be technology. Some of the functions that technology fulfils directly relate to the Mesh metaphor — how to “plug” a service into it for example. There will be much that does not though, and to a certain extent this is just as important — driving adoption is often determined by how useful an initiative is, the more useful, the more widespread the adoption. And with wider adoption comes momentum.
Finally the Blueprint. Once there is a Service Mesh to use, and even before that, there are many decisions to be made. How it is structured, how it is operated, how monitored and how do you build for it. The metaphor is less help to you here — it is an over-arching view from a high vantage point. When there are decisions to be made such as what information do I monitor or how do I structure my operations team there is much more detail required. This is where the Blueprint comes in. It provides the roadmap and guidebook for how to build the vision from the technology available.
Building anything worthwhile across a large organisation is a challenge. With many different stakeholders with different backgrounds, experience and motivations communicating a coherent vision is possibly the most important thing to get right. Powerful and easily understood metaphors are a great tool for conveying that vision. Just don’t forget, that useful though they are, they are not reality. There is always a divergence. Ironically understanding that is the way to get the best out of it.
