Achieving Purpose and Flexibility in Service-Oriented Design: Approaches with Use Cases and Service Taxonomies

Registration is free. Login or register to view/download this content.


Business Relationship Manager - Product Lifecycle Management, Chevron Corporation

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.

Click to view image - Figure 1: A Hierarchy of Services

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.

Similar Resources

Featured Certificate: BPM Specialist

Everyone starts here.

You're looking for a way to improve your process improvement skills, but you're not sure where to start.

Earning your Business Process Management Specialist (BPMS) Certificate will give you the competitive advantage you need in today's world. Our courses help you deliver faster and makes projects easier.

Your skills will include building hierarchical process models, using tools to analyze and assess process performance, defining critical process metrics, using best practice principles to redesign processes, developing process improvement project plans, building a center of excellence, and establishing process governance.

The BPMS Certificate is the perfect way to show employers that you are serious about business process management. With in-depth knowledge of process improvement and management, you'll be able to take your business career to the next level.

Learn more about the BPM Specialist Certificate





  • Business Process Management Specialist
  • Earning your Business Process Management Specialist (BPMS) Certificate will provide you with a distinct competitive advantage in today’s rapidly evolving business landscape. With in-depth knowledge of process improvement and management, you’ll be able to take your business career to the next level.
  • BPM Professional Certificate
    Business Process Management Professional
  • Earning your Business Process Management Professional (BPMP) Certificate will elevate your expertise and professional standing in the field of business process management. Our BPMP Certificate is a tangible symbol of your achievement, demonstrating your in-depth knowledge of process improvement and management.


BPM Certification

  • Make the most of your hard-earned skills. Earn the respect of your peers and superiors with Business Process Management Certification from the industry's top BPM educational organization.




  • Operational Excellence Specialist
  • Earning your Operational Excellence Specialist Certificate will provide you with a distinct advantage in driving organizational excellence and achieving sustainable improvements in performance.


OpEx Professional Certificate

  • Operational Excellence Professional
  • Earn your Operational Excellence Professional Certificate and gain a competitive edge in driving organizational excellence and achieving sustainable improvements in performance.



  • Agile BPM Specialist
  • Earn your Agile BPM Specialist Certificate and gain a competitive edge in driving business process management (BPM) with agile methodologies. You’ll gain a strong understanding of how to apply agile principles and concepts to business process management initiatives.  

Business Architecture



  • Business Architecture Specialist
  • The Business Architecture Specialist (BAIS) Certificate is proof that you’ve begun your business architecture journey by committing to the industry’s most meaningful and credible business architecture training program.

  • Business Architecture Professional
  • When you earn your Business Architecture Professional (BAIP) Certificate, you will be able to design and implement a governance structure for your organization, develop and optimize business processes, and manage business information effectively.

BA CertificationCertification

  • Make the most of your hard-earned skills. Earn the respect of your peers and superiors with Business Architecture Certification from the industry's top BPM educational organization.




  • Digital Transformation Specialist
  • Earning your Digital Transformation Specialist Certificate will provide you with a distinct advantage in today’s rapidly evolving business landscape. 


  • Digital Transformation Professional
  • The Digital Transformation Professional Certificate is the first program in the industry to cover all the key pillars of Digital Transformation holistically with practical recommendations and exercises.



  • Agile Business Analysis Specialist
  • Earning your Agile Business Analysis Specialist Certificate will provide you with a distinct advantage in the world of agile software development.


  • DAS Certificate
  • Decision Automation Specialist
  • Earning your Decision Automation Certificate will empower you to excel in the dynamic field of automated decision-making, where data-driven insights are pivotal to driving business innovation and efficiency.