Mikko Kontio, finlandés, presenta un breve documento en IBM Developer Works sobre las conveniencias de una arquitectura dirigida por modelo (MDA). Tanto desde el punto de vista de la conducción de los negocios, como desde el punto de vista de los diversos actores del area de TI. En pocas palabras, da un buen conjunto de argumentos en favor del estándar.
Para directivos:
MDA allows you to get more work done with the same people, or to do the same amount of work with less people. The time to completion on new projects will diminish radically, as will the time to make changes on existing systems.
La principal objeción:
In terms of cost, management will need to consider more than the price of tools. The biggest cost will be education, because not everyone in the organization will be familiar with MDA. Others may need time to become comfortable with the new approach. Therefore, the cost of the transition must be measured in time as well as money, but the end benefits should add up favorably.
Para analistas y diseñadores:
Analysts capture business requirements into a formal model. Because the work of capturing requirements is people-driven, most of it is the same regardless of approach. In MDA the formal model is Unified Modeling Language (UML), so your analysts will need to have a working knowledge of UML to implement MDA.
For the most part, the designer's job isn't affected by the transition to MDA. Designers turn analyst's models into more evolved ones, encompassing classes, state diagrams, detailed method actions, and so on. Because the designer's models are used to generate code, they must be detailed and precise. If your organization's UML tool uses executable UML, the designer will be able to more easily demonstrate the behavior of the model to customers.
Para arquitectos:
Company architects will likely be excited by your proposal to transition to MDA. MDA makes it much easier for architects to ensure that a system is implemented the way they designed it, from start to finish. As the system evolves, it will be easy to add new technologies, re-use existing code, or plug-in third-party modules. Performance tuning will be a snap using existing mappings, and documentation will always be up to date. As a result of these factors the overall quality of the system will improve, and fine-tuning it will be easier than ever. Most architects like to design and specify things before they are implemented, so for them MDA is a welcome change.
En todo caso, no suscribiría ciento por ciento la posibilidad de que la documentación esté siempre actualizada. No conozco (quienquiera puede desmentirme) herramientas del tipo MDA que puedan mantener como una colección integrada toda la documentación asociada. Por eso es interesante el concepto de Software Factory de Jack Greenfield, si el caso fuera que SF puede lograr esta integración.
Para programadores:
Every programmer knows how stupid it is to write the Customer class and its functions over and over. MDA cuts out much of that redundant work so that programmers can focus on more productive tasks like writing mappings to different platforms and fine-tuning existing mappings for specific reasons. Programmers put their platform expertise to better use this way, and they also get to concentrate on tough coding jobs that even the best MDA tools can't handle. With all the busy work cut out, programming can become more fun and also more challenging: programmers need to know their tools and languages well in order to work efficiently in an MDA environment.
Para testeadores:
Testing and maintaining are the grunt work of the development cycle, and MDA cuts out much of the worst of both. With the right tools, testers can generate test scripts directly from a system's UML model. This obviates the necessity of writing endless nearly identical test scripts and code fragments, allowing testers to focus on more crucial tasks.
Para mantenedores:
When not hunting down missing documentation, maintainers can usually be found frowning over out-of-date, poorly written documents that fail to yield the exact information they require. Not so with MDA, where the model is always current and applicable to solving real problems. MDA documentation is built in, which cuts down significantly on both frustration and high maintenance costs.
Agregaría que no sólo la documentación está integrada -aquí entendida en el sentido estricto del diseño del modelo-, sino que la inserción de cambios es simple, mucho más que la que se pueda pensar basado en un sistema no dirigido por modelo, dado que las partes están intrínsecamente integradas y articuladas, y un cambio se propaga en forma automática, reduciendo el alcance del problema a seguir la ruta del impacto, verificando conflictos que se pueden localizar en todos los casos, y a planificar las transformaciones que se deban implementar al ejecutar los cambios. (Hablando en términos generales; siempre puede haber excepciones).
Finalmente, adhiero a las recomendaciones de Mikko sobre la transición a la adopción de la arquitectura:
Convincing your organization to make the transition to MDA is only half the game: implementing the new approach is the second half. After you've adopted the MDA approach and settled on the tools you need to implement it, you'll want to embark on your first-ever MDA project together. Before you even launch the project, you should clearly spell out your goals. Admit that there is hype around MDA and explain its benefits, using the proposed project as an example. Make sure that everyone on the development team understands what you're aiming for. For example, if you want to generate a complete application, provide one or two examples so that people see it can be done. If you have a different intention, then clearly state it and provide examples to back up your goal.
Start with a good project that is small enough to process quickly. It's always best to introduce a new technology or approach with a project that is quick and relatively simple. After you've done a few smaller projects, everyone will have learned the basics and executing larger ones will be easier.
Make sure that everyone who needs support gets it. Project managers might be concerned about the amount of work involved in the new approach, the duration of certain tasks, and so on. Developers may be challenged by the unfamiliar techniques and tools. Having a knowledgeable expert or consultant on the job could be helpful in this phase of the transition.
Follow up is important. After the project is finished, make a final report detailing the successes and failures of the project. Be sure to record both -- plenty of praise for what worked as well as a clear discussion of problems and how they may be resolved in the future.
