This workflow defines the generic Capability Pattern used to create an enterprise level (EA), or business domain level (BD), or any other level of IT architecture. There are several paths through this workflow, the path that you choose depends on the purpose of your architecture effort, as well as the stage of the architecture effort. The possible paths through the UAM "Capability Pattern" are:

• Use Architecture – IT architecture deliverables are used to analyze the current or future architecture, to develop migration plans, to develop training materials and to consult with various stakeholders (i.e. providing guidance and advice, reviewing models for correctness, or for the initial development of plans);
• Define Architecture [Simple] – when time or resources are tight this path can be chosen. Things are simplified and existing information is leveraged in order to make this activity practical and useful.
• Define Architecture [Existing] – Often existing systems and services have not been defined in an architectural fashion, which creates problems when one needs to understand how they fit into a larger enterprise or domain context. This activity uses an approach similar to the “Simple Architecture” activity to create this architecture definition.
• Define Architecture [Moderate] or [Complex] – this should be the normal path when defining an IT architecture. On a moderately sized architecture effort with multiple locations, moderately complex interactions with other systems, and where the automation level is somewhat known, it may be cost-effective to combine the Logical and Technology Perspectives for architecture maintenance purposes. The process of arriving at the architecture is the same, but the logical models are not maintained once the technology models are developed. This means that the technology models must continue to include the fully manual tasks. It is however necessary to have a business level view for this size of architecture effort for communication purposes. This business level is a valuable tool for illustrating the impact of technology and re-engineering choices to management. It also serves to elaborate on the scope of the architecture effort in terms of the internal business operation. Three levels or views of the architecture are defined:
  • Define Business Models – this usual starting point describes the target architecture from the business perspective and using business language. Concepts of processing and technology are absent. This equates to the Computational Independent Model (CIM) using MDA terminology, or the “Scope” and “Business Model” levels in the Zachman Framework and DoDAF. 
  • Define Logical Models – this level introduces computational aspects into the models, concepts such as “server” and “storage” at the logical level. More detail is generally provided along with relationships between components. This equates to the Processing Independent Model (PIM) in MDA, or the “System Model” in the Zachman Framework and DoDAF.
  • Define Technology Models – This equates to the Processing Specific Model (PSM) in MDA, or the “Technology Model” in the Zachman Framework and DoDAF.
• Architecture Review – When architectures are completed a peer review is done to ensure completeness, consistency and comprehension among other things. Enterprise architectures would be reviewed by Domain architects, Domain architects would review Project architectures, etc. Business and domain experts would also be involved to ensure the IT architecture accurately captures the "system". 
• Architecture Decision – a number of significant decisions are continuously being made regarding the approach, patterns or technologies to be used within an architecture. This activity manages these decisions in a way that they can be publicized, reused or re–examined as needed.
• Start Architecture Project – in order to get the IT architecture project off on the right foot, this explicit step is defined.
• Maintain Architecture - IT architectures will be much more useful over time if they are maintained. A whole set of activities are defined to do this.

UAM also defines the set of Tasks, deliverables (Work Products) and the "Delivery Process" for creating architectures along with a generic governance process (See: Roadmap: Governance). There is also an extensive set of examples provided that use the templates and other resources included, providing a practical grounding in what information to capture and how it is presented in models, summaries and reports, and other artifacts (See: Guidance). There are many participants involved in the development of IT architectures; see: Guideline: Methodology Participants.