Thoughts on EA Cynicism...
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?
posted by JT at 8:28 PM
11 Comments:
So, you really don't believe that business folks care that I used the decorator pattern to decouple my proxy from adapter?
Define who is really the customer...
Not customer in the sigular James, in the plural....
Good thoughts, James! I definitely agree that perception is reality, and also you are ultimately responsible for how people perceive you.
Mcgovern: I care more that my architect peers and developers know what patterns are, when they should be implemented. Their many customers with different viewpoints of the same problem and solution. Architects need to be able to articulate these viewpoints for multiple audiences.
Bob: Agreed.
Scott: Thanks and I am also thinking one must be cautious that we manage perceptions, but not to let those (perceived) perceptions manage us into bad decisions.
It is a pity that some project managers are hesitant to 'allow' the architect to speak to the business customer. Of course, the loaded word is 'allow' because, in a pure sense, it is the architect who 'allows' the PM to PREVENT him from speaking to the business customer.
What would the architect say? He would say that he is providing the guiding vision. While the PM makes sure that the software is built correctly, the architect insures that the correct software is built.
Many customers have been fed technical details of the systems they use. They believe that they need to be aware of these details, because it appears that no one else is. For these customers, easing them off of that role may not be easy. Only the architect can do it, and only by speaking directly with the customer.
This is a good post. Well thought out.
Nick,
Thanks for taking the time to read and post!
If I am not ALLOWED to speak with a customer about their requirements...I will do everything in my power to see that I never work with that PM again.
Cheers!
This comment has been removed by a blog administrator.
From my experience, customers (defined as the ones who pay the bills) dont care about the tools/patterns/methods to get to any particular solution. They care that the Architect is experienced enough to understand their problem and to provide the right solutions. Architects should care within their community, to ensure consistency and to get estalbish the "best" in best of breed.
However, customers do care to learn that there are perhaps many ways to solve their business problem, AND, to undersand the tradeoffs. It is an art to help pull the real need/problem from the customer, and often the best way is through exploration of solution ideas.
The Architect (in my old consulting world) needs to always be paired up with a good PM when meeting with the customer, especially since the customer always comes forward with a solution...the Architect needs to help guide the customer into defining what they really need (vs. what they originally want). That's when the Architect is King for the day.
Rich A,
Thanks for your post...
How does an architect working for a customer the first time demonstrate they are "experienced"?
-JT
JT, In response to your question "How does an architect working for a customer the first time demonstrate they are "experienced"?".
First by listening, second by repeating what you have heard, and third by providing a path to get to the solution. i.e. explain to the customer the methodology you will use (not the tools, but the techniques) to get there. Then follow that methodology, engaging the customer as you work through it (often using multiple solutions and leveragin active questioning). Your are now the teacher and the problem solver rolled into one. The worst this, from my eperience is to solve the problem without ensuring you understand the problem and without a framework that the customer can understand (the customers I have worked with see this as working with a "green" architect).
Rich A,
I could not agree with you more.
Based on your thoughts... Architects should pursue certification in relationship management, leadership and communications before technical topics then?...
Do you have a blog or Wiki?
-JT
Post a Comment
<< Home