IBM WebSphere Platform User Roles

IBM WebSphere Platform
User Roles
Birgit Schmidt-Wesche
IBM WebSphere Platform User Centered Design Architect
[email protected]
Note: Before using this information and the product it supports, read the information in
“Notices” on page 41.
© Copyright International Business Machines Corporation 2003. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by
GSA ADP Schedule Contract with IBM Corp.
ii
Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
Chapter 1. Introducing the WebSphere
Platform user roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Defining the scope of the WebSphere Platform user roles . . . . . . . . . . . . . . . 1
The benefits of working with user roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Chapter 2. Defining the WebSphere Platform
user roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
What is a user role? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The defining elements of the user roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The distinguishing characteristics of the user roles . . . . . . . . . . . . . . . . . . . .
Examining the definition of a user role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
6
6
7
Chapter 3. WebSphere Platform technical
user roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Organizing and describing the user roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Business Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Product Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Solution Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Security Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Application Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
User Interface Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Information Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Internal Tools Developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Solution Integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Solution Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Solution Deployer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
System Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Secondary user roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Appendix A. Other perspectives on the
concept of user roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Actors in software engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Goals and personas in interaction software design . . . . . . . . . . . . . . . . . . . . 42
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
iii
Abstract
The purpose of software is to improve the life of users by facilitating the tasks that they perform.
Therefore, to build successful software, it is essential to understand our users and their tasks and
focus on them throughout the development process.
IBM® WebSphere® lead architects and human factors specialists met with customers, and
together they defined a set of 12 technical user roles:
!
!
!
!
!
!
!
!
!
!
!
!
Business Analyst
Product Installer
Solution Architect
Security Architect
Application Developer
User Interface Developer
Information Developer
Internal Tools Developer
Solution Integrator
Solution Tester
Solution Deployer
Systems Administrator
These user roles best characterize the user roles found in solution development that WebSphere
Platform products support.
Understanding these user roles benefits both IBM development teams and customers. IBM
development teams can design and implement software that supports the tasks of these specific
users. Customers can plan and deploy new solutions based on the users and tasks involved in
solution development. Both teams can use the set of user roles as a common basis for
communicating requirements or potential design changes.
This paper describes each user role with their essential set of tasks, their associated skills, and
their most closely related roles. It also discusses how the user roles were defined, and finally, it
presents a set of secondary roles that are not directly targeted by IBM WebSphere Platform
products, but that are nevertheless important to the overall solution development process.
Who should read this white paper?
This paper is intended for the following people:
!
WebSphere Platform development team members, including architects, lead developers,
human factors specialists, information developers, and management
!
Customers’ development team members, including executives, business analysts, solution
architects, application developers, user interface developers, and information developers
iv
Chapter 1. Introducing the WebSphere Platform user roles
This paper introduces the set of WebSphere Platform technical user roles that are most typically
encountered in developing a business solution using WebSphere products. These user roles were
developed based on the insights gained from frequent visits to WebSphere customers to discuss
how they organize their solution development and who is involved in the process.
After introducing the scope and benefits of the user roles in this chapter, Chapter 2 defines the
key elements and distinguishing characteristics of the WebSphere Platform user roles, as well as
the different types of user roles. Then, Chapter 3 defines each of the WebSphere Platform
technical user roles in detail, including a typical use case for each role. Readers who are more
familiar with user roles might want to skip directly to Chapter 3.
Defining the scope of the WebSphere Platform user roles
The initial set of relevant user roles was quite large, with only minute differences between the
roles, which made it difficult to map the user roles to a particular development environment.
Customers continuously reviewed the consolidated and reorganized set of user roles using
surveys, teleconferences, and interviews during customer visits. After all these reviews, the final
12 WebSphere Platform technical user roles described in this paper best represent the current
environment at the WebSphere Platform customer sites.
The current set of WebSphere Platform user roles is based predominantly on solution
development in large enterprises. In smaller companies we may see the same type of user roles or
a subset of them, including the merging of user roles. Further customer contacts will provide
more profound evidence for the user roles encountered in small and medium size businesses.
WebSphere Platform products support the development of business solutions by providing the
appropriate infrastructure software. Accordingly, the set of user roles for the WebSphere
Platform products consists of technical user roles. The set of user roles does not extend to the
business user roles of a business solution.
The WebSphere Platform products rely heavily upon Data Management, Tivoli®, and Lotus®
products to provide data storage, solution management, and collaboration within the solution
development environment. To ensure that the WebSphere Platform technical user roles aligned
with these other product areas, these user roles were reviewed for their similarities and
differences to these other products.
1
Leveraging
Know-how
Leveraging
Reach
Reach Business
Business
&
Information
& User
User Process
Process
Experience
Experience Management
Management
WebSphere
Platform
Foundation
Foundation
and
and Tools
Tools
Managing and Securing
Figure 1. Scope of user roles: The WebSphere Platform
The benefits of working with user roles
The set of typical user tasks are the core element of each user role. The better IBM development
understands these user tasks, the better the WebSphere Platform products can support our users.
By organizing the typical tasks into a common set of user roles, IBM development teams and
customers can more readily share experiences throughout the solution development process. For
users, the user roles provide a vehicle for communicating their requirements and specific
business needs for certain tasks and user roles. For IBM development teams, the user roles aid in
understanding cross-product tasks encountered in solution development and aid in mapping
requirements from multiple products into their own products.
For customer enterprises that are planning to develop a new business solution, the set of user
roles can help customers understand the extent of tasks involved in developing business
solutions. Having a complete understanding of the user roles and their tasks, customers can
effectively plan workloads, resources, and staff for their future e-business development projects.
2
The WebSphere Platform technical user roles are intended to be valid across arbitrary solution
development environments. Because this list of user roles is a generic set of user roles, they do
not always map directly to a given business solution involving IBM WebSphere Platform
products. In an actual development environment, these user roles will be modified and used in
one of the following ways:
!
!
!
Directly applying the generic set of user roles
Creating a more comprehensive, higher-level set of user roles from the generic set of user
roles
Creating more specific, detailed user roles from the generic set of user roles
Thus, for specific solution development environments, the number of applied user roles can vary.
A difference in type, however, like for example the inclusion of a Database Administrator,
suggests leaving the scope of solution infrastructure and entering the realm of data management.
Data Management products have their own set of generic user roles, which is adjoining to but
distinct from the set of WebSphere Platform user roles.
3
Chapter 2. Defining the WebSphere Platform user roles
User roles enable both IBM development teams and customer development teams to design and
implement products that support their business needs. User roles come in many shapes and sizes,
but are always clearly distinguished by their tasks, in the case of the WebSphere Platform by the
tasks of a solution development process.
The 12 key user roles in solution development environments of WebSphere Platform product
customers are as follows:
!
!
!
!
!
!
!
!
!
!
!
!
Business Analyst
Product Installer
Solution Architect
Security Architect
Application Developer
User Interface Developer
Information Developer
Internal Tools Developer
Solution Integrator
Solution Tester
Solution Deployer
Systems Administrator
In addition to the primary roles listed above, the following set of secondary user roles (which is
not an exhaustive list) are indirectly or partially involved in the solution development process:
!
!
!
!
!
!
!
!
CTO and CIO and CEO
Project Manager
Enterprise Information System Developer
Translator
System Operator
Network Administrator
Database Administrator
Customer Support Representative
Before describing each of these primary and secondary user roles in Chapter 3, this chapter
explains how the IBM WebSphere Platform development team defines and distinguishes user
roles.
What is a user role?
A user role is not a real person. ‘A user role is an abstract collection of needs, interests,
expectations, behaviors, and responsibilities characterizing a relationship between a class or kind
of user and a system’ [Constantine and Lockwood, 1998]. When users assume a particular
relationship to a system at a given point during the development process, they assume a certain
user role. This relationship can be quite diverse. During a solution’s life cycle, one person might
4
perform multiple roles, even during the course of one day. Likewise, one role might be
performed by several people, such as instead of one person acting in the role of Product Installer,
an entire installation department is required. (Throughout this paper, the names of user roles are
capitalized.)
From a WebSphere Platform perspective, user roles are centered around user tasks. Further
attributes of the user roles pertain to skills, in terms of particular knowledge of a business
solution, and specify the user roles that are most closely related to them. From other perspectives,
user roles might be associated with goals, which then translate into tasks. For more information
about actors, goals, and personas, see Appendix A.
Business user roles versus technical user roles
The two types of user roles are business user roles and technical user roles. Business user roles
refer to the tasks of the end-users of a particular business solution. Technical user roles refer to
the tasks of the people that create that business solution. WebSphere Platform products support
these solution developers, and thus the WebSphere Platform set of user roles consists of technical
user roles.
For example, consider a financial services company that strives to provide a consistent customer
treatment across all of its channels, which include the World Wide Web, the telephone, and
personal appointments. In this company, the two business user roles are Financial Services
Customer and Financial Services Advisor, who might be engaging in a dialogue about a private
loan. Within this same company, the employees who develop and maintain the financial
applications that support this business assume the technical user roles of Application Developer
or System Administrator, among other technical user roles like Solution Architects, Security
Architects, or Solution Deployers. Or, consider an insurance company where Claims Handlers
work with their customers, the Claims Submitters, where Claims Handlers and Claims
Submitters represent the business user roles. The technical user roles involved in developing the
insurance claim application are likely to be the same as in the financial services company.
These two sample companies illustrate a key difference between business user roles and technical
user roles. While the technical user roles are similar across solution development environments,
the business user roles are highly specific to the particular business environment.
In addition to the technical staff involved in creating a business solution there are the company’s
non-technical staff, such as project managers and executives. They, too, are considered to be
business users. Also, because of their vital role in overall solution development, they are listed as
secondary roles (see the end of Chapter 3 for more information about secondary user roles).
5
Roles in large versus small and medium size businesses
The size of a business affects the definition of user roles. The WebSphere Platform technical user
roles are based on solution development within large enterprises. The solution developers at the
large enterprises adopted many of the WebSphere Platform technical user roles.
In smaller companies, the same type of roles, or a subset of them, might be present. However, the
smaller the company, the more likely that the user roles will be merged. This does not necessarily
mean that fewer and fewer people will have to perform more and more tasks. Instead, it might
mean that in smaller companies the scope of the tasks might not be as extensive as in larger
companies and some of the tasks might not be relevant. Accordingly, a subset of tasks from one
user role might be merged with similar subsets of tasks from other user roles to form a more
appropriate user role in the context of smaller companies. The type of user roles is also
determined by the type of company. For example, independent software vendors are likely to
have an elaborate set of Application Developer user roles, while they might not have a separate
System Administrator user role. Instead, the few necessary tasks in that user role would be
associated with the Application Developer user roles. Or, perhaps those tasks would not be
associated with a user role at all, but be automated and covered by the system.
The defining elements of the user roles
Based on numerous discussions with customers who use the WebSphere Platform products in
their solution development, the WebSphere Platform user roles contain the following three key
elements:
!
!
!
Typical tasks
Skills (in terms of expected solution competency)
Most closely related roles
Because the user tasks are the core element of a user role, each user task is assigned to only one
user role. Because of this association, the user roles more adequately capture the variety of user
roles and more accurately differentiate one user role from another user role. The skills are not
associated with a certain level of education, but with the knowledge required during particular
development stages of a business solution. Finally, because people do not work in isolation, but
work closely in teams, each user role also lists the most closely related roles to create a network
of user roles upon which to rely.
6
The distinguishing characteristics of the user roles
When is a user role a user role? Although it is possible to define one user role for each task, the
WebSphere Platform development team did not follow this extreme definition.
To reasonably limit the scope of a user role, the WebSphere Platform technical user roles adhere
to the following two main criteria:
1. Each user role includes a sufficiently large set of user tasks
The “sufficiently large” set of tasks is the set of tasks performed by one person as their
primary responsibility. However, the same person might perform other tasks, most likely
the tasks of closely related user roles. For example, because the tasks that a Samples
Programmer performs overlap with those of an Application Developer, and they do not
require a full-time person, the list of WebSphere Platform technical user roles only
includes the Application Developer user role.
2. Each user role has direct technical involvement with the development of a business
solution using IBM WebSphere Platform products.
For example, the WebSphere Platform technical user roles include a Solution Deployer
but do not include a Database Administrator, because that user role is addressed in the
context of developing data management products, such as IBM DB2® Universal
Database. Similarly, the WebSphere Platform technical user roles do not include Network
Administrators or Enterprise Information System Developers, because those roles are
outside the context of WebSphere Platform products.
The primary set of technical user roles adhere to these two characteristics. Nevertheless, some
roles excluded from the primary set of WebSphere Platform technical user roles are still
tangentially important to the development of a business solution. For more information about
these secondary user roles, see the end of Chapter 3.
Examining the definition of a user role
To fully appreciate and understand how the WebSphere Platform development team defines user
roles, consider the Solution Architect user role in a large enterprise. The Solution Architect is
responsible for the design of the business services to be developed and needs to continuously
communicate with both an enterprise’s business representatives and its development community.
The business representatives instruct the Solution Architect on the business requirements, and the
developers need to understand the planned development steps.
The Solution Architect user role meets the two distinguishing characteristics. First, the Solution
Architect is directly involved in the solution development process, and therefore it is a primary
user role. Second, the amount of tasks that the Solution Architect performs is sufficiently large
7
such that one person would predominantly act in this role. (In smaller companies, a lead
Application Developer might perform a core set of these tasks.)
The following list shows the set of tasks most typically associated with the Solution Architect
role:
!
!
!
!
!
!
!
!
!
!
Designs an enterprise or line-of-business level of a new solution, application, or function
based on the specified functional and non-functional business requirements
Writes application design specifications, including clear specifications of functional and
non-functional requirements for the solution
Modifies existing services to react to new requirements
Designs the optimum IT infrastructure for a given business solution
Plans system upgrades and roll out of new capabilities (applications and products)
Defines expected behavior of services in terms of performance, service levels, and so on
Analyzes the behavior of the IT infrastructure over periods of time to highlight any trends
or variations in system performance
Defines the task flows for enabling the business service
Interacts with business people to understand a particular business process or business
requirement
Interacts with application developers to convey business requirements in technical terms
In addition to these tasks, a Solution Architect needs the following skills or knowledge with
respect to the intended software solution:
!
!
!
!
!
Has a sufficient understanding of the business goals of the business services to be
developed
Understands industry patterns and approaches related to the business solution
Might have special knowledge of particular aspects of the business (for example, billing,
manufacturing, and so on)
Has sufficient technical skills and understanding of the IT infrastructure in order to
architect the mapping of business goals to technical solutions compatible with the current
IT infrastructure
Has the ability to communicate the requirements of a solution in terms of non-technical
business aspects as well as in terms of technical development aspects
Finally, a Solution Architect works closely with the people who adopt the following closely
related user roles:
!
!
!
Business Analyst
Security Architect
All main solution development & deployment roles:
! Application Developer
! User Interface Developer
! Information Developer
! Internal Tools Developer
! Solution Integrator
! Solutions Tester
8
These tasks, skills, and colleagues appear very realistic, but remember that a user role is ‘an
abstraction, not a real person, not a job title, not a position, not a function. It is not even a real
group of people, but rather an abstract class defined by a particular kind of relationship to the
system’ [Constantine and Lockwood, 1998].
9
Chapter 3. WebSphere Platform technical user roles
This chapter describes how the user roles are organized and presents the detailed descriptions of
the WebSphere Platform technical user roles, which includes their essential set of tasks, the
associated skills in terms of solution competency, the closely related roles, and a typical technical
use case for the user role.
Organizing and describing the user roles
To more fully define and refine the WebSphere Platform technical user roles, the user roles have
been organized by task domain, compared to the Java™ 2 Platform, Enterprise Edition (J2EE)
roles, and considered within the context of technical use cases— all of which helps organize and
describe these technical user roles.
Organization of user roles into task domains
The WebSphere Platform technical user roles are organized into four task domains, which
represent the linear (though oversimplified) order of integrating a business solution into a
customer’s environment:
1.
2.
3.
4.
Business analysis (including decision making)
Up and running - unpack, install, configure
Solution development and deployment
System administration and operation
The primary technical user roles are organized as follows in the task domains:
1. Business analysis
! Business Analyst
2. Up and running
! Product Installer
3. Solution development and deployment
! Solution Architect
! Security Architect
! Application Developer
! User Interface Developer
! Information Developer
! Internal Tools Developer
! Solution Integrator
! Solution Tester
! Solution Deployer
4. System administration and operation
! System Administrator
9
By organizing the user roles into task domains, the user roles are more coherent and consistent
within and across each user role. For example, Solution Deployers are distinct from System
Administrators in that they deploy and manage the solution, not the system or environment in
which it operates. Other categorizations are possible, especially in other product areas, such as
the Data Management products, which categorize their user roles into the following less linear set
of task domains: operations, application programming, integration, architecture, and solutions.
The task domains help to create the distinctions between the user roles, while making the
descriptions of the user roles more cohesive. Because the WebSphere Platform technical user
roles are mapped according to the stages of solution development, it is easy to determine if a task
or a user role is missing when going from one stage to the next.
The relationships between the roles
The following diagram maps the 12 technical user roles across the task domains and shows the
interaction and collaboration between the closely related user roles.
Security
Architect
System
Admin.
Product
Installer
Solution
Deployer
Solution
Architect
Business
Analyst
Internal
Tools
Developer
Business
Analysis
Up & Running
Application
Developer
User
Interface
Developer
Solution
Tester
Solution
Integrator
Information
Developer
Solution Development & Deployment
Systems
Administration
Figure 2. Interaction and collaboration between the WebSphere Platform user roles across the
task domains
10
Just because one user role interacts directly with another user role for one set of tasks, the reverse
condition is not necessarily true. For example, a Business Analyst might work closely with an
Application Developer in modifying dynamic business rules. However, the Application
Developer will not necessarily work directly with the Business Analyst with specific
development questions, but instead work through the Solution Architect, who might consult with
the Business Analyst, if necessary. To understand how the user roles collaborate individually, see
the related roles section in the user role descriptions.
Relationship to J2EE user roles
The set of WebSphere Platform user roles take into account the set of user roles provided by Sun
in Java 2 Platform, Enterprise Edition (J2EE), version 1.4, [Nov. 2002]. When defining their user
roles, Sun states that ‘in an actual instance, an organization may divide role functionality
differently to match that organization’s application development and deployment workflow’. The
following table shows how the J2EE user roles compare with the WebSphere Platform technical
user roles:
J2EE user role
Application Component Provider
Application Assembler
Deployer
System Administrator
WebSphere Platform user role
Application Developer
Solution Integrator
Solution Deployer
System Administrator
Other J2EE user roles address the systems and tools necessary for the solution development
environment:
!
!
!
J2EE Product Provider
Tool Provider
System Component Provider
The IBM WebSphere product teams that provide the necessary infrastructure software for
business solution development could function in these roles.
Illustrating user roles with technical use cases
To ensure the usefulness of the technical user roles, a technical use case has been associated with
each user role definition. The technical use cases are taken from a repository of use cases
designed by the WebSphere Platform product teams. These use cases help to ensure a
cross-platform solution focus by identifying, architecting, and designing business scenarios that
customers are implementing to run their businesses. These business scenarios are then built and
tested at the solution level by simulating the various customer environments. The generic set of
user roles as defined in this paper were used in developing the scenarios and use cases.
11
Three prototypical business scenarios were investigated:
!
Private exchange
A retail application that features supply chain exchanges providing a one-stop shopping
focal point for a set of suppliers and buyers. Suppliers make their products available to
the exchange. Buyers shop at the exchange, using it as a source for product information
that they make available in turn to their customers.
!
Mergers and acquisitions
A business application that is based on the merging of two companies and the
consolidation of their currently disparate customer records. In this particular case
homeowners and auto insurance policy records; however, relevant industries could also
be banking, telecommunications, financial services, insurance, and manufacturing.
!
Customer loyalty
A business application that concentrates on enabling a company to provide a consistent
customer treatment over all possible channels (which include the World Wide Web, the
telephone, personal appointments, and so on). It could apply to many different industries
such as banking, financial services, retail, telecommunications, or insurance. The focus is
on the financial and banking aspects.
The teams design business use cases (involving business users), as well as technical use cases,
which are associated with the set of technical user roles affected by this technical use case. A
technical use case is translated into a specific test case, and testing is conducted according to user
roles.
12
Business Analyst
A Business Analyst is actively and fully involved in the solution development process, from
designing the business aspects of a new business solution to monitoring the running solutions
and checking their performance according to business needs. Business Analysts are also likely to
be performing minor technical tasks, such as creating or updating the content of, for example, a
Web site (posting notices or new articles, changing the configuration of a portlet, and so on). Or,
the Business Analyst, in close cooperation with the person acting as the Application Developer,
might define or modify dynamic business rules within an existing application.
Though the majority of the Business Analyst’s tasks focus on pure business tasks, their
involvement in technical tasks and their explicit interaction with the technical development
community justifies that Business Analysts be classified as technical user roles along with the
other solution development roles. In contrast to other members of an executive board, such as the
CEO, Business Analysts are fully involved in the solution development process, and the list of
tasks assigned to them is sufficiently large to justify the distinct user role of a Business Analyst.
Related user roles of Business Analyst
The following diagram shows the related user roles that Business Analysts are most likely to
interact with in the course of a solution development life cycle and the major tasks on which they
would collaborate:
[Designing new solutions]
Solution
Architect
[Validating test plans /
certifying solution]
Business
Analyst
Solution
Tester
[Defining / modifying
dynamic business rules]
Application
Developer
[Designing mock-up /
solution UI]
User
Interface
Developer
Figure 3. Collaboration pattern of Business Analysts
13
Typical tasks and skills of Business Analyst
The typical tasks and particular skills for a Business Analyst are as follows:
Tasks
" Advises on the current status and future
"
"
"
"
"
"
"
directions of business transactions in relation
to the business goals
Participates in purchasing decisions
Works closely with the Solution Architect in
designing new solutions
Advises the development team throughout the
solution development phase, writing detailed
requirements or business tradeoffs for the
solution
Works closely with the Solution Tester to
develop a plan to validate the solution after
delivery and establish test scenarios
If necessary, participates in the certification
of sufficiently tested solutions to ensure that
they meet the expected business goals and
that they are ready for production
In close cooperation with the Application
Developer, defines or modifies dynamic
business rules within an existing application
Creates or updates the content of, for
example, a Web site (posting notices or new
articles, changing the configuration of a
portlet, and so on)
Skills
" Is the specialist in the company's particular
business domain (finance, insurance, and so
on) and knows the particular business or
line-of-business extremely well
" Has basic technical skills to understand the
specific functions of the business to be able to
make and manage adjustments
Technical use case example for Business Analyst
The following technical use case is excerpted from the Private Exchange business scenario. It
shows how the Business Analyst and the Application Developer collaborate on the design and
development of a new shopping application, where a new catalog schema has to be created and
the enterprise’s information system data has to be aggregated and loaded into this new catalog.
The particular steps involved in this use case are as follows:
User Role
Business Analyst
Business Analyst / Application Developer
!
!
Application Developer
!
14
Use Case Step
Define catalog schema
Define the mapping between the catalog
schema and the definitions of the enterprise
information systems and the global repository
Populate the catalog repository with data
from the enterprise information systems and
the global repository
Product Installer
The Product Installer user role is a critical role for getting the products and components of the
solution up and running, from unpacking the files, to checking the prerequisites, to the actual
installation process, and often configuring the system with default values. This phase is
considered the customers’ ‘out-of-the-box experience’.
The Product Installer collaborates closely with the System Administrator and the Security
Architect to ensure the installation and default configuration are completed in accordance with
the requirements of the enterprise’s current IT environment settings and security policies. Then,
if the solution’s products need to be upgraded or migrated to new or different products, the
Product Installer works closely with the Solution Deployer to install the new product or
component versions within the running business solutions.
Related user roles of Product Installer
The following diagram shows the related user roles that Product Installers are most likely to
interact with in the course of a solution development life cycle and the major tasks on which they
would collaborate:
[Installing security specific aspects]
Product
Installer
Security
Architect
[Cooperate on product install, update & migration]
System
Admin.
[Cooperate on solution upgrade & migration]
Solution
Deployer
Figure 4. Collaboration pattern of Product Installers
15
Typical tasks and skills of Product Installer
The typical tasks and particular skills for a Product Installer are as follows:
Tasks
" Checks for and installs prerequisite products
" Installs required products of the solution on
appropriate machines
" Runs installation verification tests
" Configures the products with default values
" Administers the WebSphere Application
Skills
" Has a thorough understanding of hardware
and software components and their
distribution within the IT infrastructure
" Is familiar with the specific installation
procedures
Server, such as starting and stopping it
Technical use case example for Product Installer
The following technical use case presents a classical set of installation tasks, in which the
products need to be easily installed into a running environment, requiring minimal downtime. It
is assumed that the same hardware and network is used for both the existing and the new
solutions. The particular steps involved in this use case are as follows:
User Role
Product Installer / System Administrator
Product Installer
!
!
Product Installer
!
Product Installer
!
16
Use Case Step
Set up the admin user ID for the resources
Install the products, or ensure that they are
installed, in the proper order based on product
prerequisites or corequisites
Run a verification test or sample to ensure
that the installation was successful
If the installation was not successful or
adversely affects other solutions, roll back to
the previous installation base if this is an
upgrade, or uninstall the products if this is a
new installation
Solution Architect
The Solution Architect user role is the key role within the solution development process. Out of
the set of 12 user roles defined in this paper, the Solution Architect collaborates with eight of the
user roles during the development life cycle of the solution. This role is the bridge between the
business experts of the enterprise and the enterprise’s development community. The design of a
new solution, or the modification of an existing solution, has to adequately account for both the
business and the IT infrastructure requirements.
In the context of solution development, the role of Solution Architect has replaced previously
known user roles like the Systems Analyst. The analysis and planning tasks formerly performed
by a Systems Analysts have mostly been taken over by the Solution Architect.
Related user roles of Solution Architect
The following diagram shows the related user roles that Solution Architects are most likely to
interact with in the course of a solution development life cycle and the major tasks on which they
would collaborate:
Security
Architect
Solution
Deployer
[Verify solution's deployment]
[Design solution's security aspects]
Solution
Tester
[Design solution's business aspects]
Solution
Architect
Business
Analyst
[Instruct on tools to develop]
Internal
Tools
Developer
[Instruct on required interfaces]
[Verify solution test environment]
[Instruct
on required
solution
components]
Application
Developer
User
Interface
Developer
[Verify appropriate solution integration]
Solution
Integrator
[Instruct on required interfaces]
Information
Developer
Figure 5. Collaboration pattern of Solution Architects
17
Typical tasks and skills of Solution Architect
The typical tasks and particular skills for a Solution Architect are as follows:
Tasks
Skills
" Designs a new solution, application, or
" Has an understanding of industry patterns and
function at the enterprise or line-of-business
level, based on the specified functional and
non-functional business requirements
" Defines the interface of new business services
approaches related to the solution
" Has a sufficient understanding of the business
goals of the business services to be developed
" Might have special knowledge of particular
aspects of the business (for example, billing,
accounts payable, manufacturing, and so on)
" Has a sufficient understanding of the IT
infrastructure in order to architect the
mapping of business goals to technical
solutions compatible with current IT
infrastructure
" Writes application design specifications,
"
"
"
"
"
"
"
"
including clear specifications of functional
and non-functional requirements for the
solution
Modifies existing services to react to new
requirements
Designs the optimum IT infrastructure for a
given business solution
Plans system upgrades and rollouts of new
capabilities (applications and products)
Defines expected behaviors of service in
terms of performance, service levels, and so
on
Analyzes the behavior of the IT infrastructure
over periods of time to highlight any trends or
variations in system performance
Defines the task flows for enabling the
business service
Interacts with business people to understand a
particular business process or business
requirement
Interacts with application developers to
convey business requirements in technical
terms
18
Technical use case example for Solution Architect
The following use case shows how the Solution Architect translates the business scenarios into
an application architecture. The Solution Architect creates a document that describes the business
problem being solved, any of the constraints and issues that affect the architecture, and a
high-level, graphical design of the solution. The particular steps involved in this use case are as
follows:
User Role
Solution Architect
!
Solution Architect
!
Solution Architect
!
19
Use Case Step
Describe the business problem, the existing
IT infrastructure, and any corporate or
cultural aspects that might affect the solution,
such as the performance, reliability, and
extensibility requirements
Use a graphical tool (for example, Freelance
Graphics, CorelDraw, Visio, or Rational
Rose) to describe the business processes in a
way that they can be translated
(automatically, if possible) into IT resources
Ensure the appropriate mapping from the
customers’ development tools into the
relevant development repositories
Security Architect
Because business solutions usually are comprised of a large collection of products and
components, the security of the system demands careful planning, which is completed by the
Security Architect. The set of tasks for establishing adequate security for a solution is often
sufficiently large enough to justify the introduction of a separate Security Architect user role.
Among others, the Security architect closely collaborates with the System Administrator to
configure and administer the security aspects required for the given IT infrastructure.
Related user roles of Security Architect
The following diagram shows the related user roles that Security Architects are most likely to
interact with in the course of a solution development life cycle and the major tasks on which they
would collaborate:
[Instruct on installing
security related aspects]
Security
Architect
[Instruct on appropriate security administration]
System
Admin.
Product
Installer
[Co-design security related aspects]
Solution
Architect
Figure 6. Collaboration pattern of Security Architects
Typical tasks and skills of Security Architect
The typical tasks and particular skills for a Solution Architect are as follows:
Tasks
" Works with the CIO or CEO, or both, to
define the general policies for protecting
information assets for the enterprise
" Establishes and manages the policies and
mechanisms that control the privacy of the
access and distribution of information assets
" Conducts occasional or periodic compliance
reviews, including performing audits,
responding to external (legal) requests for
information, and reviewing system logs and
traces to detect anomalies
Skills
" Has thorough and current knowledge of
computer security technologies, current
issues, products, and so on, in order to apply
them to the particular IT infrastructure of the
enterprise
" Has a sufficient understanding of the entire IT
infrastructure in order to judge which
components need to be secured and how to
secure those components
20
" Participates in product purchasing decisions,
as they pertain to security issues
" Participates in architecture discussions and
reviews, as they pertain to security issues
" Revises security policies after intrusion
attempts into the system
Technical use case example for Security Architect
The following use case assumes that the Security Architect has completed the design of the
security infrastructure for the solution. The use case encompasses all the tasks associated with the
setup and configuration of the various products that are instrumental in implementing an
effective security infrastructure for the environment as well the products that need to interact
with the security technology the solution enables (such as Tivoli Access Manager, LDAP
SecureWay, Tivoli WebSeal, WebSphere Portal Server, and so on).
User Role
Security Architect / System Administrator
!
Security Architect / Systems Administrator
!
!
!
Security Architect / Systems Administrator
Security Architect / Systems Administrator
!
!
!
21
Use Case Step
Set up Tivoli Access Manager for operation
with the shared LDAP user repository
Set up Tivoli Access Manager for
authentication of WebSphere Portal Server
users, including single signon to all
applications
Set up the necessary components in the DMZ
if any (for example, plug-ins, Tivoli WebSeal,
and so on)
Set up and integrate all the relevant
components (that is, WebSphere Portal
Server, Lotus and Siebel products, business
applications, and so on)
Set up the inner and outer firewalls
Set up the authorization for various system
resources
Resolve how much authorization is delegated
to Tivoli Access Manager versus how much is
performed locally within each resource
manager
Application Developer
After the Solution Architect, the Application Developer is the second most prominent role in the
context of solution development. The Application Developer interacts with seven other roles on a
regular basis. In some companies, they might also act as the Solution Architect, in which case
you would rather find the role of a Lead Application Developer instead of an explicit Solution
Architect role.
The Application Developer user role is the most likely user role to be customized for a particular
business solution. For example, the J2EE specifications suggest possible refinements of their
corresponding Application Component Provider role into the roles of HTML document designers
and programmers and enterprise bean developers [Nov. 2002].
Related user roles of Application Developer
The following diagram shows the related user roles that Application Developers are most likely
to interact with in the course of a solution development life cycle, and the major tasks on which
they would collaborate:
Solution
Architect
[Translate design into component implementation]
[Implement changes to dynamic
business rules]
Business
Analyst
Application
Developer
[Synchronize tools
with component
development]
Internal
Tools
Developer
[Provide application components
for integration]
[Synchronize UI
with functional
development]
User
Interface
Developer
Solution
Integrator
[Synchronize information
with functional
development]
Information
Developer
Figure 7. Collaboration pattern of Application Developers
22
Typical tasks and skills of Application Developer
The typical tasks and particular skills for an Application Developer are as follows:
Tasks
" Develops the business services according to
"
"
"
"
the Solution Architect’s model
Decides on the specific implementation of
required task flows (workflows, message
flows, and so on)
Writes EJBs to wrap internal and external
resources
Unit tests each application component to
ensure it works according to the
specifications; that is, tests the validity and
basic performance of the developed
application components
In some cases, develops user interfaces, EJBs,
or servlet frameworks to contribute to shared
services for reuse within other solutions
Skills
" Understands parsers, editors, and generators
" Has a thorough understanding of the business
components involved in the proposed solution
and is able to program them as required, for
example:
- J2EE (new applications)
- Cobol (working with existing data)
Technical use case example for Application Developer
The following use case focuses on creating a new portlet using WebSphere Studio Application
Developer, possibly WebSphere Portal Server, and its Web Content Publisher component.
User Role
Application Developer
!
Application Developer
!
Application Developer
!
Application Developer
!
23
Use Case Step
Author the portlet in WebSphere Studio
Application Developer
Unit test and debug with WebSphere Studio
Application Developer to test the
environment or the external WebSphere
Portal server
Where necessary, associate the versioned
portlets with other artifacts in the Web
Content Publisher component
Publish the portlet and other artifacts to make
them available for solution integration and
deployment
User Interface Developer
The tasks associated with the User Interface Developer user role are sometimes covered by the
Application Developer user role, especially with smaller business solutions like some Web-based
applications. For larger enterprises, though, it is necessary to distinguish between the
system-oriented aspects of an application or solution and the user-facing aspects. Obviously, the
User Interface Developer closely collaborates with the Application Developer during the
implementation of the business solution.
Related user roles of User Interface Developer
The following diagram shows the related user roles that User Interface Developers are most
likely to interact with in the course of a solution development life cycle and the major tasks on
which they would collaborate:
[Translate solution's functions
and flow into UI elements]
Solution
Architect
[Translate system functions into UI elements]
User
Interface
Developer
Application
Developer
[Synchronize UI artifacts and flow with information]
Information
Developer
Figure 8. Collaboration pattern of User Interface Developers
24
Typical tasks and skills of User Interface Developer
The typical tasks and particular skills for a User Interface Developer are as follows:
Tasks
Skills
" Defines and creates task flow within the
" Has basic understanding of the business goals
front-end of the application
" Designs the windows to have a consistent
look and feel and exhibit ease of use, in
accordance with globalization and
accessibility standards
of the solution
" Has sufficient understanding of the users and
their tasks
" Has expertise in various user interface design
and development mechanisms and knows
which best to apply for which user task
Technical use case example for User Interface Developer
The following use case involves creating a solution management dashboard, which shows how
the user roles of the Application Developer and the User Interface Developer blend, because the
application is driven by visual cues.
User Role
User Interface Developer
User Interface Developer
!
!
User Interface Developer
!
User Interface Developer
!
User Interface Developer
!
25
Use Case Step
Create and code the JSP for the logon screen
Use existing widgets (for example, a bar
graph and meter) for the duration graph and
the per day graph
Create widget for the "top 5" table based on
the widget infrastructure
Create the dashboard JSP, which calls all the
widgets (graph, meter, and table) and feeds
the data from event infrastructure
Unit test the code
Information Developer
WebSphere Platform products should make it easier for the Information Developer to develop
user assistance components in a most synchronized way and even to directly derive usable
information units from the solution components for creating error messages, help texts, user
guides, or solution specifications. The Information Developer user role does not include the
translator of information, which is considered one of the secondary roles for the WebSphere
Platform products.
Related user roles of Information Developer
The following diagram shows the related user roles that Information Developers are most likely
to interact with in the course of a solution development life cycle and the major tasks on which
they would collaborate:
[Translate solution objectives into
appropriate information]
Solution
Architect
[Translate system functions into appropriate information]
Information
Developer
Application
Developer
[Translate UI artifacts into appropriate information]
User
Interface
Developer
Figure 9. Collaboration pattern of Information Developers
26
Typical tasks and skills of Information Developer
The typical tasks and particular skills for an Information Developer are as follows:
Tasks
Skills
" Architects and implements information
" Has basic understanding of the business goals
deliverables
" Defines which information component is
most appropriate for each solution
component, for example, books, information
centers, wizards, and so on
" Writes required text such that it can be
translated into multiple languages
of the solution
" Has sufficient understanding of the users and
their tasks
" Has expertise in various user assistance
mechanisms (help text, books, tutorials, and
so on) and knows which best to apply for
which user task
Technical use case example for Information Developer
The technical use case for the Information Developer can be seen in conjunction with the use
case for the Solution Architect who is working on the architecture design. The Information
Developer assists with the documentation of the solution architecture, and continues to create the
solution specifications, making use of system generated information units (such as Javadoc)
where possible.
User Role
Information Developer
Information Developer
!
!
Information Developer
!
!
27
Use Case Step
Edit the solution architecture
Write the solution specifications for a new
solution
Update the specs when design issues arise
that affect the architecture, including
Checking out the specs, making the changes
and checking it in with the appropriate
version of the solution.
Internal Tools Developer
Internal Tools Developers are not directly involved in creating the business solution, but are
instead involved in developing the software and tools that support the business solution stages,
from design to development to deployment to administration, tailored to the company’s specific
needs. Sometimes, Internal Tools Developers maintain artifacts that are used across multiple
solutions. This role is increasingly more important as companies develop more and more
business solutions.
Related user roles of Internal Tools Developer
The following diagram shows the related user roles that Internal Tools Developers are most
likely to interact with in the course of a solution development life cycle and the major tasks on
which they would collaborate:
Solution
Architect
[Translate solution design into implementation
of required tools]
Internal
Tools
Developer
[Synchronize development of application
components with tools]
Application
Developer
Figure 10. Collaboration pattern of Internal Tools Developers
28
Typical tasks and skills of Internal Tools Developer
The typical tasks and particular skills for an Internal Tools Developer are as follows:
Tasks
Skills
" Implements tools that help with the
" Has a thorough understanding of the tools
application development, unit testing, and
deployment life cycle in the corporate
environment
" Implements tools that provide higher-level
editors for generation of corporate patterns on
top of the base programming model
" Possibly enables for production some of the
tools for external use by some corporate
customers
" Maintains user interfaces, EJBs, or servlet
frameworks for reuse within other solutions
workbench for implementing plug-ins
" Understands parsers, editors, and generators
" Has basic user interface development skills
" Can code the corporate programming model
into a tool for development or deployment
automation
Technical use case example for the Internal Tools Developer
The following use case is a typical example of the responsibilities of an Internal Tools Developer
whose main task is to provide the adequate bridge software between given solution development
products and a company’s particular IT environment. The use case features the development of a
tool for transforming any foreign coding style into a company’s specific one, including indenting
lines of code, placement of comment blocks, capitalization conventions, and so on.
User Role
Information Developer / Solution Architect
Internal Tools Developer
!
!
Internal Tools Developer
!
Internal Tools Developer
!
Internal Tools Developer
!
Internal Tools Developer
!
29
Use Case Step
Define corporate coding standard
Launches workbench and opens plug-in
development environment perspective
Designs new transformation plug-in and
generates the corresponding skeleton
Fills in details into skeleton code to read Java
source structure and reformat it into corporate
style
Unit tests new transformation plug-in in
plug-in development
Exports plug-in and makes it available to
development community
Solution Integrator
The tasks associated with the Solution Integrator user role involve the assembly of application
components into a complete solution and the preparation of this solution for thorough testing and
subsequent deployment. Currently, these tasks are distributed across a number of other user roles,
such as Application Developer and System Administrator, but based on the customer interviews
and feedback, the Solution Integrator user role is seen as an emerging role that WebSphere
Platform development teams need to recognize and support.
Related user roles of Solution Integrator
The following diagram shows the related user roles that Solution Integrators are most likely to
interact with in the course of a solution development life cycle and the major tasks on which they
would collaborate:
System
Admin.
[Verify run-time requirements
during assembly]
Solution
Architect
[Verify assembly of solution
components according to design]
Solution
Integrator
[Create required collateral (scripts, etc.)
for deployment]
Solution
Deployer
[Assemble components according
to design]
Application
Developer
[Verify functioning of
assembled solution]
Solution
Tester
Figure 11. Collaboration pattern of Solution Integrators
30
Typical tasks and skills of Solution Integrator
The typical tasks and particular skills for a Solution Integrator are as follows:
Tasks
" Assembles application components into a
"
"
"
"
"
complete solution
Resolves interdependencies between
solution-specific artifacts (EJBs, workflows,
Web pages, and so on)
Executes a simple path through the solution
to validate it
Creates a complete version of the entire
solution
Creates required scripts, tools, or templates to
set up the environment for deployment
Supervises the version control on solution
code
Skills
" Understands the business solution and the
business environment
" Has extensive knowledge of the solution and
the related application components and their
artifacts in order to enable their efficient
collaboration at run time
Technical use case example for Solution Integrator
The following use case describes how the Solution Integrator assembles the application
components into a coherent solution, customizes the code slightly before handing it off to the
Solution Tester, and adjusts how the solution is deployed.
User Role
Solution Integrator
Solution Integrator
!
!
Solution Tester
Solution Integrator
!
!
31
Use Case Step
Customize the adapters
Customize the solution and adjust the
deployment descriptors
Test the customized solution
Produce an installable image of the
customized solution (in a setup.exe file)
Solution Tester
While Application Developers are responsible for unit testing the application components they
developed, a Solution Tester thoroughly tests the flow and interaction between these components
when assembled together into the business solution. Often Solution Testers are also involved
with certifying a new solution, where they would closely collaborate with the Business Analysts
to ensure the business goals are met.
Related user roles of Solution Tester
The following diagram shows the related user roles that Solution Integrators are most likely to
interact with in the course of a solution development life cycle and the major tasks on which they
would collaborate:
Solution
Architect
Business
Analyst
[Report whether solution works & performs as designed]
[Inform on aspects relevant for
solution deployment]
[Certify solution after
successful test]
Solution
Tester
Solution
Deployer
[Report assembly related
issues]
Solution
Integrator
Figure 12. Collaboration pattern of Solution Testers
32
Typical tasks and skills of Solution Tester
The typical tasks and particular skills for a Solution Tester are as follows:
Tasks
Skills
" Tests the functional correctness of the
" Has thorough understanding of designed
solution by verifying the proper functioning
of the application components according to
their role in the scenario
" Tests the non-functional characteristics of the
solution, verifying that aspects such as
performance, scalability, and availability are
satisfied
" Thoroughly tests the flow and collaboration
of components of a newly developed business
solution before returning it to the Business
Analyst for certification of attained business
goals
solution, and the involved application
components and their role within the solution,
in order to test the mapping of the solution to
relevant scenarios
Technical use case example for Solution Tester
The following use case involves setting up the solution test environment. Often, this requires
creating replicas of some of the environments to enable simultaneous testing of components, and
in some cases, these replicated environments need to share some of the same resources.
User Role
Solution Tester
!
Solution Tester
!
Solution Tester
!
33
Use Case Step
Determine which components will be
installed on which machines, to determine
where the various runtimes will be installed
Install the products (or components), or
ensure that they are installed, in the order
based on product prerequisites or corequisites
Run a verification test or sample to ensure
installation is successful
Solution Deployer
The set of tasks associated with the Solution Deployer are focused on the deployment of the
solution on the one hand and the management of a given solution on the other. Once launched,
the solution deployment needs to be continuously monitored and analyzed and where necessary
the deployment strategy needs to be modified in order to meet the required business needs.
Solution Deployers closely cooperate with System Administrators in guaranteeing a smoothly
running solution. The Solution Deployer overlooks solution-specific aspects and artifacts, such as
enterprise Java beans or workflows, while System Administrators handle system-related aspects,
such as resolving system failures or performing the fine tuned configuration of the IT
infrastructure.
Related user roles of Solution Deployer
The following diagram shows the related user roles that Solution Deployers are most likely to
interact with in the course of a solution development life cycle and the major tasks on which they
would collaborate:
Product
Installer
[Cooperate on solution
update & migration]
[Synchronize solution management & system
administration aspects]
Solution
Deployer
[Discuss re-configuration due to
short- or long-term QoS
requirements]
System
Admin.
[Align deployment with test results]
Solution
Architect
Solution
Tester
[Report assembly related issues]
Solution
Integrator
Figure 13. Collaboration pattern of Solution Deployers
34
Typical tasks and skills of Solution Deployer
The typical tasks and particular skills for a Solution Deployer are as follows:
Tasks
" Develops deployment strategy
" Deploys newly developed business solutions
into the existing IT infrastructure
" When necessary, manages the removal of
partial or entire solutions and the rollback to
previous versions
" Monitors and analyzes the deployment of the
solution with an understanding of business
effects and ensures the solution meets the
required business needs
" Revises the deployment strategy according to
changes in the short-term or long-term
Quality of Service requirements of the
deployment
Skills
" Has a basic understanding of the business
solution
" Has in-depth knowledge of the IT
infrastructure and can judge the impact of the
new solution on the existing IT infrastructure
and deploy it accordingly
" Understands the impacts on the deployment
because of temporary scenarios, such as
quarterly catalogs, holiday rushes, fiscal year
ends, and so on that might require that the
solution be reconfigured
Technical use case example for Solution Deployer
The following use case explains how the Solution Deployer deploys a certified solution into the
production environment. The Solution Deployer must protect the production environment, such
that the solution can be removed quickly if they cause any adverse impact on existing products or
solutions.
User Role
Solution Deployer
Solution Deployer, Systems Administrator
!
!
Solution Deployer
Solution Deployer
!
!
Solution Deployer
Solution Deployer
!
!
35
Use Case Step
Back up existing software and data
Review hardware and software levels across
the entire production environment
Apply prerequisites and test them
Deploy solutions into the production
environment
Apply any urgent fixes and test them
Prepare to back out to previous level if
problems occur
System Administrator
The scope of the System Administrator role for the WebSphere Platform products includes only
those tasks for administering the relevant security, networking, and operational aspects of the
solution that is being deployed. Further, in-depth administration is carried out by Security
Administrators, Network Administrators, or System Operators, if those user roles exist within the
enterprise. Additionally, in some WebSphere Platform customer environments, a specialized
System Administrator, called a Server Administrator, might exist to administer just the
WebSphere Application Server. In the current list of WebSphere Platform user roles these server
administration tasks are associated with the Product Installer.
Related user roles of System Administrator
The following diagram shows the related user roles that System Administrator are most likely to
interact with in the course of a solution development life cycle and the major tasks on which they
would collaborate:
Security
Architect
Product
Installer
[Configure security aspects of IT infrastructure]
[Co-operate on product install, update & migration]
[Negotiate performance related
re-configuration]
Solution
Integrator
Solution
Deployer
System
Admin.
[Synchronize solution management &
system administration aspects]
Figure 14. Collaboration pattern of System Administrators
36
Typical tasks and skills of System Administrator
The typical tasks and particular skills for a System Administrator are as follows:
Tasks
" Assists the Product Installer in installing,
"
"
"
"
"
"
"
"
"
"
"
"
upgrading, and migrating to the new solutions
Performs the fine-tuned configuration of the
IT infrastructure (operating system, and so
on), including the corresponding networking
aspects of the solution
Deals with real time problems in the
environment
Manages the change control process
Authorizes users, assigns user IDs and
passwords, and manages these resources (for
example, deleting accounts, changing account
information, and so on)
Uses system performance information to
monitor compliance with Service Level
Agreements and Quality of Service
requirements
Determines the cause and impact of problems
that occur
Resolves system failures, working with
product support teams (both in the company
and the product vendors)
Plans how to react to peaks and valleys in
solution performance within the IT
infrastructure
Potentially negotiates with the server farms to
use capacity for short peaks
Configures the security aspects of all the
components of the IT infrastructure (for
example, allocates and manages certificates
for Web servers, sets up security plug-ins, and
so on)
Manages all the access control lists (ACLs)
for all the resources within the IT
infrastructure (for example, changes the ACL,
reviews the ACL, determines the access
currently in effect for a given resource, and so
on)
Detects and responds to intrusion attempts
into the system
Skills
" Has a thorough understanding of the entire IT
infrastructure (hardware and software)
" Is able to judge the impact of system changes
" Has expertise in various operating systems
" Has system programming skills (script
languages, command line programming, and
so on)
37
Technical use case example for System Administrator
The following use case portrays a typical configuration activity that the System Administrator
handles.
User Role
System Administrator
System Administrator
!
!
System Administrator
System Administrator
!
!
System Administrator
!
38
Use Case Step
Log on to the central administrative console
Configure the display to monitor a specific
set of hardware, software, and application
components related to the solution
Store the configuration
Display the complete solution showing the
hardware and software dependencies
Show that each part of the system is up and
running
Secondary user roles
The WebSphere Platform development team identified a set of secondary user roles that are
distinct from the 12 primary user roles, but are indirectly or partially involved in developing a
business solution with WebSphere Platform products.
The following list shows the most important secondary user roles, although others are likely to
exist:
!
CTO, CIO, and CEO
As coordinators and facilitators of the development of integration software, these executives
are vital in the distributed development process, but they are not primary users of the
infrastructure software for business solutions provided by the WebSphere Platform. They are
vital decision makers from a solution development perspective, although their tasks and
responsibilities go much beyond this vital task.
!
Project Manager
Like the executives, project managers function as vital coordinators and facilitators in the
development of integration software. They stay with a particular solution development
project throughout its entire life cycle, but do not get involved as solution developers. Hence,
they have been excluded from the list of WebSphere platform technical user roles.
!
Enterprise Information System (EIS) Developer
Most likely a company will have their own enterprise information system for their internal
transactions. A particular enterprise information system can be created in various forms and
formats, such as Cobol (for example, for an IBM CICS system) or ABAP (for a SAP R/3
system). An Enterprise Information System Developer will need to have profound knowledge
in the appropriate programming language and is responsible for maintaining and updating the
business rules in the enterprise information system. This user role is addressed in detail in the
context of developing the particular enterprise information and transaction system, for
example, IBM CICS or SAP R/3.
!
Translator
The Translator will translate those text units that were selected for translation into other
languages than the solution’s original presentation language. This might include error
messages, user interface panels, help information, user guides, and so on. They do not use
IBM WebSphere Platform products for this task, but instead use tools that are specifically
tailored for translation.
!
System Operator
The System Operator continuously monitors the system transactions, creates system backups,
and starts and stops the system when necessary. These are necessary operational tasks for a
running business solution, but might not necessarily justify a separate user role. In the present
list of WebSphere Platform user roles, these tasks have been associated with the System
Administrator.
39
!
Network Administrator
The Network Administrator installs network equipment and sets up network information,
such as routing tables, and monitors network performance. WebSphere Platform software
does not explicitly support the tasks of a Network Administrator. The networking tasks
relevant in the context of developing business solutions have been merged with the System
Administrator tasks.
!
Database Administrator
A Database Administrator creates databases, business views, and database objects. They
grant authority to other users of the database, and tune and maintain the database. Storing and
managing data is an essential aspect of business solutions. However, the role of the Database
Administrator is not targeted by WebSphere software. It falls into the area of data
management and data storage software.
!
Customer Support Representative
A Customer Support Representative will support the customer by answering questions and
respond to customer requirements. They utilize the customers’ product and technology to
identify problems related to product installation, configuration, operations, or performance.
For resolving problems, very often a Customer Support Representative will have access to
the same support mechanisms as the customer. Any improvements in these areas therefore
will be of benefit to both. Since the set of generic user roles is meant to represent the roles
found at the customer sites, the Customer Support Representative is not included into the list
of WebSphere Platform technical user roles.
40
Summary
This paper presented the set of technical user roles developed in cooperation with various
WebSphere Platform customers who develop business solutions using WebSphere products. This
set of user roles is a generic set, representing the user roles involved in the development of
business solutions. However, for the development of any particular business solution, certain user
roles can be made more general or more specific.
The user roles are based on the typical user tasks. Each user role has a sufficiently large set of
tasks, and shows a direct involvement with the development of the business solution using
WebSphere Platform products. After describing the 12 primary technical user roles in detail, the
secondary user roles were summarized.
The list of WebSphere Platform technical user roles is not static, as a number of extensions are
conceivable. From an overall solution development perspective, the next step is to establish a set
of user roles that also covers the related areas of data storage, solution management, and
collaboration that are addressed by Data Management, Tivoli, and Lotus products, respectively.
Although, the current list of user roles is based on enterprise type customers, this list could be
mapped to development environments with independent software vendors or with small and
medium businesses. Perhaps the same set of technical user roles would exist, or perhaps a subset
or superset of user roles would exist. And finally, when WebSphere Platform software directly
addresses the needs of end-users of business solutions, the set of WebSphere Platform user roles
will be extended accordingly to cover both technical and business user roles.
Comments and questions are welcome on this paper: <[email protected]>.
41
Appendix A. Other perspectives on the concept of user
roles
There are various ways for adopting a user-centered perspective in software development. These
perspectives largely depend on the area of development (software engineering versus user
engineering) and the type of development (global design versus specific applications and
solutions). The WebSphere Platform user role concept is based on user tasks and is briefly
compared here to the other user-centered concepts used in the context of software development.
Actors in software engineering
In object-oriented software engineering, user roles are described as actors, whose scope is
defined slightly more broadly than the user roles. In its original definition, an actor could be any
external user of a system, which could be a human being as well as a non-human system that
interacted with the system in question [Jacobson et al. 1992]. Most notably, the Unified
Modeling Language (UML) is a language for visualizing, specifying, constructing, and
documenting the artifacts of a software-intensive system, specifying that ‘an actor represents a
role that a human, a hardware device, or even another system plays with a system.’ An actor
represents a coherent set of roles that users of use cases play when interacting with these use
cases, but it needs to be kept in mind that actors, as defined here, are viewed as not actually part
of the system. ‘They live outside the system.’ [Booch et al. 1999].
Goals and personas in interaction software design
Instead of focusing on the essential tasks, user-centered design can focus on the accomplishments
reached through performing these tasks, often called goals. Goals constitute the base element
within the IBM User Engineering approach for software design and development [Dec. 2002].
Roles are associated with goals, where goals are a desired state to be in, independent of what a
user needs to do in order to reach this goal.
The concept of a persona, too, is defined by its goals. As with user roles, personas are abstract,
representing real people throughout the process of design. ‘They are hypothetical archetypes of
actual users’ [Cooper, 1999]. The definitions of personas are quite precise and personal, although
imaginary. These pretend users are given a name, a particular work environment, a job title, and
even hobbies, if they are of any relevance to the design. Also, a persona is likely to act in more
than one user role during the course of a day. They apply any arbitrary combination of tasks to
reach their desired goal and therefore assume all the corresponding user roles necessary. The
particular combination of performed tasks might not be unique, since they might choose a
different set of tasks the next time.
42
In addition to the WebSphere Platform technical user roles, the IBM WebSphere Platform
development team could create a series of personas. In designing the interaction with a particular
IBM WebSphere Platform product, it would be quite helpful to determine the goals of the various
technical user roles and then derive the tasks that are necessary to reach these goals. Because the
WebSphere Platform technical user roles were generalized across the solution development
process using the WebSphere Platform products, generating a set of goals based on personas did
not prove as insightful as concentrating on the user tasks directly.
43
Acknowledgements
First and foremost I would like to thank the participants of the WebSphere Platform Beta
program who filled out our survey, attended a round table teleconference, and volunteered for
interviews on the user roles, giving us the most valuable feedback. In particular I would like to
thank Joe Korchmar from Wachovia Corporation, who spent much time discussing the roles with
us and was always available for yet another question!
I’d also like to thank my colleagues from the WebSphere development teams who continuously
discussed with me which tasks needed to be done and who would perform them - most notably
Mike Starkey whose constant input and advice helped shape the set of WebSphere Platform user
roles significantly.
The WebSphere Platform is closely linked to DB2, Tivoli, and Lotus in the realm of building
business solutions, and I want to thank Debbie Mayhew, Paige O’Neal, and Sandra Kogan
respectively, for sharing their sets of user roles in order to appropriately align the WebSphere
Platform ones.
The WebSphere Application Server is often called the engine of the WebSphere Platform
products. My thanks go to its entire Human Factors team who were just as much a driving force
in detailing the user roles presented in this paper.
For their extensive and constructive feedback on a draft version of this paper I want to thank
Rosanne deVries, Eileen Jones, Mark Hunsinger, Hira Advani, Terry Borden, and Julie King
from IBM, and again Joe Korchmar from Wachovia Corporation.
And finally, my sincere thanks go to our editor Michelle Corbin who added that essential bit of
flow and cohesiveness that transforms a paper from an aggregation of information into the most
pleasant reading experience from front to back!
44
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other
countries. Consult your local IBM representative for information on the products and services
currently available in your area. Any reference to an IBM product, program, or service is not
intended to state or imply that only that IBM product, program, or service may be used. Any
functionally equivalent product, program, or service that does not infringe any IBM intellectual
property right may be used instead. However, it is the user's responsibility to evaluate and verify
the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this
document. The furnishing of this document does not give you any license to these patents. You
can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual
Property Department in your country or send inquiries, in writing, to:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
The following paragraph does not apply to the United Kingdom or any other country
where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS
MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not
allow disclaimer of express or implied warranties in certain transactions, therefore, this statement
may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are
periodically made to the information herein; these changes will be incorporated in new editions
of the publication. IBM may make improvements and/or changes in the product(s) and/or the
program(s) described in this publication at any time without notice.
45
Any references in this information to non-IBM Web sites are provided for convenience only and
do not in any manner serve as an endorsement of those Web sites. The materials at those Web
sites are not part of the materials for this IBM product and use of those Web sites is at your own
risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate
without incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products,
their published announcements or other publicly available sources. IBM has not tested those
products and cannot confirm the accuracy of performance, compatibility or any other claims
related to non-IBM products. Questions on the capabilities of non-IBM products should be
addressed to the suppliers of those products.
All statements regarding IBM's future direction or intent are subject to change or withdrawal
without notice, and represent goals and objectives only.
This information is for planning purposes only. The information herein is subject to change
before the products described become available.
If you are viewing this information softcopy, the photographs and color illustrations may not
appear.
Trademarks
IBM, DB2, Freelance Graphics, Lotus, Tivoli, and WebSphere are trademarks of International
Business Machines Corporation in the United States, other countries, or both.
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United
States, other countries, or both.
Other company, product or service names may be trademarks or service marks of others.
46
Bibliography
Booch, Grady, James Rumbaugh, and Ivar Jacobson. 1999. The Unified Modeling Language
User Guide. Reading, Mass.: Addison-Wesley.
Constantine, Larry L. and Lucy A.D. Lockwood. 1998. Software for Use. A Practical Guide to
the Models and Methods of Usage-Centered Design. New York: ACM Press.
Cooper, Alan. 1999. The Inmates are Running the Asylum.Why High-Tech Products Drive Us
Crazy and How to Restore the Sanity. Indianopolis, Indiana: SAMS - A Division of
Macmillan Computer Publishing.
Jacobson, Ivar, Magnus Christerson, Patrik Jonsson, and Gunnar Oestergaard. 1992.
Object-Oriented Software Engineering: A Use Case Driven Approach. Reading,
Massachusetts: Addison-Wesley.
J2EE 1.4 Platform Specification. Proposed Final Draft 2. November 2002.
http://java.sun.com/j2ee
User Engineering. December 2002. A description of the IBM approach.
http://www.ibm.com/easy
47