Enterprise Architecture Analogies

“It is useful to be aware that analogies are tools for leverage, and indeed part of their utility is not just in extracting the insights they bring with, but insights […]

“It is useful to be aware that analogies are tools for leverage, and indeed part of their utility is not just in extracting the insights they bring with, but insights are also stimulated if we look for where the analogy falls short.” – Ruth Malan

Enterprise Architecture as Building Architecture

The differences between building architecture and enterprise architecture as follows (summary):

  • Building architects get paid for creating architecture, not buildings. In most cases the building architect gets paid when the blueprints are complete.
  • Building architects work from requirements. Their clients provide very specific requirements for what they want to be designed. EAs generally have to figure out what they are architecting and then sell it to the client.
  • Building architects usually start with a green field. EAs almost never work in a green field environment. Most of what they do at the enterprise level is renovation.

Comment (tweet) from Chris Potts about EA vs building architectue “The difference between enterprise architecture & buildings architecture is the medium. Also buildings can’t change own architecture; enterprises can.”

Enterprise Architecture as a Town Planning

With respect to the town planner vs EA comparison:

  • City planners build plans, not cities.
  • City planners have laws that back up what they say. Needless to say, EAs don’t.
  • City planners work on long-term visions. City planners work at a glacial pace compared to the typical enterprise architect.
  • City planners generally think in decades. Even the most strategic businesses use three to five years as their planning horizon.

Enterprise Architecture as a Gardening (with thanks to James McGovern)

Digging up plants by the roots and moving them around tends to damage or kill them. “I want that 50 foot tall pine tree moved just two foot further to the left” isn’t a very practical request in gardening. Doesn’t this kinda remind you of the frequency of corporate reorganizations or how we customize the snot out of enterprise applications?

Many CIOs think Software development is like planting, you can tend as many plant as you want and they will all grow simultaneously, the growth rate of each plant is independent of how many other plants are there. IT executives and their process weenie support staff simply add to the programmer’s task list and it will automagically get completed on-time, even though the programmer already has other “full-time” tasks going on and is also swamped with unscheduled “urgent” tasks every day.

Innovation in enterprise architecture is about planting of seeds, spreading of fertilizer, removal of weeds and watching things grow until they can be best harvested. Fertilizer always starts of stinky but morphs into something productive.

Enterprise Architecture as a Financial Planning Advice (with thanks to Doug Newdick)

“Think about it: I need to form opinions about the current state of the technology market and where it is going. I need to understand the needs of my “clients”. I need to make careful choices about what they should invest in to get the best return. I need to look at my “clients” current investment portfolio to understand their risk exposure. I make recommendations as to how they might invest to address those risks, how they might change their portfolio in order to better take advantage of current or future market conditions. I give advice on what the market is like, and which are wise investments and which are not.”

Enterprise Architecture as Consumer Advocacy Organisation

“Consumer advocacy organisations [e.g. dTest (Czech Republic), Which (UK), Choice (Australia)]  “… have neither the authority to ban products nor can it in any way forbid customers to buy them. Nevertheless, the power of consumer information [about product quality] and transparency leads to a change [in buying behavior] anyway.” Enterprise Architect’s World

Enterprise Architecture as a Wedding

“Transformation itself is more like a wedding and EA is more like a wedding planner. I know we have seen many weddings without a wedding planner, but it makes it easier if you have a wedding planner, because they have gone through certain steps (as part of their experience). They walk us through those processes, those methods, and those approaches. It makes it easier.” – Open Group Panel Discussion

Enterprise Architecture as Family

Enterprise architects need to work with the enterprise as if it were a family. If you look at a family, especially one with kids, they have their moments, but over time, they all start to embody a set of shared values.

From: Todd Biske – The Enterprise Family

Enterprise Architecture as a Evolution

” Charles Darwin is usually misquoted. He didn’t mention anything about ‘survival of the fittest;’ what he really said was, ‘It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.’ ” – Article by Garry Doherty, The Open Group

“A theory has only the alternative of being right or wrong. A model has a third possibility: it may be right, but irrelevant.” — Manfred Eigen, (1927 -), The Physicist’s Conception of Nature, 1973.

Enterprise Architecture as a Intelligent Design

“Most enterprises evolve through change, acquisition, merger and the purchase of customer portfolios. Business architecture seeks to change this by putting in place intelligent design … SMEs seem to work better or more easily in a evolutionary environment but when you get bigger a future must be crafted and planned … In business, intelligent design seems a much more sensible approach than sitting back and allowing fate to govern your future.” – Article on the Business Architects Blog

Enterprise Architecture as the New York Subway (intelligent design over evolution)

“[In] the New York subway.  Certain stations (e.g., 14 Street, 59th Street-Columbus Circle, Borough Hall) where you need to change lines, don’t seem to ‘line up’ properly – you have long underground walks, underground shuttles, or, in some case, have to surface to street level in order to go back down to the different line (these are aptly referred to as “station complexes” and complex they are!)  Connections between lines that should be simple, aren’t!  It felt to me as if there wasn’t a coherent architecture to the subway system.” From an excellent article by Vaughan Merlyn  that discusses how the subway “evolved” rather than was designed.

Enterprise Architecture as Sailing

  • When the wind shifts, you have to adapt your plans accordingly. There’s no point arguing about it.
  • The crew is constantly monitoring and making little adjustments to the sails.
  • You can’t always trust the map or the weather reports. You have to pay attention to what you see, not what you were told you were supposed to see.
  • You really have no idea exactly how long it is going to take to get anywhere.
  • You can speed up by throwing big heavy things overboard

From: James McGovern Enterprise Architecture and Sailing

Enterprise Architecture as Manufacturing

