Overview > Roadmaps > e-business Solutions

Roadmap: Developing e-business Solutions

Topics
Activities across the lifecycle:
Concepts:
White papers:

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 Development.  

E-business systems can be divided into:

  • first generation systems that simply use the web to publish information
  • second generation systems that implement e-commerce and simple transactional models
  • third generation systems that completely re-engineer 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 their development.

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's 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 the 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, like the one 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).

Sometimes 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. As well, 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 in detail enough about the current business in order to determine where any issues are and where you have the best potential for improvement.

Focus on understanding the scope—limit the organization to be modeled to your area of influence. Within in those boundaries, prioritize only the business use cases that will be automated.

Detail prioritized business use cases.

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

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

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

Requirements

This has less emphasis. Most of the problems should already have been found in  Workflow Detail: Assess Business Status and Workflow Detail: Describe Current Business from the business modeling discipline.

This requires less emphasis. Most of the stakeholder needs should have been found during business modeling. You will, however, need to do some exercises that focus on finding non-functional requirements on the system.

This requires 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', and produces 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 or 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 and focuses on what Web developers call the 'Creative Design Brief', which is a set of guidelines that describe (at a high level):

  • The mood of the site; for example, does the site convey authority, playfulness, or service? Is it conservative or provocative?
  • How users will be accessing the site; for example, what's their connection speed? Is there a minimum speed specified or assumed in the design?
  • The degree of user-interaction; for example, 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 on which user is accessing the application?
  • The browsers that 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; for example, mouse-overs, animation, news feeds, multimedia, and so forth

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, ASPs and JSPs, and the like). 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 predefined, off-the-shelf architectures that can be purchased or re-used from prior Web development projects. Web application frameworks, such as IBM's WebSphere or Microsoft's Windows DNA, provide just this sort of architectural template.

    Web applications typically do not have scheduled downtime. The architecture may (and typically does) need to provide for upgrading the system while it's 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 to integrate the support for this capability into the architecture.

  • Workflow Detail: Analyze Behavior

    The Activity: Use-Case Analysis is relatively unchanged, except that it's 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 (for example, active server pages, servlets, and such) 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 readjusting 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', which are 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 systemthe most important and architecturally significant use cases. It's 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 iterations, 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 elementsthe discrete graphical images that are assembled to build the Web pages for a siteare 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 use. 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 should 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 (for example, web servers, application servers, mail servers, communication gateway servers) with relatively well-defined functional boundaries. The software architect's skill, as a result, becomes focused on 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: Define Evaluation Mission

    Planning focuses, to a great degree, on performance testing to ensure that the Web application can support significant increases in the number of concurrent users. As a result, the Test Workflow Details Verify Test Approach, Test and Evaluate, Achieve Acceptable Mission, Improve Test Assets will also focus more on performance testing to ensure that the architecture is scalable.  

    Other  important types of test are usability testing and structure testing.  It's necessary to test user-interaction to verify that the structure of the Web application is appropriate to its users. In some cases, you are forced to have the application on the Internet so that you can monitor how the users are 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 so 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 the 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 it's being used. These observations can assist in developing further releases to improve user interaction.

 

Portions of this roadmap are developed in cooperation with Context Integration.

 

Copyright  © 1987 - 2001 Rational Software Corporation


Display Rational Unified Process using frames

Rational Unified Process