Last week, Todd Biske linked to my post, ”Is Enterprise Architecture Declarative or Imperative?” and added some of his thoughts in a post entitled “Transparency in Architecture.” In addition, Adnan Masood left a comment in the original post which made a similar point. Their point: Enterprise Architecture is declarative, but not always and it’s not that simple. Adnan agreed that EA is declarative at its best, but mentioned that the “sync up” process I referred to between EA and Solution Architects will have some imperative qualities. Todd also agreed that EA is declarative, but said “… I wouldn’t go so far as to say that the path to execution falls to solution architects.” Instead, Todd said that EA should define both future state and some very coarse executable actions for achieving that future state. A great point, and I totally agree. The idea of “increasing constraints” as Todd puts it, is a good way to describe the healthy tension at the EA/ SA handoff. Our VP of IT calls this “Freedom within a Framework,” a term which I believe captures the essence of how EA can be declarative. We’re not going to sit in your code reviews, but we do care how you are using Enterprise Information and upon which platforms you are delivering solutions to our customers. I heard Gartner Analyst Anne Lapkin once state that EA constrains IT for the good of the business. So, If EA is both the Keepers of the Flame and the stewards of strategy, we have to care. And you, whomever you may be, should demand that we care so you can be free to care about what you need to, be it well-run projects, well-crafted and innovative solutions, or a well-thought-of and profitable IT organization.
The second part of Todd’s post discussed the topic of governance and how projects constrained by EA should be transparent. While I like this idea far better than being pulled into a million meetings (or, more importantly, making teams feel that they can’t be trusted and must be looked after), that kind of transparency is a tall order in most situations I’ve been in, which Todd also states. But I like this idea and can see its parallels to the concept of Information Radiators in agile software development. In the same way that I can wander into a war room or bullpen and find out basic and essential information about a project (backlog, burndown, etc), these “Architecture Radiators” could provide me with the information I would need to asses the state of the architecture of the project and track its evolution over time.
But that’s just theory… what would such a thing look like? It would have to be both simple to maintain and useful. I’ll have to think on this some more. In the meantime, does anyone have any ideas or examples from projects where these types of Information Radiators existed?
If you enjoyed this article, please consider sharing it!
