I’m not too happy with your headline though, and I do actually believe that you wouldn’t have chosen it if you had taken the trial lesson:-). While I do agree on the arguments you put forward in your blog post, I don’t agree that they pertain to the ideas we propose. I believe the trial lesson would have clarified that, had you taken it.

For example, I totally agree that loose coupling between services is a very desirable attribute in SOA. The SOA patterns we suggest do result in loose coupling, not only between consumer and service, but also between different consumers of the same service. I also agree that it’s the business that should be the most important source of loose coupling, but I don’t come up with exactly the same solution in this case as you do.

Before drilling down on that I would like to take up another thing about SOA. We believe that one of the great promises of SOA is that it can help reduce the now so common redundancy both in data stored and in code that protects and manages that data. For example, you correctly point out – I’m glad that you do it – that different kinds of consumers of product data would have very different internal views of that product data.

Your examples are fully relevant, but they are also chosen to highlight the difference between these views. The difference is extremely important, but I do think that you underestimate the level of overlap in these different views of product data. Even if the differences are considerable, there will be overlaps too, and in some cases those overlaps will also be considerable. Creating separate product services for each consumer is likely to add to the now so common redundancy both in terms of data redundancy, code redundancy, and business rules redundancy.

Our goals were to solve both these problems. Both the redundancy problem and the coupling problem. Could we find a structure which would allow us to reduce redundancy without creating tight coupling? I firmly believe that we could, and that we did!

We believe that it’s a very good idea to create one entity service for each strategically important area of business information. Don’t’ be mislead by the term “entity service”! Many mistakenly believe that such a service would manage one entity type only, but that would be a very rare case indeed. Instead, it would manage all the entity types involved in that information area. In the case of the Products information area, as you so aptly point out, there would be quite a few closely related entity types. In the case of a Finances information area, the number of entity types involved to manage general accounting, budgeting, financing, invoicing, accounts receivable, accounts payable and more, would be impressive.

Notice that we’re talking about such data that is to be shared by many functional areas in the business here. Such data, organized to be managed by a set of entity services, would form an infrastructure of shareable information. This is also the name of one of our service-oriented architectural patterns: the Infrastructure of Shareable Information pattern. Notice that not all data is meant to be shared; data not to be shared must be managed differently.

Each of those entity services, for example the Product service, should be regarded as the only authoritative source of the data it’s responsible for. If you want the latest and the greatest of that kind of data – the “accurate-up-to-the-millisecond” product data, then there’s no other place to go than to the Product service. But, as you also point out, in most cases you don’t need that precision. You can make do with versions that are older and even might be stale. This is when other services can ask for periodic subscriptions of product data (or whatever kind of data they need) from that only authoritative source. This will give you the loose temporal coupling you’re talking about, but without the redundancy in code, business logic, or business rules. This, of course, is because the only place to keep that data current and up-to-date is in that authoritative source of it.

But wouldn’t this result in the problem you describe as “it’s clear that changing part of its interface could break almost every system in the enterprise”. Yes, but only if you design these interfaces from the inside out. Not if you design them from the business side and inwards. Because if you do, then you’ll find exactly that which you point out about the very different views on product data that the different consumers will have. And when you do, you’ll find that the only intelligent choice is to create different endpoints for each type of consumer. Or, better, for each different type of conversation.

The consumers you mention (sales, purchasing, product development, marketing, warehousing/inventory) will each get their own set of endpoints for their conversations with the service. So rather than have one Products service for each type of conversation, we propose one single Products service which exposes a different face for each type of conversation. This is what we call “architecting for organic growth”.

So when the sales system needs its interface to product data to change, that doesn’t affect any of the other consumers of product data at all. The sales endpoint to the service will change, and probably some of the service’s internal functionality with it, but all the other endpoints will remain the same.

So there’s loose coupling between the consumer and the service. This is because it’s based on messages. It’s also, and perhaps even more important, because the consumer is totally independent of the internal structure of the service. It only sees its endpoint.

There’s also loose coupling between the different consumers. They are coupled to each other, if only indirectly, because they consume the same service, but they are extremely loosely coupled to each other, because they don’t share the same endpoints. This makes them independent of each other.

In fact, each of these consumers will experience the service not as what it is, but as the endpoint indicates what it is. For each consumer, the endpoint is the service; everything except the endpoint is just a black box. And this makes for loose coupling indeed, because each type of consumer “sees” a different service.

Looking at the problem from the perspective of just one of the systems involved, it might not seem to be an important difference between choosing many services or just one service exposing many endpoints. From an enterprise perspective it does! Having one product service and making it expose one endpoint to each important business perspective is part of aligning software architecture to business architecture. We believe that the perspective of SOA needed to make SOA really useful is the enterprise perspective.

I’m sorry for the long reply to your blog post. The subjects you bring up are very important, but they require lots of space to discuss. I have only been able, even though my reply is so long, to cover part of what we cover in the Five Architect Roles course, and that is only a small part of what we intend to cover in the 2xSundblad Academy. I hope that this reply, together with our trial lesson, will make you agree that we aren’t so mistaken on services as your headline suggests. You might not agree with the details of our solution, but you should agree that it doesn’t at all put systems using a service in the danger of being broken that you indicated.