Enterprise Integration Zone is brought to you in partnership with:

Masoud Kalali has a software engineering degree and has been working on software development projects since 1998. He has experience with a variety of technologies (.NET, J2EE, CORBA, and COM+) on diverse platforms (Solaris, Linux, and Windows). His experience is in software architecture, design, and server-side development.

Masoud has published several articles at Java.net and Dzone. He has authored multiple refcards, published by Dzone, including but not limited to Using XML in Java, Java EE Security and GlassFish v3 refcardz. He is one of the founder members of NetBeans Dream Team and a GlassFish community spotlighted developer. Recently Masoud's new book, GlassFish Security has been published which covers GlassFish v3 security and Java EE 6 security.

Masoud's main area of research and interest includes service-oriented architecture and large scale systems' development and deployment and in his leisure time he enjoys photography, mountaineering and camping. Masoud's can be followed at his Twitter account.

Masoud has posted 82 posts at DZone. You can read more from them at their website. View Full User Profile

Project-Oriented SOA

  • submit to reddit

Minimizing Impact of Changes and Maximizing Reuse

Since changes to services are inevitable, the architecture and design patterns must be established with change in mind. Services must be designed in such a way that most of the changes introduced as part of its evolution will have minimal, if any impact on its current consumers. Another goal of service design should be to maximize service reuse as this represents the cornerstone of SOA. Both of these goals can be achieved by using the Service Façade and Concurrent Contracts design patterns [REF-1] together with a canonical modeling approach.

Canonical modeling is a well known and established approach for abstracting service consumers from the backend data sources and introducing a common entity representation. Many SOA proponents agree that canonical modeling is a critical component in the success of the SOA program. A canonical, or standard, model attempts to establish a single, consistent representation of all the entities that will be passed through a shared service. This representation should be independent from the backend data structures and service consumer specifics, which will minimize the impact on consumers when either one changes. Additionally, because LoBs may represent the same entities in a different way, a single canonical model will help reconcile these differences and allow different parts of the organization to speak the same language. This, in turn, maximizes the potential and real reuse of services built across the company.

The Service Façade pattern is used to minimize the impact of service changes on its consumers. Every service, whether it is built using a canonical model or not, should expose a façade interface via Concurrent Contracts specific to each consumer. Consumers would not access the service directly but rather through its exposed façade contract. Each façade should be designed in such a way that it presents data in a form easily understood and ingested by individual or group of service consumers. Figure 3 shows how the façade pattern should be used to design and build shared services.

Figure 3: The Service Facade pattern in action.

Because each façade contract is specific to one or many service consumers and does not expose internal (canonical) service contract, changes to the service implementation or even to the canonical model will have minimal, if any impact on the consumer. The mappings between the façade contract and canonical structure may need to be updated but this activity will be transparent to the consumers. From their standpoint, no changes will take place. The Service Façade pattern also ensures maximum reuse of the service because the same service instance is being used under the covers even though multiple façade interfaces may be exposed.

SOA Governance

All of the best processes and architectures cannot be effective if they are not being followed. This is where governance comes into play. Establishing and enforcing effective governance mechanisms and processes is paramount to the success of any SOA program. The key is to ensure minimal overhead, maximum compatibility with the existing IT governance processes, and high level of synergy with all the Software Development Methodologies (SDM) being followed in the organization. The success of the SOA program is dependent on how efficient it is, how closely it can be integrated with the existing processes, and how strongly its recommendations can be enforced.

SOA governance and the project-based IT culture are largely incompatible. SOA governance inserts checkpoints into the normal flow of software development, while projects are primarily concerned with hitting their timelines at all costs. If the governance mechanisms detect a problem and ask a project to make changes, this can lead to unpleasant conversations at even the executive level. Confrontations like these may often be unavoidable; however, the best way to ensure that both governance and project goals are met is to attain visibility into the project pipeline as early as possible and influence each project’s direction to be consistent with the established SOA guidelines. SOA governance doesn’t have to be focused primarily on enforcement and catching non-compliers but instead should concentrate on exploiting synergies with the already established SDM processes and influencing the solutions.

Figure 4 depicts a sample SOA governance process that can be employed to satisfy both project and SOA program goals. Note that it is designed to be easily integrated with the typical waterfall SDM. The governance checkpoints are very light and can be completed in a short period of time, so that projects do not lose valuable time navigating complex governance processes. At the same time, however, all the governance steps are timely and ensure proper compliance throughout the software delivery process. They are designed with influence, not enforcement in mind.

Figure 4: A sample SOA governance process.

Since all the projects that utilize existing or create new services have to follow these governance mechanisms, many goals of good SOA governance can be achieved. Getting exposure to the relevant projects as early as the Analysis phase provides the ability for SOA governance to influence their direction. This also enables the Shared Services team to gain insight into the complete services pipeline, accumulate all the related requirements together, and plan service releases appropriately. Each governance checkpoint represents an opportunity to validate whether previous recommendations have been implemented and, if not, reject the project from moving forward. Most importantly, the SOA governance process should be given an opportunity to completely close the loop on all the changes or new services being deployed, which should be represented in the formal approval or rejection of moving the code into production.

