The first thing is to think about What is Success?
At a minimum, having architects meet to provide visibility into what everyone is doing is a good idea. Reduces the likelihood of surprises... and assuming a degree of autonomy between groups, it creates selection pressure to adopt better technologies and approaches. From there we can talk about standardisation and its counterpart, innovation. But at the end of the day, we need to actually improve effectiveness, which is a combination of productivity, cost, quality, and the oft missed morale.
What's the scope of the problem?
We are dealing with socio-technical systems. To paraphrase Conway's Law , the structure of the technology must reflect the structure of the business to avoid friction. Which means that an architecture team must know and discuss more than just technology. The capabilities and development of teams is just as important as the capabilities and development of technology.
Do we want to act like advisers or entrepreneurs?
Do we suggest technologies and approaches? Or do we sell them? It's actually more likely that we have to inhabit both roles. The important thing to remember is to rely on influence and persuasion rather than mandates. At no point is commanding and telling people what to do the appropriate role to be taking.
What is a "standard" anyway?
A standard should be a target for growth rather than a lowest common denominator guideline. We don't want to be dragging down our best teams for the sake of consistency. We want the best teams to pull the others forward.
We should prefer de facto standards (what actually happens in practice) rather than de jure standards (what a committee decides should happen). That's how we ensure standards stay connected with reality.
Standard might not even be the best word. Recommendation may be better.
There should be an expectation that the recommendation should be changing over time. As Ohno said, last month's standard should be out of date . After all, if we've actually been paying attention, 30 days is more than enough time to figure out how to improve.
If we visualise the level at which recommendations are followed, we can investigate and learn from the variation. There is always a reason why a recommendation is not followed, many times they are good reasons due to a particular context. By investigating, we learn how to improve our model of reality and our recommendations. We actually learn the most from the variation since the situations where the recommendations are effective are presumably the situations we already know well.
2 comments:
Based on my experience, sometimes the architecture team does have to tell rather than sell:
"No you cannot write a new persistence layer, use hibernate."
"No you cannot directly query App2's DB, use the message-bus"
"No you cannot create an Erlang app, we have no-one who can support it."
My answer is "No, you cannot tell people what to do. That is unscalable and unreliable. You need to teach and influence them so they understand why a particular decision is better."
In this case, I'm also assuming the application teams are aligned directly with their local business functions which I'll admit is not necessarily the case. Of course, in the situation where not even the application teams are aligned directly with how the organisation makes money, we got bigger problems to worry about.
Post a Comment