Okay quick question, assuming I have any readers left after my far-too-long hiatus.

Assume that the middle box--labeled "Translation"--is EA.

With no explanation from me, what does this graphic mean to you?

What do you think it says that you would agree with?

What does it say that you would dispute?

Interested in hearing your thoughts...

When I was working on The Great Buy vs. Build Debate - Part II last week, I briefly mentioned that the configuration of a purchased application often takes the form of declarative programming, where a developer instructs a system in what to do, but leaves it to the system to decide how best to implement that instruction. Contrast this with imperative programming, where the system is told both the what and the how. In a moment of rabbit-trailing, I started to think about these terms as they relate to human systems. Specifically, I wondered: Does Enterprise Architecture, as an organizational function, serve better by interacting declaratively with implementing teams, or should said function be imperative in nature? Personally, I think that EA is meant to be declarative and should interact regularly with a group of implementing architects (we refer to them as Solution Architects) who "sync up" with these declarative visions and translate them into execution. 

However, I think that in order for an EA group to truly be declarative in its interactions with other teams, there are a few things that have to be in place:

- An official and accountable group of SA's;

- A high degree of trust both within and between the EA and SA groups;

- Clarity of vision/ strategy and communication from EA to SA's;

- A healthy and consistent feedback loop from SA's to EA.

I think that without these (and others, I am sure), the EA function is almost forced to have two feet in both camps, which is frustrating to both the EA team and the SA group, be it "official" or not.

But forget about my opinion: What do you think? Is EA truly meant to be declarative? What else belongs on the list of EA-SA collaboration prerequisites? I'd like to elaborate on this discussion more in future posts and would love some dialogue and feedback.

Sad, funny and true... Check out today's Dilbert Comic

"Economics is the study of how societies use scarce resources to produce valuable commodities and distribute them among different people." - Paul Samuelson and William Nordhaus

We know this fact... We understand the logic of it... And yet, this legitimate gripe continues all across corporate America today.

Are we insane? Misguided? Or are the organizational structures and policies of our corporations just that poorly structured?

Louis Rosenfeld on "Information Guys" one day getting the keys to the manor.

You know, I've wondered something like this ever since I started in the IT world. It seems that accounting, finance and operations management are the disciplines that corporate board like to see in their CEO's (which may partially be because that's what your board people are).

In a different tack from Lou, I've always wondered if IT people would one day achieve that goal in large enterprises. I think Lou's question is just an extension of that: Will Information people one day be asked to helm (and in some cases, turn around) companies?

I tend to think so, especially as the challenge of managing information and knowledge becomes more and more vital to the bottom line of major corporations. But I would see it happening for pure "Information guys" that helm EIA groups long before IT gets that kind of shot. No knock on IT senior execs and CIOs (a lot of which are also accounting/ finance guys), but IT departments must repair their reputation of being a corporate "necessary evil" (a la, I hate you, but I need your technology) before any board will ever give an IT guy that kind of control...

In any case, as information becomes more vital, so do the roles of those that have the skills to deal with it.