Mike Walker responded to my “Is Enterprise Architecture Declarative or Imperative” question with some great thoughts that I’d like to respond to and expand upon here.

For starters, Mike mentioned that he doesn’t really care for the terms declarative or imperative. I suspect, based on the tone in the rest of his post, that his dislike stems from the cold and mechanical way those terms may sound when used to represent people. In addition, I think that some would interpret, as Mike did, the declarative term as implying a command and control structure in the sense that EA is still telling teams “what” to do. I’d be willing to grant Mike that those are reasonable arguments,  but I will also say that the question was never about the choice between declarative or imperative. Rather, the terms ”declarative” and “imperative” represent the ”world view” an EA team adopts when sitting on one side or the other. In my mind, declarative teams foster a collaborative community, while imperative teams concern themselves with frameworks, governance, models and the “ROI of EA.” Not that these things aren’t important, it’s just that community and collaboration are more so (a la ”Individuals and interactions over processes and tools” in the Agile Manifesto).

Beyond the terms used to frame the debate, I am in complete agreement with the remainder of Mike’s post. The key, Mike says, is that EA is about “fostering community, providing the frameworks for decision making and providing assistance on mission critical projects.” I think that the real key word there is community. We know frameworks in EA (too well at times) and we know assistance (though we might know it by the word governance often), but I think we tend to shy away from community because it’s very contrary to most of the hierarchical organizations in which we find ourselves. But it is without that community that EA is “…viewed not only as Ivory Tower but as traffic cops” as Mike stated. With community, EA is able to voice the strategies of the business and speak from it’s unique vantage point, while at the same time empowering and trusting teams to take the expertise and input of EA and bring it to bear on their projects.

That being said, just saying that EA needs to foster a collaborative community is not enough. I have found that the EA/ SA (or Domain Architects as Mike calls them, a term I like quite a bit) interface can also foster confusion and generate conflict in many cases. I think that EA’s and SA’s could both function better in collaborative roles if they remember a few things about themselves and their comrades.

For Enterprise Architects:

1. People deserve the benefit of the doubt.
2. Coding or not, the people you serve (SA’s) are deeper in the code than you are.
3. Seek to serve, not command.
4. Even if you have the final say in a matter, help people understand your reasons and solicit their feedback early and often.
5. Respect their craft.
6. Keep up with technology and don’t lose your edge..

For Solution Architects:

1. People deserve the benefit of the doubt.
2. Learn to appreciate and understand the role of EA in your organization. Learn to appreciate the different perspectives which they bring.
3. If EA is acting “Ivory Tower,” have the courage to tell them.
4. Treat EA as an ally, not a roadblock.

Not necessarily a complete list, but the key is that EA and SA must learn to trust one another in order to foster the kind of collaborate community which Mike, myself and so many others speak of. If you don’t see a community like that taking shape in your organization, get one started. And if yours is floundering, ask yourself what you can be doing differently before you point to others or the woes of your organization as the cause of your troubles.

Thanks to Joe Lewis, I’ve been hit with a meme. Everyone says they never do these things, but this one sounds harmless enough since I can say whatever 8 random things I want to in response.

The rules for this meme are:

1. Let others know who tagged you.
2. Players start with 8 random facts about themselves.
3. Those who are tagged should post these rules and their 8 random facts.
4. Players should tag 8 other people and notify them they have been tagged.

Ok, so 8 random facts about me:

