Hopefully, this question is not too open-ended...I have been tasked with taking a 3 year old application (.NET 4.0, WPF, WCF, EF 4, SQL 2008) that was designed for a very specific market X and re-purposing it for a another very specific market Y.To further complicate things, the company has also mentioned a third market Z, but that may be a year+ down the road. But its definitely coming.The deadline for getting the application Y ready for market is aggressive. It might be negotiable, but just assume its a matter of 2-3 months.I have been working at the company for a while, and I was very intimately involved with the initial creation of application X, and I am still involved with the maintenance.The new application Y is interesting because there is some overlap between the features required for X and Y. For example, let A, B, C, D, and E be features and let  (prime) denote an enhancement to a feature. All of the following scenarios are valid:---X---|---Y---    ---Z--- (down the road)   A   |   A   B   |   B   C  |   C       |   D   E   |Some features can be merged from X to Y as-is (A). Some features from X must be enhanced before they can be merged into Y (B). Some features in X will not be in Y at all (E), and Y will contain features that are not in X (D). You get the idea.Here are my questions:(1) In the eyes of upper management, they ultimately see 3 different applications - one for each market: X, Y, Z. Moreover, they see 3 different copies of the same feature A that will need to go into each application. As discussed, there may be some enhancements that will make it to select products, but at the core, they are nearly identical.Sometimes I'm guilty for finding excuses to use the latest programming trends, BUT I think there's a strong business case here for utilizing the Managed Extensibility Framework (MEF). Why have 3 different physical applications (and hence 3 code bases) when it could really be one next generation application with plug-able features through something like MEF? There are several benefits that something like MEF could bring to the table.Does an extensibility solution like MEF seem valid in a case like this?(2) Given the limited time to get application Y to market...(a) Should I go with a conservative approach and simply give management what theyre asking for, i.e. make a deep copy of X and modify it for Y? Perhaps there will be time after Y goes to market to develop a more ideal and extensible solution? My past experience with this company has seen demos become fully-fledged products within no time  if you get my drift ;)It could very well be more difficult to modify X code to make it work for Y rather than it would be to create Y from scratch and import X features.(b) Leaving X alone for now, should I create Y with MEF in mind. Features from X can easily be imported into Y. If this is done properly, Z should be easy to implement. It will probably be a risky undertaking to go back and address X to fit into this framework since it's so widely used, but it could be done on the side with no specific deadline.I have to pitch this to upper management. Any advice or thoughts?
Architecting related products for different markets: MEF?
design;project management;architecture;mef
Some thoughts:Upper management very likely doesn't know or care what MEF is.  If asked, they'd likely want to know that it will get them a solution sooner and cheaper than otherwise.  That's a tough promise to keep if you are still learning the framework.Do you really want to be learning a new framework at the same time you're implementing Y with an aggressive deadline?Regarding Z in a year - what if definitely coming turns into maybe someday? or never?My recommendation would be to implement your choice (2)(a) - give the folks who sign your paycheck what they ask for.  Copy X into Y and revise.  Naturally, this isn't an ongoing pattern.  Learn MEF on the side with no specific deadline.  That way you're not risking your deadlines and you can afford to make mistakes as you climb the learning curve.If/when Z becomes a real project, you'll be in a good position to implement it with 'known technology' and probably refactor the other two into a more general solution.