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. Because an organization usually has fewer architects than it does developers, an architect's ability to deeply participate on every single project is challenged. The architect has a choice of applying himself in a shallow fashion across multiple projects or take a deeper approach on a few projects while letting others roll by.
The shallow approach means that the architect may participate in team meetings and act as "reviewer" on the design and code artifacts created by other members of the team. This risks his ability to catch critical issues early enough to modify their direction. What ends up in production may be different than what he thought was going to be implemented. This means subsequent projects may not be able to leverage capabilities as was expected.
The deeper approach means an architect embeds himself with a particular project team and takes on heavier assignments in the design phase. The architect is much more of a creator of artifacts than a reviewer. The risk to this approach is that an architect is focused on only a few projects, and he has no time for oversight of other critical projects that are going on simultaneously.
Either approach has pitfalls that can cause your governance efforts to fail. You can use both approaches provided that you apply a few techniques to maximize your governance impact. Here are a few ideas...
Triage...
Remember, one size does not fit all. As projects come in, be sure to triage them to understand which are particularly significant to your architecture team. Architects should be deeply involved with these project to ensure that upon completion, the foundations are built for the next projects to reuse. Projects that are not architecturally significant can be turned loose with only some initial direction and periodic meeting participation.
Divulge...
Every project should get an assigned architect, but that architect must clearly state his intended level of involvement in the kickoff meeting. Establishing the project team's expectations as to what the architect will be (and won't be) delivering is crucial to the project's success. This avoids the confusion that arises when an architect's involvement varies from project to project.
Leverage...
If there are too many significant projects for your architecture team to deeply participate in them all, then you need more architects. Sure you could hire them, but a better approach might be to grow them. Take another look at the "deep" project team members. Is there a developer or business analyst on the team who could assume the role of architect with some oversight? Tap them, leverage them, and help them grow into that role. This is a great "try before you buy" type of succession planning.
Engage...
Playing a deeper role alongside your project teams will let the other team members know that you assume full responsibility for the end product. Too often, the real project workers are instructed or managed from a distance. The people putting constraints on the builders are not quite stepping up to take on the accountability for their direction. Deeper involvement will let your team members know that you are putting real "skin in the game" on the project. This improves teamwork and communication with the architecture group.
Are you wading in the shallows or diving in the deep end?
photo: crankbaitcentral.com
0 Response to 'Successful Governance - Going Deep or Staying Shallow.'
Post a Comment