1. I received my undergraduate degree in MIS from Baylor University. Since then (all apart from my full-time job), I have considered seminary, law school (took the LSAT even), business school and seminary again. I enrolled in an LIS program at the University of Denver last Spring, then moved into a CIS program at DU’s University College after the faculty decided that technology isn’t that important to LIS programs. I’m a vagabond student, what can I say. If somebody is willing to give me a Master’s degree where I pick all the curriculum, I think I’d finally be happy. Of course, I could do that now. It’s called learning on your own…
2. A few weeks ago, I started teaching myself Ruby on Rails for grins. I’d been interested for a while, but I finally took the plunge and bought Agile Web Development with Rails, 2nd Ed. I haven’t had this much fun doing development in a while.
3. My dream career is to be a writer (and actually be able to live off of it). I’ve wanted to be once ever since I learned to read and have written on the side actively since I was eighteen. One of these days, I’ll force myself through NaNoWriMo and finally move in that direction.
4. My wife and I sponsor three children with Compassion International, the organization which I am privileged to serve. The names of our children are Denis (Tanzania), Immanuel (El Salvador) and Ana Maria (Dominican Republic). Last year, I was in the Dominican Republic and was blessed enough to be able to meet Ana Maria and her mother. It was an amazing experience and one I will never forget and I am reminded every day how fortunate I am that I get to do something I love for an organization who is on the front lines of ending poverty.
5. My Myers-Briggs personality type is ENFP (stealing one from Joe). Apparently, I am an idealist and am also terrible at follow-through.
6. I love technology, but my hobbies (running, biking, hiking, backpacking) take me outdoors where I feel free without my digital leashes.
7. I am an avid GTD-er. I love the book, the ideas, 43Folders and all things GTD. Right now, I am actually supposed to be doing my weekly review. I think this blog post (though on my action list) took longer than 2 minutes…
8. I wish I was as smart as Edward Tufte.

So that’s that. Now to pass this albatross on to others:

1. Ken Scott
2. Dempsey Williams
3. Jason Foster
4. Dan Fox
5. Rob Fay
6. Adnan Masood
7. Phil Ripperger
8. Russ Debenport 

Now how’s that for some structured procrastination?

If you haven’t run across the Greg the Architect site or videos yet, go there now. A couple of great quotes form the “ROI of the Beholder” episode completely out of context:

“Please note: Sarbanes-Oxley prevents us from providing cake.”

“Sorry about the metaphor…”

“The big guy doesn’t think that SOA is delivering ROI.”

“Come on, who’s my SOA ROI VIP?”

“I want ROI dripping all over this thing.”

“Product naming contest. Name a product, get a free ice cream.” 

Saw a post this morning (via James McGovern) entitled ”Hello World! Untie the Gardener” by a blogger named ingine. It’s a brief and basic call to action for more people to step out and get more ideas and dialogue around EA going. I concur with this call and am seconding it (or thirding or thirtying it). My primary motive for this blog is to get the ideas that float around our teams and our organization out into the world and grind them out. The result will nearly always be a better set than when I started. Most recently for me, the topics and discussion around Declarative EA and Buy vs. Build have only refined and improved my ideas. So hear hear! Let’s get more of this going.

When James provided his link to this post, he asked ingine to “…start the conversation by asking specific questions.” I’m sure ingine has questions or topics of his own, but I’d be happy to throw out some my random ideas and questions and see if we can grease the skids a bit:

1) What are some proven methods around iterative EA? We’ve all heard the chant of “Future State-Current State-Gap Analysis-Migration Plan” enough to have it embedded in our souls, but how do we leverage these good ideas in a way that doesn’t relegate EA to functioning as a team of Binder Boys?

2) Folks like Simon Guest with Microsoft (and many others), have started to collaborate with the User Experience community (The likes of Lou Rosenfeld, Peter Moreville, Jesse James Garret) for more interplay between Architecture and UX. Is this part of a bigger trend of moving away from EA as process and into EA “for the people?” I, for one, would love to see that happen, but what does that mean for the process- and framework-heavy aspects of traditional EA (I’m looking at you mister Zachman)?

3) How does well-run EA best serve an organization first instead of worrying about controlling its decisions? On that note, how does well-run EA best serve its stakeholders first?

4) Is Microsoft on to something with this OBA thing? For that matter, are we really there with Composite Applications? Personally, I see this very idea as an evolution of Enterprise Architectures which serve the user by creating naturally productive applications, but what do others think?

5) How can an organization already in bed with a major software vendor more towards welcoming open source where it makes sense? What experiences have others had in this realm?

6) Is ECM mature enough to be of strategic value to most organizations, or does the visible lack of standards and market volatility mean that we aren’t there yet?

7) Is it okay to have a list of random EA questions and not ask any about SOA?… crap. 

I’ll stop there for now, though more are bouncing around. Some of these are already in my blogging queue, but I’d love to hear from others on any and all of these. Let’s get some dialogue going…

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?