Scott Mark posted some brilliant thoughts on Enterprise Architects and their propensity for being cynics. I wonder whether or not the concern is less about feeling undervalued and more about wishing that they sovereign domain and discretion over the IT portfolio. What would a good architect do if they owned all budget and timeline decisions? Maybe corporations should have an architect "King-for-a-Day" day. Seriously though,
Scott's post is very timely in that a group of architects I was with just today had a discussion on a nearly identical topic. There seems to be a pattern of the importance of architecture and the profitability of the business customer we support.
I submit that the ability to speak in business terminology should be a prerequisite for most architects. If you cannot communicate with your business customer, you should not be consulting with your business customer directly. Project managers play a key role in articulating the planning details, financial implications, resource requirements and timelines of project work. As I posted before, a
healthy tension between project managers and architects is a good thing.
Further,
Scott discusses the importance of "demonstrating the value of EA through participation". I would offer that marketing IT is critical in most IT leaders' minds.
James McGovern has
posted on this as well. In the end perception is reality.
So what's the answer? I am landing on a more mature viewpoint on marketing technology and architecture. Its a Band-Aid to trust problems or process issues. Don't get me wrong, I think its critical that success be celebrated. I do however feel that through empowerment, architects will internalize and declare themselves accountable for righting wrongs. Suggestion boxes, covert meetings with business decision makers, and financial incentive/disincentives are
NOT the answer. Do we really think we have the one best answer to all problems if money, tools, timelines and resources are infinite? Should our customers be asking us to build Web Services and ESBs? Perhaps the real issue is that we spend too much time justifying technical details and not enough time demonstrating impacts to the bottom line and modeling new business functionality. Often times the best critical decision-making happens under pressure. If the business needs a economical commuter car and we engineer a Ferrari--we fail. If the business needs a strong truck and we deliver a quick and cheap Pinto--we fail. Every architect and customer must understand the REAL business problem and functionality we are solving for...in absence of that we have the potential for either designing too tactical or over-investing in undervalued capabilities.
Architects develop some
cynicism based on missed opportunities and mistakes of the past. In order for one to have success with architecture and improving the IT portfolio, one must love it a little and understand it a lot.
What do you think?
