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

Macro and Micro flows -- What is the difference?

Draw a diagram that shows how objects are connected together to create a transaction (a micro-flow diagram). Then, draw a diagram showing how a business process is made up by connecting various systems (a macro-flow diagram). The two look similar. In fact they do look very much like the flow charts Peter Abrahams of drew 30 years ago. This article continues the "Explaining integration" series.

Market Analysis

Macro and Micro flows -- What is the difference?
(or Integration Explained IV)

Draw a diagram that shows how objects are connected together to create a transaction (a micro-flow diagram). Then draw a diagram showing how a business process is made up by connecting various systems (a macro-flow diagram). Now stand back a bit and they look similar. In fact they do look very much like the flow charts I drew 30 years ago.

They are both made up of sequences, decision points, parallel flows, start and end point, and loops. For those of you who have read about Chaos Theory they are self-similar.

We draw them the same but implement them quiet differently. Micro-flows tend to be generated in procedural code, whilst macro flows tend to be defined in some declarative language such as BPEL.

Historically micro-flows have been the purview of application developers with object orientated programming and the like; whilst macro-flows have been developed by integration specialists whose main tools were adapters and message transformers and often had much closer links to the business analyst.

Besides the historic perspective, are there any good reasons for this difference? The fact that micro-flows tend to be a single unit-of-work and macro-flows are made up of multiple units-of-work suggests a real divide. However this seemly well defined boundary is being eroded. Macro flows have compensation routines that ensure consistent state through out the life of a business process. Micro flows are being built up from web services and often use some form of optimistic locking.

History has produced another reason for the divide in that the tools available were quiet different, in most cases coming from completely separate companies, hence the description of 'pure-play' integration vendors. Over the last few years there have been a number of vendors who have integrated these two sides, lead aggressively by BEA with its "application development is integration, and integration is application development" mantra for WebLogic 8.1, but also IBM with the use of Eclipse across the whole WebSphere line, more recently Oracle with ProcessConnect in 10g, but also smaller players such as Intersystems with Ensemble, Objectstar, and hyfinity.

This has been brought home to me this week whilst talking to IBM and then BEA who both showed me diagrams that I thought at first were macro flows, because that is what I went to them to discuss, but actually turned out to be micro flows. They looked the same and basically used the same tools to define and implement them.

But the main reason why this coming together of the two camps will be important is nothing to do with technology, but to do with legislation. Sarbanes-Oxley is about more transparent processes and knowing and ensuring that business processes are being followed.

Nowadays most business processes have a large level of computer automation, which leaves a problem for the auditors to work out what these processes do. Reading Java code is not the ideal way to check that a business process is being followed. Macro flows drawn as a diagram can be understood and checked by the auditors; if they automatically generate the computer system then the auditors can be assured that the automated process does what it says it does.

However this only goes down to the level of the transaction, and there is an awful lot of complexity inside a transaction. Providing micro flow diagrams that the auditors can trust will provide another level of transparency. It will then only be the individual objects, or web services, that will be defined by code. These should be small and well formed enough for them to be exhaustively tested by the auditors.

The age of separate integration and application development is ending.

Copyright 2004. 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 Topics Archive