Understanding RUP roles
Do you think IBM Rational Unified Process,® or RUP,® defines more roles than you can remember? Read on! You'll discover a hidden pattern that will make remembering them a cinch. You'll also find guidance for making successful role assignments, based on your team members' personality types.
Trying to get your mind around the large number of roles in RUP can seem daunting at first. However, there is a pattern for remembering RUP roles that stems from an approach to mitigating one of the most significant risks in iterative development: knowing what to focus on in any given iteration.
The iterative approach to software development embodied in RUP urges practitioners to adopt two perspectives. First, it urges the team to understand the overall solution, and then in each iteration to re-evaluate and adjust the overall solution, based on the results of previous iterations. Second, it urges the team to focus deeply on one piece of the solution during each iteration -- building pieces of the solution with each subsequent iteration until the whole solution is complete.
The two views corresponding to these perspectives are often called the breadth view and the depth view. In an iterative project, you focus first on the breadth view, and then pick a piece to focus on in depth. Separating breadth and depth, as we do in iterative development, makes a project much more resilient to change. Not only is the breadth view easier to create, but also, when change comes, you can smile, shrug, and adjust the breadth view with little effort.
In contrast, a pure waterfall approach would focus on the depth and breadth views at the same time and never look back. However, if you attempt to do all the breadth and depth work at once, the work takes much longer, it's more tedious and difficult to change later, and it will probably be wrong in many places to boot! If the project team is forced to adjust the breadth of a project late in the game, then a lot of depth work will become scrap.
In other words, for the Project Management discipline, a waterfall project leader would create a plan for a one- or two-year project that covered the full time span, then detail all tasks for the whole plan. Such a plan would collapse very quickly when changes inevitably and adjustments were made.
In contrast, an iterative project leader would separate the breadth from the depth, create a coarse-grained plan for the breadth view that showed phases, listed the business case, and showed how estimates might change as the project matured. The depth view would be a detailed plan for a single iteration, perhaps six weeks in duration. This plan would be much more accurate and less prone to error than a plan that tried to guess all project details for a period of one or two years.
This iterative breath and depth approach is effective for all nine RUP disciplines, not just for Project Management.
Breadth and depth roles in RUP
RUP role definitions are consistent with the notion of separating breadth and depth. Personality types for breadth workers and depth workers are very different. Breadth work is quick, inexact, and resilient. Depth work takes much more time, requires attention to detail, and must be of significantly better quality.
Each of RUP's nine disciplines has one role that focuses on breadth for that discipline, and a different role that focuses on depth for the same discipline. Once you understand this basic principle, it is a whole lot easier to remember the roles. Table 1 lists each RUP discipline along with its corresponding breadth and depth roles, and briefly explains the roles' functions. I was able to construct almost the entire table from memory by simply following the breadth / depth pattern.
Table 1: Breadth and depth roles in RUP disciplines
|Discipline||Breadth role||Depth role|
|Business Modeling||Business Process Analyst|
Discovers all business use cases.
Details a single set of business use cases.
Discovers all requirement use cases.
Details a single set of requirement use cases.
|Analysis and Design||Software Architect|
Decides on technologies for the whole solution.
Details the analysis and design for a single set of use cases.
Owns the build plan that shows what classes will integrate with one another.
Codes a single set of classes or a single set of class operations.
Ensures that testing is complete and conducted for the right motivators.
Selects what to test based on the motivators.
Decides what tests should be automated vs. manual and creates automations.
Implements automated portions of the test design for the iteration.
Runs a specific test.
Oversees deployment for all deployment units.
|Tech Writer, Course Developer, Graphic Artist|
Create detailed materials to ensure a successful deployment.
|Project Management||Project Manager|
Creates the business case and a coarse-grained plan; makes go / no go decisions.
Plans, tracks, and manages risk for a single iteration. (Note that this discipline has only one role. Assigning the depth view to a project coordinator can provide relief for overburdened project managers.)
Owns the process for the project.
Creates guidelines for using a specific tool.
|Configuration and Change Mgt||Configuration Manager|
Sets up the CM environment, policies, and plan.
Change Control Manager
Establishes a change control process.
Creates a deployment unit, reports on configuration status, performs audits, and so forth.
Change Control Manager
Reviews and manages change requests.
(Again, note that breadth and depth roles are assigned to the same people in this discipline; assistant or associate managers in the depth roles would be helpful.)
Using MBTI personality types for RUP role assignments
A colleague of mine, Ruth Nantais, is an accomplished project manager who introduced me to the Myers-Briggs Type Indicator (MBTI). I now encourage my clients and students to discover their personality type with this instrument, and then apply this knowledge to determine whether they're best suited for breadth work or depth work. They can also use it to understand what pitfalls await them if they are assigned to a role unsuited to their type.
The second aspect of the MBTI suggests that people are either an Intuitive (N) or a Sensor (S). Intuitives are big-picture thinkers who can reach decisions quickly, using their "inner sense." These people may be well-suited for breadth work. Sensors, in contrast, tend to use their five senses to gather decision-making information. Their work tends to be more precise, which can be very valuable for depth work.
The fourth aspect of the MBTI suggests people are either Judgers (J) or Perceivers (P). Judgers tend to work better with schedules and have a strong need for closure. The latter is vital to depth work, which must be complete enough to serve as a basis for follow-on work. Perceivers, in contrast, prefer a freer reign, tend to be more creative, and do not feel the same need for closure. These traits are well-suited to breadth work, which requires an ability to look quickly at the big picture and then communicate about it (typically using UML), but also to acknowledge that the picture may be incomplete and will likely change as depth work is accomplished in each iteration. Judgers tend to create more complete, high-quality work, while Perceivers tend to work more quickly and be much more resilient to change when it comes.
So based on the above observations, we can conclude that the ideal breadth worker would be an NP, whereas the ideal depth worker would be an SJ. An NP would be able to create breadth views quickly and efficiently, and to change the view as the need arises. An SJ would be able to ensure the completeness and accuracy a depth view requires to drive future tasks.
Now, this doesn't mean that people who do not fall into these categories on the MBTI scale should be prohibited from taking on specific roles. If they have a strong desire to fill those roles, they should be able to overcome the challenges they are likely to encounter. As a team member, knowing your MBTI profile can help you focus your energy and compensate for personality tendencies if you're assigned to an opposing role.
However, as your team assigns people to RUP roles, be aware that if you assign NPs to fill depth roles, they may have a tendency not to focus on details. They will need to concentrate harder than an SJ counterpart would to achieve the same level of quality, and others may reject their work as incomplete several times before they get it right.
On the flip side, if you assign SJs to breadth roles, the risk is that they will take too long to complete tasks, mostly because they have a hard time keeping the level of abstraction high enough. They may continue to miss deadlines as they labor to make their work more "complete," and include too much detail in their breadth view, making it difficult to change.
Remembering RUP's many roles and their functions is far easier if you recognize that each discipline has its own breadth roles and depth roles. This division reflects an approach to mitigating an important risk in iterative development: choosing what system components to work on in detail in each specific iteration. Also, certain personality types are better equipped to perform breadth work, and others are better-suited for depth work. Knowing your Myers-Briggs personality profile can help you predict challenges you will face if assigned to a role that does not match your personality type. Although NPs are a natural fit for breadth work, and SJs are better-suited for depth work, you can probably learn to perform either type of work if you are motivated enough.