Documentation Trivializes Everything

June 5, 2017

Several years ago my colleague Dan wrote about how we Should Not Get Distracted by the Document. Dan made the case that architecture documents are tools to figure out architecture, not the ex-post-facto results of architecture design you’ve already done in less disciplined ways (verbal debates, email chains, “brainstorming” and other adhoc, document-less activities).

But I am going to one-up Dan right now by declaring that focusing on documentation absolutely trivializes what we do as architects. Read more



Know Your Personality

May 22, 2017

5 years ago I wrote that the best personality to have in architecture consulting was the “Type A” – a personality type characterized by ambition, high energy, competitiveness, and thought to be susceptible to stress and heart disease. The whole Type A/B model of personalities isn’t a very reliable one (it was concocted by cardiologists in the 1950s), but I went with it since it is still in colloquial use, and was close enough to my meaning.

This is what they call “Passive-Aggressive”

The point was to stress the importance of being aggressive and/or assertive at the right times during your IT consulting work, although this is not always the right way to be. Knowing when to turn on your Inner Hulk, or your Inner Milton Waddams (the wimpy guy with the red stapler in the movie, Office Space) depends on where your baseline is.

So here is some wildly conflicting personality advice that will or will not apply directly to you. Read more



The Art of the Recap

November 7, 2016

If a meeting occurs, but nobody sends a recap, did the meeting happen?

We have blogged about the importance of a meeting recap, but spoke more of the practice of using meeting recaps and less of the art of creating a good recap. We do have internal guidelines that we follow, but through our mentoring process we also attempt to build expertise beyond the template and guidelines. This is my attempt to share some of that company lore. Read more



“Who” Creates Risk

September 15, 2016
Costello: Well then who's on first? Abbott: Yes.
Costello: I mean the fellow's name. Abbott: Who.
Costello: The guy on first. Abbott: Who.
Costello: The first baseman. Abbott: Who.
Costello: The guy playing... Abbott: Who is on first!

Today’s blog is triggered by the entry authored by my friend and colleague, Ben Sommer, reflecting on the laziness of describing architecture with pronouns. In our roles as architects, IT strategists, or just technical leaders guiding successful project implementations we frequently find ourselves defining plans and parceling out tasks.

Read more



Don’t Hide Behind Pronouns!

September 1, 2016

“Ya know…we send them stuff”

Let’s admit first off what none of us want to admit – that most of us have forgotten what exactly a “pronoun” is…

Its basically any use of “you”, “we”, “them”, “they”, etc. – unspecific references to people or actors in a conversation or past event being discussed.

Believe it or not – the lazy use of pronouns is a huge problem in the field of IT architecture & design, and even business analysis.

Example:

  • Bob is a project architect at a college facilitating a workshop for the design of an interface between two systems
  • In describing the current flow of information between the two systems, Bob states that “We send them a file nightly”.

Who is “we” and “them”? Bob needs to specifically state it. Read more



Value-driven Status

July 4, 2012

If you work in a professional environment, you inevitably have to communicate the status of your work to your manager. If you are in the professional services business, then you have an even tougher “manager” – your client.

Read more



The Solution Architect’s Path to Success

April 11, 2012

Welcome to today’s blog. Sit back and relax. Close your eyes. Take some deep relaxing breaths. Envision a Utopian architecture project delivery:

  • Scope is clear and agreed upon,
  • Requirements are carefully crafted,
  • Read more


Some Task Management Tips

February 29, 2012

I previously shared a simple method to conquer the task management beast in An Old School Method for Task Management.

Beyond the basic methodology, I do have some specific pointers that help me, many of which I have extracted from the many task schemes that have not worked out for me (many of the ideas come from David Allen’s Getting Things Done approach). Read more



An Old School Method for Task Management

February 23, 2012

Organizational capability is a core competency for an architect, if not for any human being who wants to be remotely effective.

Read more



The Venn of IT Solution Success

December 27, 2011

Changing technology in an enterprise requires that you have the following “must have” skills in your people:

  1. Leadership & organization
  2. Business acumen
  3. Technical chops

Normally, labor in a project is divided up according to these specialties – i.e. developers have the technical chops, business analysts have the business chops, project managers organize themselves and everyone else. Throw them all into a pot, stir vigorously and…presto! A successful project.

Hardly. Read more



Next Page »