| We described the Zachman Framework, the OMGs, Model-Driven Achitecture (MDA), and the Unified Modeling Language (UML) in Chapter 5. Are these approaches agile? This is actually a trick question because the answer depends on how you choose to implement them. Each of these techniques makes it really easy to overcomplicate your modeling efforts, to make them harder than they need to be, and to motivate you to write more documentation than you really need. For example, you can apply the artifacts of the UML in a very agile manner, something that agile modeling aptly demonstrates, or you can apply them in an incredibly dysfunctional manner. You could easily apply the principles and practices of AM to the Zachman Framework and make it very agile. Or you could use the Zachman Framework to justify a complex and documentation-heavy modeling process that requires a large architecture group to administer and control. It's your choice. Table 7-1 summarizes strategies for how each technique could be used in an agile manner. Table 7-1. Strategies for applying each technique in an agile manner.Technique | Strategies |
|---|
Model-Driven Architecture (MDA) | Keep it simple. Adopt the concept of platform independent models (PIM) and platform specific models (PSM), with mappings in between, but keep them agile by ensuring that they are just barely good enough. Adopt good tools based on the MDA that add value to your efforts. Avoid documentation-heavy, bureaucratic processes centered around the MDA. Remember that your goal is to develop working software, not to create lots of fancy models and documentation. | Unified Modeling Language (UML) | Keep it simple. All developers should have a thorough grasp of UML modeling techniques, including knowing when to use them and when not to use them. Adopt the values, principles, and practices of Agile Modeling. Remember, UML is not complete but defines the core of your modeling techniques. | Zachman Framework (ZF) | Keep it simple. Adopt the concept that your architecture efforts must reflect a wide range of perspectives. Adopt an augmented form of the ZF, renaming the "Data" column to "Structure," to avoid methodology bias. Avoid documentation-heavy, bureaucratic processes centered around the Zachman Framework. Remember, your goal is to develop working software, not to create lots of fancy models and documentation. |
|
