Posted by Mike Rollings
On November 4th, Loraine Lawson posted the IT Business Edge article “Defining Business Services Key to Building Strategic SOA”. In this article, Loraine states: “Occasionally, you’ll see someone talk about business services in SOA. I confess: I haven’t contemplated the difference between a service and a business service very deeply. I just sort of assumed a business service would more closely approximate a business process. If I had thought about it more, I probably would’ve assumed that, for the most part, when people say ‘services,’ they’re talking about business services.”
Loraine is a strategic thinker who understands that technology serves the needs of the business, hence her assumption that services = business services. I hope that we all share this perspective. Yet, I do see a difference between the two terms discussed in the post, and propose an answer to this distinction.
Simplification and business optimization are two fundamental planning approaches that drive different types of optimization and reuse:
• Simplification identifies commonalities (patterns) that emerge from examining existing elements and incorporating new functionality to reduce complexity and drive reuse of the resulting common element. It is fundamental to managing complexity.
• Business optimization is a business-driven planning and design approach that designs in solution and infrastructure reuse through the identification of shared business elements. Business-driven goals such as the sharing and reuse of business processes require the business to take the lead and for IT to partner in the collaboration to make it happen. Business optimization is not led by IT, but IT plays a key role in its realization.
Many organizations are pursuing Service Oriented Architecture (SOA) by practicing simplification alone and refactoring existing components into shared services (i.e. Loraine’s term services). It is a necessary approach, but not sufficient to maximize the business benefits of SOA. To do this, an organization must pursue business optimization and identify reusable business capabilities implemented as business services.
A business capability is identified by focusing on what the business does as opposed to how the business does it (e.g., create order, ship product). Higher-level capabilities employ workflows, services, and applications for their implementation. Identifying capabilities is related to functional modeling with the exception that many organization’s functional models reflect more of the organizations structure than is helpful. For example, you may have a department that is called “order management” that creates orders and ships products, but those capabilities could just as well be performed by a third party, or their execution realigned to another group in a reorganization—but the required capability still remains. Therefore, capability modeling captures the core functional model for an organization without the bias imposed by the organization’s structure.
One of the reasons for identifying business capabilities is that a capability model has longevity beyond that of an organizational implementation of the capability itself. Business capabilities become black-boxes so that you don’t care how the capability is performed; only that it is performed within the contracted constraints of the process or workflow invoking them.
So I believe that the difference between a service and a business service is embodied in the way that each evolves from a technical perspective or a business perspective. Many organizations are just creating services reminiscent of component-based development. Yet, if they want to maximize the business relevance of SOA, business services (a.k.a. business capabilities) must become a focus.