Roadmap: Developing e-Business Solutions

Topics
Activities across the lifecycle:
  1. Introduction
  2. Inception Phase
  3. Elaboration Phase
  4. Construction Phase
  5. Transition Phase
Additional topics:

Introduction To top of page

To build e-business applications means building Internet solutions to implement business processes. This includes e-commerce, but extends to all business processes throughout an organization.  The basic concepts and technologies used in an e-business solution are described in Concepts: e-Business Develpment.  

e-Business systems can be broken into first generation systems which simply use the web to publish information, second generation systems that implement e-commerce and simple transactional models, and third generation systems that completely reengineer a process to provide highly personalized (business-to-consumer or business-to-business) solutions that are adaptive and automate the complete business process, often integrating with legacy systems and internet devices.

The further along the systems are in the generations, the more complex the development of them will be.

Inception Phase Activities To top of page

The basic workflow for the Inception Phase applies, with the following extensions or variations:

Business Modeling

In general, there is a much higher focus on business modeling compared to other types of development efforts. To develop an e-business application generally means to develop a new way of doing business, it is an integral part of the way you run your business.

The focus here is to understand the problems the new business should solve, and also effects of not developing the new business.

Building e-business solutions involves a greater variety of stakeholders than other software application development projects. These stakeholders will usually include business executives, marketing, creative design, customer support, and the technology development team, among others.

The Activity: Set and Adjust Goals focuses on ensuring that the new business will meet the needs of this varied group of stakeholders. The primary artifact where these needs are expressed is the Business Vision. Given the diverse backgrounds of the stakeholders, a facilitated workshop (as described in Work Guidelines: Requirements Workshop) is often needed to bring the group together. Extensive use of 'storyboards' to describe the desired customer experience tend to be useful in eliciting feedback (see Work Guidelines: Storyboarding).

In some cases the stakeholders are not available because they are only on the internet. In these cases an important role of the Business Vision document is to describe how the stakeholders or customers should find the web site and how user feedback is going to be collected. In these cases you can develop prototypes to learn how customers find the web site and how they are using it. The need to obtain this kind of feedback may affect the length of the iterations and the product lifecycle.

Describe enough detail about the current business in order to determine where there are any issues, and where you have the best potential for improvement.

Focus on understanding the scope û limit the organization to be modeled to what is you area of influence. Within in those boundaries, prioritize only the business use cases that are to be automated.

Detail prioritized business use cases.

Even though you may be aiming at completely automating your business processes, the concept of business worker is useful. In the final business object model, you will have two types of business workers û automated and non-automated. Responsibilities of business workers are described to a level of detail needed to be able to make decisions on what to automate and not.

Focus on understanding what level of automation is realistic to achieve, and what limitations any legacy systems have on what can be done.

Not performed separately. The information normally captured in a domain model is already part of the business object model.

Requirements

Less emphasis. Most of the problems should have been found already in the workflow detail: assess business status and describe current organization from the business modeling workflow.

Less emphasis. Most of the stakeholder needs should have been found during business modeling. You will however need to do some exercises focusing on finding non-functional requirements on the system.

Less emphasis.  The system boundary is defined by the boundary of the business, since the system more closely mirrors the business than in traditional applications (in some respects, the system is the business).

The Activity: Model the User Interface summarizes the use cases and the 'Creative Design Brief', producing a navigation map. A navigation map is a view of the web solution that shows how users of the site will navigate it, represented in a hierarchical "tree" diagram. Each level of the diagram shows the number of clicks it takes to get to that screen/page. Generally, you want to have the most important areas of the web site only one click away from the first page (commonly known as the "home page"). The navigation map is effectively a summary of the Artifact: Use-Case Storyboards which starts by identifying the major windows or web pages for each of the use cases and considers how the user navigates between these elements.

Environment

