Inchoate Curmudgeon

While browsing James McGovern’s blog entry, “Links for 5-12,” I ran across a link to a post by Bex Huff, “What is an Architect?” Talking about this is a bit of self absorbed navel-gazing that makes the rounds where I work every once in a while. Nonetheless, I will throw in a couple of observations to add to Bex’s:

• Architects, to a greater or lesser degree, are able to tolerate far more ambiguity in discourse than their typical engineering brethren. Engineers always find this infuriating, but without this, it is virtually impossible to discuss the qualitative aspects of anything more complicated than a watch spring in less than a century. However, even the best Architect will frequently find comfort in occasional bit twiddling. In my opinion, this difference has some deep seated roots in our need to control, and Engineers not only need more of it, this is frequently the motivation for getting into the business to begin with: computers are finite state automatons, humans and human systems, otherwise known as businesses, are decidedly not. Architects tend to be curious about how technology evolves in human affairs, Engineers are frequently frustrated and annoyed by humans, otherwise known as customers, screwing up the works.
• Every architect, speaking in vague generalities per the first point, has technical training and experience, but rarely has a formal computer engineering degree. Most good Architects wield degrees in disciplines like Chemistry, Economics, Biology, Physics, Petroleum Engineering or even Fine Art over Systems Engineering or Computer Science. Its almost as though the act of crossing-over disciplines is critical to the development of the good Architect. Architecture as a discipline is much more about science in the classical sense, than applied science that is the purview of engineering.

I agree with the comments about communication skills in Bex’s blog entry, but bridging between business and technology is only the paler half of the truth: bridging between the multitude of disciplines required to apply technologists, not technology, to a problem is a core competency. Many architects have their plates full because Database Administrators and Network Engineers and Storage Engineers don’t talk. This is stupid and childish, but this is true, and again relates to the control issue. For example, Database Administrators irritate System Administrators.

Also, the Architect is frequently the only one on the team who can call “bull@*!+” on any of the technical team disciplines and have it stick. An Architect that doesn’t know how to drill down in any technical area with any of the technical team, quickly and decisively, is a moron and should be shot. This may be the only reason the technical team tolerates a good Architect. Multi-disciplinary team members not only do not know what the other Engineers do other than irritate them, they do not know how to effectively deal with the irritation without firearms or brute coercion, and they really don’t want to know.

Insofar as Project Management, really good Architects will frequently be ineffective in project milieus when not properly teamed with skilled Project or Program Managers. But, the gray area between these skills is very real. Many of the particulars of which role owns what part of a delivery is generally negotiated based on skill, experience and respect. For example, this sort of negotiation surfaces when asking and answering the question “Who owns the Risk Management Plan?”

All of this is fine, but somewhat backward looking. What I ponder these days is how Web 2.0 Social Media might affect the application of the architectural skill set. Is there a Social Media enabler of IT or Enterprise Architecture, or does the adequate application of these new, interactive communication mechanisms obviate significant portions of the skill set?

It’s hard to believe that Web 2.0 could completely transform the minions of Engineers who have been raised by wolves into kinder and gentler Architects, but perhaps the New Web 2.0 Programmer will be able to build useful services without involving either Architects or Engineers. It would be really nice to be able to just plug your program into the grid and watch it run. We just slow things down. In the mean time, we aren’t completely there yet. I’m not picking on anyone, this is just a data point, but Twitter has been up and down all day, and the near-death flame-out at Zooomr isn’t a distant memory yet.

Trackback URI | Comments RSS