Share via

IASA Perspectives Issue 4

  • Article

Issue 4 of IASA Perspectives focuses on defining an architect and brings up one of the most common questions:  What is an architect (software, solutions, enterprise, infrastructure, et. al.)?

I often ask this question during MCA boards and sometimes make it tougher to answer by asking how you would explain the role of an architect to a lay person.  There are numerous definitions of architect available, but not many of them are understandable by my wife.

Another way to think about this question is, "as an architect, what are you passionate about"?  Some architects are passionate about publishing (which is a good thing, because many of us aren't, which leads to a lot of needless wheel invention).  Some are passionate about process or governance.  Some are passionate about "abilities".

My passion as an architect is that of bridge (not the card game that Bill and Warren share a passion for).  I used to say that it was being the bridge between business and IT.  While that's still true and still a big part of what I do, I've generalized my definition as I also often find myself serving as a bridge between infrastructure and development or between central IT and business group IT or between management and individual contributors or between sales and services or between my soon to be teenager and reality ...

The point of a bridge is to tie two places together, ideally in a seamless manner (unlike the Huey P. Long with narrow lanes, no shoulders, and a 1 foot "jog" in the middle ...).  In order to do this effectively, one has to speak and understand many languages - more than just translation - actually understand and, more importantly, be understood.  I've seen many meetings drag on and on and on because group a didn't understand what group b was saying - or worse, they assumed they understood and were wrong.  This is the perfect opportunity for the architect to step in, be a bridge, and add tremendous value.

One of the key techniques I use to be an effective bridge is to assume the perspective of the audience I'm communicating "to".  Different constituencies see the same problem from different perspectives.  What's important to one group is trivial to another.  Understanding the perspective is step 1, but to be truly successful, you have to be able to step into that perspective and communicate natively.  Not unlike when you become fluent in a foreign language and start "thinking" in that language.

Unfortunately, I don't have any breakthrough advice on how to accomplish this.  Experience and practice are the only methods I know of - but that's just my perspective.

Comments