views:

86

answers:

2

At my company we are undertaking a large task of creating a new software architecture for our products. Our current architecture has been in use for many product iterations and lasted a long life and it is time for it to retire. The UI architecture is currently implemented in WTL/ATL 3.0 and COM.

We have just completed the design of the back end architecture, one that will stand the test of time as its predecessor has. However UI technologies move so fast that no one on our team has the expertise that I would consider required to lay a foundation that should last many years. We are currently targeting WPF for this architecture and considering various alternative strategies to help our lack of expertise with this technology. Some approaches we are considering:

  1. Have our experienced staff ramp up on WPF and work through an architecture - Concern with this approach is that the areas we need our UI layer to last and likely all of the learning’s required will not be gained until after many products have been implemented using this architecture.

  2. Bring in temporary expertise from a consulting firm to assist with the architecture and development - This approach is looking promising; suggestions on firms with expertise? Microsoft does not provide application and architecture consultants, so finding someone with the necessary expertise may prove challenging.

  3. Bring in a consulting firm for an architecture study and guidance session - Seems to be compelling as would provide our experience staff guidance while still allowing our domain knowledge to steer the direction of the architecture. May be difficult to find firms qualified for this type of service.

My question then to you is how have you resolved a similar situation where you must create a robust, rich, long stay architecture utilizing new technologies that your team does not presently have architect level knowledge of? Have you had success with any of the previously mentioned strategies, or are there other approaches I have missed completely?

In general I am not an advocate for working in this capacity with technologies that are unfamiliar to you. With that in mind, the user experience we believe WPF may provide will give us the capabilities we want to utilize for many years. At any rate you have to start somewhere. ;-)

+3  A: 

First off, WPF is probably a good choice. This is being embraced by Microsoft, and really seems to be the direction things are going for long term development. I recently made a very similar decision to this, and decided to go with WPF. After the initial pain that comes with a new tech., it's proving a very good decision.

That being said, I'd highly recommend a mixture of 2 & 3.

If you can find a good consultant to help with the design, you should be able to bring them in to help you with the design and architecture phase, some initial construction of the project, and they can potentially also help your developers get up to speed. Having help in house (or at least on-call) will be tremendously helpful in getting the through initial phases of trying to develop with WPF.

It also helps to bring in a developer and/or designer who has experience working with WPF.

Reed Copsey
+4  A: 

You have to learn your chosen GUI eventually.

As one of those outside consultants that comes in for these kinds of projects, I suggest a variation on option #2.

  • Engage one or two outside consultants.

  • Have them guide you through something like your option 2. You actually learn WPF and then (with their help) develop the architecture and implement it.

Your follow-on question ("suggestions on firms with expertise") is disturbing. If you don't have trusted technology partners, now is the time to start cultivating them. It will take a while to locate folks you can trust.

The only way to locate them is to pay them to do some work and see if you like them and the work. This process can take a long time.

Problems with doing #1 by yourself are the obvious ones. If you try to do this on a deadline without experts, you'll make mistakes. You'll cast those mistakes into concrete. You'll try to live with them forever. When learning something new, the calendar is the most dangerous thing imaginable.

Option #1 works when there's no time pressure. You build something disposable while you're learning. Then build something which you know that you will have to throw away. Then build the real thing.

Problem with doing #3 is that you may be asking consultants to do too much. If they plan your architecture, you probably won't completely understand it. You'll cut corners and bad things can happen. If -- on the other hand -- you do it yourself, you'll understand why those corners shouldn't be cut.

Also, #3 is an opportunity for piling in every feature you think might be cool. Until you understand the technology, you don't really understand what's essential, what's easy and what's hard. You're very likely to demand something that's expensive and risky because it's difficult to understand exactly how expensive and risky it is.

S.Lott