This is the first article in a six-part series dedicated to exploring how SOA and service-orientation relate to and affect business analysis processes and approaches. Acclaimed author Thomas Erl shares his insights into the world of service-oriented business analysis and business service modeling by providing customized excerpts from his second SOA book "Service-Oriented Architecture: Concepts, Technology, and Design", supplemented with additional commentary.
Many still resist – or are even unaware of – the benefits of introducing service-orientation into the domain of business analysis. It is easy to ignore service-oriented business modeling and simply focus on service-orientation as it applies to technology and technical architecture. That, however, is missing the point of SOA. The architectural model established by SOA and further defined by the common principles of service-orientation provides the very real potential to finally unite the
The creation of business services are therefore becoming the focal point of many contemporary SOA initiatives. They require the collaboration of business analysis and technology architecture expertise and introduce new requirements, roles, and processes to traditional development project lifecycles. In this six-part series we'll be exploring business services and discussing some of the more important aspects of how SOA and service-orientation relate to and augment traditional business analysis approaches. In this first installment we provide a brief overview of some of the tangible benefits associated with creating business services in support of building business-centric SOA.
Business Services can Increase Organizational Agility
Service-orientation brings to business analysis a manner in which to structure automated business logic that can significantly improve the flexibility and agility with which that logic can be re-modeled in response to change. This is accomplished through the use of well-defined business services that establish a highly responsive environment by grouping functionality within specific business contexts. Such an environment is responsive in that changes to business requirements or business processes can, to a large extent, be efficiently accommodated through the re-composition of these services.
This level of organizational agility typically requires the creation of a business service layer, a coordinated collection of business services that introduce the concept of service layer abstraction by establishing a loose coupling between the business and automation domains of an enterprise.
Business Services Leverage Orchestration
Orchestration provides an automation model where business process logic is centralized yet still extensible and composable. Through the use of orchestrations, service-oriented solution environments become inherently adaptive and, when combined with well-defined business services, their use can further lead to significant business agility improvements.
In the Web services world, business processes implemented as orchestrations can be expressed through service composition languages, such as WS-BPEL. By abstracting business process logic, highly agnostic business services (agnostic in that they do not need to contain logic associated with any one business process) can be created and shared across multiple orchestrations.
Furthermore, the process logic within an orchestration can also be expressed as a service and composed as part of larger service compositions. This introduces a specific type of business-related service model, commonly known as the process service. The automation landscape created by the use of process services and other forms of (non-orchestration) business services establishes a composition environment in which automated business logic is intelligently partitioned, loosely coupled, and highly adaptive.
Business Services Enable Reuse
By modeling business logic as distinct services with explicit boundaries, opportunities for business services to be created within an agnostic (reusable) context become available. For example business services can be designed to encapsulate logic associated with a specific business entity within an enterprise (such as "invoice" or "claim").
Further, by taking the time to properly align business models with business service representation, the resulting business service layer ends up freeing non-business or application services from assuming task or activity-specific processing functions. This allows application services to be positioned as and to evolve into pure, reusable units of automation logic that can support a variety business services across solution boundaries. (Examples of functionality encapsulated by application services include exception handling, event logging, notification, etc.)
As we will emphasize later in this series, establishing an environment that fosters the creation of agnostic (business and non-business) services is key to attaining some of the primary benefits of SOA.
Only Business Services can Realize the Service-Oriented Enterprise
Business service modeling marries the principles of service-orientation with an organization's business models. The process of modeling business services forces the organization to view and reinterpret business knowledge in a service-oriented manner. The resulting perspective can clearly express how services relate to and embody the fulfillment of business requirements.
Though the business service layer may accurately represent a corporate business model upon implementation, it will become outdated once new and revised business requirements emerge. As long as it is kept in relative alignment with the current state of business models, it will continue to serve as a valuable view of the enterprise. Valuable because it does not exist in abstract, but in an implemented and operational form.
Now that we've touched on some of the reasons so many organizations are going through the trouble of investing in the creation of business services, we need to explain what exactly business services are and how they can be derived from existing types of business logic documentation, as well as provide some best practices and approaches to building them. In part 2 of this series we'll continue by examining common business service models and discussing how they are typically defined and utilized.
This article contains excerpts from "Service-Oriented Architecture: Concepts, Technology, and Design" by Thomas Erl (792 pages, Hardcover, ISBN: 0131858580, Prentice Hall/Pearson PTR, Copyright 2006). For more information, visit www.soabooks.com.
About the author
Thomas Erl is the world's top-selling SOA author and Series Editor of the "Prentice Hall Service-Oriented Computing Series from Thomas Erl" (www.soabooks.com). Thomas is also the founder of SOA Systems Inc., a firm specializing in strategic SOA consulting, planning, and training services (www.soatraining.com). Thomas has made significant contributions to the SOA industry in the areas of service-orientation research and the development of a mainstream SOA methodology. Thomas is involved with a number of technical committees and research efforts, and travels frequently for speaking, training, and consulting engagements. To learn more, visit www.thomaserl.com.
This was first published in February 2006