The present invention relates generally to e-business systems, and more particularly, to a system and method of designing and building an e-business system.
Providing an e-business system to a customer is a complex undertaking that demands the consideration of a wide range of disciplines. Security, performance, system access, and functionality are just some of the domains that system designers must consider when designing the hardware and software components that define the system. To simplify design, designers often consider the system in terms of separate domains, and produce a separate solution for each domain. The separate solutions are then integrated during implementation.
While this approach may make it easier to design the system, it can also lead to inefficient, incomplete, or incorrect solutions that cost far more to deliver and maintain than originally expected. For example, because each domain is separately considered, potential conflicts between system components may not be known until after design is complete and the various solutions are implemented. In addition, interoperability between components may suffer. Addressing each of the various domains as it relates to the other domains may uncover such incompatibilities.
The present invention provides a method of designing and building an e-business system. The method comprises identifying one or more domains relevant to the e-business system. Each domain represents a different set of problems to be considered, and includes one or more patterns having information specific to its domain. A system designer generates an intermediate set of patterns by selecting one or more patterns from one or more of the domains according to predetermined criteria. The designer may then progressively refine the patterns in the intermediate set of patterns, and combine the patterns to produce a multi-domain pattern. The multi-domain pattern defines the components of the eBusiness system.
In one embodiment, the method may be performed by a system comprising a server, a database communicatively linked to the server, and a controller communicatively linked to both the server and the database. The controller may be adapted to display one or more domains to a user, wherein each domain includes one or more patterns having domain specific information. The designer interacts with the system to generate an intermediate set of patterns by selecting one or more patterns from one or more of the identified domains based on predetermined criteria. Combining patterns in the intermediate set of patterns produces a multi-domain pattern that defines the components of the eBusiness system.
The present invention provides a system and method of architecting, designing and building an e-business system by combining one or more domain patterns to produce a multi-domain pattern. Domain patterns comprise information specific to a given domain, while the multi-domain pattern comprises the combined information from one or more of the domain patterns. The multi-domain pattern is then used to build the hardware and software components of the e-business system.
As used herein, a pattern is defined as a template or component that includes information that has proven successful in solving a recurring problem. A designer may use a pattern as a starting point, and then modify the pattern according to varying criteria, or use the pattern as-is. Patterns may comprise, alone or in combination, software solutions (e.g., design patterns, architectural patterns, analysis patterns, business process patterns, code modules, etc.), hardware solutions (machine types, processor types, memory requirements, etc.), documentation, network maps, and various other parameters as needed or desired. As will be described in more detail below, patterns may be stored in memory on a computer system so that the designer or other personnel may select and/or modify the various pattern components.
Referring now to
Pattern window 12 organizes domains 24 into logical groupings for the designer. This embodiment illustrates domains 24 as a security domain 24a, a functional domain 24b, and a performance domain 24c; however, other domains not specifically identified herein may be included as required or desired. Each domain 24 includes one or more domain patterns 28 that define known solutions to recurring problems particular to its domain 24. In
The patterns 28 within each domain 24 may be grouped into classifications 26 according to the types of problems they are known to solve. For example, the security domain in
The selected patterns window 14 displays patterns an intermediate set of patterns 15, which includes one or more patterns 28 selected by the designer. To generate the intermediate set of patterns 15, the designer simply selects the desired patterns 28 from the pattern window 12 according to predetermined criteria. In the embodiment of
Those skilled in the art will appreciate that the designer may select patterns 28 singularly, or in groups. Further, the present invention is not limited to selection by expanding lists and double-clicking on. Designers may also select various patterns 28 from a list box, by clicking on one or more radio buttons or check boxes, or simply by dragging and dropping the desired pattern 28 into the selected patterns window 14.
The criteria that the designer uses to select desired patterns 28 are accessible by clicking on criteria button 22. The criteria may encompass customer requirements and/or industry regulations, and may be stored in memory 40, 46 (see
The conflict window 16 displays possible conflicts between the patterns 28 in the intermediate set of patterns 15, which allows the designer to identify and address possible problems early in the design process. Rules that define conflicts between selected patterns 28 in the intermediate set of patterns 15 may be collected and stored in memory 40, 46 (see
The save button 18 permits the user to save the intermediate set of patterns 15 at each stage of the process. As those skilled in the art will appreciate, clicking save button 18 may launch a window (not shown) that accepts a file name and location in memory to store the intermediate set of patterns 15.
The software may execute on a system 30 of the type shown in
Workstation 34 comprises a display 36, a controller or microprocessor 38, and memory 40. Display 36 is any display known in the art, and outputs information to the designer, for example, display 10 of
Server 42 may be any computing device capable of operating as a server on network 32, and comprises a microprocessor 44, and memory 46. Microprocessor 44 and memory 46 are similar in functionality to the microprocessor 38 and memory 40 described above, and thus, their functionality is not repeated here. It is sufficient to say that like microprocessor 38, microprocessor 44 may be adapted to execute the method of the present invention embodied as a software program stored in memory 46.
Database 48 may be any database in the art, proprietary or commercial, and may be stored in memory 46 on server 42. Alternately, however, database 48 may be stored on workstation 34 or other computing device that is separate from server 42, and linked to server 42 via network 44.
Turning now to
After the designer has selected the initial set of patterns 28, a conflict check (box 58) determines whether a possible conflict exists between the selected patterns 28 in the intermediate set of patterns 15. In a simplistic example, consider patterns 28a, 28d selected from the security domain 24a and the functional domain 24b, respectively. Each pattern 28a, 28d may provide hardware and/or software requirements for the server 32 or workstation 34 having Internet capability. However, while one of the patterns (e.g., 28a) may allow remote employee access, the other pattern 28d may block remote employee access. The conflict check (box 58) would permit the designer to identify this problem early in the design process, and take an appropriate form of action. For example, the designer may wish to select other more compatible patterns 28 from these domains 24, or simply modify one or both of the offending patterns 28a, 28d. Alternatively, criteria specifying remote employee access may not be well-defined at this stage of selection. Thus, the designer may simply wish to note the conflict and continue the process with the understanding that subsequent pattern selections based on narrower criteria will eventually eliminate the conflict. If no conflicts exist, or if the designer elects to continue with the conflicts, the designer may proceed to modify and/or save the patterns 28 in the intermediate set of patterns 15 to the database 48 (box 60).
Next, the designer selects a second set of patterns (box 62) by applying a second, narrower criteria (box 64) to the patterns 28 in the intermediate set of patterns 15. Continuing the above example, the second criteria may call for a server 34 that allows remote employee access, and that is able to handle a very high number of secure transactions. Thus, the designer would then refine the intermediate set of patterns 15 by selecting only those patterns 28 from the intermediate set of patterns 15 that relate to servers 34 that provide for remote employee access, and are able to handle a high number of secure transactions.
After selection, the designer may modify the patterns 28 in the intermediate set of patterns 15 before storing them in the database (box 66). A second conflict check (not shown) may be done to ensure compatibility of the patterns 28 in the intermediate set of patterns 15, to permit the designer to address any conflicts as previously described. This selection process may continue with the designer progressively refining the intermediate set of patterns 15 based on progressively narrower sets of criteria. That is, the designer progressively selects subsequent patterns 28 from the intermediate set of patterns 15 until the individual patterns required to build the system have been selected.
The final set of patterns includes one or more domain-specific patterns 28 from one or more of the identified domains 24. The designer may then combine the selected patterns in the intermediate set of patterns 15 to form a multi-domain pattern (box 68) that will be used to build and implement the e-business system (box 70). In one embodiment, combining the selected patterns into a multi-domain pattern comprises associating all the documentation, code, and other parameters for each selected pattern, and storing the association in the database 28. The association may be embodied as a file containing links to source code, documents, and/or other parameters as required or desired. Thereafter, the patterns 28 that define the multi-domain pattern, including any new or modified patterns, may be included in the database 28 and utilized by the designer to design and build subsequent e-business systems.
To support the incremental development through multiple levels of progressively more detailed selections, the tool distinguishes and saves each pattern set as a distinct design stage. The user can then review each stage separately, as well as make a copy of a particular stage to use as a starting point for other e-business systems. In this respect, intermediate sets of patterns and multi-domain patterns are re-usable, and can become new patterns in the repository.
The present invention may, of course, be carried out in other specific ways than those herein set forth without departing from the spirit and essential characteristics of the invention. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive, and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein.