jump to navigation

Carthago delenda est! June 30, 2009

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

“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!

Advertisements

Comments»

1. Alexander Samarin - June 30, 2009

The classic EA is some kind of “enterprise genotype” (a full nomenclature of enterprise artefacts) which is not yet well connected to “enterprise phenotype” (a set of observable characteristics such as performance).

I think that a formal link between can be done via “enterprise executable model” – EA enhanced by BPM and SOA.

Thanks,
AS

wrivkin - June 30, 2009

Hi Alex,

Good to hear the familiar voice in the darkness. You are absolutely right, while I would not scare our colleagues with another pair of absolutely correct but ‘scary’ definitions like ‘genotype’ and ‘phenotype’.

We can stay in the familiar for everybody territory of ‘architecture’ (taxonomy) and ‘processes’. Combining Architecture & Processes of an Enterprise, we can obtain its Features and Behaviors, which as we all know from OO&A fully define an object.

Once again, we understand Architecture as rather a method of analyzing of a taxonomy of an Enterprise in a three-tear hierarchical fashion: Architecture – Design – Primitive (Development)-level artifacts; likewise ALL Enterprise Processes we see as a combination of the three kinds of processes:
1. External (business) and internal (supportive) BP’s, which are understood and described under the BPM Framework;
2. Internal process of creating of the artifacts that an Enterprise uses to conduct the first aforementioned two: the Business Process Development Life Cycle (BPDLC);
3. The process of overall change of an Enterprise over time, which we call Enterprise Architectural Business Transformation (EABT) and which should be define, described, and, as possible, direct by a corresponding Framework (EABTF).

This combination of EA, BPM, BPDLC, and EABTF, which, if being known, fully defines an Enterprise I called Enterprise Development Methodology (EDM) (the kind of Enterprise-ology). Do not like this term much but could not come with anything better. If you can come with something else, I would appreciate it.

BTW, there is some idea, related to this, which I rather describe in a private letter to you.

And, of course, as you already know:

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

Best regards,

WR.


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: