Udostępnij za pośrednictwem

Positive and Negative behaviors to look out for in Enterprise Architects

  • Artykuł

I’ve been fortunate to be in a position as a trusted advisor assess individuals during performance reviews as well as to hiring managers internal and external to Microsoft looking for strong architect candidates. For the most part, a lot of my judgment is based on my assertion of a candidates hard and soft architect skills. Hard skills such as architecture design skills and domain architecture knowledge. Soft skills like leadership/emotional intelligence and professionalism expertise. This has been relatively successful but I’ve observed very qualified architects unfortunately limit themselves due to some negative behaviors and I’ve observed others rise unbelievably quickly due some very positive behaviors.

I thought I’d share some of these observed behaviors to help you in your efforts to find successful Architects to hire or partner with.

 

Negative behaviors:

  1. Gossip Train. This is the behavior some conduct when discussions tend to always veer into conversations laden in gossip. You can tell when someone is a gossip train when they quickly begin whispering in a conversation or habitually close their office door when a discussion begins. I find that these behaviors have a tendency to brood insecurity and misunderstanding based on insecurities than actual fact or reality. It also tends to encourage a schizophrenic dynamic in teams.
  2. Passive Resistor. This is the behavior where individuals don’t communicate disagreement directly to those they disagree with. These passive/resistance people then subtly resist via random poking at those they disagree with causing wide-spread disagreement on several fronts triggered from a specific topic of disagreement.
  3. Vague concept with poor execution. This is a behavior where a person has an idea concept and immediately begins executing without a) thinking through the idea concept to ensure it has real value, and b) any sort of plan to know optimal timing of execution or implications through change management. This behavior causes so much fits-and-starts to teams surrounding this individual resulting in randomization of effort and wasted investment of energy to unwind the poor execution.
  4. Hack-itect. We can usually spot the common hack-itectwith some simple interview exercises but occasionally they still slip through the cracks. Essentially, a hacki-tect is a name I use to describe a self-proclaimed architect who uses creative expressions instead of models with deliberate use of notation and abstraction to convey some sort of design. They make it up.
  5. Rebel. This is a behavior relating to individuals who have a natural preference to be different. At the enterprise-level, consistency has tremendous value and impact to an organization. There are times concept, although imperfect but good enough, is often more valuable than a more accurate concept that no one will adopt. Individuals with a rebellious nature can be counter-productive.
  6. Insecurity/Fear of Rejection. This is a behavior that lacks assertiveness. At the enterprise-level we Architects must be able to stand up and be counted. Failing to do so at the right time due to fear of rejection or insecurities results in tremendous lack of credibility and a reputation for being vacillate. 
  7. Megaphones. This behavior comes from individuals that have humongous egos. They tend to like the sound of their own voice. They are the first to publicly announce (maybe via a personal blog) anything with the possibility of being trendy for the purpose of taking credit. They like to lay claim to new concepts for the purposes of claiming authorship even if they seem suspiciously similar to existing concepts. There seems to be a strong affinity to Rebellious behavior as most Megaphones prefer to work alone and struggle to enjoy working in teams.
  8. Role-blindness. This behavior is demonstrated in the unfortunate individual who isn’t always cognizant of the role they play or the roles they interact with. The result is being out-of-role, engaging at the wrong levels, or asking the wrong question. Often, these individuals are misunderstood and confused why they don’t get the traction they deserve. My heart goes out to these individuals. I find that they are sorely under-valued. If it’s an consolation, when I get the opportunity to mentor individuals with this behavior, Stephen Covey’s Seven Habits of Highly Effective People is very useful.
  9. Manipulation through Obfuscation. This behavior relates to individuals who intentionally try to win arguments or get acceptance of inappropriate suggestions through fancy-talk or stringing together a series of seemingly important terms to sound knowledgeable while having an expression of certainly on their face when all along they have no idea themselves. They just want to get passed the conversation. This bit of obfuscation around the actual concept is a manipulative technique. The amount of effort caught-up in churn and unwinding the obfuscator’s trail of acceptances can be tremendous.
  10. Due-it-yourselfers. This is the behavior of individuals who are particularly bright and think they can do it all by themselves. These are individuals who are skilled in one architecture domain and feel they are qualified to represent all other architecture domains. At the enterprise-level, this is unbelievably naive. We need segmentation of architecture responsibilities and collaboration to make the whole enterprise function. No one can do it all.

 

