UML is a well-established notation for the design of object-oriented applications. In component detailed design meetings people are comfortable describing a design and articulating issues using UML.  This is not the case in integration projects. I go in the meetings to review an integration solution and invariably the discussion is based on a Power Point presentation with diagrams that include very basic, ad-hoc notations. The picture on the right is an example; the diagram mixes the component model with the deployment model, using ad-hoc notations for the components and execution environments.

Why is that? Why UML is not used more often in integration projects?

First, different teams need different UML diagrams. It is still UML but not the same diagram.  The audience of the Component Design is mainly developers interested in a design that focuses on encapsulation, code re-use, extensibility. The class diagram is very good for this. The audience for Solution Design is business analysts, infrastructure architects, directors. They are more interested in the component model and the deployment model. Although both groups are using UML, the diagrams are very different.

Another reason is that people confuse diagrams. Most users of UML have experience with 2-3 diagram types. When faced with a new problem or reading a solution, a person may not recognize a diagram type and consequently will not understand the message. I have this problem when trying to express the scope of a project using a use-case diagram.  See the diagram on the right. Most people look at this image and they think that the ovals represent some components an the arrows are data-flows. They confuse a use-case diagram with a component/class diagram.

Finally, people want to show multiple models in the same diagram . The typical case is the Component and Deployment model. 20  years ago the component model and the deployment model were very similar: a Customer Management component was deployed on an AS400 computer, running the OS400 operating system. The storage was on the same computer and the database was integrated with the operating system and the application development environment. This made it easy to refer to the Customer Management component as the “AS400” and it appears with this label in Solution Design diagrams (see the first diagram in this article). But technology changes broke the one-to-one relationship between component and server. A Customer Management component. built using J2EE technology is now running on an WebLogic container, running on a virtual machine on a Sun M8000 server; the storage is on an Oracle database running on a HP server, with the storage from SAN that is based on HP infrastructure (see the deployment diagram in the right image).  Often, rather than separating the component model from the deployment model, a diagram will try to show both. And will do a poor job at showing either. Then, the author will introduce ad-hoc notations to try to clarify the design and, in the process, give up on UML.