Friday, June 21, 2013

Car Designer, Auto Mechanic, Car afficianado or Taxi Driver?


One very fine, very early spring morning I was driving to Union Station in Washington DC to drop off my guests who were taking an early train to New York. Living more than twenty miles away, we rarely go to Washington and even more rarely to Union Station. My daughter had taken the GPS and I was on my own with a few remembered landmarks, a tremendous faith in the city's road signs and confidence in my quickness of reaction from 45 years of driving. I had also given us plenty of time to fold in the allowance for mistakes and false turns.


As I headed down Interstate 66 and crossed the river, I made my first mistake. Instead of staying on Constitution Avenue which was the continuation of I-66 as US 50 I veered off to the right and wound up by the monuments headed towards Independence Avenue. Before I knew it I had veered off some more and found myself travelling into the tunnel and I-395 with the prospect of being marooned in Southeast DC and the dreaded Anacostia area with the housing projects.

The clock was ticking inexorably for the departure of my guests' train. I mumbled something about putting them in a taxi if we reached a point of no return in our journey towards Union Station by a certain cutoff. As we drove, my eye caught the AMTRAK symbol sitting below the Massachusetts Avenue exit. To change three lanes and take the exit was the work of a moment.

As I grimly followed signs to Union Station, I was able to hang in there and get to the station with a little more than an hour to spare for the train to depart. Two happy guests bid goodbye and went off to take their train.

What does this story have to do with enterprise architecture?

Knowing how to operate the car was the least of my problems. Whether I was driving my own car, or my wife's or my daughter's, I was equally comfortable. The problem was the ability to plan, correct, navigate, constantly redirect and correct, recover from mistakes, and interpret and use information to make decisions. A combination of all of these were required for me to reach Union Station.

In the EA and architecting industry we hire people for the cars they know how to drive! Today, most architecting organizations hire people because they have Provision knowledge or System Architect Knowledge or Troux or Mega or.. They know how to operate the car. But do they know, during the course of a architecture project, how to plan, correct, navigate, constantly redirect and correct, recover from mistakes, and interpret and use information to make decisions?

We also hire System Engineering experts and practitioners to help us drive to Union Station.

Systems Engineering is the process of building the car and is even more removed from driving or operating the car. Systems Engineers should be working at General Motors and not as taxicab drivers. In the US, we appear to be using System engineers to also help get the enterprise "to Union Station and then on to New York". When we hire for knowledge of System Architect 11.0, we are hiring drivers very knowledgeable in operating a Ford Taurus 2012 Model to help us get across a town that is strange to them. We need to rethink the skills for architects. And we wonder why enterprise architecture projects are not successful or any different from systems engineering!

An experienced driver with knowledge of many roads and cities but also with the agility to "observe, orient, decide and act (OODA)" is a tremendous asset to an enterprise!

No comments: