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:
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.
- The artificact was packaged as a Powerpoint deck. Unfortunately, the deck appeared to be created by cutting-and-pasting portions of Word docs, PDFs, Website materials, and other stuff into the pages. Very tough to read, must less digest and understand, slides that were just many paragraphs of text.
- The work was quite comprehensive, all the way down to explicit specifcations of laptops the organization will order for its employees from now forward.
- The explicit infrastructure software bias - OS, enterprise messaging/EAI, and database servers were all from a certain extremely huge vendor located in Redmond, Washington. I wonder if that will tick their stock up a buck or two. Worse, there was no mention of how COTS-related dependencies (and they have them) with respect to other vendor's wares (i.e. Oracle) were to be handled, and the CIO mandated a few years ago that COTS solutions were to be purchased and implemented over custom development whenever feasible.
- There was no unifying theme to the architecture - technical or business, and that was obvious when only base technologies were addressed and the organization's major applications and data stores went completely unmentioned.
- Didn't see anything about the future, such as SOA, web services, etc. even though he muddled through a strawman to-be state that was inconsistent and in some cases, technically erroneous.
- Standards for languages, coding, etc. were presented as 'guidelines' - that is, he's calling it a guideline but in reality, we'll do it his way and exceptions will be far and few between if they're granted at all.
- Speaking of exceptions, if you aren't at the director/VP level in IT or above, you won't be presenting any to him.
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.
