Software Architecture and Information Technology Perspectives

Understanding Model Driven Architectures

Introduction
Model driven architecture, or MDA, is the latest buzzword on the market. In short it defines an approach to creating architectures that are independent of platforms and thus vendors. This has been the holy grail of information technology customers that seek to reduce technology costs by reducing their dependence on a single vendor. While this concept may seem to be passe with the arrival of newer technologies such as Java, XML and web services, these technologies have not yet been supported by a methodology that seeks to leverage them.

Enter Model Driven Architectures.
A key driver of model driven architectures is its emphasis on open source. The use of opensource software reduces integration times for most major firms that deal with myriad technologies, vendors and service providers. The absence of clear standards for documenting software technologies and systems increases the complexity of integrating these systems. Furthermore, in the absence of significant knowledge about the internals of software any paucity of documentation or public knowledge cannot be circumvented. By enforcing the use of open source software, the MDA approach helps allievate this issue. Now in the presence of poor documentation or the absence of it, a developer can simply view the internals of the software to determine what is being done therein.

Necessities for executing Model Driven Architectures
With all the hype surrounding model driven architectures, there is a significant danger of this approach being a victim of its own publicity. Other past attempts to create a methodology that seemed promising resulted in poor results due to irrational expectations and inadequate knowledge of the assumptions of the approach. Some of the fundamental requirements for a successful model driven approach include
a) Committment to going the distance.
Every novel approach necessitates change. The magnitude of this change may vary. This change will result in a decrease in the efficacy of the executing team due to a number of factors such as learning curves, resistance, turnover of key employees and the like. It also necessitates a significant investment in time and resources before measurable benefits can be realized. Making the choice must mecessarily therefore be a well thought out decision.
b) Adequate training of the executing team
If execution is everything then it is imperative that the team tasked with utilizing the approach understand it and have the skills and knowledge to execute effictively. A haphazard attempt to utilize newer approaches without the right skill sets is a recipe for disaster.
c) Controlled execution to meet project deliverables
Changing an approach results in assumptions fundamental to a successful project plan being made invalid. Estimates that were fine tuned over a ten year time period with a different approach cannot be expected to be valid in the new scenario. Rules of thumb critical to meaningful project plans will have to be revisited again.

(c) 2004 Vivek Pinto
For more details please visit us at Wonomi Technologies

Special thanks to Dr Bill Pottenger as always

posted by vivek pinto @ 5:13 PM