Governance or Governess?

In a previous post, I explained that architects need to stay around to make sure the architecture fits the solution (and that it would likely change and evolve in the first few iterations of the project).

In this post I examine the other issues that Eliyahoo's question raises:

• How do we know someone does not adhere to the architecture?
• What do we do once we find such a violation?
• How can we avoid architecture violations in the first place?
• How involved should the architect be?

Before looking into what can be done, let's take another look at the root cause of the problem -- why would anyone want to circumvent, change, or ignore the (hopefully) wonderful architecture you created, even if you kept it relevant (following my previous post, of course :-) )

Some people would do that because they have other interests which conflict with your's or they just don't care -- most people, however, are concerned with the project success just as much as you are but:

• They flipped the bozo on you -- they think they know better.
• They don't see the big picture and they try to optimize locally.
• They don't know any better, they just do what they always did.
• They believe they are following your design but they didn't really understand what you've meant (or alternatively -- you didn't explain yourself very well).
• They cut corners to meet deadlines (just to appease the project manager).
• Etc.

As was the prerequisite for understanding there is something wrong with the architecture, you need to stay involved with the project. Designing an architecture (as elegant and great as it may be) and disappearing will most likely (if not always) not cut it. As time goes by the architecture will deteriorate. How involved should you be? There is no magic number I know of, in my experience the first third of the project as well as the iteration(s) when approaching a release milestone are more prone to trouble vs. the rest of the project but your millage may vary.

Things you can do to find existing violations include reviews (code and design), pair programming (with the developer in the driving seat most of the time and the architect sitting with her), staying approachable (make people feel at ease talking to you), positioning yourself as a "mentor" or "coach" (someone people would want to come to when they don't understand or know something). You can see I only mentioned one command-and-control approach vs. three collaborative approachs -- even though the task is to enforce the architecture, achieve governance) etc -- getting there by collaboration (even though it takes more effort on your part) is always better. Even if you do get your way by pulling rank or whatever, people will not like working with you in the long run. (At least that was my experience until, I changed my ways.)

When you find that something is amiss, you sometimes need to be curt, right the wrong, and be done with it. As a general rule, however, try to avoid that and instead explain your decisions, listen to other views, and try to persuade you are right. Developers are smart people. They usually understand the bigger view (they just don't have the time to attend to that).

I don't think you can avoid all "violations", but to minimize violations you need to be aware that they can happen, be attentive for what happens in your project and try to work on your soft-skills, like leadership, organizational politics, communications and human relations. (I'll cover both communications and human relations soon.)

Both this and the previous posts touch the D(eployment) activity of my SPAMMED architecture framework. The common denominator between them is that you, the architect, need to stay involved in the project after the moment in time where you declare the architecture "ready". This deployment of the architecture may not take 100% of your time (though in a large, multi-teamed project it is not likely). You can use the "free" time to participate in the coding or work with additional projects -- anything goes -- as long as you don't neglect your responsibilities as an architect for the project and help maintain its designated quality.

Posted by Arnon Rotem-Gal-Oz at 11:31 AM  Permalink