 | Level: Intermediate Giuseppe Fioretti (giuseppe.fioretti@it.ibm.com), Software Engineer,
IBM
Giancarlo Carbone (gcarbone@it.ibm.com), Advisory Software Engineer,
IBM
08 Jun 2007 Recently, business process optimization has become a primary strategy
for reducing costs while improving efficiency. Indeed, the first step in the IBM SOA
strategy consists of modeling business processes and organizations. Nevertheless, a
well-established usage pattern for eliciting and modeling the business has not yet
emerged. This article guides you through a process for integrating and applying two
different methodologies to analyze and design solutions: business modeling and
interaction design. Applying both these methodologies yields solutions that are both effectively aligned
to the customer business and highly usable by those who
implement the business day-to-day.
Introduction
"All businesses have a business design. A business design describes how
that business works—>the processes that it performs. A service is a repeatable
task within a business process. So, if you can identify your business processes,
and within that the set of tasks that you perform within the process, then you can
claim that the tasks are services, and the business process is a composition of
services."
This excerpt is from the article, "IBM's SOA Foundation—An Architectural
Introduction and Overview" (see Resources).
The article makes clear that the IBM vision of Service-Oriented Architecture (SOA)
is not only about technology, but it is also about a business
design that is founded on the composition of services to be provided by distinct
and pluggable software components. This vision is the basis behind the need to
integrate multiple products into a single solution where
each product strictly collaborates with the others, providing superior customer
benefit and value. While some architecture teams start their work on data models and
technologies used among those products, this article starts from the customer benefit and
value, trying to answer questions, such as:
- What are the customer values that those products can provide together?
- What are the customer problems and issues those products are trying to solve all
together?
- Why should customers use the solution instead of each individual product?
|
Interaction design, business modeling, outside-in
design
Interaction design is a user-interface design methodology that
was first proposed by Bill Moggridge and fully developed by Alan Cooper.
The interaction design focus is on the end users to drive user-interface design. Business modeling is a
methodology focused on business scenarios to drive functional definition,
usually implemented through visual modeling. Both methodologies fall in the wider
outside-in design approach that recommends best practices for designing products
from the outside in, maintaining the focus on the goals that the product consumers
need to achieve (goal-driven or goal-oriented design). |
|
The work described in this article was carried out in the context of the IBM
Tivoli® Asset Management (IT AM) solution, which was developed to meet the need to
respond to the customer demand to implement efficient processes for managing both
hardware and software assets. Before that, IBM Tivoli was more focused on the
Software License Management part of IT AM with the IBM Tivoli License Compliance
Manager point-product, whose scope was mainly the management of the compliance of
software licenses in the distributed environment. After acquisition of Isogon
Corporation and MRO, IBM Tivoli portfolio was enriched with the IBM Tivoli License
Compliance Manager for z/OS® and IBM Tivoli Maximo Asset Manager for IT products in
the IT asset management space, making Tivoli a primary player in the arena of
software for managing IT assets. Integration of those individual products,
originally developed by different manufacturers, into one single product family
could only be driven by the customer values and benefits, which is driven by the
business perspective.
 |
