EA Governance - Architecture's Sustainability

One of my fellow consultants here at Oracle had a great quote the other day regarding EA Governance:

"One cannot overstate the tedium nor the importance of EA Governance"

For those in the EA discipline that "grew up" through more technical disciplines (e.g., software engineering) the establishment of committees, boards, and sets of standards might feel like a visit to the dentist. But it is so essential to long-term success that it cannot be ignored.

You can draw the slickest diagrams utilizing all the best patterns for loose coupling and separation of concerns dazzling your clients. But without the checks-and-balances that governance brings, the models will be nothing more than pretty pictures to gaze at. The models will not be actionable nor will the architecture be sustainable. Entropy will prevail in the architecture choking out an organization's ability to innovate and be competitive.

Setting up governance, while it might seem like an afterthought in some ADMs, is really a task that (needs to) weave itself through any ADM phase.

Comments:

Any thoughts on how to implement governance that: 1) Is not a bottleneck to projects 2) Is accepted & supported by development teams 3) Is not more painful than a root canal Vic Stachura Rich Products Corporation

Posted by Victor Stachura on December 02, 2010 at 12:44 AM EST #

Victor - great question worthy of a longer response. Simply put: Its up to the architecture program to determine within each organization how much architecture is needed at the right time. Good architecture is not about the quantity of standards or principles or amount of paperwork but rather the quality of how those principles are institutionalized into the culture. Its important too for the EA program to *connect the dots*; why does a particular standard actually make a project teams' job easier? How does it preserve the existing infrastructure so projects may "live to code another day"? I think answering those questions helps to get the EA program instilled into the project teams. Some other random thoughts occur to me: 1) Those who participate in projects should feel like they have a say in how the EA is being formulated. This means having balanced representation at the right time to make changes to the architecture. 2) As much as an EA program needs to be prescriptive they also need to listen to the needs of the project teams.Because the project teams are working at a finer level of detail than architects (typically), its important for the architect to take into consideration what the project teams are saying. Eventually, the architect may propose changes in the architecture to address a particular concern. HTH

Posted by Eric Stephens on December 03, 2010 at 12:54 AM EST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Art, Artifacts, and Best Practices for Enterprise Architects

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today