EDABlog

One of the major differences between the  oft and bad used example of building Architecture  and Software architecture is people.  When you build a building people know how to pour the concrete and a few specialized roles are imported electricians etc  but with software we are expected to know all. If you have been writing Windows Forms apps for years if the new project is a web app it is expected  that you know write a web application , the only exception seems to be with languages people seem to except a C# programmer cant write VB or Java  - which is amusing as IMHO its probably easier to change language than to change roll ( Web /Service/Forms   or DBAccess/Logic/Gui or Procedural/OO)  .

As architects this is our number 1 problem , we worry about SOA , EDA better OO designs etc but unless you have the people the results are poor.

While some organisations wisely train these skills on lesser interim projects, in the majority the major projects get the attention and big changes.

When you begin your design consider your teams skills before anything else. Its better to do an important project in old technology eg VB forms and Databases then blood a team on SOA/OO . You will meet your deadlines and have far less issues.  If you have some people who are skilled its common to make your services OO/SOA/EDA and leave the client technology as tried and true.

This is especially an issue for SOA/EDA designers as you are caught in a catch 21 , you dont get the benefit unless you work with big/critical  systems  but you dont get the skills unless you start doing some smaller systems which will be over-engineered.