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

Wednesday, December 28, 2005

 

Stories of Enterprise Architecture

I've been holding off on commenting about Rebecca Parsons column in IEEE Software because I wanted to think about my approach to this issue for a period of time rather than being simply reactionary. Her column states that enterprise architects should become members of software development teams, and the primary rationale behind that assertion is that developers are often faced with the 'ivory-tower' approach to EA isn't often in touch with their technical work and burdens them with additonal requirements that must be realized in working software.

Point taken, and her premise misses the mark with respect to what the discipline of enterprise architecture is supposed to accomplish within organizations.

Enterprise architects are in a tough spot in the IT food chain. Enterprise architecture is sold to organizations as a means of getting their many needs met in an orderly, expedient, and cost-effective fashion. It's sold to CIOs, developers and IT operations as a, for lack of a better term at the moment, "unified theory" of IT that allows agility, robustness, and operational excellence of applications and supporting technology infrastructure.

Successfully straddling that line is a tall order for any professional, and I've searched for possible solutions and techniques for a long time. The first issue that comes to mind is how enterprise architects are supposed to get these seemingly divergent camps onto roughly the same page in addition to their own views and assertions about the various issues involved.

Part of the answer came to me on my flight back to Portland from my midwestern holiday: a marketing guy by the name of Seth Godin wrote a book titled "All Marketers are Liars" that I bought at the airport bookstore and thumbed through as the flight progressed.

Godin correctly asserts that humans pay far more attention to their wants as opposed to their needs, and drive their decisions and actions toward them. Simple enough, but this tenet (what Godin terms the worldview that all people have) plays a huge role in almost all decision-making, especially regarding purchases and other financial committments. I have no doubt that this extends to the workplace as well.

As such, Godin maintains that the old ways of marketing, and of being better, faster, and cheaper don't work anymore. The solution today is in the stories that we tell - both to ourselves and others. The kicker here is how the stories are interpreted by the listeners, complete with inherent wants and biases - in short, their worldview.

Does this mean that we tell lies? Not at all. Does this mean that folks hearing our messages discount things that don't align with their worldview, even in the face of solid data supporting our cause? In effect, lying to themselves? Most certainly.

What Godin means is that we have to become much better storytellers. In fact, those in the agile camp intimate to me that the better and more complete the user story is, the better the overall outcome of the agile project. Makes sense, but why doesn't it happen more often, especially on larger projects?

Parsons' article, deconstructed to its core element, is simply this: whining from one of the camps that enterprise architects deal with. In fairness, the business-side whines a lot too, but the continued mantra of "you can't do architecture if you don't write code" argument gets really old, really quickly. I could counter that with "you can't do architecture if you can't do business analysis," but the end result is the same.

But then again, they make (and have) the money. And Seth Godin is a marketer who tells stories and admonishes us to tell them also. It appears that we can learn a lot from him on successfully dealing with the stakeholders in our architecture efforts.

Comments:
I am in full agreement with Rebecca when it comes to EA's participating on software development teams. The key isn't to be a full-time member but a participate.

It is possible to write code and demonstrate leadership. This doesn't mean that you have steward all lines of code throughout its lifecycle but you should gain credible visibility into everything going on and in order to do so, you must participate...

http://duckdown.blogspot.com
 
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