“The older disciplines of Architecture and Manufacturing have accumulated considerable bodies of product knowledge through disciplined management of the “product definition” design artifacts from which the Framework was derived. This has enabled enormous increases in product sophistication and the ability to manage high rates of product change over time. Similarly, disciplined production and management of “Enterprise definition” (i.e. the set of models identified in the Framework for Enterprise Architecture) should provide for an accumulation of a body of Enterprise knowledge to facilitate enormous increases in Enterprise sophistication and accommodation of high rates of Enterprise change over time.” John Zachman in “The Challenge is Change”

Enterprise Architecture as Complex Product Engineering (Airplaines, skyscrapers, trains, battleships)

“Every airplane, every hundred story building, every locomotive, every battleship, every computer, every industrial product has Architecture. Otherwise, we couldn’t have created these complex products and we couldn’t make continuous engineering changes to them without catastrophic results.
Jay Forrester observed that “Organizations built by committee and intuition perform no better than would an airplane built by the same methods … As in a bad airplane design, which no pilot can fly successfully, such badly designed corporations lie beyond the ability of real-life managers.” Zohn Zachman interview

Enterprise Architecture as Product Design & Assembly

“Regarding mass customization, if you engineer the “primitive” components (the single variable models, the “elements”, one category of the schema) such that they can be assembled into more than one product (implementation) and if you pre-fabricate them so they are in inventory before you ever get an order for a result (an implementation), then you can reduce the time to create the end result to only the time it takes to pick the parts, the “primitive” components, out of inventory and assemble them in response to the order, virtually, zero time-to- market.” Zohn Zachman interview

Analogies are not identities. And analogies are useful in blends and transforms, more than simply straight up. And different analogies help us make different points or draw on different insights, serving different contexts. – Ruth Malan

Enterprise Architecture as the US Government

As shown below there are three major branches; the Judicial, Legislative, and Executive.

image

You can see a ton of similarities here. I break these three forms of government into the following activities of the EA function:

  • Judge It - This area goes into the governance activates of an Architecture Review Board (ARB). Ideally ARB’s should have limited power and only have the ability to review architectures not to create the laws (i.e., standards).
  • Standardize It - When we talk about standardization this is the activity that forms virtual teams of domain stakeholders to build what is commonly referred to as Principles, Policies and Standards.
  • Execute On It - The executive branch in reality is the “commander chief” that is the official spokesman and stimulates action in time of need. Likewise with EA’s on strategic projects and management of future strategies.

From: Mike Walker’s MSDN blog

Enterprise Architecture and the Toilet in the Kitchen

The underlying principle is boringly uninteresting “Separation of Concerns”, in my naive language saying “Put things where they logically belong” … when you insist on implementing certain functionality or placing data in a concrete application … we are just saying “Please, be so kind and use your BPMS to implement your processes, client related functionality mostly does belong to the CRM and when talking about the CRM, no it’s not the place for your mortgage simulation just because you’ve got full client profile there … It’s like saying “I guess you don’t have a toilet in the kitchen either, eventhough there’s drain and water”.

From Ondrej Galik‘s Enterprise Architect’s World

Enterprise Architecture as Human Anatomy

A doctor, a surgeon cannot diagnose or operate without being familiar with all the body parts, systems and vital processes. Similarly, an Enterprise Architect cannot operate without knowledge of business Functions, Layers, Views and business Flows. Even more, doctors specialize in one of these systems like in the Enterprise, the domain architects do.

Without anatomy and physiology medicine could not progress. We are at a stage now where we able to roughly describe what happens in a human body. But to fine tune a body, cure incurable  deceases there is much more to understand about the human body and its processes. We are at the beginning of the journey to understand, fix and improve the Enterprise. But we need first to understand its anatomy and physiology.

From: Adrian Grigoriu Enterprise Architecture is the science of anatomy and physiology of an Enterprise

Enterprise Architects as Composers (ed. – Posers more like *grin*)

If the CIO is the conductor of an orchestra, where the woodwinds are the software, brass is the databases, percussion is the operations/data center, strings are the network communications, etc. the enterprise architect is the composer – the person that figures out how to make all these instruments (organizations) work together to effectively make great music, ideally matched to the movie (company strategy business-IT alignment).

From: Kirk Rheinlander in response to this blog

Enterprise Architecture as Music

Enterprise Architecture as Music

Architecture Music
Architectural methodology Music theory
The architect The composer
The architecture The musical score
The project/program manager The conductor
The implementers The musicians
The project The performance
The users The audience
The sponsor The impresario

From: Natty Gur First but created by Len Fehskens.

Enterprise Architecture NOT as the Roman Colloseum

“The Roman Coliseum is NOT Architecture. The Roman Coliseum is the RESULT of Architecture. The RESULT of Architecture is an instance of Architecture, an implementation. In the end result, the implementation, you can see an instantiation of the Architect’s Architecture. If an Architect had not created the descriptive representations (the Architecture) of the Roman Coliseum, they could not have built the Roman Coliseum. They couldn’t have even ordered the stones they required in order to build the Coliseum without the Coliseum Architecture which had to be created long before the Coliseum was constructed.

Architecture is the set of descriptive representations that are required in order to create an object. If you can’t describe it, you can’t create it. Also, if you ever want to change the object you created, Architecture constitutes the baseline for changing the object once it is created, that is, it is the baseline for changing the object IF you retain the descriptive representations used in its creation and IF you ensure that the descriptive representations are always maintained consistent with the instantiation.” John Zachman “Architecture is Architecture is Architecture”

Related articles

 

Share this page:
  • Print
  • Facebook
  • Twitter
  • Google Bookmarks
  • email
  • LinkedIn
  • PDF
  • Tumblr
Tags: , , , , , , , , , ,

About admin

Enterprise Architect