Over the past decade, we have learned that the challenge of building service-oriented solutions is less about technology and more about solving real-world business problems. Enterprise architects realize that any solution must revolve around an organization’s business processes, IT infrastructure, policies, and standards, and it makes sense that many aspects of service design will revolve around those key areas. As enterprise applications are built to support enterprise functions and business processes, it is often helpful and necessary to build use cases in order to adequately capture the operational requirements of a software system. Traditional and successful software development processes utilize use case modeling as a successful first step in design.
In many conversations I have had with SOA technologists over the past year, I have discovered that there are two completely opposite schools of thought on building use cases for the design of services, and many architects I talk to seem to (consciously or subconsciously) adhere to either one of the other approaches. Each school of thought has a point, but each is incomplete as both miss a fundamental aspect of service-oriented design.
- School of Thought #1 – All Services should be designed based on specific, functional business use cases. Because SOA architects are rarely in a “Greenfield” environment where there are no constraints, legacy applications, or infrastructure with which to integrate, this practical approach focuses on the project’s requirements and the organization’s business processes. Use cases are developed based on the use of certain enterprise applications and infrastructure as use case actors, and are driven by organizational business rules. Using this approach, the resulting service provides functionality reflecting the current business requirements and the current operational environment.
- School of Thought #2 – All services should be designed based on abstract functionality that can be re-used in many use cases. This approach avoids the presupposition of applications and infrastructure, with the idea that use cases based on current applications, business processes, and infrastructure may result in “stove-piped” services that will only be use for the unique and specific applications for which they were designed. Using this approach, services are built based on abstract functionality.
Before I go into what each approach is missing, it is important to say that both approaches offer valid points. Each approach, taken to an extreme, will suffer pitfalls. School of Thought #1 is practical and often successful as the designed service meets the demand of the current project and requirements, but can often lead to brittle architectures when architects don’t account for other applications, infrastructure, or future architectural change. On the other hand, School of Thought #2 offers, in theory, the ability to be loosely coupled from current applications and infrastructure, but without looking at the real operational use cases, the resulting service will most likely suffer from lack of desired functionality. Taken to an extreme, the second approach can become a “blue sky” exercise that could translate to meeting none of the current operational requirements!
It seems to be common sense that we need to walk the tightrope between these two approaches when designing services that are exposed to applications in the enterprise. It is crucial to understand the current operational environment when you design your services, and it can certainly be helpful to use application-specific use cases. At the same time, it is also important to also take a new look at potential and future use cases, realizing that applications and infrastructure will change. A methodology that focuses on the benefits of each approach (#1 – mapping service design to current requirements, applications, and architecture, and #2 – keeping services loosely coupled) will lead to the most useable and flexible services that can be reused over time.
The Importance of Service Taxonomies: Services Are Not Designed Equally!
Each approach represents a valid point, but they are both incomplete because not every service should be designed in the same way. It is important to know that not every service needs to be built with an understanding of the environment or your business processes – the development of some services may not require this at all! For example, anyone who builds a lower-level utility service that calculates interest and principal will only need to know how to make calculations! Such granular services require no knowledge of the enterprise applications, specific processes, use cases, or higher-level services that use them. On the other hand, the design of a higher level business service, such as a “Banking System Service” will certainly require an understanding of the business processes and use cases for user-based withdrawals, deposits, exchanges with other banks, and those uses cases will need to be based on the applications that need to use them.
As Mike Rosen, Boris Lublinsky, Marc Balcer, and I discuss in our recent book, Applied SOA – Service Oriented Architecture and Design Strategies (Wiley 2008), a successful approach utilizes a taxonomy of services – many of these services require and demand an understanding of specific business use cases and others do not. As you can see in Figure 1, lower-level utility and integration services perform discrete and granular functionality, and higher-level business services perform business-specific functionality. The highest-level services (business services) are based on business processes, and these highest-level services call the lower-level services in order to achieve granular functionality in their particular use cases. The second highest-level in the taxonomy are domain services focusing on domain-specific logic. Utility services perform discrete utility functions, and integration services that integrate with existing systems are based on communications with the existing infrastructure. Much like there are large differences between the design of session beans and entity beans in J2EE solutions, there are significant differences in the design of services in such a hierarchy. When you design services in such a hierarchy, you can reuse successful service interaction patterns between them, and many of these are discussed in our book.
Figure 1: A Hierarchy of Services1
Classifying services into such a hierarchy, therefore, provides much flexibility and is fundamental in a successful SOA. Many of the application-facing business services require meeting the needs of your applications, and therefore should be designed with those requirements in mind (jiving with School of Thought #1); therefore, use cases based on those requirements are quite helpful for designing business services. Using functional decomposition based on your use cases, lower-level utility services can and should be chosen and designed separately. Over time, more business level services will be reusing those lower-level services, and therefore the design of such services should not be specifically tied or tightly-coupled to the needs of any high-level business services. Such lower level services should be designed separately, focusing on granular functionality in order to maximize reuse.
Let there be no debate on business use cases – they are necessary and a valid aspect of service design for business-level services. However, a successful SOA will utilize a mix of services in such a hierarchy we present in Figure 1 – some designed based on business-specific use cases (School of Thought #1), and some designed based on granular functionality that can be reused in many use cases (School of Thought #2). Such a hierarchy provides flexibility, allowing you to design a system somewhere between the concrete requirements of today’s applications and the abstract requirements of tomorrow’s. Your approach must be practical, and your services must meet the demands of your current application requirements, but you must leverage good tenets of architecture and design in order to achieve flexibility and reusability. When you do so, you design for both now and the future.
1 Figure derived from Rosen, Lublinsky, Smith, Balcer, Applied SOA, Wiley 2008.
