More and more people are deploying Services, APIs and all kinds of distributed components. Major content providers are finally finding out that exposing their features to developers not only keep them relevant but also creates a nice ecosystem around their business.

When someone decides to expose a piece of software to others –being internal users in the room next door or the whole Internet- the question that arises is always something like: But what is a Service anyway?.

There are many definitions for SOA and Services and I don’t think I fully agree with anything I’ve read in this topic. I’ve worked with multiple flavors of distributed components in the pre-SOA days and can’t see much difference between what people use to define SOA and the resources already available in Component-Based Design.

But I do believe that Services are different from components. For me, though, the main difference is that SOA is about reducing noise in architecture. SOA is about using components that are not only technically sound, they are part of the business. In other words, for me SOA is Domain-Driven Architecture.

The Amazing Invisible Component

Once I was in a client to perform the installation of the new release of a telco product. While in the client’s office I was invited to take part in some discussions about the new project they were about to start.

The new product was some sort of system that would allow people to pay their bills using mobile phones, something really advanced at that time. I was required at some meetings because one of the systems we had installed at their network was required to talk to whatever was going to be built.

In one of those meetings, I finally got a chance to grab a copy of the architecture for the new system. I was a bit surprised to see that the client was going to buy a billing system that would be the heart of the operation.

What got me surprised was that they already had many instances of billing systems, most of those bought from my company. Indeed my task there was to upgrade one of those instances to the new release! I tried to argue that the current system could handle that requirement easily but my argument was dismissed as if I was just trying to sell my stuff –that was already sold anyway.

Back to my hotel room I tried to understand why that happened and looked at the network’s diagram that was something like this:

It is hard to remember the real structure but I guess this illustrates my point.

The new deployment would be something like this:

Then I understood what I think it was the main problem in the whole situation. I was a developer on those products so I knew that they were just like this:

We used instance-based components for the billing systems. They were used as a lower Layer in the Pre/Post paid products but essentially, they could bill any kind of transaction. The client had access to documented interfaces to talk to the billing Layers and they used those interfaces to handle marketing campaigns and administrative tasks easily.

In this case was that the architecture didn’t reflect the business. For sure there are constraints in what and how you expose things when you are a vendor of an expensive product. If we focus only the technical aspects of the problem, though, I would suggest that if we intended the business people to think about the billing feature as something they can use when designing their strategies we should make it a first-class citizen. We should make it more explicit, something like this:

And then the obvious path for the business would be not only less risky but save a couple million dollars in licensing:

Everyone’s Architecture

The architecture of a system is not only expressed in Services. Usually there are many components that are not exposed to external viewers but play an important role in the system.

But Services are visible from outside. They are meant to be reused and recombined in multiple ways. To leverage this potential we need to make the stakeholders aware of them.

The technologies behind SOA are pretty much the same technologies used in good old Component-Based Design. A lot of what we do today using Services could be done using component technology. The main difference is the mindset, components were often created by technicians and used by technicians. Services have a broader user base.

And I’m definitely not talking about those fancy BPEL tools that look great in the demo but behind the curtains drag your programmers back to the stone age of software development. What I’m talking about here is not related to a specific group of technologies. I am talking about getting your architecture into the Ubiquitous Language used by developers and stakeholders.

Just as it happens at the design level, getting a Ubiquitous Language for the architecture of a system requires some work. Nevertheless I would say that it is probably easier to work based on the Domain-Driven Design principles at the architecture level as architectural components often directly impact business -they are more tangible- something that is not true about most classes and objects.

The Service is on the Eye of the Beholder

Once you stick to the Ubiquitous Language it gets easier to identify what is a Service and what is not –just like what happens in Object-Oriented design.

A Service should be the implementation of a concept that the user understands. As a dumb example, suppose you are going to offer access to your email service through a web API. Internally you happen to implement your service using two different components for POP3 and SMTP. You could implement your service following this structure:

That deployment would give you several advantages. Flexibility, scalability and a lot of other bilities. The problem is that it doesn’t match well to how your users think about e-mail. Considering you have a public mail service, like Yahoo! Mail or Gmail, most people have no idea that we often use two different protocols for sending and receiving emails –some time ago they had some idea but Gmail exterminated that.

In order to achieve a deployment that feels more similar to what your users have in their minds it is probably better to simplify and offer a familiar metaphor:

Although internally the service is implemented by the two specialized protocols this is not important for the service, just like it wouldn’t be important for the user interface.

The example was clearly an oversimplification but this is a very common scenario. We see Google as a single web page with a text box and a “Search” button, for example. Developers know that the actual system is not as simple as the interface makes you believe but the API uses the same metaphors we have at the web version. If you are familiar with Google search products it is very likely that you will find out how to use a given API in a few seconds, you understand the domain and only have to learn the syntax.

What is important is to define a service that is part of how your user thinks about his tasks. Only if the API user fully understands the language you are using when defining your Services you can achieve your goal of opening up your system. Even if you supply them with a detailed manual the amount of translation required between the way they think about your service (often imposed by how your user interface looks like) and how you implement it.

Move ubiquity one step up.