Brandon Satrom) in
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.
| 2.5 |
