Background

The Unified Method Architecture (UMA) has been developed with the aim to unify the representation schemata and terminology of all method and process engineering approaches within IBM as well as to support the most important standards in industry.  Hence, as shown in the figure below, UMA has been developed in a collaborative effort by the architects of the IBM Rational Unified Process (RUP), IBM Global Services Method (GS Method), and IBM Rational Summit Ascendant.  In addition to this core group of architects, stakeholders of many other development process initiatives within and outside of IBM reviewed and contributed to the specification.  The specification itself has been submitted to the OMG as a proposal for the SPEM 2.0 standard.  Because, the RUP 2003 meta-model had been developed based on the current SPEM 1.1 standard, this SPEM 2.0 draft proposal can be seen as a significant but continuous evolution of that standard.

The main goal of this unification was to come up with one set of terms and data structures that allows all of these methods and processes to be expressed without losing key characteristics.  For example, UMA had to be designed to support many different lifecycle models: the RUP iterative development lifecycle, incremental GS Method lifecycles, and Summit Ascendant waterfall and iterative lifecycles.  In addition, terminology differences needed to be resolved: What RUP would call an Activity was called Task in GS Method, RUP would speak of Artifacts where Summit Ascendant would define Deliverables, and so on.

Changes in UMA for RUP 2003 Users

As a result of defining just one data structure and more importantly one terminology for all of these approaches, compromises and changes had to be accepted by all stakeholders. Although these changes might be disturbing to the current RUP user, on the long run they will benefit from one broadly used unified terminology and standardized way of expressing method content and processes improving communication about processes and facilitating reuse.  The following list summarizes the most important changes to the RUP 2003 meta-model.  The table at the end of this page provides you with a complete terminology comparison of all the key sources for UMA.

• Activities have been renamed to task: To provide a tighter link to process enactment and project management we renamed the lowest assignable units of work to Task, because this is the term most commonly used.
• Workflow details renamed to activity: Workflows are commonly expressed in hierarchies of activity diagrams (e.g. activity diagrams defined in the UML 2.0).  Although RUP only provided one level of workflow breakdown, UMA is designed to provide multiple levels of such a breakdown. Because the word Activity was more commonly used to express the elements of activity diagrams as well as the activity diagram itself, we decided to replace the name Workflow Detail used in RUP with the name Activity.  We realize that the shift in the usage of the word Activity might cause confusion with existing RUP users.  However, one important goal of the UMA work was to use terms in the way they are most commonly used in standards and industry. 
• Tasks (former RUP Activities) can be performed by many roles:  In RUP 2003 an activity was modeled as an operation of a role.  Customer feedback, a look at other process modeling approaches, as well as changes introduced in UML 2.0 indicated that this was a too restrictive way of modeling human behavior.  This approach did not allow expressing that some work was performed as a collaboration of different roles.  UMA addresses this issue by making Task an independent model element to which performing roles can be assigned as resources.  UMA therefore now allows several roles to be assigned to a task.  For backward compatibility, it still allows a primary performing role to be identified (being responsible for the task) as well as several additional performers.
• Refinement of the artifact concept: RUP only used the concept of artifact to define things that are used and produced in a development project.  UMA defines an extended taxonomy for these concepts.  It defines the general concept of work product, which has three different specializations (specific work product types): Artifacts (managed work products), Deliverables (packaged work products that will be delivered to a stakeholder for review), and Outcome (unmanaged, intangible work products).
• Different categorizations for work products and roles: In RUP, artifacts and roles were all categorized by discipline.  However, sometimes artifacts were used across disciplines and a categorization to only one discipline caused confusion.  In UMA different categories have been defined for work definitions (discipline for tasks and activities), work products (domain and work product kind), and roles (role sets). 
• Process Components renamed to Method Package: The concept of component is commonly used in many standards and technologies. Most applications of component link it to the abstraction of encapsulation defining a component as a black box which can be used via well-defined interfaces. RUP components did not fulfill this black box criterion. Also the SPEM standard defined packages as well as components. To be compliant to SPEM and the industry usage of the word component, we renamed Process Component to Method Package. (It is technically a 'method' because it can contain method elements or process elements.)
• Separation of method content elements from process elements: In RUP 2003 you created a new process by defining a new configuration and documenting manually in a development case artifact changes to standard RUP.  UMA provides extended concepts in addition to the configuration concept for tailoring processes.  It allows you to model concretely for a process what work defined in the method content you want to actually do in each phase, because you can easily add, remove, and reorder elements in the process structure, reusing or not reusing whatever you want from the method content. It achieves these features by a more clear separation of method content (e.g. tasks defined for disciplines) and the application of method content in process (expressed with activity diagrams and/or work breakdown structures) as well as the modeling of processes (i.e. creating new or adapted activity diagrams or new or adapted work breakdown structures).  It introduces a few new concepts such as descriptor that support this separation and achieve new capabilities for maintaining and reusing many different families of alternative processes and process parts all within the same configuration.

Terminology Comparison