Where i'm at now there's a separate architect dept. I've actually heard these bozos say they don't need to understand the business processes to create a good data model. On the last 2 accting systems i've worked on, they have surrogate keys in the account code table. So the surrogate key is also in the transaction table. Similar in some other code tables.

This means that any report needs at a minimum 5 or 6 joins. And there's not always proper indexes. So they can't figure out why reports run so slow. In another sub-system some of these same people normalized the data to such an extent that some what you would think of as simple inserts, need to update 8-10 tables.

They actually paid MS big bucks to send in some experts to tell the company why the system was so slow. If an insert required updating 8-10 tables, reporting was extremely hairy. When they first went live, if 2 people ran the wrong reports at the same time, it locked up the entire system.





>>I've been working extensively with ASP.Net recently with VB code and I gotta tell you...it's just not that hard. Sure there are some weirdnesses and unintuitive stuff but one could say the same for VFP. Years ago I posted that VFP people could take over their world because we understand architecture and they only understand code syntax. With my latest experiences, I still believe that.
>
>You should work on some java projects in large IT departments (insurance, bank). At least over here I find them to be "overarchitecting" as a group while the best people manage to create a workable architecture and implementation by keeping "code" (sometimes "byte code" <g>) still on the radar. But perhaps it is worse in germany (seriously meant).
>
>Also remember that not all vfp frameworks automatically give you a nice and workable n-tier solution. I actually think current web platforms like ROR or Grails "teach" better architecture by creating clean MVC-patterns while still fitting into the RAD corner of development.
>
>regards
>
>thomas