Wednesday, May 03, 2006

Integration Driven Development and Anatomies

I attended a talk by Lars Taxén about Integration Driven Development and Anatomies today. IDDA is a development methodology for large projects. "Large" means 1,000+ people.

IDDA was developed at Ericsson for use in telecommunications projects. One of the things I found interesting was that the anatomies part, a method for modelling complex systems, is quite similar to Domain Modelling. That is, both methods aim to create models that mirror real world objects or processes. Anatomies, like Domain Models, make use of bounded contexts to separate different parts of the system.

Some things were very different from what I am used to. For example, IDDA subsystems are implemented in the order they are activated when the system is used. That is very different from the Agile practice of implementing the most valuable functionality first.

For example, consider a document production system consisting of three subsystems: an XML authoring system, a Document Management System (DMS), and a printing system.

With IDDA, the first system to be built would be the authoring system, then the DMS, and finally the printing system. This is the order in which the subsystems are used. First an author writes something, then she stores it in the DMS, then it is printed.

With an Agile methodology, the most likely order is authoring system, printing system, DMS. The authoring system is built first, to enable authors to start using the system as soon as possible. Then the printing system would be built, because that makes it possible to print documents, even though there is no DMS yet. That makes it possible to get value from the system, even though the central piece is missing. The DMS is added last.

The situation may be a bit more complex, of course. For example, once the basic printing engine works, it may be most profitable to implement the basic DMS system, go back and finish the printing engine, and finally put the finishing touches on the DMS.

IDDA focuses on the dependencies between subsystems. For very large and complex systems, this may be a better strategy than focusing directly on business value. (I am not quite convinced, but I am certainly interested in learning more.) Culture and cooperation are other areas that are of particular interest. Ericsson's projects often involve people from all over the world. It is important that they can communicate over the barriers of culture, language, and physical distance.

IDDA hasn't been directly influenced by Agile methodologies, but Systems Thinking has played a part. This may to some extent explain the similarities between Agile methodologies and IDDA, even though they target very different projects.

No comments: