Type A’s Needed!

We write frequently on this blog about our proven method to deliver IT architectures based on industry-standard tools and approaches like UML and IT Risk Management. We also write about the critical intangible skills that an architect needs to succeed, such as meeting facilitation, diplomacy and organization. One needs to be steeped in all these areas – as well as to form a strong “magic triangle” of technical/business/management skills to really succeed.

Skills, experience, and methods alone, however, are not enough to get the job done right.

Assertiveness and Aggressiveness

You may recall from your introductory college or high school psychology class one theory on the three archetypal attitudes:

  • Passive
  • Assertive
  • Aggressive

I vaguely remember it being insinuated to me by my instructor that assertive was the behavior to aim for. Passive gets you rolled in life, aggressive takes its toll emotionally, and their monstrous offspring passive-aggressive makes everyone’s life miserable and usually hints at buried emotional problems in the “perpetrator”.

This model has stuck with me, but I’ve lately formed my own Pop Psychology re-interpretation that, while retaining Assertiveness as the goal in dealing with people, also promotes aggressiveness in other matters relating to action.

Successful IT Architects:

  • Deal assertively with other people
  • Work aggressively toward meeting goals and completing tasks

There are many other soft-skills one needs for success – including a sense of humor, social and emotional intelligence to tell one when to push or pull, basic politeness and many others. But if forced to pick two personality factors for success as an IT Architect, I would stick with these two.

Though there are many examples I can cite to contrast passive from assertive behavior and the differing results each will get for an architect, I focus on the one most dear to IT workers: Requirements Management. I also pick this because it dove-tails nicely with the aggressive approach I described on how to get IT project estimation done.

Requirements Unclear: To Architect or not to Architect?

A near-daily reality for a working project architect is a lack of clear and unambiguous business requirements upon which to design his architecture.

Absolutely everyone loves to belly-ache about lousy requirements, unrealistic requirements, no requirements, etc. Though it’s true that a software project whose business requirements are in any of the aforementioned states is certainly flirting with failure, its not true that the assigned architect is excused from delivering at least some of his work.

In cases of true stalemate – where requirements are simply too unclear or unrealistic to work from – immediate escalation by the architect to both the project’s leadership and his/her own manager is the assertive thing to do. This is no time to be a timid communicator. Sitting around waiting for the requirements to appear, making work for yourself around the periphery of your true architecture tasks just so you can maintain a holding pattern until those darn requirements show up – neither of these is a safe option. And by “safe” I refer not only job/role security, but also to simple bodily health. Not knowing when and how to vote no-confidence in a project’s requirements will lead to much teeth-grinding and stress.

But in those vast majority of cases where requirements are merely incomplete, or contain ambiguities – even large ambiguities – there is always ample room to begin architecture design by

  • Aggressively drafting straw-man diagram views of the architecture
  • Working from a “most likely outcome” for any ambiguous requirement
  • Making educated assumptions regarding what the business needs on any given point

This is how a successful architect deals with his responsibilities.

The fact is that most “business requirements” are focused on detailed functional aspects of software, and less on higher-level capabilities, which is really what solution architecture needs to address.

This is also how one gets noticed and appreciated, especially by business stakeholders who in the end are paying all the bills. You will rarely be faulted for going too far with your architecture if you clearly state that you are working on assumptions and the good faith that your requirements questions will be answered prior to completing your architecture.

Everyone appreciates leaders, especially if they lead by example and through influence, not through dictates. Working aggressively and assertively at the appropriate times is a great way to lead.

If you happen to be a “Type A” looking for a challenge, check out our Careers page!

Ben Sommer was a Principal Consultant with Systems Flow, Inc. He consultsed in enterprise & solution architecture for large clients. He also led training programs for Systems Flow. His career panned network, systems, and open source software engineering with a focus on identity management. Ben is a trained musician and composer.

Latest posts by Ben Sommer (see all)



Comments

Comments are closed.