TO be or not to Be - An Architect that is..
Someone recently asked me what it takes to become a top-notch architect. I think if you ask that question to five people, you will receive five different answers. Here's my answer.
To break it down, here are some high-level traits you need to look for. Either from the hiring or self-development standpoint, these are the must-haves:
1) Technical Competence. The individual must have experience and knowledge relevant to the level in which they seek to Architect. Most of the architectural engagements I deal with is at the Enterprise level. There's different set of criteria relating to Enterprise-wide designs a Systems Architect or Client/Server architect. There is much more topology to consider when making a decision. For example, if the system in question does not deploy single-sign on, then how will that impact your solution. What happens if the system does use single-sign-on but your system does not support the implementation? You need to fit the level of experience to the level of architecture. A client/server architect has less topology in general to be concerned with. Enterprise-wide architects have security layers, messaging layers, etc. along with the typical people-politics.
Moving past technical competence, what does this leave us to ponder?
2) Clear Communication. This is a major concern and a difficult issue to address either from the interviewee or personal standpoint. First, can the individual articulate clearly in the given language? Does the individual create clear and concise emails or documentation? Does the individual have poor communication skills? Is this apparent in written communication as well?
On my trip to China to work with our Global Development Center, I realized, often too late, that I speak too quickly and use English terms that were not understood. Rather than clarify or ask probing questions, I assumed that I was understood. After a couple of misunderstandings, I changed my approach and was much more successful.
3) Listening Skills. Can the individual listen? Don't confuse the inability of the individual to speak a given language (shyness) with their ability to listen. The skill to listening is tricky and can be difficult. Think of the car salesman who only wants to sell you a car. No matter what you say, he ignores you and persists with the sale (effective sales technique.)
Sometimes, we listen but our brain registers something else. A good way to make sure that what you are hearing is what is being said, is to ask a clarifying question like, "So what you are saying is ____________?" or "So in other words, you mean _____________?", "Is this correct?"
I usually reiterate back a list of bullet point take-aways from a meeting to insure that I do not bungle this important facet of communication.
4) Presentation Skills.
If the architect is presenting an architecture to a client, boss, team or other group of people, the presenter must be able to clearly explain their ideas, defend them, and win over the audience through presentation. You will not win all of the battles, but ultimately, you need to win the war.
I am currently working with an individual who is trying to transition from a lead developer position to an architect position. This is someone who has spent a long career in support and development roles and wants to move up the technical ladder.
While he is technically proficient on webMethods, J2EE, database and other skills, he cannot present his ideas with clarity. He isn't quick on his feet.
So, I had a brainstorm one day, and I had him look up Toastmasters International. They have local chapters all over the US. Their primary function is to meet and help others develop or polish their presentation abilities. He is now attending Toastmasters and has started to understand what it will take for him to achieve his goal.
5) Business Vision.
Many architects or architect-wanna-bees lack the ability to present or defend their ideas. It doesn't mean they aren't capable. Sometimes, this is because they lack business vision or do not understand how a business works and therefore cannot understand the reasons why certain steps exist in a process. Or, they miss an entire spectrum of thought for a decision process. Developers often do not need to worry about specifics above their part of the puzzle. People are inclined to stick with things within their comfort level, or stick to technologies that they know inside and out. This precludes them from learning or accepting new things.
If an MBA school is out of the question, here's a few tips that will help all of us to understand how businesses operate:
a) Subscribe to free Industry magazines. I subscribe to about 15 different magazines, most of which are free. Some of the top magazines are CIO, Oracle, DB2, Baseline, CRM, VAR Business, wired, INC, Forbes, Government VAR and Government Executive. Since I still work in the government space, I try to keep abreast of government projects, procurement, etc.
Reading these industry rags helps in many ways. The most important item that I key in on is ROI and the business case. It's easy to postulate about a particular technology but it's harder to justify without all the facts and developing the business case for your presentation. I have found that those who do their homework from the business perspective rarely get cornered during a presentation.
Technically, it helps to justify your idea to a C-level individual when you understand all parts of the concept. Using the earlier single-sign-on example, what will be the required effort to establish single sign on? What is an acceptable workaround for those applications without the ability to work directly with the SSO product? Will the solution pass security audits? What will be the savings or ROI? Will it drive down support costs? Or increase them? Knowing and understanding a basic business case will keep you on sure footing.
b) Join network groups in your area. Even small towns have networking events. This is an opportunity to meet other people in or out of your profession. I believe it is just as important to commingle with those OUTSIDE of my profession as those within. By meeting with people on the outside, you gain insight to your profession by others with a very different perspective. The same holds true by networking with those within your profession. A government employee whose role is that of J2EE architect plays a far different role than a consultant to a multi-national fortune 500 company. Get those two together to talk about projects and I'm sure that conversation would yield some nuggets for all of us to grab. Understand not only the technical, but business reasons for a particular technology choice.
c) Attend events, seminars and conferences. This provides you with the capability to stay on top of your industry. Conferences generally provide a good networking atmosphere. In October of 2002, my company laid a bunch of us off. I decided to attend Integration World 2002 in San Francisco at my own expense. The networking opportunities were awesome. I met with Dan Green, curator of wmusers.com, and many many webMethods people. Less than five weeks later, I was on a plane heading to Sydney, Australia. I ended up working with the Australian contingent that I met at Integration World. I didn't win the job at Integration World, but it gave me the ammunition I needed to position myself for the work in Australia.
6) Lack of Processes. Individuals that come from smaller companies often lack rigid standards or processes. When transitioning from a small to large company, these processes are often viewed as archaic, cumbersome or outlandish. The ability to understand these process models can be a huge factor in the job you are trying to land. Software Change Management, version control, quality assurance are among some of the key processes that drive enterprise architecture and implementation.
A key ingredient of some large organizatations is the use of the Capability Maturity Model. This standard is met by most of the large defense contractors for the U.S.
The CMM standard was developed by a coalition of industry, government and the Software Engineering Institute to objectively assess the full range of an organization's software and systems engineering, program management and organizational management capabilities.
There are five levels of CMM maturity, each a layer in the foundation for on-going process improvement, designated by the numbers one through five with five being the highest. Higher maturity levels signify lower risks to successful program execution. The BearingPoint Global Development Center has achieved Software CMM level 5.
From the architecture, development and delivery standpoints, this requires more modular processes, more paperwork, very rigorous testing, but in the end delivers in a timely and highly successful fashion.
In the end, the ability to communicate effectively receives the highest level of scrutiny when I interview a candidate.
To break it down, here are some high-level traits you need to look for. Either from the hiring or self-development standpoint, these are the must-haves:
1) Technical Competence. The individual must have experience and knowledge relevant to the level in which they seek to Architect. Most of the architectural engagements I deal with is at the Enterprise level. There's different set of criteria relating to Enterprise-wide designs a Systems Architect or Client/Server architect. There is much more topology to consider when making a decision. For example, if the system in question does not deploy single-sign on, then how will that impact your solution. What happens if the system does use single-sign-on but your system does not support the implementation? You need to fit the level of experience to the level of architecture. A client/server architect has less topology in general to be concerned with. Enterprise-wide architects have security layers, messaging layers, etc. along with the typical people-politics.
Moving past technical competence, what does this leave us to ponder?
2) Clear Communication. This is a major concern and a difficult issue to address either from the interviewee or personal standpoint. First, can the individual articulate clearly in the given language? Does the individual create clear and concise emails or documentation? Does the individual have poor communication skills? Is this apparent in written communication as well?
On my trip to China to work with our Global Development Center, I realized, often too late, that I speak too quickly and use English terms that were not understood. Rather than clarify or ask probing questions, I assumed that I was understood. After a couple of misunderstandings, I changed my approach and was much more successful.
3) Listening Skills. Can the individual listen? Don't confuse the inability of the individual to speak a given language (shyness) with their ability to listen. The skill to listening is tricky and can be difficult. Think of the car salesman who only wants to sell you a car. No matter what you say, he ignores you and persists with the sale (effective sales technique.)
Sometimes, we listen but our brain registers something else. A good way to make sure that what you are hearing is what is being said, is to ask a clarifying question like, "So what you are saying is ____________?" or "So in other words, you mean _____________?", "Is this correct?"
I usually reiterate back a list of bullet point take-aways from a meeting to insure that I do not bungle this important facet of communication.
4) Presentation Skills.
If the architect is presenting an architecture to a client, boss, team or other group of people, the presenter must be able to clearly explain their ideas, defend them, and win over the audience through presentation. You will not win all of the battles, but ultimately, you need to win the war.
I am currently working with an individual who is trying to transition from a lead developer position to an architect position. This is someone who has spent a long career in support and development roles and wants to move up the technical ladder.
While he is technically proficient on webMethods, J2EE, database and other skills, he cannot present his ideas with clarity. He isn't quick on his feet.
So, I had a brainstorm one day, and I had him look up Toastmasters International. They have local chapters all over the US. Their primary function is to meet and help others develop or polish their presentation abilities. He is now attending Toastmasters and has started to understand what it will take for him to achieve his goal.
5) Business Vision.
Many architects or architect-wanna-bees lack the ability to present or defend their ideas. It doesn't mean they aren't capable. Sometimes, this is because they lack business vision or do not understand how a business works and therefore cannot understand the reasons why certain steps exist in a process. Or, they miss an entire spectrum of thought for a decision process. Developers often do not need to worry about specifics above their part of the puzzle. People are inclined to stick with things within their comfort level, or stick to technologies that they know inside and out. This precludes them from learning or accepting new things.
If an MBA school is out of the question, here's a few tips that will help all of us to understand how businesses operate:
a) Subscribe to free Industry magazines. I subscribe to about 15 different magazines, most of which are free. Some of the top magazines are CIO, Oracle, DB2, Baseline, CRM, VAR Business, wired, INC, Forbes, Government VAR and Government Executive. Since I still work in the government space, I try to keep abreast of government projects, procurement, etc.
Reading these industry rags helps in many ways. The most important item that I key in on is ROI and the business case. It's easy to postulate about a particular technology but it's harder to justify without all the facts and developing the business case for your presentation. I have found that those who do their homework from the business perspective rarely get cornered during a presentation.
Technically, it helps to justify your idea to a C-level individual when you understand all parts of the concept. Using the earlier single-sign-on example, what will be the required effort to establish single sign on? What is an acceptable workaround for those applications without the ability to work directly with the SSO product? Will the solution pass security audits? What will be the savings or ROI? Will it drive down support costs? Or increase them? Knowing and understanding a basic business case will keep you on sure footing.
b) Join network groups in your area. Even small towns have networking events. This is an opportunity to meet other people in or out of your profession. I believe it is just as important to commingle with those OUTSIDE of my profession as those within. By meeting with people on the outside, you gain insight to your profession by others with a very different perspective. The same holds true by networking with those within your profession. A government employee whose role is that of J2EE architect plays a far different role than a consultant to a multi-national fortune 500 company. Get those two together to talk about projects and I'm sure that conversation would yield some nuggets for all of us to grab. Understand not only the technical, but business reasons for a particular technology choice.
c) Attend events, seminars and conferences. This provides you with the capability to stay on top of your industry. Conferences generally provide a good networking atmosphere. In October of 2002, my company laid a bunch of us off. I decided to attend Integration World 2002 in San Francisco at my own expense. The networking opportunities were awesome. I met with Dan Green, curator of wmusers.com, and many many webMethods people. Less than five weeks later, I was on a plane heading to Sydney, Australia. I ended up working with the Australian contingent that I met at Integration World. I didn't win the job at Integration World, but it gave me the ammunition I needed to position myself for the work in Australia.
6) Lack of Processes. Individuals that come from smaller companies often lack rigid standards or processes. When transitioning from a small to large company, these processes are often viewed as archaic, cumbersome or outlandish. The ability to understand these process models can be a huge factor in the job you are trying to land. Software Change Management, version control, quality assurance are among some of the key processes that drive enterprise architecture and implementation.
A key ingredient of some large organizatations is the use of the Capability Maturity Model. This standard is met by most of the large defense contractors for the U.S.
The CMM standard was developed by a coalition of industry, government and the Software Engineering Institute to objectively assess the full range of an organization's software and systems engineering, program management and organizational management capabilities.
There are five levels of CMM maturity, each a layer in the foundation for on-going process improvement, designated by the numbers one through five with five being the highest. Higher maturity levels signify lower risks to successful program execution. The BearingPoint Global Development Center has achieved Software CMM level 5.
From the architecture, development and delivery standpoints, this requires more modular processes, more paperwork, very rigorous testing, but in the end delivers in a timely and highly successful fashion.
In the end, the ability to communicate effectively receives the highest level of scrutiny when I interview a candidate.
posted by Ray Moser at 10:47:00 AM
0 Comments:
Post a Comment
<< Home