The concept of patterns is not new; they have been used extensively in the fields of design and architecture for centuries. In fact, some of the most referenced works in the field of patterns are not from software engineers or technologists but from the acclaimed architect, Dr. Christopher Alexander. Dr. Alexander's work and writings have had a significant impact in the area of software solutions. The constructs, ideas, and techniques identified and documented in his writings have been applied extensively to the fields of software engineering and object-oriented programming.
In his 1977 book, A Pattern Language, Dr. C. Alexander provides a simple and concise description of patterns as they apply to the problems in creating cities and towns, neighborhoods, and buildings:
Each pattern describes a problem that occurs over and over again in our environment and then describes the core of the solution to that problem in such a way that you can use this solution a million times over without ever doing it the same way twice.
Experienced software engineers will readily accept the fact that the process of developing software has many similarities to the process of developing cities, towns, and buildings. Thus, it is not surprising that the idea of patterns has gained acceptance among software designers and developers. It enables efficiency in both the communication and the implementation of software design, based upon a common vocabulary and reference.
The process of developing patterns in any domain takes experience-lots of it. Over the past six years, IBM has played a significant role in developing the Internet marketplace by providing the technical leadership needed to define and put structure around this rapidly evolving field. IBM has Internet-enabled its product portfolio and has helped its customers implement e-business applications. This application base spans all major industries, and ranges from static Web sites to some of the most complex transaction-processing applications on the Web today. Some of the most commonly occurring patterns are described in this book.
It is important to remember that patterns are not just concepts, but practical and actionable constructs derived from experience in building real-life applications. Patterns help capture and codify expert knowledge and make it possible to share that knowledge with others. In general, patterns are not invented, but are identified and mined from extensive experience in a particular field. Patterns enable you to rapidly develop solutions without sacrificing the quality and service expected from those solutions. They also make sure that the knowledge gained from the implementation of solutions is shared, to avoid reinventing answers to problems that have already been solved.
Patterns in software development
In the context of developing software applications, the architecture of the solution should address two major domains: the functional domain and the operational domain. The functional domain addresses the business functionality of the solution, the structure and modularity of the software components that will be used to implement the business functions, the interactions between the components, and the interfaces between them. The operational domain describes the system organization (such as hardware platforms, connections, locations, and topology), the placement of software and data components, the service requirements (such as performance, availability, and security), and the system management (capacity planning, software distribution, backup, and recovery).
There is clear evidence of patterns in both of these domains. System-level patterns identify and describe the overall structure and interactions that can occur between components of a system. These patterns can typically be used during the high-level design phase to develop the structure of the overall application solution. The authors of Pattern-Oriented Software Architecture-A System of Patterns identified patterns for system architecture at a higher level than the original design patterns. Their patterns relate to the macro-design of system components such as operating systems or network stacks.
Design patterns represent the original, and currently most comprehensive, description of more granular patterns that can aid the design of software components. In their ground-breaking book, Design Patterns: Elements of Reusable Object-Oriented Software, the authors, often referred to as the "Gang of Four," document 23 patterns recognized as providing accepted solutions for recurring problems in object-oriented design. These patterns help software designers establish the structure and operation of the code that supports the functional components of the application.
These patterns have focused primarily on the design and programming phases of application development, dealing with the structure and behavior of the code that supports the application.
Introducing the patterns for e-business
Chapter 1 introduces e-business solutions, showing how these solutions span multiple business domains and are more complex to implement than traditional application systems. These solutions require a constant and clear exchange of ideas and information between the business owners driving the solution and the IT personnel responsible for its implementation. While constructs such as design patterns are still very useful in the development of the solution, they have minimal impact in the early stages of the solution design, where key decisions are made regarding the solution's overall structure and end-to-end architecture.
The Patterns for e-business introduced in this book extend the domain of software patterns to earlier phases of the application development life cycle. These patterns help us understand and analyze complex business problems and break them down into smaller, more manageable functions that can then be implemented using lower-level design patterns. There are four major types of Patterns for e-business:
- Business
- Integration
- Application
- Runtime
The Business and Integration patterns have the same structure, as shown in Figure 1.
Figure 1: Business and Integration patterns have the same structure
Business patterns are high-level constructs used to establish the primary business purpose of any solution. These patterns help establish three key aspects of any solution:
- They define the major objectives of the solution. For instance, a Self-Service business pattern is observed in solutions that enable users to access systems directly, without going through a service intermediary (such as an insurance agent or a customer-service representative).
- They identify the high-level participants who interact in the solution.
- They help us understand and describe the nature of the interactions that occur between the participants.
It is important to note that the concept of Business patterns transcends the domain of computers and systems. In other words, the Business patterns identified in this book can be observed in any solution you interact with on a daily basis. For instance, the Collaboration business pattern can be observed in daily business operations such as conference calls, sending and receiving voice mail, and participating in face-to-face meetings.
Integration patterns help to implement a full solution, integrating the individual Business patterns to satisfy the full e-business requirements. The integration is actually done at the Application pattern level for each Business pattern. Integration patterns can also be used within a Business pattern to integrate core business applications and databases. These patterns implement the specific interactions between the logical components that make up the Application pattern. Again, this integration is done at the Application pattern level for the Business pattern.
Overall, Integration patterns help provide:
- A seamless customer experience to the users of the solution. These patterns provide a single sign-on function to multiple back-end systems, personalized user interfaces, and the ability to support the same customer experience across multiple devices.
- Varying levels of integration with the applications and databases that exist within the organization.
Application patterns help refine Business patterns so that they can be implemented as computer-based solutions. These patterns help provide structure to the Business patterns by identifying and describing the high-level logical components needed to implement the key functions of each Business pattern. Specifically, Application patterns represent the partitioning of the application logic and data together with the styles of interaction between the logic tiers. Application patterns serve as the foundation for the subsequent critical step: the placement of the application and data elements on top of the middleware structure.
Usually, more than one Application pattern can be used to automate a Business pattern. Which Application pattern to use depends on the key business and IT drivers unique to the organization. For instance, when implementing the Self-Service business pattern as part of a customer site, the choice of Application pattern can be affected by the need to:
- Reduce the latency of business events
- Provide a unified customer view across lines of business (LOB)
- Enable easy adaptation during mergers and acquisitions
A different combination of these business drivers might lead to the selection of a different Application pattern.
Runtime patterns are used to define the logical middleware structure supporting the Application pattern. Runtime patterns depict the major middleware nodes, their roles, and the interfaces between these nodes. These patterns also address how the processing logic and data are placed on these nodes. Like Application patterns, Runtime patterns represent logical constructs put together in a predefined structure that enables the solution to provide acceptable service levels to its users. The logical nodes can then be translated into a physical implementation, using vendor product mappings, recommended best practices, and personal experience. In other words, Runtime patterns describe the logical architecture required to implement an Application pattern.
More than one Runtime pattern might work for a particular Application pattern, as shown in Figure 2. The process of selecting the appropriate alternative involves evaluating the specific operational requirements (such as security, scalability, and ease of maintenance) that might apply to the solution.
Figure 2: For each Business or Integration pattern, there can be more than one Application pattern. For each Application pattern, there can be more than one Runtime pattern.
Applying the patterns for e-business
The combination of Business, Integration, Application, and Runtime patterns provides a clear and consistent approach to bridge the divide that sometimes arises between the business and IT departments within an organization. The Patterns for e-business are also relevant to a wider spectrum of users:
- Line-of-business executives who understand the business aspects and requirements of the solution can use Business patterns to develop a high-level structure for the solution.
- Senior technical executives can work with the line-of-business executives to agree on the structure of the solution. They can then use the Application patterns to make critical decisions related to the structure of the solution, as well as the architectural decisions needed to implement the solution.
- Solution architects and systems designers can work with the business and technical executives to arrive at the solution structure and the key architectural decisions. They can then develop a technical architecture by using Runtime patterns to realize the Application patterns.
As shown in Figure 3, this book provides a detailed overview of Business, Integration, and Application patterns. Runtime patterns are more technical, and require detailed technical discussions that go beyond the scope of this book. For detailed descriptions of runtime patterns, see the official Web site (http://www.ibm.com/framework/patterns) and the patterns resources page, which includes the patterns Redbooks (http://www.ibm.com/developerworks/patterns/library/index.html). (Redbooks are technical publications from IBM&s International Technical Support Organization, or ITSO.)
Figure 3: The scope of this book is Business, Integration, and Application patterns.
These Patterns for e-business resources capture best practices that apply at various stages of the application development life cycle. Reusing these architectural and design best practices can minimize the overall risk of your projects. Throughout this book, the FutureStep Electronics case study illustrates how you can use the Patterns for e-business resources to reduce both risk and time to market. This is accomplished by means of asset reuse during the early stages of the application development process.
The case study presented in this book applies the following ideas to a concrete problem:
- Most complex e-business problems can be decomposed into simpler problems, each of which can be matched with one of the four primary Business patterns.
- Based on the business and IT drivers, you can choose appropriate Application patterns to automate the Business patterns.
- Integration patterns can be used to combine the chosen Application patterns and compose a complete e-business solution.
- Web-based resources can be used to further elaborate this solution and customize it for your needs.
FutureStep Electronics: a case study
This section describes the application development process at FutureStep Electronics and the high-level requirements of the e-business solution. It also describes how senior executives can pictorially show both the solution and the key participants in the solution. Subsequent chapters introduce additional technical and business requirements that help demonstrate the process of developing the architecture for the solution by combining Business patterns. These chapters also describe how this architecture can be refined further by selecting Application patterns and making critical architectural decisions.
This overall structure can then be implemented as a solution by using other resources dedicated to the Patterns for e-business (the Web site and the Redbooks). These resources help define the logical architecture by selecting Runtime patterns, and develop a physical architecture by selecting products that can be used to implement the solution.
FutureStep Electronics, an electronic parts manufacturing company, wishes to use e-business technologies to implement a customer self-service solution that will give its customers comprehensive, around-the-clock service. The solution will provide the following:
- A personalized customer-service experience
- Access to electronic component information
- Opinions and buying advice that enable customers to make improved buying decisions
- An easy-to-use component ordering process
- Access to financing from outside financial institutions
FutureStep would also like to provide access to these business functions across several channels, including Web browsers across the Internet, personal digital assistants (PDAs), and pagers.
We have simplified many areas of the case study by not including key topics that are typically found in similar solutions, such as order inquiry, order cancellation, fulfillment, and reverse logistics. This was done to facilitate the discussion and keep it focused on the concept of the Patterns for e-business.
Step 1: Develop a high-level business description
In the first step of the solution-definition process, the business owner should develop a high-level business description that illustrates the major business functions of the proposed solution. This description can be simply one or two clearly worded paragraphs describing the actors participating in the solution and the high-level interactions between these actors required by the new or modified business functions. The actor entities will not be modified by this solution, but are critical for the completeness of the overall solution. For example, actors can be people, devices, external institutions, packages, applications, and data that may be accessed but not modified.
To better understand this concept, consider the following business description for the FutureStep solution. (The blue items identify the actors in the solution, and the items in bold represent the high-level business functions that need to be provided or modified by the solution.)
The FutureStep Electronics Customer Service (FECS) solution provides an end-to-end customer-service solution for our business customers, who are end-product manufacturers that use our electronic components. The FECS solution should support a browser-based interface (and other widely available device interfaces) and be accessible across the Internet.
The FECS system allows customers to register their names, locations, shipping addresses, preferred financial institutions, and other relevant information. This function also allows customers to change passwords, set user interface parameters, and perform other online account-maintenance functions.
Customers can log in to the FECS system and select components from a product catalog. They can optionally enter a product research forum, where they can learn more about the experiences of other manufacturers, in the form of structured content providing the key design specifications, assembly advice, and reliability and desirable service strategies appropriate for their line of finished products. The information from this forum can also be accessed by customers as a research tool, even when they are not browsing through the catalog. This information comes from FutureStep&s internal knowledge base or from data available on other related Web sites on the Internet.
When the customer wants to place an order, the FECS system verifies that the component is available by querying the in-house inventory control application. It also links to a financing application that lets the customer select from several financing options provided by different financial institutions. FECS automatically accesses the customer&s preferences and other profile information from the customer registration database to complete the details of the order. Once the order is saved, the customer is notified electronically via e-mail or pager. The completed order is then forwarded via e-mail to the warehouse to be filled and shipped to the customer.
This short business description captures the high-level requirements of the business problem outlined in this case study.
Step 2: Develop a solution overview diagram
The next step is to develop a Solution Overview Diagram that helps translate the textual description provided by the business description into a pictorial representation. Once again, the objective is to keep the diagram simple and informative. Four major symbols facilitate this:
- A rectangle represents a high-level new or modified business function.
- A rectangle with two vertical lines represents a predefined function, which is an application or package that will interface with the solution, but will not be modified or changed by it. (In other words, it is one of the actors.)
- A picture or other icon represents other actors.
- A connector links the other three symbols.
The Solution Overview Diagram can be drawn in a few simple stages. The first stage is to analyze the business description developed in the previous section and draw rectangles to represent the key business functions (the items in bold in the description). For instance, from the business description, you can identify the following functions in the FECS system (the terms in parentheses are used in the description):
- Customer financing (financing application)
- Customer notification (notified electronically)
- Order entry (place an order)
- Customer registration (register)
- Product selection (select)
- Product research forum (product research forum)
- Product knowledge base (knowledge base)
The second stage is to represent any predefined processes (such as the inventory control system) by a rectangle with two vertical lines. The third stage is to use pictures or icons to represent all the remaining actors in the business description. These include the following:
- Customer
- Browser
- PDA
- Pager
- Warehouse
- Financial institutions
- Other (external) Web sites
The result is shown in Figure 4.
Figure 4: The FECS business functions and actors are represented in the process of developing a Solution Overview Diagram.
The last stage is to use the business description to walk through each process and link the individual symbols using connectors. This produces the completed Solution Overview Diagram shown in Figure 5.
Figure 5: The completed diagram connects the FECS business functions and actors.
The Solution Overview Diagram provides a concise and comprehensive way of representing key aspects of the proposed solution. It provides the foundation for the process of identifying and applying the Patterns for e-business. The discussion of this solution and the solution development process continues in Chapter 4, after the concept of Business patterns is introduced in Chapter 3.
- Alexander, C., et al. 1977. A Pattern Language. New York: Oxford University Press.
- Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., and M. Stal. 1996. Pattern-Oriented Software Architecture, A System of Patterns. New York: John Wiley and Sons.
- Gamma, E., Helm, R., Johnson, R., and J. Vlissides. 1995. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley.
- IBM's Patterns for e-business Web site contains detailed information a group of reusable assets that can help you speed the process of developing applications.
Jonathan Adams has led the definition and development of Patterns for e-business. The resultant patterns are used by IBM and its business partners to help reduce risk and increase speed to market. Jonathan holds a master's degree in mathematics from Trinity College, Cambridge. You can contact Jonathan at jonathan_adams@uk.ibm.com.
Dr. George Galambos is Director, Architecture in IBM Global Services, Canada. He advises international companies on subjects ranging from advanced systems design to strategic IT plans. His current interest includes system design patterns, with a focus on integration. George is an IBM Distinguished Engineer and a member of the IBM Academy of Technology. You can contact George at galambos@ca.ibm.com.
Srinivas Koushik is IBM Global Services BIS Architecture and Technology Executive for the Americas. He has over 15 years of experience in several areas of computing, including large-scale systems integration, and design and development of distributed computing systems. Srivinas is an IBM Distinguished Engineer and a member of the IBM Academy of Technology. You can contact Srinivas at skoushik@us.ibm.com.
Guru Vasudeva has broad experience in various aspects of Solution Architecture and Enterprise Architecture disciplines. His areas of technical and business expertise include Web Services, Service Oriented Architectures, Internet Architectures, Component Based Development, Business Strategy, IT Strategy, Application Portfolio Management, and IT Governance. He is co-author of the book "Patterns for e-business -- A Strategy for reuse".
