jump to navigation

The Magic Cure or the Poisonous Alphabet Soup? April 10, 2010

Posted by wrivkin in Enterprise Architecture & Business Transformation, General Creative Thinking.
add a comment

This post is the reaction to the article by C. Bernstein in “Baseline” magazine (*) , where the author, in her turn, reviews the study: “IT Governance and Control: Making Sense of Standards, Guidelines and Frameworks,” which was prepared for the Society for Information Management by Sue Conger, an associate professor and director of IT and IT service management at the University of Dallas, and Ulrike Schultze, an associate professor at Southern Methodist University.” “It shows – the author of the paper writes – considerable overlap among the frameworks, even though they emphasize different aspects of IT processes and use different vocabulary and conceptual schemes.” The author and the study are talking about CMMI, COBIT, ISO 20000 and ITIL frameworks.

SIM’s Advanced Practices Council report, which is based on five case studies and uses a cross-referencing tool for mapping the frameworks, shows that IT organizations use process frameworks for different reasons…” says the article. Without any clue for the real purpose of this ‘soup’, add I. Why? Because nobody, including the ‘cooks’ seemingly have this clue.

Why?! Anybody, at least somewhat familiar with those “alphabet soup” frameworks knows that their primary goal is to describe IT processes for non-IT, technologically-illiterate managers. They are trying to describe IT as a ‘black box’, considering what is going on there as some abstract and agnostic ‘processes’. So what, ask you: isn’t you yourself a proponent of abstraction? Yes, say I, but on the specific abstraction level. A framework should be abstract, where it should be abstract, specific, where it should be specific, and its author(s) should have knowledge to differ the former from the latter.

Moreover, there are different levels of abstraction itself: philosophic abstraction – scientific abstraction – framework abstraction – framework layer abstraction. To retain the same level of abstraction throughout the whole framework means really describe or resolve nothing. This is why this CMMICOBITISO20000ITIL framework turned into pure bureaucratic a*s covering, along with their architectural sister FEAFDODAFTOGAFZEAF.
Exact knowledge, corresponding to the level of a framework: this is the recipe, this is the cure.
So, do not try a soup before being knowledgeably convinced that it is good for you.
*C. Bernstein. (2009) The Alphabet Soup of Process Frameworks , Baseline, Issue 99;

Will There Be a Next Generation of Enterprise IT Leaders? April 5, 2010

Posted by wrivkin in Enterprise Architecture & Business Transformation, General Creative Thinking.
add a comment

A year ago I blogged about the ‘CIO Insight’ magazine’s editor Brian Wilson’s worrying about “Disappearing CIO”, and how CFO often replacing them to just cut off IT’s cost by any means.

A year has passed, and recently I have participated in the discussion at LinkedIn.com: ‘Will the CIO Lose the C?’, co-authored with John Sviokla, who wrote:

“There is some disturbing new data for the role of the CIO. Thomas Wailgum of CIO.com says, “Given the… warning signs, it’s easy to speculate that the CIO’s role and the department’s sovereign power might be slip-sliding away.” Half of our Diamond Digital IQ Survey respondents said that more than 30% of the dollars spent on IT is done outside of IT. Power in any organization usually follows those who can create new revenue and value, but our survey shows that 75% of the CIO’s innovation role is internally facing”

I have answered to this discussion:
“Yep, they will, but only if, … If they and their boss CEO, and their peers CXOs will not acquire some open mind, common sense, and, most importantly, the exact knowledge of what does it mean to be responsible for the Enterprise Digital Information Processing (DIP).
Let us ask ourselves: Why is it CIO, not CTO is in danger? We all know that technology per se is being more and more commoditized, quickly going into Cloud? On the other hand, the volume and complexity of INFORMATION to be processed by an Enterprise is growing almost exponentially. And so is the value and the criticality of the effective and efficient processing of this information. And the role of the guy, who is responsible for this crucial element of the Enterprise Business Model is … right, being diminished more and more !? It is utmost logical.
Why?! The answer is very simple and pitiful: Because all these CXOs, including CIO, have no idea how to process this information effectively and/or efficiently in the case of the modern, extremely complex Enterprise. This is why, just because they do not know better, these idiots (sorry, didn’t you know that CXOs could be idiots like everyone else? Yes, they are mere mortal) turn IT into a cost center and let Finance guys to kill it by blindly cutting the costs without any idea, whether what they are cutting bring revenue or competitive advantage, or not. Why? Because they do not know how to identify that.
Is there somebody, who knows? Yes, some people do? One example is myself. So, good riddance from IT, and ahead to Cloud we go”.

