The increased manageability, reliability, and opportunities for reuse promised by a SOA can only be fulfilled with an effective governance structure in place to coordinate service creation, maintenance, provisioning, and consumption.

However, many small and medium-sized organizations struggle when starting their service catalog due to the seeming contradiction between the strategic benefits of SOA and the often negative impact that governance can have on individual line-of-business project schedules. How do we get our projects done while building a service portfolio? This article proposes governance structures that embrace the tactical, project-centric nature of much of our work while acknowledging the strategic importance of services.

The Need for Governance
By definition, services are intended to be shared resources. Sharing resources among stakeholders without a system to govern their use can and often does lead to conflicts over resource management and utilization. Services need to be governed effectively to keep ROI high (e.g., by preventing the re-creation of the wheel) and meet SLAs (e.g., by ensuring that services are provisioned with appropriate computing resources to fulfill the needs of their consumers). Governance also enables enterprises to discover new service requirements and adapt to change.

The Need to Deliver
While we need governance processes to make SOA work, the purpose of SOA is to help IT deliver value to the enterprise. However, the enterprise generates revenue (or other value) through its lines of business (LOBs). It's fair to say that LOBs are the engines of the enterprise and technology projects are merely one of the means at their disposal to accomplish this end. Given this direct linkage to the enterprise's most visible efforts, the timely completion of LOB technology projects is critical.

Some books and articles on SOA suggest a complete realignment of the business in order to drive the efficiencies promised by service orientation. In this way of thinking, all development projects should be pipelined through a SOA governance process that enforces standards and ensures the quality of the architecture as the portfolio grows and changes.

Unfortunately, this approach often makes the incorrect assumption that there is no architectural governance in place already - whether formal or informal. Any new governance process must find its place within the already crowded landscape of formal and informal means of controlling technology projects in any enterprise, many of which have grown organically over time, compete for control, and perhaps impede project delivery to an extent not warranted by the value they add.

For small and medium-sized enterprises (SMEs), this may be especially problematic because they may not have the resources to staff such a process in a way that achieves its intent while enabling LOBs to execute their projects on time. Maybe they can't staff a distinct services team. Maybe they don't have enough architects to review every development activity without bringing development screeching to a halt. As a result, the SOA implementation may be undermined as LOBs lose confidence in the long-term vision of reduced costs and increased productivity. They ask the valid question of whether the current delays are having a bottom-line impact that may not be recovered until after SOA is replaced by the next IT buzzword. They haven't heard about Cloud Computing yet... shhhh.

If we assume that development teams are already delivering value to the LOBs they support then they are designing software that works well for the purposes of the LOB but may not be usable by other LOB development teams because it is tightly coupled, lacks the ability to scale, etc. The fact that this is inefficient at the enterprise level is not readily apparent to the LOB. These development teams are not necessarily looking for opportunities to deliver value to the enterprise - they are focused on their LOB. The perceived value of their work is high. Slowing down delivery of development projects to resolve an enterprise-level inefficiency is unlikely to be popular with the LOBs.