Understanding the design inputs
Business modeling and process analysis are well-established disciplines. Many
books and articles are available (see Resources). There
are organizations, such as the Workflow Management Coalition and Oasis, that take care of its
standards. While modeling and
analyzing business processes has been well-studied, there is no practical
methodology for eliciting the processes themselves. Furthermore, business modeling
does not help you understand how to link automated processes with user
interaction, which is always required, at least to some extent. One approach is to
look to the interaction design discipline for
both business process elicitation and for a way to research the user interface
definition.
Interaction design (IaD) is a goal-directed design methodology by Alan Cooper
that aims to describe "how things behave and then, as necessary, to describe the
most effective form to communicate those behaviors." Its perspective is from "an
understanding of how and why people desire to use products." It is based on the
following:
- The creation of personas, which are archetypal users of products with their goals,
backgrounds, and mental models.
- The description of scenarios involving actions the
personas want to perform and for which a product must be designed.
- The creation of storyboards of the product interface derived from persona scenarios and mental
models, which then drive the rest of the product design.
Start your IaD work drafting persona hypotheses, which are a first cut at
defining the different types of users to be used as a starting point for user
interviews and observation. You can identify your persona hypotheses from personas
already created, identifying similarities and
differences, and looking at the collected interview transcripts from previous
product releases in
order to come out with a single set of personas.
In order to fill missing gaps, you can also leverage Information Technology Infrastructure
Library (ITIL) roles and even try searching on Wikipedia. In order to express
the entire set of design artifacts combined together in a single language, this
article models persona hypotheses in UML. In particular, the article uses
UML stereotyped classes to represent persona hypotheses, their roles, and their
goals. This is basically the same semantic used to represent personas described
in Modeling IaD personas.
|
ITIL
The Information Technology
Infrastructure Library (ITIL®) is a set of books that describe
internationally-recognized best practices for IT infrastructure management. Such
best practices provide guidance, but not a step-by-step methodology, to facilitate
the quality management of IT services, and, in doing so, to increase the efficiency
with which the corporate objectives and business requirements are met. The names
ITIL and IT Infrastructure Library are Registered Trade Marks of the United
Kingdom's Office of Government Commerce (OGC). The content of the books is also
protected by Crown Copyright. |
|
The main difference between an enterprise product (such as a tool for scheduling
jobs on a mainframe) and a consumer product (such as a cell phone) is that the
former aims to automate business processes, while the latter aims to satisfy the needs of
a user who is not within any process, but just wants to perform a task in the
context of his or her personal life. For this reason, the design of a consumer
product must encompass the tasks that the user wants to perform with the product (IaD
context scenarios), while the design of an enterprise product must encompass both
the business scenarios required to support the company's business and the concrete
tasks that the final users have to perform with the product in their daily work in
support of the business. Of course, there is a direct relationship between context
scenarios and business scenarios for an enterprise: the former can be considered
the implementation of the latter in the real life. Context scenarios bring to the
business scenarios information about how workers actually complete the tasks
required to reach the goals they have been assigned in the context of their
businesses.
This article uses IaD context scenarios to elicit business processes. If effective context
scenarios are the implementation of business scenarios, business processes can, in
turn, be considered the abstraction of context scenarios coming from the user
research. Therefore, after defining personas, you can develop complete and detailed
context, arranging and describing them in such a way that you can easily transform
them into business processes.
Understanding business design
This section describes the business process modeling tool, business processes, and some
modeling tool tips.
Using a modeling
tool
Business process modeling is not strictly computer aided, but doing so is highly
recommended. This article uses IBM Rational Software Architect in order to
achieve a full, consistent UML representation of the design. Using UML to model business processes can help in discovering missing parts or
unclear relationships between activities and, more importantly, between different
participants (business actors and customer stakeholders). But the
most important benefits are that it aids thinking and collaboration between
designers and that it allows a deeper analysis than can be achieved by simply writing
text documents. While IaD means are irreplaceable for capturing and synthesizing
user information that supports the optimal design of the user interface, you might
find UML modeling to be essential in capturing information and visualizing the business
processes that enterprise products must support.
Handling business processes and their actors
Write IaD context scenarios in the form of work flows
with an appropriate level of detail and include variations in order to provide
the most complete business implementation picture possible. If you chose to
elicit business processes from IaD context scenarios, translate IaD personas
into actors of the processes, such as business actors.
Start with the definition of customer stakeholders and their business goals.
The inclusion of customer stakeholders is fundamental when designing a solution
for an enterprise product, because their interests and priorities represent the
business goals that the individual tasks performed by the primary personas aim to
achieve. Identifying the aims of the customer stakeholders is the first step
towards designing a solution that is not only usable but is also effective in
supporting the business goals. Customer stakeholders do not exist for consumer
products, and Alan Cooper quickly and simply suggests treating them as secondary
personas.
Next, build the map of business processes, representing the flow of processes
required to meet the business goals. Assign each process to an enterprise
department in which it is executed. Drilling down from the map, create UML
activity diagrams whose actions represent tasks to be possibly automated by the
solution. This activity also leads to the first draft of a business data model,
which is the collection of all the objects exchanged between business actors in
order to complete business processes, such as reports, documents, and
requests. These objects are called business entities. Business
entities are discussed later in the article.
Finally, elicit business use-cases from activities within business
processes, and associate them to both the business goals they aim to support and
to the business actors responsible for them.
Figure 1 shows an example of the result of the activities just
described, where the Software Asset Manager executes the Reallocate
software licenses task in order to Optimize expenses for software,
which is one of the goals for the IT Finance Manager.
Figure 1. Example of relationships between customer stakeholders, business
goals, business actors, and business use-cases
Exploring some IBM Rational Software Architect tool tips
- Use colors to distinguish between actions that will not be automated by the
solution (such as the negotiation of a contract) and actions that will be
automated by the solution (such as the retrieval of a report of software
installations). This facilitates subsequent business analysis and the sharing and
reviewing of the models.
- Determine where you can decompose actions and generate sub-processes that can be reused
within multiple processes. These are referred to as activity states, while other
actions are referred to as action states. Early identification of these
activities saves a lot of time.
- When you are sure an action is to be automated by the solution, do not create
it as a call behavior action (an action that can be further decomposed and
can lead to a drill-down diagram), because the tool adds the corresponding
sequence diagram in the same package. You might want to keep the business
design and the business analysis separate in the two different models. Later, after
developing a sequence diagram, you can replace the simple actions with call
behavior actions, linked to the sequence diagram.
|
Modeling from business processes to system design
This section describes business process details, business analysis, and system
modeling. It also offers some use-cases for examples.
Defining business actors, business workers, and business
entities
After modeling the business processes and identifying process activities that
are eligible for automation in your solution (and so require further
analysis), pin them down in more detail. This article does not go into
a complete and formal description of this step, because it is already described
in detail in the developerWorks article, "A proposal for a Unified Scenario
Based Design Method" (see Resources). This article
just highlights some crucial aspects.
Identify the person who is responsible for or initiates each automated
activity and the person who carries out the real work. The former is a business
actor while the latter is a business worker. For example, an Inventory
Administrator initiates a wall-to-wall inventory, and he is responsible for its
completion and accuracy. But, the physical verification of hardware locations is
delegated to someone else, who goes around with a piece of paper and reads computer
serial numbers, types, and models.
In order to understand how to partially or completely automate a process, an
analysis of which business workers can be replaced by computer systems is
required. In other words, only business workers whose tasks could be
automatically executed by computer systems can be tagged as
automated workers and called systems. Business actors who interact with a system
become system actors and users of the system interface.
In order to complete the activity, business actors and business workers interact
and exchange information, data, and artifacts that are called business entities. As
explained later, business entities play a crucial role both in the user-to-computer system
interface and in the interface among different computer systems. During the
business process design activity, you identified most of the business entities as
objects, which are the outputs of an action and the inputs for another
or the same action. Nevertheless, during the business analysis phase, you refine
them and find new ones. This should not be considered a sign of poor business
design work. Analysis leads to a deeper understanding of what happens at the
higher layer. Iterating across different, contiguous abstraction layers cannot
be avoided to reach a complete and accurate design.
Completing business analysis
The business analysis work consists of defining sequence diagrams where business
actors and business workers collaborate to complete the activity. This
collaboration is realized exchanging messages and business entities.
Following are some suggestions for performing a good business analysis:
- Messages should have the appropriate level of detail. If they are too
specific, the result is that you have described how systems work to respond to
requests from business actors, while you only have to describe what they are
required to do.
- Messages received by a business worker should be carried out by the worker in order
to respond to the request in the message, such as Prepare software license
compliance report. Messages received by business entities should be actions performed
on the entity, such as Review content.
The sequence diagrams that describe how actions in the business processes are
realized are called business use-case realizations. A business use-case
realization can have multiple alternative flows, each of them being mapped to an
activity within a business process. Each business use-case realization is then
mapped to a business use-case, and each business use-case is linked to one or more
business goals that it supports.
The whole picture is that customer stakeholders set business goals, and business
actors perform activities in the context of business processes, which define
business use-cases, which in turn support business goals. Systems (automated
business workers) and human business workers do the dirty part of the job in
support of business actors.
Figure 2. The big picture of
business modeling
Going from business analysis to system modeling
So far you have been working on business actors, workers, entities,
relationships, and collaborations. The next step is to move from the business
domain to the system domain. In other words, you need to define how one or more computer
systems can support the business by fully or partially automating the business
workers.
Analyzing and modeling a system with UML through system use-cases, actors, and
use-case diagrams is a well-established discipline. There is a wealth of published
information on this subject, such as "Applying Use Cases - A practical
guide" (see Resources). This article only highlights some key concepts.
As stated, automated business workers become systems. Those who interact with
them are system actors. Because you might define multiple systems
and find that some of them interact with others, some systems can also be
system actors for other systems. Ultimately, each system can have both
human and computer-automated system actors. For example, the Software License
Management System has the Software Asset Manager (human) and the Inventory
Management System (computer) as its own system actors. The former uses the
Software License Management System, while the latter provides software inventory
information.
Use the following procedure to derive use-cases from the business analysis:
- Create a use-case for each message a system receives. You probably have a lot
of use-cases.
- Look for similarities, overlaps, and generalizations, and go back and update the
business analysis work if necessary. If you do not need to, you are either
the perfect business analyst, or you are going the wrong way.
- Refine and group use-cases using generalization, extension, and inclusion
relationships.
At the end of this activity, the result is the drafting of use-cases that
are organized into groups (a group being generally represented by a parent
use-case generalized from others and, in turn, extended by or including others). Such
results are very valuable at the next step—storyboarding time.
Creating user interaction use-cases and system use-cases
At this point, the models are ready to be worked out by the System Analysts and
the extended design team, who follow up with all the tasks required to implement
the systems.
After the initial review, the entire use-case model required to design
the systems is not complete: all the use-case modeling of the internal behavior of
systems was neglected. But, this is not surprising, because the work came out
of interaction design research, which specifically models the business and the
users. The missing use-cases can only be elicited from the system architecture
that establishes technology and data model boundaries.
In this article, the use-cases derived from business processes are referred to as user interaction use-cases
in order to differentiate them from the use-cases derived exclusively from the internal architecture of the systems.
Exploring more tool tips for IBM Rational Software Architect
When you start analyzing messages exchanged between business actors and business
workers in order to create use-cases, the work can seem difficult because of the
quantity of messages and their tangled relationships. It may help initially to
create a use-case for each operation associated with a system. The tool
automatically adds an operation to a business worker each time you create a new
message whose target is the business worker. Then drag and drop the entire group
of archetypal use-cases defined for the system into a use-case diagram for that
system. This comprehensive view helps a lot with further analysis.
Continuing with user and
user-interface modeling
As stated previously, business actors who interact with automated business workers,
that is with systems, are actors for such systems, and therefore they are system actors in
the system modeling layer. This means that they initiate use-cases. They are users
of the interface of the same systems, and therefore they are users in the user interface
modeling layer. This means that they initiate storyboards.
|
Storyboarding
Storyboarding is a technique originally developed by Disney for cartooning, and
then they also used it for filmmaking. It was adapted from the film industry to
business and eventually to the interactive media industry, where the term
storyboard describes interactive events, as well as audio and motion, particularly on user
interfaces. Each step in an interaction between the user and the user interface
can be portrayed on a slide or using a visual tool. Storyboards
can be represented through UML, as well.
|
|
Modeling IaD personas
IaD personas can be modeled in UML using a
specific, stereotyped class that provides attributes to model skills and goals. It is also
possible to link them to system actors in the system modeling layer. End goals are
UML classes stereotyped as user goals, linked to personas through association
relationships. Such end goals are linked to use-cases from the system modeling
layer through support-stereotyped dependency relationships. Because use-cases are
derived from business use-cases, user goals
implicitly support business goals, which is really important for an enterprise
product (searching the Internet for cooking recipes could be a nice user goal, but
not as useful for the enterprise business).
In the context of an enterprise product, it is also important to assign one or
more user roles to each persona. Add dependency relationships between the
personas and the user roles defined in the IaD preparatory work. This gives you
the whole picture of the described models.
Figure 3. IaD persona modeling
Figure 3 completes Figure 2 and creates a first link between the business and the
user designs. However, you have not yet captured one of the main outputs of the IaD
research: the persona's mental model, which plays a key role in defining the user
interface.
Modeling user concepts
People do not need to know all the details about how a complex artifact actually
works in order to use it. There is a cognitive shorthand for explaining it: one
that is powerful enough to capture interactions with it, but that does not
necessarily reflect its actual inner mechanisms. This is how Alan Cooper introduces
the concept of mental model, also known as the user conceptual model.
To model the user conceptual model in UML, here are two UML stereotypes:
user objects and user views (also known as abstract views). User objects describe
how the user perceives the objects to be dealt with, including their
relationships. User views describe how the user imagines that such objects
should be presented by the systems. IaD data elements and persona conceptual
models can be modeled through user objects, while user views can represent a first
link between the user mental model and the user interface. User views can be
considered design artifacts that are very close to Cooper's user interface
framework. However, Cooper's user interface framework is also based on functional
elements, and you already have use-cases that are probably more powerful than
functional elements to describe things the user wants to do with the system.
Storyboards, which Cooper recommends you design starting from user interface
frameworks, are created taking both use-cases and abstract views as input.
The user conceptual model still lacks a connection with the business (remember that the user of an enterprise application uses it for supporting or
running the business, not for the pleasure of using it). Therefore, any object a
user manipulates when interacting with one or more systems needs to have some
connection with the business processes supported by the same systems. In the
previous analysis, you already identified some objects that business actors (from
which you derived system actors and, therefore, users) exchange with business workers
(from which you derived systems), and you called them business entities.
Start creating user objects from business entities, defining relationships
between user objects on the basis of the existing relationships between business
entities. In this way, you can produce conceptual models for each business actor and,
so, for each persona. It is important to highlight that, while business entities are
abstract objects within business processes, user objects describe how such
abstract objects are perceived by personas who implement business processes
through their tasks. The result is that the same business entity can have multiple
user object representations, because different personas have different mental
models.
The formal relationship between business entities and user objects is a
refine-stereotyped dependency, while a display stereotype was introduced for the
dependency relationships between user views and user objects.
Figure 4 illustrates the link between the user conceptual model and
the business analysis.
Figure 4. Links from
business entities to user views
User objects and personas are simply associated through appropriate packaging of
the models.
The link just described completes the interconnection between the
business design and the user model depicted in Figure 3.
Figure 5 shows the whole and definitive picture.
Figure 5. Links between
business and user domains
Moving toward user interface design
At this point, you have user interaction use-cases derived from business modeling,
and user views derived from user modeling. The part that is still missing is the
user interface design.
Some methodologies, such as the Unified Scenario Based Design methodology
(see Resources) already propose stereotypes for designing the user experience
(UX) storyboards, which are UML representations of the
user interface to be used together with the classic pencil storyboarding Cooper
proposed. It is basically the UML UX modeling discipline, with its
static and dynamic views of the user interface. The static view enables you to
model panels using UI elements, which are appropriately stereotyped classes, such
as screen, compartment, and input form. The classes have attributes of appropriate
types, which represent the controls within the panels and the operations, which are
either the actions the user can perform when interacting with the controls or the
actions the user interface performs in response to user interactions. The dynamic
view consists of sequence diagrams, whose lifelines are the user (user-stereotyped
system actor), and the UI elements, whose messages are the operations exposed by
the UI elements. Such sequence diagrams (which can be converted into more readable
collaboration diagrams as explained in the book, "The Unified Modeling Language
User Guide" in Resources) model the interaction flows of
users with systems, and so they are called user experience storyboards. Classic visual
storyboards are to be used in tandem with these tools to add look and feel
and to facilitate review of the design with customers.
Because a user interaction use-case defines a boundary between a user and a
system, you can design a UX storyboard for each use-case. While that is valid,
storyboards can miss the business big picture. As discussed, each business
process originates from multiple user interaction use-cases, so that designing the user
interface focusing on the use-cases one-by-one can produce several independent
flows that the user must follow in order to complete a wider task related to a whole
process or to a part of it, which does not support ease of use. For example, if
you design a UX storyboard for the search for an end-point use-case, you run the risk
of creating a panel containing only controls for searching for end-points. But
searching for an end-point only makes sense if some subsequent operation must be
performed on the end-point, such as changing its location within the
enterprise. Taking this into account, you might want to add other controls within the
same panel for moving the end-point once it is found.
This consideration leads you to focus on groups of user interaction use-cases in
order to avoid missing the wider context that surrounds each individual use-case. The final
solution is to draft use-cases that are organized into groups. A group is generally represented by a
parent use-case generalized from others, and in turn is extended by or includes
others. Parent use-cases, which can be called main use-cases, can be considered
access points to the systems by the users who are associated to them. As a result
of such considerations, develop UX storyboards for each main
use-case, keeping in mind all use-cases included in the group, and exploring any
path from the main use-case to any other use-case when creating the UI elements
that make up the UX storyboard. To support Create-Update-Delete (CRUD)
generalizations, design multiple alternate flows for the same UX storyboard.
Create partial UX storyboards for use-cases that are included in more
than one use-case, and link these to the including use-case using
references within the UX storyboard sequence diagrams.
Here is an example. In Figure 5, the main use-case of the group is the manage
systems use-case. The UX storyboard that corresponds to
it should have at least two alternate flows for removal and movement of systems
(delete and update). When designing the UI elements that participate in the UX
storyboard, remember that controls should be available for searching,
moving, and removing systems. Also remember that a separate UX storyboard for searching for
systems should be developed and reused within the main flows. The Search for
systems UX storyboard should include two alternate flows: one that leverages
common search criteria and another that leverages a shortcut for searching for
end-points that are to be removed from the enterprise topology.
Figure 6. Example of linkage
between UX storyboards and user interaction use-cases
In this way, you have the means of defining UX storyboards that fully cover and
support the business by linking to
any group of user interaction use-cases.
So, how do you make them usable? How do you support the users?
Alan Cooper says that any user interface should reflect the mental model of its
users. Because you developed a user conceptual model based on the IaD persona
mental model, you can now design UI elements derived from the user views that were, in
turn, designed starting from the user
objects. In other words, draft UI elements that reflect the information
contained in the user views and their relationships. Complete them with
controls derived by the analysis of the use-cases associated to the UX storyboards
in which the UI elements are included.
Figure 7 shows the relationships between the user interface model and
the business and the user conceptual models. It definitively summarizes the entire
modeling stack, including all the abstraction layers.
Figure 7. From the
business and the user to the user interface
The loop is now closed. You designed a user interface that takes as input
the needs of the customer stakeholders synthesized in the user interaction use-cases and the vision of the users, synthesized in their conceptual models.
Exploring even more IBM Rational Software Architect tool tips
Define a library of panel controls that extend the UML primitive types. You
will be aware of the technology chosen by the development team for implementing
the user interface, and you can mime the set of available widgets. You can use these
types when adding controls to the UI elements, setting them as types for the UI
element-stereotypes classes. When you partition a UI element into compartments
(compartments are also stereotyped classes that represent panel frames), notice
their dynamic behavior and reflect it through environmental
operations, stereotyped with a special symbol, such as the $. For example, if the
user clicks a button (a button-stereotyped operation) in the compartment A, this
can cause compartment B to refresh, so add a refresh $-stereotyped operation
to compartment B.
Figure 8 exemplifies a UX storyboard where the UI elements are a hub
screen of end-points, an end-point information compartment, and an end-point
selection form (contained in a compartment not shown). The inventory administrator user role opens the panel, searches for
end-points, and selects one in order to review its data. The environmental
operations are the display-found end-points and the display end-point information
messages, which are originated by UI elements and not by the user. The other
messages are operations whose stereotypes indicate the type of active control used
for the interaction.
Figure 8. An exemplification of UX storyboard with environmental operations
Conclusion
Following the process outlined in this article, you applied both
interaction design and business modeling and found along the way that some gaps
had to be filled to get a full integration between these methodologies and, in
consequence, between the business (stakeholder goals) and the user (ease of use).
The result is an outside-in design usage pattern. This article includes many well-known
concepts and steps along with some practical tips for you to apply to your solution.
The first key point in the usage pattern is a way to leverage IaD not only to
understand the user, but also to understand the business. A single interviewee
cannot have a high-level picture of the business, but putting real data together
and matching them against more theoretical best practices (such ITIL
recommendations, marketing information, and trusted business whitepapers) can
produce a complete, detailed, and concrete result. At the end of your research,
analysis, and design, you will understand both the business and the user.
The second key point is a consequence of the first, to some extent. You have
understood the business and the user domains, but you have to integrate them into
a single model. This is the only way to design a solution that effectively
supports the customer's business and is easy to use by those who run the
customer's business. The integration consists of translating the abstract
objects created and manipulated by the business processes into things that are
familiar to users, easy to understand, and that reflect users' mental
models. Because all the required information is available, you simply need to find
and model the appropriate connections and relationships between the business data
model and the user conceptual model, keeping in mind that each user can have a
different perception of the business.
Resources Learn
- Review
IBM's SOA Foundation - An Architectural Introduction and Overview - Version 1.0
by Rob High, Stephen Kinder, Steve Graham, to see the SOA Foundation as
defined by IBM and to be guided to a wealth of existing information on SOA.
- See
Effective Business Modeling with UML: Describing Business Use Cases and Realizations - November 2002
by Pan-Wei Ng for an overview and some practical hints about business use-cases
and business use-case realizations.
- Consult
About
Face 3: The Essentials of Interaction Design - Version 2.0
by Alan Cooper, Robert Reimann, and David Cronin for a book about interaction design.
- Refer to
A proposal for a Unified Scenario Based Design Method - Version 1.5
by Roberto Longobardi, Alex Donatelli, Rosario Gangemi, Claudio Marinelli, for a
visual, UML-based modeling methodology to link automated processes to system
analysis and design.
- Look at
The Unified Modeling Language User Guide - 2/E
by Grady Booch, James Rumbaugh, and Ivan Jacobson for the definitive user guide of UML.
- Check out
Applying
Use Cases - A practical guide - 2/E
by Geri Schneider and Jason P. Winters for a clear
and practical introduction to the cutting-edge software development technique: the
use-case analysis.
- The
SOA and Web services zone
on IBM developerWorks hosts hundreds of informative articles and
introductory, intermediate, and advanced tutorials on how to develop Web services
applications.
- The
IBM SOA Web site offers
an overview of SOA and how IBM can help you get there.
- Stay current with
developerWorks technical events and webcasts.
- Browse for books on these and other technical
topics at the
Safari bookstore.
Get products and technologies
- Innovate your next
development project with
IBM trial software,
available for download or on DVD.
Discuss
About the authors | 
| | Giuseppe Fioretti is an Interaction Designer at IBM. He has been working on Tivoli projects related to Software Asset Management, first as a user interface designer and developer, then as an interaction designer and business analyst. Challenged to provide a design hypothesis for integration of spot products into a single IT Asset Management solution, he significantly enhanced the consumability of the overall solution by getting it closer to the business and the needs of its potential users. This outside-in design usage pattern is the result of his collaboration. |
| 
| | Giancarlo Carbone is an Advisory Software Engineer in the Tivoli Laboratory in Rome, Italy. He joined IBM in 1996, working on research projects in broadband Internet and digital video broadcasting. Since then, he has worked on several development projects, mainly in Software Asset Management with specific focus on understanding partners' and customers' processes and needs. |
Rate this page
| |
