.comment-link {margin-left:.6em;}

Friday, January 27, 2006


Enterprise Architects, CTOs, and Coalitions

I recently reviewed a CTO's handiwork explicitly framed by him as the "enterprise architecture" for the organization going forward. I'm using quotes because for various reasons, it clearly wasn't. In fairness, I can describe it as a roadmap of sorts to get to some sort of architecture, but the work suffered from numerous problems:

Whoa. I haven't had that many warning buzzers go off in my head in such a short period of time for quite some years. It was clear that this guy doesn't have a good grip on architecture, much less presentation and political skills. Funny thing about this is, about half of this organization's IT folks thought it was great!

And I'll give you one guess who the other half was who thought it was crap - that's right, the organization's software developers. And they're right.

In my previous post about developer 'whining' about architects being placed into development teams, the point I was trying to make there is that enterprise architects need to strike some kind of balance and focus between the business and technical sides of the house. Yes, they need to interact directly with development efforts, but the reality is that they are not paid large sums of money to write (or even review) coding efforts. There just isn't enough time to prioritize that over architecture and business-focused work. Putting them on development teams solves nothing with respect to technical strategy and business-technology issues, and its the same for keeping enterprise architects in so-called 'ivory towers' - pretty soon, whatever they say or do is simply viewed as pontificating to development teams, and usually gets summarily dismissed or ignored.

The linkage I'm thinking about to address this problem focuses more on the interactions between enterprise architects and system architects/designers/development team leaders. Project managers also if the IT organization has that function. Getting all of these folks on the same page is critical if a to-be architecture will ever be realized. Mandates and "thou shalt/thou shalt not' edicts from EA's to the rest of IT don't cut it - never have, and never will. On the other hand, design-by-committee and endless consensus building doesn't get us anywhere either, at least not very quickly.

The enterprise architect in this situation has another avenue to pursue unity: building a coalition. The dictionary defines a coalition as "an alliance, especially a temporary one, of people, factions, parties, or nations." This is a great strategy for architects in getting agreement between the business and IT because temporarily getting the parties on board with respect to major issues trumps no agreement on anything (and thus, no progress) hands down.

True consensus is almost impossible to achieve on complex technical and business issues, but coalitions are relatively straightforward because all of the parties involved get something out of their membership and contribution, but not necessarily everything they're looking for.

Which is not a bad thing if you cannot achieve consensus and harmony (and very few can) on large, complex projects.

Comments: Post a Comment

Links to this post:

Create a Link

<< Home
Technology Blog Top Sites |

This page is powered by Blogger. Isn't yours?

Weblog Commenting and Trackback by HaloScan.com