News Stay informed about the latest enterprise technology news and product updates.

Architecture Marchitecture

A Marchitecture is an architecture produced for marketing reasons, normally by a vendor. It is designed to put the vendor in the best possible light by emphasizing the positive as well as hiding the negative. Peter Abrahams comments in this column from

Market Analysis

Architecture Marchitecture
A Marchitecture is an architecture produced for marketing reasons, normally by a vendor. It is designed to put the vendor in the best possible light by emphasising the positive as well as hiding the negative. If you are in marketing you will spell it Marketecture.

Whereas an architecture is an attempt to define how the various, and many, components of a system fit together and interact.

Why do we produce architectures and why do they seldom meet the various demands laid on them?

The first question is easy to answer. Any system that is worth discussing is complex and human brains are not good at dealing with complexity. Our solution is to divide the world up into manageable chunks and then show how they relate. Having done this we have the added advantage that we can modify or replace bits without breaking the whole; as well as handing the individual components out to separate groups for development.

The more difficult question is why are they often inadequate?

The first requirement is that an architecture should be a graphical representation with written back up. This leads to the first set of reasons for inadequate architectures. Some people are less able to think graphically than others. More serious is the medium used - two dimensional A4 pieces of paper, or the digital equivalent. Architectures, like the plans for a house do not conveniently flatten themselves out into two dimensions.

The second requirement is that the picture should mean something meaningful. Sounds obvious but too often two boxes are put side by side for no apparent reason except that the producer wanted both of them on the same piece of paper.

Please tell us about your pet hates in marchitecture diagrams.

Here is my list as a starter:

  • Overloading: trying to put everything on to one page. Often to be recognized by the use of three dimensional boxes that attempt to show how things are built on one another, or by bars down the side saying things like security or monitoring without any indication how they fit together. After a recent discussion about an overloaded architecture it was agreed that a picture is worth a thousand words but it cannot say two thousand.
  • Underloading: a picture with four boxes and some pretty patterns generated by powerpoint. In general four boxes do not make an architecture.
  • Diagrams showing flows of processes or data that do not have a predominate flow in one direction (left to right, top to bottom, or occasionally middle out).
  • Layered architectures where it is not obvious (or in some cases true) that the higher levels are built on the lower.
  • Architectures that do not recognize the flow of time and the development life cycle.
  • Architectures that do not show the whole of the business problem. Normally because the bits left out are difficult or not supported by the vendor. This is often difficult to recognise as it is very difficult to answer the question: what is missing from this picture?
  • Pictures that have unrelated thoughts on the same page. For example should a database design tool and a firewall be on the same page?
In a future article I will discuss some techniques to alleviate these problems. In the meantime if you are looking at an area, first devise your own architecture and then use that to critique vendor diagrams.

Copyright 2003. Originally published by, reprinted with permission. provides IT decision makers with free daily e-mails containing news analysis, member-only discussion forums, free research, technology spotlights and free on-line consultancy. To register for a free e-mail subscription, click here.

For more information:

  • Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
  • Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
  • For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
  • Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.

  • Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
  • Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
  • Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
  • Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
  • Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.

Dig Deeper on Service orchestration



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.