So I walk into a conference room full of design engineers and project managers the other day and get a bunch of dirty looks from them. These looks probably meant:
Who is this guy?
What is he doing here?
Who invited him?
Here we go again (sigh)
Ah, here comes the trouble maker (extended sigh)
You enterprise architects out there probably know what I am talking about. I am sure you have encountered situations where you had to repeatedly explain your role in the project. Most design engineers probably never heard of you and developers, even less. The other senior managers/directors (usually your peers, really) probably think of you as another highly paid architect and so expect you to attend to the technical minutiae of every aspect of the project.
Levity aside, the role of an enterprise architect is rarely perceived clearly. To adapt an oft-quoted idiom, “He/she is all things to some people and some things to all people”. Your immediate boss and probably the boss’s boss (the guys who hold your purse strings) probably know what your role is and where you fit into the organization. If they do not, then “Gawd help you”.
So how do you fix this problem? Here are five suggestions:
First, with the help of your boss (and your boss’s boss), put on a road show. Create a reasonably slick PowerPoint (Flash is even better) presentation. Take every opportunity within (and outside) the organization to showcase your abilities, your role and how you are here to help them. Tell them what you can and cannot do, what you will and will not do.
Second, establish your credibility. Always be prepared for your meetings. It is okay to ask basic questions but ensure that the intent of your questions is well understood. Other folks attending the meeting who were hesitant to ask the basic questions may now “cotton on” on to your intentions.
Third, lead “brown bag” lunch discussions on important technical and business topics relevant to your organization. To ensure participation (at least initially) provide free lunch. Believe me; a free lunch would get them in droves. Slowly, but surely, you will see your investments in time and effort paying off.
Fourth, insert yourself into as many meaningful projects or discussions. The earlier in the project cycle, the better it is for your cause. This requires some diligence on your part to get into discussions that may end up nowhere. But then, it at least adds to your visibility.
Finally, produce as many artifacts as you can to help the cause of your fellow architects or engineers. No one likes to be sermonized from a pulpit. If you can supplement your ideas with artifacts from your previous job experiences (obviously scrubbed and sanitized for your own protection), it will help to establish you as a person with substance.
These five suggestions have been used by me in the past and I continue to use them even today. Remember, having the best wares does not guarantee that it will be sold. It is marketing these wares that make the difference.
Thursday, January 29, 2009
Wednesday, January 28, 2009
Enterprise Architecture - three things that can make it succeed
Enterprise Architecture has been an active buzzword at least for the past few years. It has achieved some success in some organizations but definitely not the total success that most excecutives have come to expect. But then, that is the nature of the beast.
EA means many things to many people and that is possibly the fundamental problem in this area. For most senior executives, the expectation is that the role will be filled by a senior archcitect who is accomplished in quite a few areas. The expectation also is that they could use this person to do the jobs previously done by multiple individuals. There are quite a few others who think hiring an EA is a panacea to all the endemic IT problems within the organization.
Business executives have come to expect the EA to miraculously solve all of the problems within a few months. In fact, they start to expect results within two weeks of a new hire. This high expectation is not entirely their fault. Frequently, IT executives justify the high price of hiring/retaining an EA by setting a rosy scenario where the business and IT live in one happy kingdom under the watchful eyes of the wise wizard, the Enterprise Architect.
So what does it take for an EA program to succeed in an organization? First, get the definition right. Does it mean the same thing to the CIO, CTO, CEO, CFO? Does the hiring manager's definition of an EA the same as the incoming/incumbent EA?
Second, get the expectations right. It is important to let the senior officers in both the business and IT areas know what can and cannot be achieved within the realm of EA. Goals need to be broken into short term, medium term and long term. At the risk of using an oft repeated cliche, "grab the low hanging fruit". There are probably more naysayers in the organization than there are champions and therefore it is important to have a few early successes to establish the credibility of the program.
Third, give the EA some teeth. Most organizations make the mistake of making the EA an individual contributor with no real authority to override the design architects in critical decision making processes. While it is important that the EA does not unnecessarily put a roadblock into the implementation of projects (or even the operation in a steady state), he/she must throw a "hissy fit" when absolutely required. While most senior IT executives do "talk the talk" under day to day scenarios, very few "walk the talk" during distress conditions. By distress conditions, I mean situations of system breakdown. I certainly do not mean that everyone needs to sit in a room and espouse the cause of structured arhitectured and design analysis when all hell is breaking loose in the business wing of the floor. Yes, the systems need to come up first. That is the number one priority, no matter what. And most IT organizations do a decent job of getting it back up as soon as they possibly can. But here's where most organizations fail - they bask in the reflected glory of resumed operations that they fail to pay heed to the core crux of the problem.
These three aspects, by themselves, are obviously not enough in sustaining an EA program but it is good start to a long and fruitful relationship between business and IT.
EA means many things to many people and that is possibly the fundamental problem in this area. For most senior executives, the expectation is that the role will be filled by a senior archcitect who is accomplished in quite a few areas. The expectation also is that they could use this person to do the jobs previously done by multiple individuals. There are quite a few others who think hiring an EA is a panacea to all the endemic IT problems within the organization.
Business executives have come to expect the EA to miraculously solve all of the problems within a few months. In fact, they start to expect results within two weeks of a new hire. This high expectation is not entirely their fault. Frequently, IT executives justify the high price of hiring/retaining an EA by setting a rosy scenario where the business and IT live in one happy kingdom under the watchful eyes of the wise wizard, the Enterprise Architect.
So what does it take for an EA program to succeed in an organization? First, get the definition right. Does it mean the same thing to the CIO, CTO, CEO, CFO? Does the hiring manager's definition of an EA the same as the incoming/incumbent EA?
Second, get the expectations right. It is important to let the senior officers in both the business and IT areas know what can and cannot be achieved within the realm of EA. Goals need to be broken into short term, medium term and long term. At the risk of using an oft repeated cliche, "grab the low hanging fruit". There are probably more naysayers in the organization than there are champions and therefore it is important to have a few early successes to establish the credibility of the program.
Third, give the EA some teeth. Most organizations make the mistake of making the EA an individual contributor with no real authority to override the design architects in critical decision making processes. While it is important that the EA does not unnecessarily put a roadblock into the implementation of projects (or even the operation in a steady state), he/she must throw a "hissy fit" when absolutely required. While most senior IT executives do "talk the talk" under day to day scenarios, very few "walk the talk" during distress conditions. By distress conditions, I mean situations of system breakdown. I certainly do not mean that everyone needs to sit in a room and espouse the cause of structured arhitectured and design analysis when all hell is breaking loose in the business wing of the floor. Yes, the systems need to come up first. That is the number one priority, no matter what. And most IT organizations do a decent job of getting it back up as soon as they possibly can. But here's where most organizations fail - they bask in the reflected glory of resumed operations that they fail to pay heed to the core crux of the problem.
These three aspects, by themselves, are obviously not enough in sustaining an EA program but it is good start to a long and fruitful relationship between business and IT.
Subscribe to:
Posts (Atom)
About Me
- Sree Sundaram
- Sree Sundaram is currently a Sr. Director of Enterprise Architecture at a major global technology firm. He is currently engaged at two major international biotechnology firms in optimization and migration of infrastructure from their current platform to a newer technological platform that is in line with their current and future business needs. Sree has solid experience in understanding the needs of both middle and top level management and has the ability to communicate at both levels. He is fundamentally aware that the transactional and short-term needs of middle level management are different from the long-term vision of top-level management. He has successfully dealt with such issues by providing an IT framework that meets both the short term and long term needs. In general, Sree helps to prioritize competing initiatives using a combination of his acumen, communication skills, strategic and operation plans.