Blog Archives
Methodology vs framework – why waterfall and agile are not methodologies
There are often fights amongst people in the IT profession about whether the 'waterfall methodology' will or won't work. Over coffee friends and colleagues discuss why the 'agile methodology' is better, or alternatively, too hard to implement. It's also common for selection criteria to frame questions such as these (taken from real selection criteria and job descriptions):
"Experience in or an ability to acquire knowledge of software development methodologies (such as Agile development, Model Driven Architecture, etc.)."
"Application of a recognized software methodology (e.g. UML) to the design and development of embedded systems…"
It is shocking that intelligent, well educated people don't know the difference between a framework and a methodology. It's also shocking that prominent and respected organisations display this same ignorance. Who cares? Is this a semantic argument? No, this isn't a semantic argument and the difference between the two is an important distinction. It's important because a framework allows you to be loose and flexible; to have 'poetic license'. A methodology is much more prescriptive. Both can be handy at different times. But a methodology, is generally better and I'll show you why.
Definition of framework The Federal Enterprise Architecture Framework defines a framework as:
Generally within the software lifecycle realm, a framework is a picture or a model that guides you to understand which artefacts you should produce when. It doesn't tell you what to do though. For example, typically the waterfall framework begins with analysis as the first stage of software development. But it doesn't tell you how to do that analysis. Even if the framework is detailed enough to specify the template you should use, it won't tell you how to populate the template. Often though, a framework won't go into that much detail, giving you lots of flexibility to choose how you're going to do that stage. Flexibility is a guise though. Ambiguity is another term for it. You aren't compelled and guided to produce specific artefacts according to a process. Instead you are left to fumble your way through, trying to apply some kind of structure. This means that you will inevitably make different choices from your colleagues who are using the same framework. If your organisation only has a framework to guide its employees, there will be a lack of consistency. The problem is compounded when people think they have a methodology and all they have is a framework. As you can see in the quotes above, they employ people based on the wrong premise and they also loose faith that a methodology will guide them. They also start to argue about one framework being better than another, when what they are desperately seeking is a methodology.
SPEM does this by defining two things: method content and method process. Method content is what you do. Method content defines the artefacts that through a flexible method process are applicable in a number of different contexts. The method process shows you how to apply the same content for greens field development verses what you do when you are performing maintenance. The diagram below, directly out of the SPEM Specification, shows you concrete examples of how the two are combined.
Definition of framework The Federal Enterprise Architecture Framework defines a framework as:
"A logical structure for classifying and organizing complex information."
Generally within the software lifecycle realm, a framework is a picture or a model that guides you to understand which artefacts you should produce when. It doesn't tell you what to do though. For example, typically the waterfall framework begins with analysis as the first stage of software development. But it doesn't tell you how to do that analysis. Even if the framework is detailed enough to specify the template you should use, it won't tell you how to populate the template. Often though, a framework won't go into that much detail, giving you lots of flexibility to choose how you're going to do that stage. Flexibility is a guise though. Ambiguity is another term for it. You aren't compelled and guided to produce specific artefacts according to a process. Instead you are left to fumble your way through, trying to apply some kind of structure. This means that you will inevitably make different choices from your colleagues who are using the same framework. If your organisation only has a framework to guide its employees, there will be a lack of consistency. The problem is compounded when people think they have a methodology and all they have is a framework. As you can see in the quotes above, they employ people based on the wrong premise and they also loose faith that a methodology will guide them. They also start to argue about one framework being better than another, when what they are desperately seeking is a methodology.
Definition of methodology
"A documented approach for performing activities in a coherent, consistent, accountable, and repeatable manner."
The Object Management Group, the organisation that has carriage of the framework, UML, also has carriage of a standard that defines what people should expect from a methodology. The Software & Systems Process Engineering Meta-Model (SPEM) Specification is built to help people define methodologies.
The scope of SPEM is purposely limited to the minimal elements necessary to define any software and systems development process, without
adding specific features for particular development domains or disciplines (e.g., project management). The goal is to
accommodate a large range of development methods and processes of different styles, cultural backgrounds, levels of
formalism, lifecycle models, and communities.
SPEM does this by defining two things: method content and method process. Method content is what you do. Method content defines the artefacts that through a flexible method process are applicable in a number of different contexts. The method process shows you how to apply the same content for greens field development verses what you do when you are performing maintenance. The diagram below, directly out of the SPEM Specification, shows you concrete examples of how the two are combined.
Rational Unified Process (RUP) is one of the more popular methodologies. The SPEM specification illustrates how it displays both method content and method process.
A good methodology is adaptable to the situation and takes you clearly through the steps to produce quality, consistent artefacts. So if you're going to argue with your colleagues in the break out area, make sure you're both on the same page as to which one you're talking about. Because it's obvious you're arguing about more than just semantics.
