Service Reuse

The more I think about the phrase "service reuse" or any other variation of it, the more I don't like it. I feel like it's making me think about services from a perspective that is too technical and too low-level. Reuse is something you want to achieve with code but you shouldn't be thinking about services as just code. When you're designing and building your services, you need to think about it from a much higher and more business-oriented perspective. You shouldn't be building a service because you think it's a great piece of code that other applications may be able to reuse. You build a service because it represents some significant capability of your organization that needs to be offered up to other units within the organization or external partners so that the business can operate more effectively. It's about sharing business capabilities and information, not reusing software. When you keep this in mind, you'll be more likely to build services that end up getting "more reuse" because you're providing valuable business capabilities or information that others need to use.

Extending Reuse to the Last Mile

While services make it easier to share your data and functionality, some developer still has to write the code to consume your service and present the results to the end user. In many cases, that code to consume and present a visualization of the service can be reused by other applications. This has already exploded on the Web with Facebook widgets, embeddable YouTube videos, blog traffic counters, etc., so what I'm talking about here is nothing new.

However, within the enterprise the use of shared UI widgets is still not very prevalent. This is problematic because it still leaves the creation of useful applications out of those shared enterprise services within the hands of IT. This really does not make the enterprise that much more agile at delivering useful capabilities to the end users. Real agility is achieved when end users can create those capabilities themselves by building lightweight micro-apps that are composed of various shared widgets for consuming and visualizing those enterprise services. These micro-apps can themselves be packaged up as widgets so that they can be reused within other apps.

So the next thing to do after you're done building those enterprise services is to start building some UI widgets for those services so that you end up with a portfolio of widgets that can be shared alongside your portfolio of services. This will extend the ability to share (or reuse) those services all the way to the end user, i.e. the last mile. You can think of this as sort of a "widgets-based architecture" that is built on top of your services-based architecture.

SOAP/WS-* vs. REST and The Art of Politecture

Those of you who've worked on very large scale enterprise-wide architectures know that it's always the people and politics that are the biggest hurdles. I came across the term "politecture" in Nick Malik's blog here. You can follow the link for the definition, but it's essentially an architecture that's been designed with the influence of political factors. Some may say this isn't right, but I think it's perfectly fine, even necessary when you're designing a large scale architecture that has to be adopted by many people and organizations.

So what's this have to do with the SOAP/WS-* vs. REST debate? I tend to agree that there are very many scenarios in large scale distributed systems in which a simpler RESTful approach is a technically superior solution. However, IBM, Microsoft, OASIS et al. have done such a good job touting the power of standards in the WS-* world that most folks within large enterprises are sold on the WS-*-based architecture. Whether or not those standards actually help you is a topic for another discussion, but the point is that within most large enterprises you're going to have a much better chance of getting people to adopt your WS-* "standards-based" architecture than you will with a "maverick" REST-based architecture. Is this a problem? Maybe, but from what I've seen usually not. So what if you end up with a technically more complex solution? I can solve the technical problems that result from the added complexity of WS-*. Like I said at the beginning of this post, it's the people and political issues that are the biggest hurdles. From my experience, it's usually the people and politics that cause projects to fail or be canceled. If I can't get people to adopt my architecture because I'm going with a "non-standards-based RESTful architecture", I'm not even going to have a project to worry about it failing because WS-* is more complex, less interoperable, etc.

As an architect, you're not implementing, but you need to get everybody to agree to what you've defined so that they will implement it. If this means making some compromises that perhaps result in a less technically superior solution, but will allow you to achieve consensus then go ahead and do it. As I've painfully realized in my transition from developer to architect over the past few years, things are not so black and white with architecture, i.e. you can't always just go with the solution that makes the most technical sense. If you fail to see this or cannot adapt to this, then you will not be a successful architect.