The Critical Role of Shared Services in Enterprise SOAs
Observe five best practices for implementing shared business and infrastructure services
by Frank Martinez
September 4, 2003
Editor's Note: This article provides insights for enterprise architects from one of the speakers of the Enterprise Architect Summit 2003. Look for additional speaker articles to appear in future issues of EA Insight.
There is a dull roar coming from enterprise software vendors that threatens to quickly reach a deafening pitch. Vendors are exclaiming the latest acronyms that promise to re-invent how applications are developed and integrated: SODA, ESB, EDA, XML. All of these are parts of a collective move toward services-oriented architectures (SOAs). Many in the technology industry believe SOAs will overcome interoperability and inflexibility barriers needed to finally fulfill a promise IT has been making for decades.
One simple but consistently overlooked concept that lies at the center of this trend is the role of shared services. Shared services have two distinct definitions in today's IT world. Operationally, enterprise IT groups offer shared lines of service to business unit clients, such as storage or directory services. Technically, within an enterprise SOA, shared services are addressable, reusable Web services that encapsulate complex business logic and IT functionality, and expose them as shared services that are easy to discover, consume, and reuse.
The power of shared services comes from their ability to deliver simplicity to the IT landscape. Generations of systems and applications have layered complexity into IT, making it difficult to utilize information buried in business applications and leverage functionality resident in core IT systems. Shared services strip that complexity away from any system—CRM, order management, directories, systems management—by breaking them down into component pieces and giving each service a standards-based veneer.
There is remarkable power in converting functions such as customer lookup, process order, and authenticate user into discoverable, consumable, and reusable shared services across an enterprise.
There are two fundamental types of shared services within an enterprise SOA: shared business services that perform an atomic unit of application logic and shared infrastructure services that perform a specific unit of security, QoS, monitoring, or routing logic to ensure the reliability of Web service interactions.
The majority of shared services can be used to improve efficiency of business operations. Shared business services reduce redundancy in common business tasks, such as accessing customer records or processing an order. Application developers can now discover and consume a shared service, instead of recreating redundant functionality. Shared infrastructure services bring consistency to routine IT tasks such as policy enforcement, logging, and performance management. Application developers are no longer burdened with the complexity of building infrastructure into each application. IT operations can also use shared services to ensure consistent control and management across multiple applications.
While the efficiency and cost benefits realized from utilizing shared services are more than enough to warrant their adoption, the real value of shared services is in creating value through unique business services. Unique business services—sometimes referred to as composite applications—are assembled from the building blocks of shared services, and represent business processes or functions that drive unique value beyond cost and efficiency savings. Unique business services, such as single customer view applications, horizontal business processes, and real-time management dashboards, can only be realized by implementing a shared services model (see Figure 1).
Getting Shared Services Right
While shared services are conceptually simple, and their value reasonably evident, realizing a shared services infrastructure within a distributed enterprise can still be difficult. Building the right architecture and adopting the following five best practices needed to achieve a shared services vision can ease the transition, and help ensure both short-term and long-term success:
-
Think SOA. Standards-based shared services ensure interoperability regardless of platform; while loose coupling makes them easy to discover, assemble, and adapt. It's easy to give lip service to SOA principles, but critical to take these principles to heart.
-
Encourage adoption. It's important to articulate the value and benefits of shared services to application developers and IT managers throughout a distributed enterprise to spur adoption. Nobody benefits in the long term more from shared services than application developers, who can be freed to focus on higher-value applications. Convincing them to leverage shared services first before building redundant functionality and to build great service interfaces is an essential first step.
-
Get the governance right. Architecture is important, but the gating factor toward realizing a shared services infrastructure is often having the correct IT governance model. Shared services only work when centralized IT and distributed business units agree on a federated governance model—one that gives business units the flexibility to adapt their applications to meet changing needs and IT the control to ensure that these rapidly changing systems and applications meet enterprise reliability, security, and interoperability standards.
-
Ensure control. Loosely coupled, network addressable resources that are easily accessible over Internet protocols form the basis of shared services, as well as their biggest impediment. Ultimately, shared services only work when their use is effectively controlled and managed by the right infrastructure. Deploying a distributed control layer ensures that a shared services vision can be realized without any sacrifice to IT control.
-
Avoid architectural pitfalls. Shared services drive efficiency by bringing as much as possible into the shared infrastructure. Many service management solutions today continue to push complexity back into service end points, hampering the opportunity for reuse. While attractive for individual projects, proxy and agent-based solutions that treat each end point as a separate domain should be avoided.
About the Author
Frank Martinez is chairman and CTO of Blue Titan Software.
Back to top
|