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?

(Continue reading …)

From time to time I read about an interesting Java project and would like to try it.  For example Apache Jackrabbit, a library implementing JSR 170 (Java Content Repository). But setting up the my Java environment to run the examples is a hassle because of the many libraries required. Over time I got better at starting new projects: I have project snapshots that contain all the Eclipse and Ant artifacts for a simple application with proper JUnit tests and logging. Still, downloading all required libraries in the proper directories and updating Ant and Eclipse configuration is a drag. There must be a better way to do it other than downloading manually libraries from various sites. In this context I decided to try  Apache Ivy with the recently released version 2.0.0.

(Continue reading …)

A few years ago I worked for a company that just created a new IT team for "integration." One member of the team was the "solution architect." There was no formal definition of that role but there was an informal understanding that the person will be responsible to ensure that the system works end-to-end. Since then, the role has become more common and there are more or less formal definitions many of which are very generic and, as a result, they loose any practical meaning. Recently, having the task of training people for the Solution Architect role, I tried again to explain what Solution Architects do and how they do it.

(Continue reading …)

I recently read a blog by Roy Fielding on REST. Deep, in one of the comments, Fielding says:

[…] I think most people just make the mistake that it should be simple to design simple things. In reality, the effort required to design something is inversely proportional to the simplicity of the result.

People who saw many good and bad designs relate to this. But it is not acknowledged in day-to-day life, on the contrary:

• Many integration solutions are overly complex because people just don’t appreciate how much (high quality) work goes into designing a simple/elegant solution;
• (Junior) architects do not appreciate the beauty of a simple solution. They will over-engineer the solution creating more adaptation layers between systems with no benefit, interfaces too generic loosing all the advantages of strong type checking
• It is hard to win the argument in an architecture meeting suggesting a simpler solution as if that shows a lack of knowledge rather than a honed skill.

Fielding’s quote should be on the first page of software design books.