Skip to main content

Patterns for e-business
for new and enhanced IT solutions

For further background and definitions click here

Scope

The scope of business requirements addressed by the P4eb architectural process has always included end-to-end subsystems, integration subsystems and combined subsystems as defined here.

Process

The P4eb solution architecture process has always been closely aligned with the classic architectural techniques of problem decomposition, solution abstraction (using reusable patterns), solution composition, solution refinement (using a reusable pattern hierarchy), and solution deployment planning.

Original Process

The original P4eb solution architecture process for new IT solutions applied these techniques in a simple linear fashion

Revised process

In order to update the P4eb solution architecture process for business requirements including new and enhanced IT solutions it has been necessary to develop additional patterns and visual decomposition/integration frameworks.

Applying the revised P4eb

The combined patterns and visual frameworks can be used by architects in many disciplines. Recommendations on their use by solution and integration architects can be found here.

Tab navigation

Scenario decomposition summary

Step 1 applies these classic architectural techniques to analyze and decompose a business scenario into a number of subsystems characterized by a combination of existing and new Foundation E2E Business patterns and Front-end & Back-end Integration patterns. For each subsystem characterized by a new Foundation E2E Business pattern, the Foundation E2E patterns and asset hierarchy can be used to refine the subsystem resulting in a proposed product list (Iteration 1)

Process of using the patterns

This step is more fully described together with a worked example on the Step 1 Scenario decomposition page.

Business patterns

Business patterns highlight the most commonly observed interactions between Users, Businesses, and Data. They are the fundamental building blocks of most e-business solutions, and describe the interaction between the participants in an e-business solution. For the seven revised Business patterns see Business patterns for Simple Implementations or 'The revised P4eb Business patterns and the scenario decomposition framework'.

Integration patterns

Complex e-business solutions can be built by combining multiple Business patterns together. This is accomplished by using Integration patterns as the "glue" between Business patterns. Integration patterns are differentiated from Business patterns in that they do not themselves automate specific business problems. Rather, they are used within Business patterns to support more advanced functions, or to make Composite patterns feasible by allowing the integration of two or more Business patterns.For the two Integration patterns see Integration patterns for Advanced Implementations.

Composite patterns

Composite patterns combine Business patterns and Integration patterns to create complex, advanced e-business applications. Of course, there are numerous potential combinations of Business patterns and Integration patterns, but only a limited number of Composite patterns documented on this Web site. A solution design composed of these multiple building blocks is only considered a Composite pattern when it is recurrently employed to solve the problems of businesses across a wide range of industries. Examples of such Composite patterns include the four documented on this site:

  • Electronic Commerce
  • e-Marketplace
  • Portals
  • Account Access

Custom designs

Custom designs, like Composite patterns, combine Business patterns and Integration patterns to create complex, advanced e-business applications. Custom designs are solutions that have not been implemented to the extent of Composite patterns, however. Custom designs can be developed to solve one specific company's e-business problems, or perhaps several enterprises with similar problems. This purpose can prove incredibly valuable, of course. But, Custom designs do not meet the higher qualifications of a Composite pattern, and do not give as great a reassurance of reusability, because they have not been "recurrently employed to solve the problems of businesses across a wide range of industries." However, as the Custom designs detailed on the Patterns for e-business Web site are used more and more by diverse developers, vocal about the benefits and limitations of these solutions, these custom designs might eventually achieve the status of Composite patterns.

Application pattern

Atomic application patterns provide a further decomposition of eleven of the Logic patterns.

These more specific patterns can be used to perform both a decomposition of the existing IT subsystem and a decomposition of the planned enhanced IT subsystem. In the latter case the Atomic application patterns can provide a linkage to discover possible product mappings and related assets for implementing these products as part of an enhanced new or existing subsystem being developed.

Runtime pattern

The Runtime pattern uses nodes to group functional requirements. The nodes are interconnected to solve a business problem. An Application pattern leads to an underpinning Runtime pattern.

© IBM Corporation 2004, 2010. All rights reserved. Java and all Java-based trademarks and logos used on this site are trademarks of Sun Microsystems, Inc. in the United States and/or other countries. All statements regarding IBM's future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only.

New or updated

Resources