The solution is to combine service lifecycle management, architecture, SOA governance, funding, and SOA metrics into a single comprehensive program. The ultimate goal is to ensure that through addressing project needs services are being effectively designed and implemented and that leverage takes place and is verifiable and that the overall SOA program objectives are being achieved. This article introduces an effective technique for moving your SOA program forward through an incremental, project-based approach. Leo Shuster introduce you with project-Oriented SOA.
Everyone, from the CEO to the developer, understands the benefits of SOA and why it should be used. However, many companies still struggle with questions on how to correctly start, shape, and advance an SOA program. Even with careful and expert guidance, SOA initiatives face mounting challenges. The most critical barrier to SOA success is the very basic unit of IT operations – a project. Projects are the oldest and most widely accepted way to deliver work in an IT organization. Projects are time bound and oriented towards delivering specific outcomes for limited audiences. SOA initiatives span multiple groups and organizations and are geared towards addressing the broad needs of leveraging existing assets or creating new reusable assets. Thus, project-based work is largely considered incompatible with SOA.
Most companies that have embarked on the SOA journey find themselves in the unenviable position of trying to reconcile tactical project work with the strategic SOA initiatives. Project work requires delivery of custom applications or third party packages, while SOA’s goal is to establish a base of reusable services. Projects only care about their requirements. Shared services must take the requirements across multiple projects into account to be truly reusable. Project’s funding comes from the Line of Business (LoB) that is supposed to benefit from it. Since SOA efforts can span multiple LoB’s, a single organization may not be the primary funding source. Merging these diametrically opposing views into a comprehensive approach has proved difficult for most IT shops.
The methodology outlined in this article bridges the gap between project work and SOA. It introduces a set of techniques that not only allow the projects to achieve their goals but also promote the creation and reuse of shared services. Additionally, it addresses the funding, reward, and enforcement issues that are necessary to achieve both project and SOA objectives.
The Service Ownership Problem
One of the biggest political obstacles facing SOA in any organization is service ownership. Since project teams drive the delivery of custom code or integrations, they consider that it is their domain and responsibility to build services that address project needs. Outside teams are viewed with distrust, even if they work alongside the project team (For example, code created by others is often dismissed or disregarded). Project teams consider themselves the experts on the subject area covered by the project requirements while dismissing the knowledge that exists outside of the team.
Ownership can be a touchy subject. Many project teams and IT managers subscribe to the silo mentality where they consider the whole stack – from the UI down to the data sources – as their property. Thus, they consider any services, shared or not, that address project or application needs as part of the whole stack. Any discussion or initiative that can be construed as an infringement on their territory can trigger irrational behavior or illogical conversations. Unfortunately, the reality of IT is often such that empire building and territorialism are viewed by the middle management as the best way towards success.
In order to become successful with SOA, IT organizations must break these silos. Shared services that can be consumed by a number of projects must be owned and managed separately. Services must be considered independent software products that have their own lifecycles different from those of projects or applications they serve. Their code needs to be stored separately from other code. They must have their own test cases and test suites. Shared services should reside on a dedicated, independently scalable infrastructure to ensure appropriate levels of responsiveness, scalability, and performance. Ideally, even the data accessed by the shared services must be enterprise caliber and reside on an enterprise scalable infrastructure. Figure 1 depicts how an ideal SOA infrastructure should look following these guidelines.
Figure 1: An “ideal” SOA infrastructure environment.
One of the critical reasons for breaking down silos and managing services independently is incongruence between SOA and project goals. Projects only care about their own timelines and objectives. If a project or application team creates a service and assumes ownership over it, the same team will have to be responsible for making changes needed by its future consumers. It will have to address new requirements that are coming from a different team, comply with that team’s timeframes, and ensure that changes do not impact existing consumers. These responsibilities represent a complete departure from traditional project goals and therefore are simply not be adhered to in many situations. As a result, the decentralized ownership of services ends up leading to increased duplication and an overall failure of the SOA program.
The way to address this issue is clear – create a centralized team responsible for shared service design, development, testing, and support. It will take responsibility for reconciling all of the service-related requirements, designing services to address them, establishing and enforcing SOA standards, ensuring proper scalability of services, and managing the services as independent software products. Gartner often calls this type of a team the Integration Competency Center (ICC). This approach eliminates the previously outlined problems and minimizes the project-centric focus because services are delivered by a separate group whose primary goal is the advancement of SOA. Additionally, a centralized team is better suited for driving the adoption of shared services in the most efficient and effective way.
Service Lifecycle Management
Most organizations deliver business initiatives via IT projects. Therefore, projects will most often drive the demand for services. There is, of course, a better way to identify what reusable services are needed, by whom, and when. A comprehensive business process mapping will create a clear roadmap for service identification and demand. Unfortunately, many companies still choose not to move in this direction and continue to allow projects to remain the driving force behind service identification and implementation.
When a service is designed and developed to address specific project needs, it is not fully reusable. New consumers invariably need changes introduced to the service to comply with their requirements. This typically involves field changes or additions, new operations, addition or removal of major entities, and even potential business logic changes. The biggest SOA secret is that services are almost never reused as-is – changes and integration costs are practically unavoidable.
In order to make services truly reusable and ensure maximum leverage, the service lifecycle must be centrally managed. The central team responsible for the delivery of services must also be charged with service identification, lifecycle management, and pipelining activities. All of the disparate service requirements supplied by different projects must be accumulated together to create a comprehensive view of the service pipeline and roadmap. Figure 2 depicts the relationship between project needs and a service roadmap.
Figure 2: A service roadmap as influenced by projects.
The key to the pipelining activity is accurate and timely information. This will make it possible to incorporate different project requirements into the service that is supposed to be created for a specific project. If the project timelines are close enough and the requirements are well defined, service designers should attempt to include as many of them as possible into the current release. This introduces efficiencies, scalability, and agility into the delivery mechanism through accumulating processes and information gathering across multiple projects. Centralized and consistent service lifecycle management can make this a reality.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)