Simplifying the Design of Software Architectures: Taming Monsters

Yesterday I was in Brussels participating on a meeting for the NEXOF-RA european project. This project aims at defining a service-oriented meta-architecture called NEXOF Reference Architecture. It is composed mainly by a reference model and a set of patterns joint with the corresponding guidelines and principles that allow to create concrete interoperable architectures adapted to the varied requirements of the (up to now vague concept of) Future Internet.

During the meeting, we were discussing about one of the current patterns under development related to the architecture of the Internet of Services (IoS). Inmediately arose the question about how the design decissions we were taking on the pattern impacted on the existing conceptual model of the architecture (defined early in the project). The current view of the architecture was defined starting from the point of view of the main (general) concerns affecting the service-oriented architectures, their functionalities and relationships, what resulted in a big and messy diagram. Anything but simple. In fact it was called internally "the monster". On the way to Brussels, I was reading the book Subject To Change. The book relates the experience and vision of a particular company (Adaptive Path) in developing successful products mainly from the point of view of experience-based design. One of the key principles they remark is keeping the design of things simple (what does not means simplistic).

When the second year of NEXOF-RA started, the main purpose was: "let's tame the monster". Well, in the end it seems that the monster has been tamed. At the end of the meeting we have reached a consensus on a new high level view for the conceptual model of the NEXOF-RA. To me, this view contains the main important adjective to understand anything: it is "simple". It contains a good enough graphical representation with no more thant 7 building blocks, their names are short and descriptive enough and their functionality is concisely described in one or two sentences. That is, anyone that takes a glance at the new diagram can understand intuitively the overall reference architecture, the purpose of the main components and why are they structured in that way.

To conclude this journey through simplicity, in the comeback flight, I asked the air hostess for a newspaper and she brough me The Wall Street Journal. To my surprise, there I found an article from Gary Hamel entitled "A great design can be the missing link" advocating for the same principles: design simplicity and the added value that provide properly-designed things.

In summary, keep software design and architectures simple (but don't be simplistic!).

Unfortunately to me, the trip to Brussels was not so-simple to arrange :-)