I work for a company with about 350 employees and we are in the process of growing. Our current codebase is not structured very well and we are looking both at how to improve it immediately (by organizing objects into namespaces, separating concerns, etc.) and moving to a model driven architecture approach, where we model and design everything first with uml, then generate code from that model. We have been looking heavily at Sparx Systems Enterprise Architect (EA) (which is UML 2.0 capable) and we are also considering the tools in VS 2010. I know there are other tools out there (Rational XDE being one) but I really do not think we can spend $1500+ per license at this point.
I'm not looking for answers on which tool is better than another but more for experiences moving from a cowboy coding environment (that is, little planning and design, just jump in and start coding) to a model driven architecture. Looking back was it helpful to your organization? What are the pain points? What are the risks? What are the benefits?
Our current codebase is not structured very well and we are looking both at how to improve it immediately [...] and moving to a model driven architecture approach, where we model and design everything first with uml, then generate code from that model.
First, it's great that you and your company realize that there are some deficiencies in your software development process and that there is a willingness to improve.
It seems like however that there is quite a bit of work in front of you, and many things to improve in different directions. My first advice would be to not try to change everything at once. People are generally reluctant to changes, and everybody needs some time to digest new changes. It's also very important to create a common understanding about what needs to be set up. This common understanding will not be created in one day. Such change require a mid- or long-term commitment.
Then, regarding MDA, it's important to notice that it requires some discipline. Depending on your team, the first part might well to work on that first in a way to prepare the next step, which would be to introduce MDA. I'm saying that because you say you have a "cowboy" process, which means people are probably used to do whatever they want -- it's a no-go for MDA.
Then comes the introduction of MDA itself. There are various way to do MDA (and I won't expand about thsat here), but the still predominant way to do it, is the so-called round-trip engineering. The biggest problem then is to keep the model and the source synchronized.
( My take is that MDA leads to a positive return on investment only if the model can be reused for several projects. This means that you must have identified the things that you do over and over, and have a sufficient clear view on the problem to be able to create a sufficiently complete model and transformations that you can reuse across project. I don't believe that MDA works if each project is completely different; the time spent to get the model right and the transformation, etc. will be bigger than working only with code and documentation. )
Another appraoch is to not do MDA completely -- you don't generate code from the model -- but to increase the awareness of people about modeling and design issue, e.g. with UML. This way you won't face round-trip issue but still improve the maturity of your software development process.