The importance of the Activity: Develop User-Interface Guidelines is amplified, focusing on what web developers call the 'Creative Design Brief', which are a set of guidelines that describe (at a high level):

  • The mood of the site (e.g. does the site convey authority, playfulness, or service? Is it conservative or provocative?)
  • How users will be accessing the site (e.g their connection speed). Is there a minimum speed specified or assumed in the design?
  • The degree of user-interaction. Should we only inform the user or should we try to communicate with the actor (two-way communication). Should the design of the application be different depending which user is accessing the application.
  • The browsers the users will be using, including differences across operating systems.
  • Whether the site will use frames
  • Any color limitations the site will have
  • If applicable, a graphics standards guide (including standards on logos and all corporate colors)
  • The usage of specific web techniques (e.g., mouse-overs, animation, news feeds, multimedia, etc.)

The 'Creative Design Brief' evolves into the Artifact: User-Interface Guidelines; it is essentially an early version of the user-interface guidelines.

Elaboration Phase Activities To top of page

The basic workflow for the Elaboration Phase applies, with the following extensions or variations:

  • Workflow Detail: Define a Candidate Architecture

    The Activity: Architectural Analysis takes advantage of the knowledge that a web application has a relatively well-defined architecture, including a set of well-defined mechanisms (web browsers, java applets and servlets, ASP's and JSP's, etc.). Usually a simple layering structure as described in Concepts: Layering is sufficient unless the web application development framework is more specific. In many cases, there may be pre-defined, off-the-shelf architectures that can be purchased or re-used from prior web development projects. Web applications frameworks such as IBM's WebSphere or Microsoft's WinDNA provide just this sort of architectural template.

    Web applications typically do not have scheduled down-time. The architecture may (and typically does) need to provide for upgrading the system while it is running and switching to standby servers during primary server failure or when maintenance or server upgrades occur. Some web application frameworks provide tools for production support. Regardless, if your application has high-availability requirements, you will need to plan to buy or build the infrastructure necessary to support this requirement, and integrate the support for this capability into the architecture.

  • Workflow Detail: Analyze Behavior

    The Activity: Use-Case Analysis is relatively unchanged, except that it is important to focus on not only the behavior of the GUI but also the underlying business logic (the part that will typically run on either the web server or the application server). If this is forgotten, the most significant portion of the system behavior will be overlooked. Web pages themselves are represented as 'boundary' classes, data elements are represented as 'entity' classes, and server-side behavior (e.g. active server pages, servlets, etc.) is represented through 'control' objects.

    Immediately following use-case analysis, the Activity: Identify Design Elements refines the Artifact: Analysis Classes, mapping them onto existing mechanisms in the web development framework, reusing existing design elements from prior projects or iteration where possible. This often requires re-adjusting the scope and definition of the identified analysis classes to achieve the desired degree of reuse.

    A more detailed description of the use of UML to describe web applications is described in Modeling Web Application Architectures with UML.

  • Workflow Detail: Refine the System Definition

    The Activity: Prototype the User Interface is performed iteratively within the Elaboration iterations. The early executions of this activity focus on producing 'creative design comps', mocked-up representations of the design of key web pages in the site. These 'comps' are typically "flat" pictures framed with browser window graphics to give a look of a browser window. The main benefit of 'comps' is to postpone the investment of more elaborate and costly HTML prototypes until there is consensus on the specific graphical direction for the site.

    'Creative Design Comps' are created by looking at the interface requirements of the most important use cases and developing many alternative designs (perhaps 10 or more) for its look and feel. From this set, the three most promising options are chosen to present to the stakeholders. This is done iteratively until there is agreement on the final web design, resulting in an early, non-functional version of the Artifact: User-Interface Prototype.

    Once there is agreement and sign-off, the creative design comps evolve into a functional user interface prototype through repetition of the Activity: Prototype the User Interface. The Initial Web UI Prototype typically supports only portions of the system, the most important and architecturally significant use cases. It is important to have a good structure in the use case flow-of-events before developing prototypes to ensure that functionality drives the layout of the user interface and not the reverse.

    In subsequent iteration, the web prototype is expanded, gradually adding broader coverage of the use cases and deeper exercise of the architecture.

  • Workflow Detail: Prepare Guidelines for an Iteration

    In addition to developing user interface guidelines, web design elements, the discrete graphical images that are assembled to build the web pages for a site, are created. Consistency of the user interface across a web site is essential to usability; the web site should provide a consistent user experience. To ensure this, the project must consistently use a set of standard graphical components across the whole site.

    The development of these elements is an extension of the Activity: Develop User-Interface Guidelines and includes the creation of guidelines for their usage to ensure that all team members understand when and how to use these components. Examples of web design elements include graphical elements such as navigational devices and page backgrounds. Reusing high quality standard graphical elements across the entire site ensures consistency, reduces time to market and reduces development cost, as well as increases quality by deploying a smaller set of higher quality components.

    The Activity: Develop User-Interface Guidelines is performed in conjunction with the development of the Initial Web UI Prototype. This style guide will, among other things, specify how and when Web Design Elements shall be used, color schemes, fonts, cascading style sheets, and details on how navigational elements should function and be positioned.

  • Workflow Detail: Refine the Architecture

    The Activity: Identify Design Mechanisms becomes more focused on mapping the non-functional requirements of the system onto the mechanisms provided by the web development framework; mechanisms not provided by the framework (if it exists) will need to be identified and alternative solutions found.

    The Activity: Describe the Run-time Architecture becomes focused mostly on the web server and application server tiers (see Concepts: Distribution Patterns) and the processes and threads used there to manage concurrency in the application; typically there is little or no control over processing on the client-side machines.

    The Activity: Describe Distribution changes focus from one of deciding 'what kinds of server nodes to have' to 'how many of each kind of server node to have'. Typically, the web development framework will provide a fixed number of server types (e.g. web servers, application servers, mail servers, communication gateway servers) with relatively well-defined functional boundaries. The architect's skill as a result becomes focused upon determining how to deal with scalability and fault tolerance requirements using the available server types, usually by determining how many of each kind of server are needed. In addition, measurement plans need to be made to determine how to know when additional servers are needed.

  • Workflow Detail: Plan Test

    The Activity: Plan Test focuses to a greater degree on performance testing, to ensure that the web application can support significant increases in the number of concurrent users. As a result, Activity: Design Test, Activity: Implement Test, and Activity: Execute Test will also focus more on performance testing to ensure that the architecture is scalable.

    It is important to test user-interaction to verify that the structure of the web application is appropriate to the users of the application. In some cases are you forced to have the application on the internet so that you can monitor how the user is using the application.

    Another type of test that consumes a lot of time are browser tests, since compatibility between browsers and browser versions often limits the design options in the user interface.

  • Workflow Details: Implement Components, Integrate Each Subsystem, and Integrate the System

    In order to validate the architectural decisions made thus far on the project, one or more architectural prototypes are developed and tested, involving successive execution of Workflow Detail: Implement Components, Workflow Detail: Integrate Each Subsystem, and Workflow Detail: Integrate the System. Testing, as mentioned above, should especially focus on the scalability of the application to unpredictable increases in system load.

Construction Phase Activities To top of page

The basic workflow for the Construction Phase applies, with the following extensions or variations:

Transition Phase Activities To top of page

  • Product release in the web environment tends to be incremental and continuous, and less focused on traditional distribution of media. Release planning must be adjusted accordingly.
  • User education in the web environment tends to be integrated into the design of the web site itself, so that the use of the site is intuitive. Creation of traditional education and user manuals or documentation is reduced, with increased emphasis on graphic and content design at the front-end of the process.
  • Production application support in the web environment must focus on maintaining high availability under unpredictable load. It may also need to be able to provide the ability to continue running when primary servers fail, and to allow for server upgrades while the system is running.
  • Knowledge transfer from the development team to the production support team must occur, so that the production support staff is capable of running the system and performing routine maintenance.
  • Follow up how the users are using the application. This information is valuable for learning who is using the application and how they are using it. These observations can be used in the development of further releases to improve the user-interaction.
 
Portions of this roadmap developed in cooperation with Context Integration.

 

Copyright  ⌐ 1987 - 2000 Rational Software Corporation

Display Rational Unified Process using frames

Rational Unified Process