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.
add a comment

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

Is a Customer-Oriented IT Necessarily a Good Thing? July 11, 2009

Posted by wrivkin in Enterprise Architecture & Business Transformation.
2 comments

Some time ago, I blogged about the fact that the best CIOs, according to the definition of CIO Magazine, used in their interviews different methods and approaches to describe their success.  The criterion of this success was quite uniform though: cutting costs.  Recently, I have re-read some of those interviews and found another criterion common for many CIOs: making their IT department more customer-oriented.

By the customer, and this is very important, they meant the external end user of the company. At first glance, this conception seemed viable: what, after all could be wrong if IT is more customer-oriented? Isn’t it the customer whose satisfaction defines a company’s success?

Now, giving it some thought, I am not sure that it is that simple. Let us analyze it and let us, for a change, do it based not solely on opinion, experience, best practices, or other kinds of guesses that are very wide-spread in the IT community today, but rather on an objective, unambiguous approach called Enterprise Development Methodology[1]. We are using this approach to avoid adding just another opinion in an IT world suffering from an overabundance of opinions.

Briefly, EDM considers Enterprise as an object fully described by its features, represented by Enterprise Architecture, and its behaviors, represented by the processes happening within, without, and with Enterprise. Namely, these are Business Processes (BP), Business Process Development Life Cycle (BPDLC), and Business Transformation (BT). The first two of these behaviors: BP and BPDLC are of the most interest for us now.

As it is defined by UML, the end customer is the most important external actor receiving valuable results from BP. So, our goal should be to make our BP as customer-friendly and mutually beneficial as it can be.  But who in an Enterprise is responsible for that? If an Enterprise has a Business Management and Business Analysts, then the answer is obvious: they are.

However, one may ask:”So what? What bad could happen if a company has both a Business and an IT department that are customer-oriented?” The answer is: chaos. If the IT department considers external customers as their clients, it means that it ignores Business as such. The understanding of customer needs and their implementations might be very different within those two departments, because they speak different languages. As a result, an IT department implements not what Business wants, but what IT thinks the customer wants! And this is far from the same thing!

This approach could create an informational abyss where an informational gap was before: between Business and IT.

So, what is the right approach? It is for IT to be BUSINESS-, not CUSTOMER- oriented. Everybody in an Enterprise should do what they are supposed to do. Business should try to improve BPs to satisfy the customer, and IT should create effective and efficient informational simulations of these processes. IT must consider Business as its one and only client. A company should follow BPDLC[2] to achieve smooth inter-operations of its departments and teams to the utmost benefit of both itself and the customer.

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


[1] W. Rivkin Technology Does Not Matter, Methodology Does. SOAInstitute.org, March 10, 2009

[2] W. Rivkin. Closing the Business-IT Gap Once And For All. BPMInstitute.org, December 12, 2008