Then, I had considered the issue more or less clear. However, a couple of days ago, I read in the freshest issue of the ‘CIO Insight’ magazine (a year after the aforementioned article (!), another curiose one: ‘Building the Next Generation of IT Leaders ”, with such a motto:
“Organizational politics, patience and pragmatism all play key roles in helping CIOs to develop next-generation IT executives” (?! W.R.)

It is not a surprise that with such a level of expertise, and simple sanity of its authors, the magazine now is published once in a quarter. It is a surprise that it is published at all!
What CIOs? The ‘disappearing’ ones? What ‘next generation’ when it is evident that without any precise knowledge and expertise about their profession, replaced by “organizational politics, patience and pragmatism”, these poor people will never stay a chance to preside over non-yet-existing in-house Enterprise IT, which migrates to Cloud long before their generation will have an opportunity to have any job in this in-house Enterprise IT, let alone the mythical then role of CIO?

They reject even notion of knowledge, they contradict to each other, not reading or ignoring each other’s articles. Once a week, once a month, once a quarter, then ’neverrmorre’ – the periodic for morons is disappearing with morons themselves.

I now call them “CIO-Outside”. Ziff Davis, Brian Watson, Steve Weitzner. Remember their names. It is them, their ignorance and arrogance, who killed any chance for in-house IT. Well, good riddance. The picture of T. Hoffmann looking for another job warms my heart.

Talleyrand has once said about French aristocracy: “They have forgotten nothing and learned nothing .” Well, the majority of our IT aristocracy has nothing to forget, for they always knew nada, and they have now neither time nor ability to learn anything.

The Emergence of the Super-prise December 3, 2009

Posted by wrivkin in Enterprise Architecture & Business Transformation, General Creative Thinking.
add a comment

At all our discussions about Enterprise, we seemingly did not pay enough attention to the emergence of a new, higher form of commercial or social organization: a business-wise or administratively tightly bound conglomerate of Enterprises. Such a conglomerate can take the form of a private-sector (multi) national corporation, comprised of several Enterprises, each of which has a different Enterprise Business Model (EBM), or a government structure that includes sub-structures of the Enterprise level of complexity (so called Segments)  that have little to nothing in common (e.g. the  DoD and the Department of Agriculture).

It is not a goal of this article to discuss the reasons that led to creation of such conglomerates. In the case of government, these reasons just reflect the complexity of the whole hierarchy; in the case of the private sector the reasons were and are pure of the business nature, which put them out of the scope of this consideration.  Our goal is to recognize these conglomerates as a reality and to consider whether their current level of effectiveness and efficiency may be improved via Architectural analysis.

It is also not our task to recommend or to oppose the unification of the elements of such structures under single governing body from the business or costs values points of view. They are just here; they emerged as a next phase in development of their organizations, and our task is just to analyze them.

To their benefit, the government has reacted first to this new reality, now considering its different sub-entities as independent but architecturally related Segments, united under the umbrella of Federal Segment Architecture Methodology (FSAM). They have defined segment architecture as a ‘detailed results-oriented architecture (baseline and target) and a transition strategy for a portion or segment of the enterprise’[1] “, while Segments are: “Individual elements of the enterprise describing core mission areas and common or shared business services and enterprise services.” A graphic interpretation of the relationship between overlaying Federal Enterprise Architecture and Segment (Agency) architecture can be seen in Figure 1.

Figure 1 FSAM Segment Architecture

Originally uploaded by wrivkin

We are not here to discuss the methodological and ontological strength of these definitions. Obviously, architecture is not a strategy; Segment and Enterprise Architecture are not entities of the same level, etc. However, at least this framework tries to understand and address an actual and important problem. In the commercial sector a similar framework has not been formulated until now, despite the fact that such structures exist and operate for quite some time already.

Here are two well-known examples of such companies, chosen simply because the author has some personal insight regarding their business structure:

Cox Enterprises®, a holding company, which contains:  Cox Communications, the #3 US cable system operator; Manheim Auctions, the largest wholesale vehicle auctioning company worldwide; Cox Newspapers (17 daily papers reaching 1.2 million readers); Cox Television (about 15 local stations);Cox Radio (more than 80 stations); AutoTrader.com, an online used car listing service.

The Thomson Corporation, includes the following major Enterprises: Thomson Reuters, Thomson Financial, Thomson Healthcare,  Thomson Legal,  Thomson Scientific, Thomson Tax & Accounting.

They represent purely administratively-bound conglomerates of Enterprises having distinctly different Enterprise Business Models (EBM) and operating in different markets;

Let us call such conglomerates Super-prises. Once again, the main distinction between such an organization and other complex commercial structures is that its subsidiaries have absolutely different EBMS. Our goal is to try to analyze and describe the features and behaviors that distinguish them as objects from usual Enterprises, as well as analyze their inter-relations, which form a higher, Super-prise Meta Architecture.

In both cases we can differentiate a Holding Enterprise (e.g.  Cox Enterprise or Thomson Reuters), who’s EBM consists almost entirely of the Business Processes of managing the underlying Subsidiary Enterprises, which , in turn, operate in completely different markets and, again, have absolutely unrelated Business Models (see Figure 2)

Figure 2 represents the Current Super-prise Meta-Architectural State when all the constituents of the Super-prise operate separately, having only parent-child relationships.  They share neither artifacts, nor architectures, nor even principles of building these architectures. Both Subsidiary Enterprises and the Holding Enterprise have different but equally chaotic, ‘spaghetti-like’ Legacy Enterprise Architectures. The usual inevitable task of Enterprise Architectural Business Transformation (EABT) lies ahead of them, as it lies ahead of any Legacy Enterprise, but their interrelation makes this task a bit different.

Figure 2 Initial Super-prise Meta-Architecture

Originally uploaded by wrivkin

Obviously, as in the case of the government structures, this initial state is far from optimal from the Super-prise point of view. And it is the Holding Enterprise that has the most interest in transforming the whole Super-prise to run in the most effective and efficient way.

Let us apply our usual approach to any Architecture as three-level taxonomy of a field to the Super-prise:

  1. (Meta) Architectural level: Interconnections of Subsidiary and Holding Enterprise Architectures; we call this level Super-prise ‘Meta-Architecture’
  2. Architectural (the usual Design) level: The internal Super-prise participant’s Enterprise Architectures;
  3. Design (the usual Primitive) level: the Enterprise’s Internal Business Process & Service Domains;

This taxonomical shift should be easily understood by anyone familiar with our approach to Architectural Analysis expounded in [2].

A Constructional Architecture (CA) project, analogical to such a super-structure already exists; it is called ‘Tokyo Sky City’ (Figure 3).

Figure 3 Constructional Super-Architecture Analogue: The Tokyo Sky City

Originally uploaded by wrivkin

As seen in Figure 3, Tokyo Sky City project’s Meta-Architecture describes the organization of architectural artifacts, like Buildings (apartment complexes), Parks (inner green spaces), City Transportation (inter-level elevators), Neighborhood Transportation (In-level monorail trains), Stadium, etc. under a united Meta-Architectural umbrella. It completely ignores Construction Architecture’s usual primitive-level artifacts, like Building Spaces.

While having this kind of structures in practice, we, enterprise architects and our discipline, Enterprise Architecture, are still far behind this level of understanding and completeness. This is why in this article we are only trying to trace the contours of the future Super-prise Meta-Architecture, while hoping to lift EA closer to the level of objectivity and completeness of CA in yet other publications.

So, let us outline some of the current unique attributes both of the Super-prise and of its elements:

  1. Super-prise itself:
    1. Is mostly a logical entity; physically its functions (but not architecture) are delegated to one of its constituents – Holding Enterprise;
    2. Has the next higher level of artifact complexity compared to a common Enterprise;
  2. Holding Enterprise (HE):
    1. Is a common Enterprise with its own Business and IT structure;
    2. Has, however,  a business model representing the whole Super-prise; thus it has an interest in the effective and efficient functioning of its constituents;
    3. Does not usually serve End Customers; its customers are its constituents;
  3. Subsidiary Enterprise(s) (SE):
    1. Are also usual Enterprises with their own Business and IT structure;
    2. Have Business Models different from each other;
    3. Currently function completely separately from the rest of the organization, having informational ties only with HE.

Today, from the whole Super-prise’s point of view, its constituents are using not only different technologies but different methodological principles , such as SDLC, architecture, governance, BI, etc. That makes the whole Super-prise even less effective and efficient than its parts.  Can’t it methodologically do better? Definitely, it can. We see no reason why EA cannot offer a structure as methodologically united, effective and efficient as CA did in Figure 3. In the same way, the Super-prise is interested in establishing common Meta-Architecture and Meta-Processes working in orchestration throughout the whole organization.

We know that it is business and architectural drivers that push an organization from its current state. In the case of Super-prise we can formulate the following ones:

  1. It is proven already that every Enterprise should function under EA Transformation Framework (EATF). It is possible to formulate a Reference EATF, valid for any Enterprise[3]. Hence, it is economically beneficial to have a common REATF for the whole Super-prise. Such a Reference Desired model is already proposed by ESOAF and is called there Elegant Enterprise (Figure 4). An elaborate analysis of this model is done in [3].

Figure 4 Elegant Enterprise

Originally uploaded by wrivkin

  1. We consider this model as the Desired State for every SE transformation, which will eventually lead to the creation of methodologically uniform artifacts throughout the whole Super-prise, thus making creating, changing, managing, and analyzing these artifacts and their informational output much more cost-effective;
  2. Despite having different EBMs, SEs may and will find that they have lots of common data and service domains (Data Storage, CRM, ERP, etc.). The general tendency of Enterprise Methodology[4] today is to outsource these domains to SAAS/Cloud providers[5]. The Super-prise is extremely interested in establishing its own Internal Cloud, which can serve as a services provider to all ESs via a unified Cloud Service Bus (CSB). It will provide a considerable decrease in  the Super-prise’s overall IT TCO through reuse of its services and more efficient use of its IT resources.
  3. This Internal Cloud may serve as a unique proxy/gateway to External Cloud(s), should the Super-prise decide to further outsource the technology part of its Information Processing.

All this leads us to the following concept of the Super-prise’s Target Meta-Architecture.

Figure 5 Target Super-prise Meta-Architecture.

Originally uploaded by wrivkin

A workflow, capturing the process of creating and running the Super-prise Service-Orchestration Meta-Architecture Framework (SSOMF), which can be considered as an extension of ESOAF for the case of the Super-prise, is shown in Figure 6.

Figure 6 SSOMF Workflow

Originally uploaded by wrivkin

The figure shows the inter-operations of all current and future constituents of the Super-prise in order to create an effective and efficient business organism.

So, we can state that, despite the seemingly independent character of the Business Models of Subsidiary Enterprises, they may benefit from their business and IT architectural collaboration. The goal of such a collaboration would be, as usual, an increased efficiency and agility both of each member of a Super-prise and of the organization as a whole.

[1] FSAM Glossary

[2] W.Rivkin Architecting Enterprise Business Model SOAInstitute.org April 6, 2009

[3] W.Rivkin Enterprise Architecture and the Elegant Enterprise. Architecture & Governance Magazine. March 31 2009.

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

[5] W.Rivkin BPM SAAS AS THE FOUNDATION OF A CLOUD-BASED POST-IT ENTERPRISE. 2009 BPM & Workflow Handbook (chapter). June 2009.

<!–[endif]–><!–[if gte mso 9]> <![endif]–><!–[if gte mso 9]> Normal 0 false false false EN-US X-NONE X-NONE <![endif]–><!–[if gte mso 9]> <![endif]–> <!–[endif]–><!–[if gte vml 1]> <![endif]–><!–[if !vml]–><!–[endif]–>

Shared Services: Good, Bad, or Ugly? October 4, 2009

Posted by wrivkin in Enterprise Architecture & Business Transformation, General Creative Thinking.
add a comment

Paraphrasing Leonard Cohen: “Nobody knows”. At least, apparently, not “CIO Magazine”, which has recently published an article on the issue[1]. The subtitle of the article is just awesome: “Shared services are back in vogue” (italics are mine W.R.). I do not know whether the irony is deliberate, or it is just sub-consciousness, but I bet it will go unnoticed in our community. Actually, we agree with this level of understanding of Enterprise trends, which follows vogue, fashion, hype, but not knowledge! What knowledge, one can ask? Who can foresee the mysterious ways of this incomprehensible object called Enterprise? We can guess about it, but know it?!

However, let us return to the article under consideration. “The idea of IT services shared among industry rivals isn’t new,”-writes its author – “but attempts to establish them have a spotty track record. Previous initiatives, such as an effort in the early 1990s to form a shared travel reservation network called Confirm was started, but never materialized…” Why? Nobody seems to know. Well, maybe I can add my two cents. In the early 2000s I was a part of Alltel’s project called Compendium, which was intended to create standard, component-based applications for shared usage in the Telecomm industry. It failed miserably and, even back then I understood why, spoke from the beginning against it with its major proponent, my boss and VP, risking my relationship with him and my job. Back then I called it ‘competitive edge’. Now I call it ‘competitive business processes’.

Nobody, in their right mind, would share them. It does not matter whether we have Cloud computing, SAAS, open source, and all the other technologies and methodologies that the author listed in the paper. Technically, it was all possible 20 years ago, and it is so now. Business-wise, it made no sense back then and it makes no sense now.

All this makes even more mysterious to me the call for a common reservation system, made in the same paper by the CIO of Intercontinental Hotel Group. It is mysterious, because it seems to contradict IHG’s current Business Model. It is no secret (see their website), that a few years ago the chain sold almost all their hotels and became a franchise. This substantially increased their capital in the bank but made their reservation system the only source of their revenue. The revenue per room with this EBM has decreased four times compared to what it was before the Big Sale (again, see the public data on their website).

For me that means one thing: if the chain fails to create a reservation system with a substantial competitive edge over their rivals, who still own their hotels and have corresponding revenue streams, it may mean the chain’s business failure! This is exactly what would happen, if they all use the same reservation system.

So, when IHG’s CIO says: “With the advent of cloud computing, I think that’s going to open up the doors to this type of collaboration”, it is an example how methodological confusion can lead to some IT decisions with potentially unsafe business consequences. My humble advice to IHG and others in the same situation is:”Please choose wisely which door you are going to open up.”

So, what, thou shalt not share? Aye, thou shalt, but only the processes and services that have become commodities and do not bring a competitive edge. Enterprises have always shared their power and telephone providers. Now the time comes to share technological resources and commodity services. However, if you are about to share your EBM’s core business processes – your intellectual property, your competitive advantage – think more than twice! Especially if Information Processing is your main line of business.

[1] T. Hoffman ‘Common Ground’. CIO Magazine September 1 2009 p.38

The Writing On The Wall – Real Example #2 August 8, 2009

Posted by wrivkin in Enterprise Architecture & Business Transformation, General Creative Thinking.
add a comment

Here is another real-life example of how a chain of methodologically wrong decisions led to a massive and dramatic shift in Information Processing for one of the major telecomm providers.  About a year ago they outsourced ~90% of their IT to an external vendor. It was before the recession, this US subsidiary of this multi-national corporation was the most profitable that year, and the IT-supported Customer Care of this company was recognized then as the best in the industry. So, why did they outsource their IT? They did it because their new CEO made this decision. Why? Because he came to do it and he could! He came just to stop the entire headache associated with the internal IT. Ten years ago he would not have done that, because he could not! But now he could and he did, unfortunately, as we shall see further, also without deep methodological considerations.

As a result, 80% of IT employees lost their jobs. Was it predictable? Absolutely! I have observed, from the outside, their architectural chaos for the last four years, and it indeed became worse and worse. They meaninglessly flounced back and forth from one technology to another without any methodological clue about why they were doing what they were doing.  They were buying Weblogic, TIBCO, Siebel, SAP; they invested millions of dollars in new technologies, tools, training, and migration trauma only to throw each new technology away or to misuse it. Why? Because they chose to ignore the writing on the wall that clearly said: TECHOLOGY DOES NOT MATTER ANYMORE; PAY ATTENTION TO METHODOLOGY! So, they ultimately got a more understandable and undeniable message from their CEO: MY OWN INTERNAL I.T. DOES NOT MATTER TO ME ANYMORE; GET THE HECK OUT!

A year has passed since that transformation, and they seem to be OK so far, like they never even had their internal IT. Now, as I said before in this post, having absolutely agreed with this CEO in WHAT he did, I have my doubts about HOW he did it. It seems that he now has very tightly (possibly fatally) coupled his company’s Business Processes to this one external vendor. He got the first contract, evidently, cheap enough, but what will happen when the term of this contract is up? What would his company do if their service provider triples the price then? They will have nowhere to go. Then he can discover another truth: WHILE TECHNOLOGY DOES NOT MATTER, INFORMATION PROCESSING VERY MUCH DOES! Nobody can do now without Information Processing (I.P.), especially a company whose Business Model is to provide information! And you better be free in choosing by WHOM, HOW, AND FOR HOW MUCH your information is processed, or you might find that you have another headache, this time around caused by your neck being in a tight noose, with its end in the hands of your IT service provider. Now, isn’t that simple? Evidently, not for everybody.

Returning to our case study, it is very probable that this company will ultimately find out how costly and deadly methodological and architectural mistakes are. They could’ve changed their IT architecture to make it more open and flexible, when it was in their hands. It would’ve been methodologically right! Now, all architecture is in the vendor’s hands, and no vendor is so stupid as to invest money in a serious, costly client’s architecture change just to make it easier for the client to go to another vendor! So, as the client company inevitably sees their Business Model and their Information Processing growing more and more complex, with their vendor adding more and more point-to-point integrated functionality, they may find themselves doomed to use the services of this particular vendor forever, bound to pay whatever price it would ask, unable to set themselves free.

OK, now the $64K question: “Could they have done better?” Absolutely, and it was this very case that made the author of this post once develop and publish his Enterprise Cloud-Oriented Architecture concept and framework explaining how it is possible to do better . Why then didn’t they do better? It is because among those 80% fired and 20% kept technologists, including their so-called Enterprise Architects, there were no methodologists, who would’ve been able earlier to stop this costly technological madness, or, later, to explain to their CEO how to create a viable Enterprise Cloud-Oriented Architectural Framework, allowing them to avoid the later fatal methodological mistakes. They did not care (exactly as you, my reader, do not), and then it was too late. Instead, they hit the road, looking for another technological job, with the recession coming. May God help them. Not all of them were on the Methodology level, but their managers and architects must’ve been. It is their ignorance that has let the technology people along with their company down.

Are you and your company the next? Are you able to read what is written on the wall?

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!

Carthago delenda est! June 30, 2009

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

“Carthage must be destroyed!” – that was the phrase Cato the Elder, the ancient Roman statesman and consul used to conclude his each and every speech in the Senate , no matter what the main subject of the speech was. It was his way to force this idea into the heads of Roman senators, too wealthy, intellectually lazy, and comfortable in ‘now’ to lend a thought to the future. I can only imagine how annoyed they were by this phrase. However, a drop wears a stone. After a while they already knew this ‘catch-phrase’ by heart and expected, even waited for it. Then, the idea behind this phrase started penetrating into even the thickest heads:”Rome cannot prosper and advance until the constant threat of Carthage’s invasion or interference is eliminated”.

History has proven that the old, stubborn, obsessive visionary was right: it is only after the Third Punic war and final destruction of Carthage that the Roman Republic really started its territorial, cultural, and civilizational expansion, which led to its stability and prosperity.

“The methodological chaos in the formulation and implementation of Enterprise Architecture must be overcome” – this is the phrase I intend to put at the end of my every blog post from now on. Enterprise Architecture cannot become the universal method of describing and improving all things Enterprise while it remains in the minds of the professionals, pursuing it as their career, as the field of voluntary opinions, baseless frameworks, vague statements, and overall confusion. To prove that this is the right picture of the discipline, let us just take a look, for example, merely at the themes of recent EA-related discussions in the major EA-related groups of the major professional network site – LinkedIn:

·         What is Enterprise Architecture anyway?

·         Is Enterprise Architecture being used properly?

·         Enterprise architecture frameworks are dead, long live real-life practice !

·         What is Information Architecture anyway?

·         What are the steps to creating an EA roadmap? What does an EA roadmap look like? Does any one have any ideas on this or suggestions?

·         Is it necessary to document the current state (architecture) as part of the EA effort? Is there an alternative that is more productive?

·         How much target state definition/documentation is needed for EA (or any other strategic initiative like eBusiness) before projects are executed?

It can go on and on. Enterprise Architecture as a discipline has existed for over 30 years now. All these and many other confusing questions have been discussed hundreds of times. Still, every framework, every ‘school of thought’ has a different answers to this questions. How is it happened that these basic questions are not unambiguously, objectively answered yet? We need Unified Enterprise Architecture Framework exactly as 30 years ago, after years of discussions and schools’ wars we needed Unified Language and Unified Process for Object-Oriented Analysis and Design. Only after this, the OOA&D was successfully adopted by the industry and allowed it to advance and prosper, until it reached the Architectural state.

And what do we have nowadays? The desperate cry for help in the field of darkness:  “Does any one have any ideas on this or suggestions?” Oh, yeah, we do! If we follow the comments/answers to these discussions we can find many interesting “ideas and suggestions”, mostly contradicting and denying each other! Then we catch the closest voice, create another Frankenstein, and then start crying how hard it is to ‘sell’ the business value of this monster to higher business management! What value? Of exactly what ? Everybody has a guess, nobody has an exact knowledge.

“Enterprise Architecture is failing” not “because there are too many consultants” but because there are too many “ideas and suggestions” and too little exact knowledge in their heads.

There is an old Jewish anecdote: A farmer comes to a rabbi and says:”Rabbi, my chickens are dying, please help!” “OK” – says the rabbi – “I have an idea: divide your coop into two parts and put all chickens in one of them.” “Wow”, – says the farmer and goes. In a couple of days he comes back and says:”Rabbi, my chickens are still dying!”. “OK”, – says the rabbi – “I have another, even better idea! Draw a circle in the middle of the coop and put all chickens in this circle!”. “Wow!” – says the farmer and goes back to his farm. In a couple of days, though, he comes again, crying:”Oh, rabbi, my chickens are all dead!”. “Oh”- says the rabbi – “It is such a pity: I still have so many ideas left!”

Yeah, we all have so many ideas, we divide our coop into the number of parts recommended by ZEAF or TOGAF, we draw a circle of best practices, but our chickens keep dying! Yes, they are, that’s what all these unanswered aforementioned basic questions tell us! They are dying, Hannibal is at our gates, while we keep arguing about what a chicken is, and is it possible to define it and an egg in exact terms!

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

The Importance of Thinking Regularly April 21, 2009

Posted by wrivkin in General Creative Thinking.
add a comment

About three to four thousands years ago my very distant ancestor Avram Ivri, who lived then in the Kingdom of Babylon and whose name meant  ‘a man from the other side of the Euphrates’  started experiencing a deep spiritual crisis. He suddenly felt that he cannot consider clay-made figures to be mighty gods anymore.  He had seen enough of them cracked in the oven or broken by an unlucky movement or a gust of wind. Everybody else had seen this as well, but somehow it did not bother them. These totems had been a part of their religion and culture for so long that nobody seemed (or everybody was afraid) to be bothered by their obvious insignificance.

So, where is the force that rules everything, thought Avram?  Is it the wind? However it seems to change depending on the season and the time of the day. Then, is it the Sun, which defines both the former and the latter?  That answer was good enough for the people of the whole neighboring empire, Egypt, but Avram rejected it after some consideration. After all didn’t the Sun, the Moon, and the stars regularly and predictably move across the sky, definitely obeying some higher order?

As Avram says in Thomas Mann’s novel ‘Josef and His Brothers’, “I, Avram, being a Human, must strive for the very highest”. Thus, the false idols preventing humankind from moral and intellectual advancement were destroyed, and the enormous idea of the single, almighty, invisible and eternal God was born.

This is an extreme example of independent and dissident thinking. We obviously do not need to put such an intellectual effort into trying to disprove every idea. After all, we are standing on the shoulders of giants like Avram, who we know now as Abraham; we can and should rely on some proven moral and intellectual truths, upon which our very civilization is based. It does not even matter whether we believe in Avram’s God or not, because it is this objective moral law that He put into our souls that makes Avram’s intellectual leap the irrefutable basis for our very existence.

If we thoroughly understand the validity of certain truths and their boundaries, we can stop spending our time trying to doubt them and concentrate on the new challenges that progress poses us every day. This is why, for example, we have stopped researching Newton’s mechanics, the boundaries of which we know, but not those of Einstein, the boundaries of which we do not know. Otherwise, we can never progress in our knowledge.

However, the opposite is even worse. If we stop investigating a field that is not deeply understood and well-defined yet, if we are satisfied with half-baked guesses and stop searching for real, profound knowledge and understanding, then all our efforts are worth as much as a prayer to clay idols. In this case we have the illusion of progress when in fact we are just wandering in twilight.

When our culture rewarded profound, unorthodox, and innovative thinking, we invented the car and the airplane.  When our culture started rewarding clichés and loyal intellectual numbness, we lost our ability to make the best cars or airplanes in the world.

We live now in a country where the previous, half-witted government wishfully thought that it is enough to give a mortgage to anyone who asks for it, and we would have a whole nation of home-owners gratefully voting for them forever; where half-witted citizens wishfully thought that it is OK to pile up debts without ever considering how to pay them back; where half-witted managers of financial institutions didn’t even think of such an improbable possibility as low-income clients ceasing to pay their bills; and where the new half-witted government wishfully thinks that every problem can be solved by printing enough green paper with presidents on it and telling everybody what to do.

We live in a country where CIOs think that CEOs value them very highly and consider their I.T. departments as the company’s best asset.

We live in a country where creators of the movie ‘Idiocracy’ wishfully thought that they fantasize about very improbable future.

We must stop this. We must stop letting these salesmen from TV or IT magazines think for us. We must stop considering the very process of thinking as a dirty, hard physical job we would prefer to ousource to a third-world country. We must start trying to think for ourselves again, first once or twice a week, then more often. We can do it. Yes, we can!

Then we must start trying to think deeply, innovatively, unorthodoxically. We can do it, we still have these genes! Then one day one of us will say:

“I, Avram, being a Human, must strive for the very highest”.

And then we can discuss Enterprise Architecture…