jump to navigation

Why Did We Get Fired? – Real Life Example #1 July 23, 2009

Posted by wrivkin in Enterprise Architecture & Business Transformation, General Creative Thinking.
trackback

OK, no more ‘philosophy’ regarding the importance of Enterprise Methodology, just bare, naked, real facts (those who have Methodology –phobia may stop reading and probably get fired in the near future).

In 2006 I was hired by a regional telecom giant – a daughter company of a former super-giant – as a consultant to oversee the results of their three-year-long Business and Architectural Transformation initiative. Ring a bell? OK.  Let us call the company SEB.

The Enterprise Architectural Transformation part of the initiative was outsourced by SEB to one of the major (Big X) consulting companies. Let us call it Acupuncture.  It would be completely wrong to say that during their three years in the initiative Acupuncture did not provide SEB with any Architecture. On the contrary, it even provided them with several ones. Moreover, Acupuncture provided SEB with several types of architecture, elegantly designed as separate, hardly related silos. There were Legacy silos, ‘spaghetti’ silos, ESB-based silos, you name it. Everybody on the client side, with any tastes and preferences, felt and indeed was served! I counted five types of ESB’s only (of course completely different and separated from each other)! I would call it a perfect example of an Architectural Sampler if not for the poor real company doomed to work with this architectural jungle. Bottom line, for me it was a feast of methodological and architectural idiocy!

Now, it would be unfair to say that methodological idiocy was completely Acupuncture’s prerogative. The client’s side completely and enthusiastically shared and in supported it and, moreover, added its own unbelievable dabs to this chef d’oeuvre of surrealism. For example, having no notion of Business Process Orientation and, as a result – no idea of how to meaningfully (from the methodological point of view) divide all needed functionality changes and enhancements into projects, they invented (at least for me) the term Track.

They divided the whole mass of changes for every release to an arbitrary number of Tracks (exactly like the rabbi from one of my previous posts!).  Each track had the same six-month project time-span.  Among those tracks, which I witnessed, were some quite complicated projects, like the complete outsourcing of their website to a service provider. It was, though, a different one that astounded my imagination.

It was a full-blown six-month Track, comprised one incomprehensible task: to change the consumer price of one of SEB’s services from $32.99 to $29.99!!!???

When the stirring committee started discussing this Track, I honestly was speechless for a while. Upon the return of this ability, I humbly asked the meeting-room’s audience, which consisted of systems’ and domains’ owners: “Why, for God’s sake, do they need more than three days to change a reference table’s field value and to test this simplest of changes?” The answer to me was silence. My second question was: “OK, maybe nobody can vouch for the whole process chain; however, could any system’s or domain’s owner say that inside his/her system this so called ‘change’ (one number for another with the same format) will probably not cause problems and is easy to test”? Nobody could!

After several more speechless seconds, during which I had been realizing all the possible consequences of such a situation, I asked: “You are making this change because your cable competitor has already made it. Do you think that your Business can wait six (!) months for such an elementary change? Silence again, like in the desert at night. Next question: “What is the problem, as you see it?” Finally a weak anonymous voice: “It is too complicated”. Voila! “It is too damn architecturally complicated!” OK, baby, say ‘thank you’ to auntie Acupuncture!

I spent the next several days talking to some Architectural and Managerial decision makers, trying to explain to them that such an architectural situation is unbearable from the Business point of view (putting aside such minutiae as a multi-million-dollar IT project to change a reference field!). In return, I got some polite answers, whose translation into real English was: “Who the heck are you to teach us! We are SEB! We have been doing this stuff for years, exactly as our parents and grand-parents did!”

Bottom line. In three weeks (!) the company was sold; in three months the whole project was halted, $500M were thrown out the window (except for what ended up in the pockets of Acupuncture, of course), and 10,000 SEB people were fired. It all happened during the economic boom, not the recession.  There were no objective reasons for a failure of these proportions, just the usual methodological incompetence, arrogance, and ignorance. If SEB’s people understood that their business complexity had changed and their grandparents’ methods are now irrelevant anymore, if they had just tried to think about HOW they need to organize their business, including IT, to really achieve WHAT they needed at this new, higher level of complexity; if their upper management had been methodologically astute…

It is July 2006… I am sitting alone on the 16-th floor of ESB’s 42-story building.  It is incredibly hot, but technicians some days forget to turn on air-conditioning on that floor, and I need to make call after call, convincing everybody that there is still a (too) warm body on the floor that was full of probably hundreds of bodies and minds just some weeks ago. My opponents are long gone. The last days after their disappearance they blushed and stared at the floor when occasionally meeting me in a hallway (there were no more business meetings, of course). Soon I will be gone too, after finishing my semi-meaningless job of choosing the architectural artifacts of the late Great Initiative worth preserving just in case… The new owners are coming. They think they do not need me or anybody of my kind. They are full of enthusiasm to do things the way their grandparents did. I think they will probably re-hire Acupuncture.

There is a saying: “smart people learn from somebody else’s mistakes, while fools from their own ones”. What would one call people who are simply unable to learn from anybody’s mistakes whatsoever? IT Technologists?

The methodological chaos in the formulation and implementation of Enterprise Architecture must be overcome! Carthago delenda est!

Advertisements

Comments»

No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: