to the auther: MMF, IFM?

[Hanna Habashy]

Can you describe briefly what is MMF and IFM.
thanks

[Ernest Friedman-Hill]

See the opening post in this thread.

[Jane Cleland-Huang]

Sure.
MMF stands for Minimal Marketable Feature. It is best described as a "chunk of functionality" or an incremental delivery of part of the product you are building. An MMF is characterized by its ability to return value to the customer, where value can be measured in terms of cost savings, revenue generation, or a number of less tangible factors such as increased brand recognition, increased customer loyalty etc. We therefore deconstruct a product that is to be developed into these MMFs.
A related term that we haven't mentioned much in this forum is an Architectural Element or AE. An AE is similar to an MMF except that it is cost incurring but NOT revenue generating. Typically an AE is an element of the architecture that needs to be delivered in order to support the functionality of an MMF.
Finally, IFM stands for the Incremental Funding Method. IFM is a process and related concepts and heuristics that we use to sequence MMFs and AEs in order to optimize the value of the software project, where value is measured in terms of the financial metric known as Net Present Value (NPV). The idea is to identify the delivery sequence (which can be linear or concurrent) that meets the needs of your organization.
THe primary goal is to optimize project level NPV, but we may also be interested in manipulating other metrics such as the initial funding investment, time to reach self-funding (ie when the income from earlier MMFs funds ongoing development), and break-even time (ie when the income from earlier MMFs has paid back earlier investments).
In Software by Numbers we provide an introduction to this type of financial analysis and describe how to apply the IFM approach.

[Ilja Preuss]

Originally posted by Jane Cleland-Huang:
A related term that we haven't mentioned much in this forum is an Architectural Element or AE. An AE is similar to an MMF except that it is cost incurring but NOT revenue generating. Typically an AE is an element of the architecture that needs to be delivered in order to support the functionality of an MMF.

Interesting. Wouldn't it be appropriate to see that AE as a part of the MMF? Why did you decide to handle it explicitely?

[Valentin Crettaz]

Jane, could you please mention an example about what concretely could be a AE and an MMF so that we can see why a distinction was made in the first place and why an AE is cost incurring while an MMF is revenue generating. To the same extent, which aspect(s) of the AE makes it being cost incurring?

[Ilja Preuss]

Originally posted by Ilja Preuss:
Interesting. Wouldn't it be appropriate to see that AE as a part of the MMF? Why did you decide to handle it explicitely?

Ah, I see that you already answered that question in this thread.
[ April 28, 2004: Message edited by: Ilja Preuss ]

[Jane Cleland-Huang]

Initially we only had the concept of MMFs. We thought we could decompose a system entirely into MMFs. An MMF obviously costs money to construct but also returns value - so it has both costs and returns.
However then we discovered that sometimes two or more MMFs both need the services of something that we can consider a physical implementation of the architecture (ie an AE) - such as a secure messaging system. So this created an analysis problem. Which MMF should we attach these AE costs to? Obviously they belonged to whichever MMF we ended up sequencing first.
From a process perspective it therefore makes sense to recognize AEs as valid elements to be built and sequenced. Our IFM heuristic works in such a way that an AE would NEVER get scheduled until it is needed by at least one of the MMFs because an AE doesn't provide any useful functionality on its own. It is useful ONLY because it supports the user requested functionality of the MMF. In other words secure messaging is ONLY important as it supports functionality such as an ATM user requesting information about their account balance or to support the user in transferring funds. Because an AE doesn't return value on its own - we see it as a cost incurring element, drawn into the sequence as and when it is needed by an MMF.

[Tina Coleman]

Do you handle interrelated Architectural Elements? E.g., AE1 is dependent upon AE2. MMF1 needs AE1 but doesn't explicitly care about AE2. I'd assume AE2 would just tag along for the ride in AE1?

[Jane Cleland-Huang]

Well if AE1 is dependent upon AE2, and MMF A upon AE1 then it implies that MMFA also needs AE1. If that is not the case then it would probably indicate that you didn't do a sufficiently fine-grained decomposition of the AEs. The idea is to decompose them sufficiently so that you only invest effort developing those parts of the architecture that you need for the current MMFs.
There are two approaches you can take - depending on whether you are in an agile or a non-agile project. For agile projects you can create AEs as you go! (ie no big upfront design). For other projects (and certainly this can also be done in agile projects too), you can design your architecture upfront according to the MMFs that you plan to build in the near future, but you can then decompose the architecture into AEs.
In either case, if you want to optimize the value of your project you should only build AEs as they are needed.

[Mark Denne]

Part of the elegance of IFM is that it treats AEs and MMFs equally. In other words, it's just as sceptical of doing the work associated with an AE as it is of an MMF. Whether it's an MMF or an AE, it has to emerge as the most compelling thing to do now (in comparison with everything else that could be done) in order to be the action recommended by the IFM heuristic.
This means that to a large extent we've transcended the traditional religious arguments about Architecture (should we do it all up front, or should we just do bits of it as and when needed?) that often characterize the debates between adherents to traditional and Agile processes.
By applying the same rules to AEs as we apply to MMFs we've ensured the same financial analysis and justification is demanded of Architecture as all other aspects of the project. At the end of the day, it allows us to answer the question "should we do all the architecture up front?" with a dollar figure - a monetary gain or loss against doing it "just in time".

[Ilja Preuss]

Originally posted by Mark Denne:
By applying the same rules to AEs as we apply to MMFs we've ensured the same financial analysis and justification is demanded of Architecture as all other aspects of the project. At the end of the day, it allows us to answer the question "should we do all the architecture up front?" with a dollar figure - a monetary gain or loss against doing it "just in time".

That's quite interesting!
Do you already have any experience on how often the analysis tends to suggest upfront development of architecture in contrast to just in time development?

[Jane Cleland-Huang]

Do you already have any experience on how often the analysis tends to suggest upfront development of architecture in contrast to just in time development?

I think we would have a hard time quantifying that. We can observe specific types of project in which upfront development makes sense. For example if the requirements are relatively stable it may make sense to build a slightly more extensive architecture upfront to save refactoring costs later. However this is VERY different from building the entire architecture up front.
We actually advocate upfront architectural design, but incremental development and delivery.

[Ilja Preuss]

Originally posted by Jane Cleland-Huang:
We can observe specific types of project in which upfront development makes sense. For example if the requirements are relatively stable it may make sense to build a slightly more extensive architecture upfront to save refactoring costs later.

Mhh, I'd think that there needed to be more requirements:
- our *understanding* of the requirements had to be relatively stable,
- our understanding of the desirable solution to the requirements had to be relatively stable, and
- the saved refactoring costs had to make up for delayed ROI because of the delayed delivery of the first features (if we deliver incrementally, of course).
Would you agree?

However this is VERY different from building the entire architecture up front.
We actually advocate upfront architectural design, but incremental development and delivery.

Which begs the question: what do we actually mean by "architecture"? XP, for example, advocates to develop a System Metaphor early in the project, a very high level description of a few sentences about how the system will work internally. Would that suffice for you, or would you want to go into more detail?

[vasu maj]

Are these terms (MMF and IMF) standardized ? Are they your own terminology that you are advocating that the industry should start using?
Just curious.
Thanks,
vasu

[Jane Cleland-Huang]

The terms MMF and IFM are both new - although of course Mark and I are both pleased to find that they are starting to be adopted as terms in peoples' conversations.
In writing our book, we felt that the new focus on software development as a value-creating activity was best expressed through the introduction of some new terms.