Enterprise Architects face many directions at once and the deliverables are intended to help with the various lines of communication.

     *  The models help aid the validation and discovery phase with the stakeholders and later provide a well known visualization of the stakeholders plans the architect can use to communicate with the project teams.

     *  Clear governance is more for the end users than the developers.  Governance might include preventing the HR department from developing its own financial system, or a prohibition against individual or groups installing their own virus detection software. 

     * The repository and binaries provide a means for the Architect to directly engage the project teams.

 

I spend my days moving across projects and there is one thing I have come to believe very strongly … if you’re not making it easier, nobody cares.  If an Architect is truly doing enterprise strength work s/he must provide direct value to the various project teams.  The inclusion of enterprise concepts, goals, and staff as a dependency in a project must not negatively effect the projects milestones.  In fact it must improve the project teams’ ability to deliver higher quality, on time, and under budget.

 

Domain Architects have generally held ivory tower positions within an enterprise.  They were prophets with nearly mystical insights wandering the cubicles dolling out words of wisdom to the true believers. They promised efficiency and saving to management who, in return for the architect’s favor, endowed the architect with few real responsibilities and the freedom to be an agent of change.  Alas the architect was thwarted again and again by the project teams who, turning a blind eye to the architect predictions of future loss, managed to deliver real working software to better the lives of their users.

 

My inclusion of a shared repository and binaries as is directly related to the need to close the divide between true believer who sees the broad need to support the business and the ground pounding foot soldier knocking out code every day delivering to, but not exceeding, the requirements. 

 

Enterprise architecture is much more a kin to city management than building architecture.  Buildings plan for appropriate amounts of water to flow through a structure to support the proposed population and use.  City planners need to provide the water, provisioning it to the many buildings and homes all while balancing the need with maintaining the environment and assuring future availability.   It seems unlikely to assume the builder will do the right thing from source to use to disposal.  Instead the city provides pluming, sewage, and well known standards for interacting with each.

 

Due to the under-developed sense of what Enterprise Architect provides, we must do more than just supply the plumbing and the guidance on its use.  Enterprise Architects must get in the trenches and demonstrate how, when, and why using to the supplied binaries is “better”.  Consider if you will, architects working (actually coding) side-by-side with the project developers.  The architect would attend their meetings, participate in reviews, and kibitz with the project leads.  

 

They bring measurable value by ;

      * bringing experience that the project may not he budget for or otherwise have available.

      * being the “expert in earshot” stepping in before a problem escalates to a level of embarrassment that forces the offending developer to confess to its existence.  

      * directing project members to existing components in the enterprise repository before they spend limited project dollars re-inventing the wheel

      * identifying and promoting project specific components to the enterprise when appropriate.

      * providing real-time interpretation of the stakeholders vision and goals gleaned across the various project in the enterprise.