The Day that Star Trek Died

By |2011-01-29T01:55:34+00:00January 29th, 2011|Enterprise Architecture|

Twenty five years ago, the Space Shuttle Challenger exploded shortly after lift off, killing seven astronauts.  But for me, that explosion over Cape Canaveral took away Captain Kirk, Spock, Bones, and all the other denizens of the United Federation of Planets.

I grew up with Star Trek.   My parents divorced when I was 9, so I don’t have a long memory of happy times in my house, but of the times we did have, Star Trek held a kind of magical memory.  It was one hour, each week, when we all sat quietly and watched our “big” 20-inch black and white television.  It was one hour when we could see a vision of the future, where people weren’t rioting about the color of their skin or their country of origin, where money wasn’t the only motivation for smart people to succeed, and where intelligent, passionate people followed higher ideals than self interest.  I wasn’t the only one watching. 

Dr. Ronald E. McNair was also watching.  He, too, had grown up watching Star Trek, and imagining what it would be like to be an astronaut.  One big difference: Dr. McNair was black, and he grew up in the segregated city of Lake City, South Carolina.  On Star Trek, he saw white people and black people working side by side.  As his brother Carl told Storycorps years later, Star Trek’s hopeful vision was one of the inspirations that led him into science (where he became and expert in quantum electronics and lasers) and then into space as a mission specialist.  He was the second black man in space in 1984, when he flew aboard a previous Challenger mission. 


In 1986, I was a young software developer.  I’d been working with computers for many years by then, including such golden oldies as the IBM 370, the DecSystem 10, and the HP/3000.  These were also the early days of the microcomputer.  I had the opportunity to spend some time, (but very little professionally), on the Kaypro, the Compaq Portable, and of course, the IBM PC.  I was employed at a small manufacturing company in Tennessee called DeRoyal Industries.  They made a variety of different medical products, from orthopedic braces to surgery trays.  They also had a small software division, where I worked to create a product for hospital operating rooms to allow them to schedule surgery efficiently.  It was all on Unix System V, running on an AT&T 3B2/400 minicomputer.  In those days, the word “hacker” was a compliment, Zork was cool, and we were thrilled to use the UUNET to make computers talk to one another.

But America was no longer investing in Space.  In constant dollars, the budget of NASA in 1986 was one third that of 1966.  America was losing interest.  The drama was gone.  In 1984, President Reagan placed a challenge at NASA’s doorstep: build a permanently manned space station, but he didn’t increase NASA’s budget to make it happen.  So, when NASA went on a nationwide search for a teacher to travel into space, they wanted to add some interest, especially from children.  The idea was to capture the imagination of the next generation of astronauts, just as Apollo had captured me.

So, on the morning of January 28, 1986, millions of schoolchildren were tuned in, and television stations around the country were all showing the launch live.  After all, a teacher was onboard.  She was one of us.  We all sat in awe as the countdown reached zero, and the rockets fired, and the shuttle gracefully headed toward space.  And 71 seconds later, we all watched in horror as the solid rocket booster exploded, destroying the Challenger and her seven-man crew: Francis R. (Dick) Scobee, Michael J. Smith, Dr. Judith A. Resnik, Dr. Ronald E. McNair, Ellison S. Onizuka, Gregory B. Jarvis, and Sharon Christa McAuliffe, the first teacher in space.

I was heartbroken.  It was the first time we’d lost a mission.  It was the end, for me, of the dream of space that had started with Star Trek.  After that awful morning, no one spoke of NASA with the hushed tones of awe that I remembered from my youth.  Now, it was only talk of price tags, and O-Rings, and the failure of NASA to deliver on Reagan’s (unfunded) challenge.  NASA was no longer a place I wanted to work.  Visit, yes.  Support, sure.  They were the only game in town.  But to work there, or become an astronaut… that dream died in 1986.  For me, that was the day that Star Trek died.

Crew of the Space Shuttle Challenger

In the white space between stakeholders

By |2011-01-10T01:06:27+00:00January 10th, 2011|Enterprise Architecture|

The more time I spend as an Enterprise Architect, the more I realize just how important this role is.  Yet, the stories that we tell fail to bring across that value.  Our metaphors (framework, capability, roadmap) are woefully inadequate to communicate the actual problems that are solved when an Enterprise Architect is “in the house.”

The metaphor I’m starting to lean toward is this: Enterprise Architecture is the art of understanding the white space between stakeholders.

Of course, this is not a new metaphor.  BPM folks have been using the concept of “white space” for a while.   BPM professionals usually use the term “white space” to refer to the gap between process steps.  That gap is important to the Enterprise Architect as well, but the EA does not stop with the gap between business processes.  An EA is also interested in the gap between business entities (information), the gap between business functions (business), and the gap between integrated systems (integration).

What do I mean by “the white space between stakeholders?”  It is a combination of many things:

  • White space is the gap in alignment between what one person expects will happen and what another person decides to do. 
  • White space is the gap between the way that information is understood and the way that it is actually collected. 
  • White space is the gap between the business function that is responsible for achieving results and the business function that performs both necessary and unnecessary activities in support of those results. 
  • White space is the gap between the performance characteristics of a system that exists and the changing needs of the people who use it.


Enterprise architecture is not the art of bridging any one of these gaps.  Solving for only one variable is a sure route to suboptimization.  Enterprise Architecture seeks to rebalance the tradeoffs between the various variables, creating a new mix of performance characteristics that is better suited for the evolving needs of the business.  The “old” tradeoffs are not wrong.  The business has simply evolved to need a better mix than exists today.

This is not to say that EA is somehow “better” than the related arts of BPM or System Integration or Information architecture.  EA identifies what variables need to change, and the direction to change them.  The related arts are necessary to get us there.  Enterprise Architects are not the people to actually improve the processes or reconfigure the information or reintegrate the systems.  They are the ones who force us to look at our goals and using analysis methods, pick the variables to change: this goal can be reached through a combination of better processes and improved systems, while that goal can be reached through restructuring the information that we will collect and changing the boundaries of various business functions. 

Enterprise Architecture lives in the white space, pulling and pushing and reconfiguring.  We are the “rack-and-pinion” system in your car.  We don’t decide what direction the car should go, but if you want to change course, it is a lot easier to use an accurate and responsive steering mechanism than to hoist a sail and move the boom.