We all know the tale of Goldilocks and the Three Bears: the story of an interloper that seemed to want her chair,...
porridge, and bed just so, despite her invasion of ursine privacy. Just as one-size-fits-all food or accommodations could not sate Goldilocks, so too are early proponents of Service-Oriented Architecture (SOA) realizing that they must size their services just so in order to meet their pressing business problems so that they can maximize reuse and minimize unnecessary expense. Not only that, these early adopters are realizing that they must tackle significant aspects of service infrastructure and architectural best practices from the very beginning, even if they are deploying a small set of services. After all, a successful SOA implementation requires not only the right services, but implementing them in the right way.
One of ZapThink's repeated refrains is that SOA is an aspect of enterprise architecture, which itself is not a technology, but rather a discipline. An essential SOA best practice, is understanding just how to create the right set of services so that they solve the right set of problems. After all, IT is in the business of solving business problems, not simply implementing technology solutions in hopes that they will find some business problem to solve.
Identifying Problems of the Right SizeOne of the keys to finding the right approach for identifying services of the right size is to identify the appropriate scope of the SOA initiative - in other words, to solve the right business problems. There's significant danger in tackling a SOA project by focusing on all the potential services a company might want. This approach amounts to trying to boil the ocean and is an exercise in futility. After all, the purpose of SOA is to deal with the unpredictable and frequent changes that companies undergo. As such, it doesn't make sense to try to solve too large a business problem by trying to identify all the services a company might need from the get-go, since those services will necessarily have to continue to change over time.
On the other hand, ZapThink has been misquotedadvocating that companies should start with the "smallest problem" that they can successfully tackle with SOA. Now, it's easy to misconstrue that statement as recommending that companies develop only fine-grained services, or even worse, suggesting that people tackle trivial problems that no one really cares much about. Certainly some notable experts in SOA space have confused what we meant here, but their commentary on this point is right on the mark. Indeed, we actually agree with many of their points (especially James Governor's comments). On the contrary, the last thing that a company should want is a large collection of finely-grained services that serve such narrow business requirements that each individual service is nearly useless. Companies need services of the right level of granularity to solve business problems. But just how big should the business problem be? This question is different from asking how granular the services should be, or even how much infrastructure, architecture, and planning the company needs to implement those Services.
It's important to understand what's wrong with building an SOA composed entirely of fine-grained services (or entirely of coarse-grained Services, for that matter). We like using LEGOT blocks as a metaphor for SOA to illustrate the answer to this question. Implementing SOA solely from fine-grained Services is like trying to build something only from the smallest LEGO size possible, the 1x1 blocks with a single bump on the top. Sure, each block has the right interface in that you can connect it to other 1x1 blocks, but good luck trying to build anything! Similarly, if you think about having only coarse-grained services, it would be like having a box of LEGOs shaped like houses and cars. Sure, they have bumps on them, and they do look like what you want, but they aren't particularly reusable, and they're entirely useless for building anything other than houses or cars. The moral of the story is that you need to have the appropriate assortment of services ranging from fine-grain ed to coarse-grained in order to address your particular business problems.
How Much Infrastructure Do We Need for Our First Services?If you are beginning a new SOA initiative, you might have a limited scope for what those services might do. But that doesn't mean you need to have limited infrastructure. Just because an organization might implement a small collection of services for their first project doesn't mean that they can afford to treat these services any lightly than if they had hundreds of services in production. In fact, having one coarse-grained Service that the business relies upon is just as important, if not moreso, than having hundreds of fine-grained Services, each of which solves a small part of the overall business problem. As such, companies need to consider from the get-go how they plan to develop, deploy, test, and maintain their Services over the whole lifecycle.
One particular case in point is what ZapThink has observed about the role of registries, repositories, metadata management, and SOA governance. In the early days of SOA and Web services, it seemed that few people were interested in those infrastructural components at all. The reasoning went that registries and governance weren't needed until "enough" services were built and deployed in the organization. However, companies that successfully deployed SOA realized that in reality those solutions were needed much earlier on in the service development process, because even though only a few services were under development (and not even deployed), it was important enough to establish architectural best practices early on, and as such, governance and metadata management were implemented as soon as possible. This is also the case for security and identity management. Indeed, for any SOA solving business problems of importance, SOA implementers realize that they need to consider the w hole of the SOA Implementation Roadmap (conveniently available in poster form from ZapThink
Starting with the Business RequirementsThere's no way that a company can undergo an SOA initiative without targeting some significant business problem. After all, if all we do is build services to solve small problems, we'll get into the same mess we've always gotten into by building monolithic islands of IT capabilities. While all software projects must naturally start with the requirements of the business, with SOA, the primary business requirement is the "meta-requirement" of implementing an architecture in a way that responds to unpredictable change-in essence, implementing an agile architecture. Nevertheless, the architect must first be aware of specific business requirements on IT, for example, some new business capabilities, new products, new business relationships, or new budgetary constraints. Regardless of these business needs, however, the service-oriented architect must realize that these requirements are never the end of the story, but rather the beginning.
SOA projects, after all, are not your typical IT projects. Typical IT projects begin with a fixed set of business requirements, and the architect or someone else on the team sits down with the business stakeholders (the people with the requirements) and distill a set of use cases for those requirements. Use cases for SOA projects, however, are a different kettle of fish entirely. Instead of laying out specific "I want the system to behave this way" kinds of requirements, SOA use cases describe how various users may wish to leverage the services that will be at their disposal-services the architect must then identify, design, and schedule. And so, rather than assuming a set of fixed requirements ahead of time, service-oriented architects must expect requirements to change. The resulting solution must then not just meet the transitory requirements of the business, but must also be able to meet future requirements as necessary.
The ZapThink TakeWe say, therefore, that SOA projects should target the smallest business problem. We don't mean the smallest possible application or smallest possible solution. Just as business processes are composite in that they are composed of services, which may in turn consist of smaller business processes, business problems are also composite. A company might have a business problem of trying to serve its customers better, but this problem is actually composed of multiple smaller ones such as getting a better idea of who their customers are, improving the process of customer support, or reducing the time and cost it takes to support its customers. Each of these problems may in turn be composed of smaller ones.
Service-oriented architects must be therefore be able to maintain a pragmatic mental picture for how the organization can evolve iteratively while still maintaining a single, cohesive vision of the organization's architecture. In this fashion, architects can build SOA solutions to business problems using services of the right level of granularity that they're not too small, not too big, but just right. Goldilocks would approve!
While us industry pundits might not always agree, the fact that we're having this dialogue at all is a very encouraging sign. At long last, we've stopped talking about what SOA is, but rather how to go about doing it. This conversation is helping folks realize that the key to SOA success lies not with the selection of appropriate runtime middleware, but rather with the selection of the right Services, and implementing the right infrastructure to make those services valuable to the organization.
Copyright 2005. Originally published by ZapThink LLC, reprinted with permission. ZapThink LLC provides quality, high-value, focused research, analysis, and insight on emerging technologies that will have a high impact on the way business will be run in the future. To register for a free e-mail subscription to ZapFlash, click here.