Introduction

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.

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

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

Environment

Activity: Prepare Environment for an Iteration

The importance of the Task: Prepare Guidelines for the Project 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 user interface guidelines documented in the Work Product: Project-Specific Guidelines; it is essentially an early version of the user-interface guidelines.

Requirements

There is an assumption that some of the following activities are using the results of a business modeling exercise which is outside of the scope of this guideline.

Activity: Analyze Problem

This has less emphasis. Most of the problems should already have been found during business modeling.

Activity: Understand Stakeholder Needs

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.

Activity: Define 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).

Analysis and Design

Activity: Analyze Behavior

The Task: Design the User Interface produces a Navigation Map. A Navigation Map is a view of the Web solution that shows how users of the site will navigate it, possibly 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 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.

Elaboration Phase Activities

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

Activity: Define a Candidate Architecture
The Task: 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 Concept: 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.
Activity: Analyze Behavior
The Task: Design 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 a set of Storyboards and a Navigational Map.

Once there is agreement and sign-off, the creative design comps evolve into a functional User-Interface Prototype through repetition of the Task: 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'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.

The Task: 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 Task: Identify Design Elements refines the Work Product: 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 Whitepaper: Modeling Web Application Architectures with UML.
Activity: Prepare Environment.
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 elements across the whole site.

The development of these elements s an extension of the Task: Prepare Guidelines for the Project and includes the creation of guidelines for their use. Ensure that all team members understand when and how to use these elements. 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 elements.

The preparation of guidelines is done in conjunction with the development of the initial Web User-Interface Prototype to produce the style guide for the site. 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.
Activity: Refine the Architecture
The Task: 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 Task: Describe the Run-time Architecture becomes focused mostly on the Web server and application server tiers (see Concept: 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 Task: 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.
Activity: 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 Activities 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.
Activities: 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 Activity: Implement Components, Activity: Integrate each Subsystem, and Activity: 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

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

Activity: Plan the Integration
Task: Plan Subsystem Integration and Task: Plan System Integration need to address the different kinds of implementation elements created in the construction phase.
Activity: Implement Components
The Task: Implement Design Elements focuses on several different kinds of elements:
- Web pages, applets, scripts, graphics, and other elements that "execute" in the browser environment
- Server-side pages, scripts, servlets, and other elements which "execute" in the Web server environment
- Executable code enhancements to legacy applications
- Database tables, triggers, stored procedures, and other elements that execute in the database management system
The differences in the tools, and the deployment technologies between these different kinds of elements, means there will be a number of similar variations on the Task: Implement Design Elements. There will be similar adaptations in the Activity: Integrate each Subsystem and Activity: Integrate the System.
Activity: Define Evaluation Mission
Test planning continues to focus on performance testing, but increasingly focuses on functional testing. A slightly different testing approach is required for each of the different kinds of elements that comprise a web application. There will be similar adaptations in the Test Activities Verify Test Approach, Test and Evaluate, Achieve Acceptable Mission, Improve Test Assets, in which the focus increasingly shifts from architectural performance-focused testing to functional testing, ensuring the details of the system behavior are correct.

Transition Phase Activities

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 page are developed in cooperation with Context Integration.