Another important element of the SOA governance process that is depicted on Figure 4 but not yet discussed is the role of the Registry/Repository (RegRep). Each checkpoint prompts an action related to service registration or promotion. This is necessary not only to document a true state of the service but also to formalize and automate the whole SOA governance process. Many RegRep tools contain governance automation capabilities. Exploiting them is extremely valuable since it streamlines the whole process and eliminates inefficient manual steps. Establishing a policy that all services must be registered to be consumable closes any loophole projects can try to exploit. Since registration and promotion steps are tightly coupled with the SOA governance checkpoints, which need to be performed by an independent party, projects will not have an option to sidestep any of them. If they do, services will simply appear to be unavailable for consumption or in a state incompatible with the project needs. Finally, registries can be used to collect run-time service utilization metrics, the importance of which is discussed shortly.

Service Funding

Funding for the SOA program should come from a central source. It should cover everything from the shared infrastructure, technology, tools, and methodologies. Where the money comes to build individual services, however, presents a bigger challenge. Since projects are the primary drivers behind demand for services, special consideration should be given to project needs and budgets. As discussed earlier, individual service’s pipeline and roadmap should be independent from those of a project. Thus, service design and implementation can incorporate additional requirements that fall outside of the project scope. Another typical project-related problem stems from the shared nature of services. It is unfair to burden a project with the full cost of a service that will be utilized by a number of other consumers.

There are three possible ways to address the service funding concerns.

1. Make the first project to build a service provide the complete funding

2. Establish a central funding source that will cover all service design and construction expenses

3. Provide supplementary funding to projects building services

If option 1 is selected, several strategies for recouping the initial investment can be used.

a. Do not recoup the investment

b. Place a surcharge on each instance of service leverage

c. Charge a small fee for each service call

As mentioned above, it is unfair for the project to carry the complete costs of the service build-out, especially if it includes additional requirements. Thus, unless the project implements one of the options to recoup its initial investment, funding option #1 is not going to be viable. Not recovering the funds is not a realistic option either as it does not incent the projects to build truly reusable services. The other cost recovery strategies may work but require detailed metrics to be captured on the service leverage and/or transactional volume.

Establishing a central funding source for all projects to use when building reusable services is probably the ideal approach. Few companies, however, would be willing to write what in essence would be a blank check for the projects to use in their service delivery efforts. The opportunity for abuse and misappropriations would be too tempting. Unless strong governance and control mechanisms are in place, this funding method will most likely end up costing the company more money and provide unrealistically small return on investment.

Providing supplementary funding to projects building services is probably the most realistic approach. A central fund needs to be established to cover the efforts falling outside of the project scope. Since shared services would typically incorporate other projects’ and enterprise requirements, the actual cost ends up being higher than what projects budgeted for their needs. Thus, the easiest way to distribute supplementary funding is to allow the projects to pay for functionality already included in their budgets and cover all the additional costs through the central fund.

Whatever the funding approach is used, it needs to be carefully administered. A party not involved in day-to-day project work is best suited to play the administrative role. The Shared Services team is the most likely candidate to control the budget and use it appropriately to further the SOA program adoption, increase service leverage, and avoid political influences.

SOA Metrics

Once the SOA program is up and running, its effectiveness, level of adoption, and results need to be measured. This can be achieved through the collection and communication of the relevant metrics. The most popular SOA measurements are the number of services created, amount of service reuse, and cost avoidance/savings.

Since the central Shared Services team has a complete view of all the current and future service creation or reuse opportunities, it is in the best position to collect and report on the metrics. In order to accumulate accurate metrics and produce relevant reports, the following steps need to be performed.

1. Capture all the services that are being created

2. When completed, determine the cost to build each service

3. Capture all reuse opportunities

All the steps above should be completed for each project that either creates or leverages services. Any modifications to the existing service should be counted towards the total cost of the build.

Once all the data has been collected, cost avoidance can be calculated. The basic formula for individual service cost avoidance as related to a specific project is provided below. Service Cost Avoidance = Service Build Cost – Project’s Service Integration Cost
Service Build Cost = Initial Service Build Cost + Cost of all Subsequent Changes

To calculate the entire project’s cost avoidance amount, simply add the cost avoidance for all the services being leveraged. To forecast the total potential cost avoidance at any point of time, multiply the number of times each service is envisioned to be leveraged by its build cost and add it all together. Since the integration costs for each ongoing or future project can only be estimated, a standard reuse factor can be applied to the service build cost. 80% is the typical number used in these situations. Note that projects creating services should not count towards cost avoidance.

In cost avoidance calculations and projections, understanding each service operation rather than the whole service reuse will lead to more accurate results. To achieve this, current and future reuse opportunities should be tracked at the service operation level. This level of granularity might be hard to achieve, however, especially when keeping track of the build costs. Thus, approximation techniques can be used that determine the operation build cost based on some manipulations of the total service build cost. Dividing the total service build cost by the amount of operations produced might be the simplest approach. If tracking is performed at the service operation level, the cost avoidance formulas above need to change to indicate operation rather than service specific metrics.

Once metrics are collected, they need to be distributed to all the SOA program stakeholders. Depending on the organization, it can be IT managers and executives, business executives, and partners. Metrics should not be reported simply for the sake of sharing the progress made by the SOA program but rather to support SOA program’s goals and influence the behavior leading to achieving them. Specific targets need to be set by the IT executives and metrics should be used to determine whether they have been successfully reached or not. Metrics collection and reporting should be performed by a central team in order to ensure that the whole process cannot be compromised to misrepresent the reality or serve individual team’s or group’s interests.
Published at DZone with permission of its author, Masoud Kalali.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)