Forward: "Governance" is a word that gets thrown around a lot. For this article, "Governance" means the practices that are used to guide the architectural design of services. The goal is to increase reuse, and ensure the team is building toward a strategic, unified vision.After our first attempt at service governance failed, we took a hard look at what was going wrong. We saw that we needed to move our involvement in the solution designs earlier in the cycle before commitments were made.
Historically, when we tried to get involved early, one of the concerns was that some projects could not bear the weight of full architecture oversight. Team members who were most concerned with budget and delivery would view forcing small projects into a complete architectural design and review process as overkill. However, we wanted to see and get involved in more important projects from the beginning. We needed a new process that allowed each project to understand what to expect from the onset. We developed the concept of "project categorizations"...
Categorization
We all accepted that "One size does not fit all". In other words, we needed some flexibility in our process to put small, non-strategic projects on the fast track through architecture review. However, we also understood that larger, architecturally-significant projects needed to be governed prior to the first expectation-setting conversation with its stakeholders. We instituted a lightweight scoring process where the project manager submitted the existing project concepts to our review board, and the review board quickly (in say, 20 minutes) designated the project as in one of four categories.
Category 1 projects are small with little need for architectural oversight. The working area is non-strategic or the expected changes are cosmetic or otherwise inconsequential. Examples of projects that fall into this category can be upgrades of existing tool sets or enhancements to smaller areas of the landscape deemed as not business-critical.
Category 2 projects are those with slightly more interesting changes that the board feels are significant. These projects are often in areas where a direction has been established and progress is on-going. The board may refer these projects to existing reference architectures or landscape maps, but specific guidance is left to the architecture member on the project team.
Category 3 projects are the ones that require significant oversight from the board. These projects will be discussed at length prior to any conceptual design being created. We ask that these projects come back to the board for this discussion, and the results are documented in the form of specific directives to the project team. The architecture member of the project team is then held accountable for compliance to these directives, and is responsible for bringing any variances back to the board for further discussion.
Category 4 is reserved for those "Wow!" projects. These are the ones that the board feels should be restructured because they are so broad and so wide-reaching that they intersect with multiple platforms and road maps. Usually, members of the board work closely with the project managers and stakeholders to break the project into a set of individually smaller efforts with interim way points (each with its own categorization).
An Accountable Team Member
To make sure that the board has an accountable project team member, a project architect sits on the team for EVERY project (even the Cat 1 projects). This person is responsible for being the eyes and ears of the review board, for ensuring that the project adheres to guidance, and makes sure that a project seeks direction from the board when appropriate. The project architect is selected from any of our internal architecture teams.
The value provided by this approach comes in two parts. First, the project team and its stakeholders can set early expectations as to the level of architecture team involvement in the project. Minor projects get minimal involvement. Major projects get significant involvement. More importantly, the project team and the architecture board open conversations at the inception of a project allowing both sides to work together toward a common result.
I'll post a few more things that we did to improve our service governance soon. In the meantime, if you have something that worked well, share it in the comments.
photo: taberandrew
0 Response to 'Successful Governance - One Size Does Not Fit All'
Post a Comment