Positive behaviors:

  1. Leadership: Openness and Honesty. This is very powerful behavior and one we very much appreciate. Being an Enterprise Architect can be very challenging. We are often in high-level discussions that affect broad audiences. Giving critical feedback while maintaining a professional image is something successful Enterprise Architects do.
  2. Rigor. Successful Enterprise Architects exhibit behavior of architectural rigor in their work often when modeling and during their industry analysis. They tend to search for best practices and test new concepts against academic knowledge. This type of behavior adds integrity to their architecture deliverables and raises the quality of their work.
  3. Architecture Purity: Architects NOT Analysts. Enterprise Architects must be able to provide evidence of architectural decisions. The most successful Enterprise Architects are able to trace a decision back to the independent data entities in a well-formed data model based on architectural rigor and enterprise taxonomies to justify an assertion. Using subjective analysis based on homegrown analysis methods do not fare well. Enterprise Architects that exhibit behavior of basing judgments and assertions on architecturally pure methods tend to fare far better than analysts.
  4. Simple and Accurate. This behavior relating to an Enterprise Architect’s ability to understand the complex and make it simple. Some of the most successful Enterprise Architects have the behavior to naturally refine and simplify. It’s a habit to them. Mind you, all of the simple results are traceable back to the origins of complex models, but only the expert Enterprise Architects need to know that.
  5. Collaborator. The great Enterprise Architects collaborate effectively. They fully appreciate and build co-dependent partnerships. They help others fulfill their roles to deliver enterprise-wide impact in a concerted mutually beneficial manner.
  6. Articulate. This behavior relating to an Enterprise Architects ability to understand the complex and make it simple for the sole purpose of articulating it to various groups at various levels of the organization. They are self-confident and resonate meaning to their audiences. They are clear on their simple message being absolutely accurate and can trace their words back to an architecturally pure, and often complex, model.
  7. Story teller. This is the behavior that successful Enterprise Architects exhibit to resonate and pass along knowledge and experience. They leverage metaphors and analogies to explain complex concepts. They keep the message in focus always progressing from problem to cause to solution.
  8. Mentor. The most revered Enterprise Architects are guides. They maintain an innate responsibility to grow others. It helps them scale and build momentum for the purpose of broadening their impact to the enterprise.
  9. Respectful. The strongest Enterprise Architects recognize we are all part of the machine. Each individual is a cog with a purpose. Each individual taking on a difficult responsibility for the greater whole. Respect for each individual empowers them, therefore, empowering the machine.
  10. A sense of humor. For the Enterprise Architect, the highest-level Architect responsible driving toward the proverbial future state architecture through numerous challenges from all directions, change can seem slow and inevitably frustrating. The successful Enterprise Architects can always find humor in it all. :)

Comments

  • Anonymous
    March 29, 2010
    Hi, Your blog is great. Can you help app archs to take next step towards enterprise architecture. Some good  references or starting point would be great. For example : Is Zachman framework a must learn ? If not what are other desirable and must reads? Thanks

  • Anonymous
    March 29, 2010
    Hi Ian, I get this question a lot. The truth is that there is no definitive curriculum for becoming an Enterprise Architect. Every year I hear of rumblings from Universities that are forming Masters programs and the like for one to get a degree in Enterprise Architecture. I’ve never seen the results so I can’t comment. I also know of several certifications to gain an accreditation on Enterprise Architecture. I’ve never gone through a certification course nor do I have any Enterprise Architecture certifications under my belt. So, unfortunately, once again I can’t comment on them either. I can say that Enterprise Architecture is an incredibly young discipline. I find gaps in every one of the popular Enterprise Architecture Frameworks and Methodologies out there. Btw, many of the gaps are sometimes due to the framework themselves, however, some of the gaps are caused in a lack of rigor and consistency of ‘the enterprise’ which the EA Framework is applied. My favorite example to illustrate this gap is Business Architecture. How many different flavors of Business Architecture are out there? Tons. Maybe its because ‘business’ is conducted differently across all enterprises? You think? :) Sorry that I don’t think this was the answer you were looking for. I’ll try to be more helpful. In my limited experience, I’m a fan of Solution Architecture backgrounds. I mean Solution Architecture as in the Microsoft Solutions Framework role description. That is a fundamental skill set in my opinion. To make the transition to Enterprise Architect, one must have the skills to model all lines of businesses in an enterprise, be able to derive information models and system models to support them, and be a leader to make the necessary changes to realize the architectural vision.

  • Anonymous
    May 14, 2012
    This a fantastic article and certainly one that will "stand the test of time", in terms of insights shared.  I continue to strive and to grow within the EA discipline and your thoughts on positive/negative behaviors are things I will take to heart and carry with me going forward and make part of my "continual" self improvement plans. Excellent!

  • Anonymous
    April 19, 2013
    Back here again... using the wisdom here as a guide, as a compass to avoid certain pitfalls, and yet embrace new opportunities to grow.  I've said it before...this is pure gold!