There is a lot of information about the UAM on this web site, but basically the UAM architecture framework (the set of models as defined in the methodology) is different from other approaches; and using this framework separates concerns for the target audiences in two ways:
- Vertically – the top-level perspective is for business people; the next level is a mix. The Logical models are where lots of decisions are made, both business and technical … they go together. The Technical Perspective is naturally very much aimed at all the techies involved, and the specific technology decisions that are required.
- Horizontally – the Data, Process, Location and People aspects are aimed at and of interest to different sets of stakeholders.
The other important difference from other approaches is that a methodical and logical approach (i.e., a well-defined development process) is used to define IT architectures. It is not hap-hazard or even arbitrary like many methodologies out there! And the architectures are complete — all interrogatives are addressed.
Finally, this methodology can be applied anywhere within the organization, from EA down to specific systems, and if carefully done all of these architectures are clearly related.
A simplified version of UAM is view-able online here: UAM Online. The methodology provides an overview of notations used and other background information, definition of the processes used in creating IT architectures, along with extensive help and guidance. Background information and the motivations for the creation of UAM, along with an introduction to the methodology is available here: Background.
The images below provide a simple introduction to the UAM methodology.
UAM Fractal Concept
Another important concept is that each of the perspective's viewpoints can be looked at as a fractal. Similar to the MDA concept where “one person’s PIM is another person’s PSM”, this IT architecture set framework can be applied in many different contexts: the enterprise level can be viewed as the “default”, but it can also be used at the business domain or business line level, the business departmental level, or in any other context desired. This context needs to be kept foremost in one’s mind when developing the architectural viewpoints; otherwise there will be misunderstandings and confusion. This concept is useful for example in defining more detail for a portion of an already defined architecture—a drill-down mechanism that also has the benefit of maintaining traceability, all the way back to business concepts, drivers, and requirements.