After creating our first service oriented framework, we realized that an effective governance structure would be key to protecting the value of the newly-built services. With dozens of developers creating a bunch of services, there would be plenty of opportunities for duplication of logic and ill-conceived, single-use services. Governance would ensure that the organization as a whole would follow a cohesive vision. If we expected standards and patterns to be followed, establishing a good governance process was a must.
We pulled together the Architecture Review Board consisting of the most experienced architects in the organization from all the primary disciplines. This group was tasked with reviewing designs from every project undertaken by the organization.
We met and critically reviewed the details of each project. We discussed the pros and cons of each design. We discussed, and argued, and provided open and honest feedback to the develop teams.
And... We failed. - Miserably. But today, with the benefit of hindsight, I can tell you where we went wrong.
We failed because...
...We Viewed Governance as a Review Meeting
Our review board was established as project gate between the design and coding phases for a project. This architectural review happened once, and after the checkpoint was cleared there was no architectural oversight for the remainder of the project. This review was our one and only chance to govern the services in a project.
All design documents were created with little input from the architects, and the work focused more on creating the minimum required to pass a review rather than on the appropriate level of design for the project. Every project, regardless of size, would show up to a review with roughly the same amount of design documentation. Tiny projects would have 4 pages of design. Huge projects would have 4 1/2 pages of design. Even worse, the project's that did show up with decent documentation were scrutinized more heavily because they had something to scrutinize. This drove project teams even further towards the absolute minimum.
Governance cannot be a checkpoint. It must be a collaboration between architect and developer throughout the entire development life-cycle. It needs to start early in the process to help guide the services through their conceptual design and past their detailed design. When issues come up during coding, they need to be assessed against the early service strategies and re-worked to be the best fit possible.
...We Tried to Apply Governance After Commitments were Made.
The review was a traffic stop in the project immediately before coding began. Developers were in a place where they could see deadlines already approaching. Project managers may have already missed deadlines and were looking at possible budget overruns. The business had already been assured of a delivery date. Absolutely no one, other than the architects, wanted to slow down and re-discuss a design. If an architect felt so strongly about a design being wrong that he was willing to lay down on the tracks, more often than not, he was run over by the train.
Governance must be in place early in the process before there are concrete expectations (i.e., budgets, deadlines, and release dates) established. If everyone has a chance to understand where the strategic design guideposts exist at the beginning, they can all agree to them, and the team can move forward as a unified group. The design is understood, accepted, and protected by all.
...We Believed that Policy Alone Would Ensure Governance.
The review board would either pass or fail a project. When we failed a project, it was asked to re-work the design and reschedule a review. A project was not allowed to proceed without a good review. That is, except, when it had to proceed. The governance was protected only by policy, and the policy only had the influence and authority that was bestowed on the review board. Some projects, usually those managed responsibly, were slowed because they could be without risking delivery dates. The projects that were coming in over budget and late - were given exceptions. Again, we were more often penalizing well-managed projects and waiving bad projects through.
Governance that is applied inconsistently or intermittently is almost worse than no governance at all. Project teams that are singled out and held to higher standards begin to resent the process. Even when architecture is protected for a single project, the next ungoverned project can wreck the gains that were accomplished.
Consistent application of a governance process is the only way. Policies that are unevenly applied must be replaced with mechanics in the process that cannot be avoided. There must be a fair and authoritative enforcement mechanism in your governance processes.
Governance is one of those topics in Service Oriented Architecture that many experts say you absolutely need. Unfortunately, there is much less information to explain how it should be executed. Our organization learned many difficult lessons over the tenure of our Architecture Review Board. In upcoming posts, I will discuss our later, more successful, attempts at injecting governance into our software development processes.
Hopefully, you can benefit from our experiences. Tell us about your own experiences with SOA Governance. Have you succeeded or failed in this critical area? Share your experiences or thoughts in the comments.
photo:Rock Portrait Photography
0 Response to 'How to Fail at Service Governance'
Post a Comment