Transparency in Architecture
Brandon Satrom posted a blog last week asking the question, “Is Enterprise Architecture Declarative or Imperative?” In clarifying the question, he pointed out that declarative programming is where a developer instructs a system what to do, but leaves it to the system to decide how best to implement that instruction. Imperative programming is where the system is told both the what and how. He goes on to discuss that his thoughts are that EA should be declarative, but working closely with a group of Solution Architects (much like I presented in my People! Policies! Process! post) that take the visions and translate them into execution.
I will agree that for the most part, EA is a declarative activity, although I wouldn’t go so far as to say that the path to execution falls to solution architects. If EA’s merely define the future state, but don’t define the executable actions (albeit at a higher level, they’re not providing project plans), they’ll likely become an ivory tower. Personally, I think the model of increasing constraints is probably a more accurate depiction of what goes on. Through reference models and architectures, there’s a certain set of constraints established that projects must now adhere to. Within the project, there are additional constraints that are established based upon the solution architecture, and then the class design, etc. You could argue that each set of constraints represents a declaration of what things should be.
As soon as you establish constraints, the subject of governance now comes up. I had an interesting discussion with someone today regarding this topic and he made the point that the projects that are intended to operate within the constraints established by EA must be transparent. Rather than assign someone from the security force to watch over the project team with an iron fist, simply make the architectural decisions visible so that at any point, someone can take a look. This made perfect sense to me. I’ve worked at a company that had taken a similar approach for financial governance on projects, where reports were generated every week and the budget watchers could easily determine whether things were compliant or not. It struck me that this would be a good approach for architectural governance, as well. Of course, this does imply that there needs to be a way to actually see the architecture from the outside, which is another story. Visibility to the source code does not equate to visibility of the solution architecture. What are your thoughts on this?
2 Responses to “Transparency in Architecture”
Leave a Reply
[…] 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 imperative, 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. If EA is both the Keepers of the Flame and the stewards of strategy, we have to care. And you, whomever you are, 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 interviewer, Mike Gotta, made the comment that blogs within the enterprise need to be purposeful, and that there’s a fear that they will simply be a soap box or a place to rant. To any manager or executive that has a fear about them becoming a place for employees to rant, you’re looking at the wrong issue. If employees feel a need to rant, they’ll be doing it in the hallways, break rooms, and cafeteria. If anything, blogging could bring some of this out in the open and allow something to be done about it. This is where I think there is real value for blogging, wikis, etc. in the enterprise. I recently had a post titled Transparency in Architecture that talked about a need for projects to make their architectural decisions transparent throughout the process (and the same holds true for enterprise architects and their development of reference architectures and strategies). Blogs and wikis create an opportunity to increase the transparency in enterprise efforts. I’ve worked in environments that had a “need to know” policy for legitimate reasons, but for most enterprises, this shouldn’t be the case. When information isn’t shared, it may be a symptom of lack of trust in the enterprise, which can be disastrous for SOA or anything else IT does. […]