Share this
by Bill Ross on 24 November 2015
"How do you see model-driven architecture in relation to Agile?" This was a question I was recently asked by Raffaella during my webinar Lean architecture - Architecting in an Agile world.
There was insufficient time for me to answer this question during the webinar so I will give my answer in this article.
What is model-driven architecture?
Before getting into the details I believe it is best to be clear on what we mean by 'model-driven architecture' (MDA). The phrase comes out of a standard that's driven by the Object Management Group and they have a model-driven architecture approach.
Models using notations such as Unified Modelling Language (UML) or Business Process Modelling Notation (BPMN) can be used to describe a system. The idea of MDA is that you can then essentially generate the system from these models. This thinking has actually been around for a while. It goes right back to Computer-aided Software Engineering (CASE) tools and the thinking behind it is to raise things up to a high level of abstraction and forward generate the code.
This model driven approach is also known as software factories (i.e. a factory that takes the model and generates the code). You could theoretically quickly change your model, regenerate your code and you've changed the software. In theory this seems an attractive approach for projects and you can see why this would be attractive for organisations who want to be very Agile.
Using platform-independent models
The further concept of platform-independent models (PIM) describes how models can be described in ways that are independent from technology platforms. So in theory for example, you could have a platform-independent model and from it generate software for the .NET platform and then subsequently re-generate software for a Java platform.
Clarification of Agile model-driven development
One point of clarification - you may also come across the term 'Agile model-driven development' used by Scott Ambler, who is quite well known in the software industry. It has a very similar name to MDA but is quite a different approach. He is referring to modelling in an Agile way to support normal software development, as opposed to modelling to automatically generate the software. For the purposes of this article we are talking about modelling to then automatically generate the code.
Does model-driven architecture work?
I found an IEEE article written by Axel Uhl entitled Model-driven architecture is ready for prime time (note: you need to pay to view the full article). The problem is that the article was published back in 2003. From my perspective MDA's prime time still hasn't really be realised even 12 years later.
In theory, model-driven architecture seems possible and it makes sense, but in our experience this approach rarely delivers in practice. One of the problems is technology churn. To generate code you need a stable target environment that you're generating the code into. Many organisations also do not have the resources or expertise to implement the necessary factory to make model-driven architecture a reality.
The goal of model-driven architecture is to save time in the coding activities, but most time on projects is not so much time spent actually coding, it's spent understanding the domain and the problem enough to either model it or to code it. Once you understand the problem, the coding is often straightforward. So making the coding fast doesn't necessarily give you a huge advantage.
What we have seen is that other techniques, such as Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD) have achieved more traction in the Agile area. Refer to our article Use ATDD to Agile development requirements on any project to find out more about ATDD.
Model-driven architecture if feasible can enable agility
If an organisation is able to make MDA or software factories work, then the approach would work nicely with Agile. Once you understood the domain, the problem and the business requirements, you could theoretically change your model, regenerate your code and fairly rapidly update your software.
MDA does not necessarily require going back to a 'big design upfront' or a waterfall approach. You could start with a very simple model with just maybe one or two use cases or user stories and generate code for that and then get feedback working in an Agile manner to iteratively expand the software product.
In reality with MDA you could follow an Agile process the way that you normally would with normal software development. So you'd have a backlog of items that need to be actioned by the Agile team. The backlog items and user stories are a promise for a conversation. A member of the team has the conversation with the product owner or the business representative and captures the essence of the detail either within the model using a MDA development approach or within automated tests and code using a Acceptance Test Driven Development (ATDD) approach. The software is delivered or demonstrated to the business at the end of the iteration or sprint and changes required may be added as new backlog items and the process begins again.
Greater Agile development gains from other approaches
Eric Evans introduced the concept of domain-driven design a few years ago to address the complexity in software development. In his book by the same name he describes how, as you go through the process of developing software, you are always learning and coming to an understanding of what the system's supposed to do. He describes the concept of "ubiquitous language" so that the terminology and the phrases applied to software entities and components use the same language as used by the business. This helps with building a domain-specific language.
In our experience, techniques such as domain-driven design, that help Agile teams have the conversations with the business, where much of the time can be spent on Agile projects, most likely give greater productivity gains in than necessarily investing in MDA or in creating a software factory.
Your experience and views on model-driven architecture as it applies to Agile development may be quite different. If you have seen MDA work well with Agile, or have other views on this topic, I'd love to hear about it. Feel free to share your thoughts in the comments.
Image: UML Diagram by boldmagicpizza, used under creative commons license CC BY 2.0.
Bill Ross is Principal Consultant specialising in archtiecture and is based in Equinox IT's Wellington office.