Approaches to resolving this dilemma typically involve driving change from the top and parallelizing all service development into a separate specialized team. This is rational and capitalizes on popular approaches to increasing development throughput (if ignoring Brooks' Law). With the CXOs on board, one would expect the outcome to be a well-resourced services team standing at the ready whenever needed to implement services in support of the main development team's efforts. However, the mission of this team is not to provide the best results for the LOB, but for the enterprise. To achieve this, the services team needs to be strategic in its creation of services. It must take the requirements of a given LOB team and research them to determine if they are already generic enough to work for other teams. It must assess the scalability and manageability issues of the service across consumers. In short, it must be careful. Being careful takes time. In a small enterprise, projects have short delivery timelines - often less than a year, very frequently one business quarter or less. How can the services team serve the mission of being careful while delivering in short timeframes?

Make It Work, Make It Right, Make It Fast
The job of governance is to help identify opportunities for increasing efficiency in the development of software across the enterprise. While the enterprise needs governance to help it realize the full value of a Service Oriented Architecture, we need to ensure that the governance is enabling not limiting. The focus should not be on preventing mistakes, but on encouraging success. Kent Beck's famous exhortation "Make it Work, Make it Right, Make it Fast" doesn't start with Make it Right because that leads to a quest for perfection in the absence of a completed work product. What if the organization identified a potential new service during the course of the normal work of a LOB development team, but allowed the team to continue its work implementing the new service for itself (perhaps even as a library) while tasking another team to determine whether the function(s) were worth expending the effort to turn into a service and planning that work? From the enterprise perspective, we would be starting to Make It Right even while the LOB was getting started Making It Work. This seems like the best of both worlds.

Unfortunately, many governance models serialize the processes of governance and development - governance is a gate through which all projects (or even ideas) must pass. The creation or modification of a service has an enterprise impact and so must be carefully considered. It can get crowded at this gate and projects needed by the LOB can get stuck there while the governance team debates the merits of the project functions in relation to the SOA.

When the services have been identified, it is a common recommendation to pass the service requirements on to a team specializing in service creation / maintenance / management. This is another potential bottleneck as the delivery of services to the main project must be carefully coordinated to ensure the project delivers on time. A quality enterprise service that considers the needs of multiple stakeholders can take as long to design, implement, and test as the main project.

Agile SOA Governance
There is without doubt merit in both of the core concepts commonly presented in the context of SOA: the need for governance to coordinate on services; and the advantages of creating a team with skills and experience to focus on services. The problem is in the process that manages work across these expert groups and the line-of-business development teams. Figures 1-3 present alternative approaches to this flow.

In all of the alternatives presented, requirements are collected and passed through the filter of an architectural review panel which serves the governance board for services among other duties. This panel determines whether the project incorporates concepts that appear to be candidates for services. Some of these will have already been created and are planned for use in the project. Some will have already been created, but their use was overlooked by the analysis team. Still others will be candidates for the creation or modification of a service.

This review is meant to be light so as not to impede the flow of development as we make the assumption that we should first Make It Work and that opportunities to Make It Right and Fast will exist down the road. What happens after this filter determines how rapidly the project can be delivered and I would assert how successful the adoption of SOA will be in the enterprise.

Figure 1 presents a fairly conventional linear approach to the problem. If a service exists, its use is required and fed into the design phase of the relevant LOB development iteration. If it does not exist or is inadequate in its current form, the requirements are fed to the services team, which then goes through a standard development cycle of elaborating on the requirements in the enterprise context, designing a solution, developing and testing it, and finally deploying it for incorporation into the LOB development cycle. This can be problematic if the service is fundamental to the application, and development of other parts of the software is dependent on understanding and utilizing the service. The problem arises from the fact that the LOB development team is not aware of the service interface and other characteristics until the completion of the service project. Without careful planning, this may have the impact of serializing the services project and the LOB project, thereby undermining the intended effect of a separate services team.

Figure 2 takes the problem of late information and deals with it by providing earlier communication between the services and LOB teams. In this approach, the LOB team receives the planned interface for the service from the services team after it completes its design phase. Depending on approach, it may get more than just the interface. For example, it may get mocks, stubs, or tests as well. All of these things will help it move forward in developing the software in its system that depends on the service, thus decreasing the bottleneck effect. If during implementation, the interface needs to change, that should be communicated to facilitate the refactoring of dependent code. If the LOB team develops a local proxy or business delegate, this should make it easier to refactor. Later, when the service is fully implemented, integration testing can be performed. Nevertheless, the final integration testing and deployment are dependent on the completion of the services team's work. While we have provided more information earlier, allowing for a more adaptive and accurate approach to concurrent development, the enterprise work may still delay the LOB work.

The final approach depicted in Figure 3 assumes that the LOB development team can develop either a service or library itself locally that satisfies its needs for project work to proceed rapidly without dependencies across teams. Ideally, it will anticipate the creation of a service that will replace its local implementation and hide its implementation behind a business delegate. Whenever the services team completes its work, the LOB team should refactor to replace its implementation with the service. Communication between teams about evolving interface definitions will minimize later rework.

While the final approach is inefficient from the perspective that we have two teams concurrently working on developing very similar functions, both anticipate fulfilling the SOA vision. They understand that this is a tactical decision that minimizes the schedule risk of the LOB while enabling the enterprise to move in the direction of its strategic objectives.

On a project-to-project basis, organizations have to determine which of these processes is appropriate. Some enterprise services are more rapidly developed than others. The capabilities of development teams vary. The impact of a service on the application will depend on how core it is to the application. All of these variables factor into the decision-making process and help the organization devise the best approach.