Service Semiotics and the SOA Illusion
Quick! What does a Service look like? Is it an icon on the screen or some collection of XML? Or maybe the concept of Service is too abstract to have a visual representation at all? This question may sound superficial, but in fact, goes to the heart of how Service-Oriented Architecture (SOA) interrelates with related concepts like Web-Oriented Architecture (WOA), Business Process Management (BPM) Enterprise 2.0, as well as the fundamental question of how SOA provides value to the business.
In fact, visual representations of Services, as well as the composition and consumption of those Services, are becoming the key to many SOA success stories. Without a visual component you can show business users, SOA becomes abstruse; furthermore, as organizations leverage Web 2.0 principles to build mashups, the visualization aspect of the Web 2.0 value proposition becomes a driving force for SOA. Understanding how Services look, therefore, is a critical part of understanding how they provide value.
The Semiotics of Business Services
Providing a visual representation to an abstraction like a Service only serves a purpose if it has meaning and is useful in context. How to represent a concept like a Service with a symbol that provides meaning and is useful to its users falls under the topic of semiotics, which is the study of how symbols come to have meaning (semantics), how those symbols relate to one another (syntax), and how people do useful things with their symbols (pragmatics). How we should visualize Services to make them useful, therefore, is a semiotic challenge, and furthermore, solving this challenge goes to the heart of SOA.
At the heart of SOA, of course, is the notion of the Business Service, which is an abstraction that provides a representation of a business capability or data that the organization can compose with other such Services to implement business processes. As ZapThink has explained before, such Business Services are a level of abstraction above Service interfaces like Web Services and REST-based Services. And yet, even though the notion of a Business Service is critical to understanding SOA, and even though ZapThink spends substantial time and effort both in ZapFlashes as well as in our Licensed ZapThink Architect (LZA) courses explaining this notion, true understanding of the Business Service abstraction remains elusive for most people.
This is where semiotics comes into the story. The problem with abstractions is, well, they’re abstract — but visualizations are concrete. Instead of focusing on the abstract, then, let’s focus on the visualization of the Service, and how it serves its role within the organization. So, then, what does an abstraction look like? And how do we put abstractions to use?
Abstractions: A Primer
Chances are, you’re looking at this ZapFlash in a window on a computer screen. We all know how to use such windows — how to open them, close them, resize them, move them around, and access the icons that appear within them. We’re also quite comfortable calling them “windows.” But are they really windows? Can you buy them at a home goods store? Do you install them in your house? Do they let fresh air in when you open them? Of course not. The window you see on your computer screen is an abstraction. It simplifies things for the user by hiding underlying complexity.
There’s no way this window will let fresh air in because in a fundamental sense it’s not real: it’s actually an illusion. The window on your screen is really just a pattern of pixels, supported by underlying computer code that changes those pixels according to a complex set of rules. All the “windowness” of that window is convenient slight of hand that fools us users into thinking there’s something there we can open, close, and move around.
I remember the first time I saw a Graphical User Interface (GUI) with a window, in 1984 on one of the early Macintoshes. My computer interface experience before then was via a command line, where you could easily navigate file system directory structures with simple typed commands. Seeing that first Mac window, and the icons in it representing files, made immediate sense: That’s what a directory looks like! That’s what files look like! But the fact remained that the GUI was really just more computer code, and that windows and icons were abstractions that provided the simplicity that became the raison d’être of the Macintosh, and all GUIs that came after.
The Meaning of the Abstraction
Now, drawing rectangles on the screen was relatively straightforward, even in the early 1980s. But there’s a big difference between a rectangle and a window, namely the semiotics of the window: how windows refer to the directories they abstract, how windows relate to one another and other GUI elements, and how people can use windows to accomplish useful tasks. In other words, the difference between a simple rectangle and a window is that a window actually works. And therein lies the true power of a successful abstraction.
Let’s extend this line of thought to Business Services. We could easily draw an icon on the screen and designate it as a Service, but that’s not good enough. We need an icon that actually works. What does it mean, therefore, for a visualization of a Service to work within the context of the user interface? Here’s where semiotics helps again. For the visualization to be effective, it must solve three problems:
- Semantics: the Service visualization must represent the underlying Service itself. If it’s a data Service, the visualization must provide the relevant data; if it’s an application or transactional Service, then the visual environment for the Service must support the relevant capabilities.
- Syntax: the user shouldn’t have to worry about data formats, Service contract templates, XML schemas, and the like. The visual environment should coordinate all these nuts-and-bolts details behind the scenes on behalf of the user.
- Pragmatics: Whatever users want to do with the Service should work when they try to accomplish those tasks with the icon representing the Service. Composing the Service with other Services in the visual environment should effect true Service composition. Mashing up data from different Services should provide an accurate visualization of the combined data.
In fact, working visualizations of Services, as well as the consumption and composition of those Services, are fundamental requirements for successful SOA — and furthermore, any SOA project is incomplete (or potentially, entirely unsuccessful) without such working visualizations.
Bringing the Conversations Together
If it sounds like I’m describing an enterprise mashup tool or a business process modeling tool, that’s no accident. For years, ZapThink has been espousing that mashups cannot be enterprise mashups — that is, cannot be useful to the business — without the loose coupling, management, and governance that SOA provides. With this ZapFlash, we’re arguing for the converse as well: SOA cannot be truly useful to the business without working visualizations of abstracted Business Services.
In a simplistic sense, you could say that SOA without WOA is too abstract and complex to be useful, while WOA without SOA lacks the flexibility and robustness to meet enterprise needs. But the underlying truth of the matter is more profound: SOA and WOA are two sides of the same coin. They both represent loose, overlapping collections of best practices, and the true best practice set is a superset of both.
The same argument applies with SOA and BPM. SOA and BPM are two sides of the same coin as well, with the keystone holding them both together being the working visualizations of the Services that support the business processes under management. Perhaps this is why SOA success has proven elusive for many organizations: the SOA, BPM, and WOA camps are often at odds with one another, competing for resources and attention where instead they must all work together for any of them to be successful.
The ZapThink Take
Success with combined SOA/BPM/WOA projects, therefore, depends on the successful implementation of the Business Service abstraction, which is at its heart an illusion. Relying so heavily on an illusion to support the broad range of business challenges that such projects are meant to address strikes fear into many a heart, both on the business and information technology (IT) sides of the organization. There’s always someone (usually a developer) in every LZA course who wants a more concrete notion for a Service, and invariably confuses Business Services and Service interfaces as a result. Anybody who thinks they’re talking about SOA when they’re really talking about Web Services, for example, is making this mistake.
The business side has challenges with Service abstractions as well, but from a different perspective: they’re skeptical about whether the solutions IT delivers will actually work as advertised. And for good reason; IT has never been very good at fully delivering on its promises to the business. Once the business gets wind of the fact that IT is proposing basing their architecture on an illusion, they’re likely to pull all support for the initiative. For this reason the notion of Service semiotics is critically important, because it combines the notion of abstraction with the pragmatics of getting such abstractions to actually work as promised. Only when IT can deliver working visualizations of Services to the business that the business can actually use to solve real problems will SOA, or for that matter, BPM or WOA, be truly successful.