I ran across an blog posting by Brandon Satrom called "Is Enterprise Architecture Declarative or Imperative?". It was an interesting read. I agree with some of the concepts that EA's should interact regularly, however I don't really like using the terms Declarative vs. Imperative.
See below:
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.
I believe that Enterprise Architecture is all about fostering community, provide the frameworks for decision making and provides assistance on mission critical projects. It's less about "telling the system what to do" rather fostering collaboration with these teams. When EA's go in by force they are viewed not only as Ivory Tower but as Traffic Cops. EA's should step back an enable and empower the community to make the right decisions, this gives EA's creditability and support because they are not viewed as micro-managing.
Additionally sometimes Solution Architects (SA's) or as I refer to them Domain Architects; do not apply in certain situations. I would be careful there for that reason and that not all organizations are structured the same.
For example below are two organizations I have had interactions with over the past few months:
One is structured around the Org Chart the other in a domain model.
Lastly, I would check out Todd Biske's post regarding this as well. He has some good thoughts around transparency around the interactions between teams. He focuses a lot on the Solution Architect role, I agree with that however I think the higher order bit here is that EA's and SA's facilitate the change they do not micro manage teams. If they do resistance will be found and the organization rebels.
コメント