I used to be a follower of ICONIX Process. I did some training, I implemented ICONIX process in some software projects, I taught others about the process. I am no longer a follower of ICONIX Process, for reasons that I will lay out below. However like all software engineering or software architecture theories, there is a bit of good and a bit of bad in it and I like to take away the good and leave behind the bad.
What Is ICONIX Process?
Firstly, let’s look at the often-used diagram encapsulating ICONIX Process:
(Source: https://iconixprocess.wordpress.com/iconix-process/ — although I scaled up the diagram somewhat.)
ICONIX as a software architecture method has been around for a very long time. It predates agile development, although the primary textbook about the process — Use Case Driven Object Modeling with UML, Theory and Practice — was published in 2007, somewhat after the Agile manifesto was published in 2001.
The fundamentals of ICONIX process are to model the software in two parallel processes — static and dynamic models.
ICONIX Process Flow
The overall flow of the ICONIX Process is as follows:
- In the dynamic model, extract use cases from the requirements or GUI storyboard, then construct a Use Case model. Step by step, decompose that dynamic model into a Robustness Diagram and then multiple Sequence Diagrams (each mapping out one interaction).
- In the static model, commence with a Domain Model, update that model as time passes, then decompose that into one or more class diagrams laying out the data structure or class structure of the system.
- During the process, map components in the Use Case or Robustness Diagram or Sequence Diagrams into one or more classes to demonstrate construction of the software.
Faults with ICONIX Process
Critics of ICONIX Process have commented, quite correctly, that ICONIX is a lot of design before we commence building any software. It’s commonly associated with waterfall methodology where we do “big design up front” and ensure that the system is well designed (including test plans) before we commence writing any code.
That whole process is very much the antithesis of agile development — where we code small incremental pieces of the system at the start and then demonstrate those to a small audience (maybe a product owner) and then continue to refine those pieces over time.
In particular, I have never found very much use for a Robustness Diagram. Sequence Diagrams are things that I use very rarely — I don’t need to have a Sequence Diagram to map every interaction between each and every class, for example. The few cases where I use a Sequence Diagram are where I need to make clear some timing requirements of a particular external API that may have some number of complex interactions. An example of this is when I was dealing with a payment gateway that had many callbacks as the payment was in flight, many of which were asynchronous and involved critical timing requirements.
At the lowest level, I really don’t consider Class Models to be part of software architecture. They are software design, and I don’t really see the benefit of asking a software architect to draft a Class Model covering every individual class that we may have in the final system before we commence coding. The only time when I might use a Class Model is when we have a senior developer mentoring a team of junior developers, and that senior developer needs to draft up a few diagrams to give the junior developers some ideas about how to logically and correctly structure their code (to comply with SOLID principles for example).
What Can We Learn From ICONIX?
ICONIX is not all bad, though. I still use Domain Models extensively, and I have stated my reasons for that elsewhere. Domain Models are a good way of communicating the overall structure of the system to a non-technical audience.
In abandoning “big designup front” processes completely, what we often find is that the incremental delivery of an agile project causes a lot of technical debt. One common mistake is that we commence building micro-services without first considering which micro-services we need and what they should do. Having a Domain Model up front is a useful architectural process to go through to give some more structure to our micro-services.
We have been building systems using MVC architecture for a long time, and we are now finding, as we move towards more separation of the front ends and back ends, that MVC is actually a bad idea. Domain Modelling is one way of resolving the problems inflicted on us by MVC.
Domain-Driven Design (DDD), once considered too esoteric to be of value in the MVC/Agile world, is making a comeback, and Domain Modelling is one way of giving structure to that DDD approach.
We can use bits and pieces of a good framework, even a framework meant for waterfall design, in an agile world, to some advantage. Just because we have learned that XYZ is bad in an agile world because of Y and Z, does not mean that we have to discard the whole thing to make use of X.