In the ETAM-as-regulator model, the ETAM team is responsible for characterization and diagnosis, for design principles, and for integrating ETAM-as-regulation into methodologies and practices.
So long as IT management takes responsibility for the associated culture change -- and takes it seriously -- the decentralized approach can work. The result will be more fluid and organic than the centralized alternative; in other words, the results will be better than accidental architecture, but less elegant than what a fully centralized ETAM team would provide.
How should IT decide which model is best?
One approach is to assess your current level of ETAM organizational maturity. Maturity models are popular. They start with chaos and end with enterprise-level control and continuous improvement. There's a lot to like about maturity models, along with one major drawback: They all assume that more is better.
Most assuredly, it isn't. While a sundae, with two scoops of vanilla ice cream, lots of hot fudge, nuts, sprinkles, and a cherry on top is mighty fine, making one with 53 scoops of ice cream and everything else increased in proportion is adult-onset diabetes.
The nonmetaphorical disadvantage is that the more you centralize design and planning, and the more standards and practices you impose, the more you disenfranchise the on-the-ground teams responsible for making everything happen. That's enervating and demotivating -- exactly what you don't want in a field where energy and engagement are essential.
Here's the best advice I have on the subject: If you currently administer an accidental architecture, start by instituting the regulator model of ETAM. Get good at that, then reconnoiter. You might find this is all the business needs. Or you might find value in taking an additional step or two.
One more suggestion: With the possible exception of your lead architect, make ETAM responsibility a rotational assignment, not a permanent role. The best way to make sure your ETAM-driven standards and practices are grounded in reality is to implement an organizational solution that leads to everyone who designs the regulations having to live with them later on.
This story, "Good IT architecture means knowing when to take control," was originally published at InfoWorld.com. Read more of Bob Lewis' Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.