Previous column

Next column


A Reuse Parable

Mahesh H. Dodani, IBM Software Group, U.S.A.

space COLUMN

PDF Icon
PDF Version

1 THE SETUP

The ever-growing complexity of computer applications and systems has made it necessary for the major forces in software engineering to integrate in order to effectively and efficiently design and implement solutions. This article presents a parable for leveraging assets to address this complexity and serves as a guide for reuse in the 21st century.

First, lets meet the players in the story: complex business needs, large reusable assets to accelerate solution development and ensure that established best practices are used, and agile methodologies to help build solutions to address these complex needs.

The complexity of computer applications and systems continues to grow at an exponential rate. In a very short period of time, we have evolved from single applications addressing a specific functionality or set of requirements on a dedicated mainframe to an integrated set of applications representing an enterprise e-business that are able to sense and respond to fluctuating market conditions and provide products and services to customers on demand (http://www-106.ibm.com/developerworks/ondemand/.) Companies can quickly increase or decrease their requirements as their markets change (http://www.timesonline.co.uk/article/0,,9023-856626,00.html), and will be able to acquire additional functions or infrastructure as they need them.

To keep up with this ever-growing complexity, software engineers have targeted their work efforts on building reference architectures, patterns, frameworks, and open standards that capture best practices and proven experiences into customizable reusable assets. Of course the larger the asset, the more useful it is in helping drive the entire solution and the more difficult it is to reuse. In this story, we focus on IBM Patterns for e-business (http://www-106.ibm.com/developerworks/patterns/) which define a set of proven, reusable architectures that can drive the design, development, implementation and extension of e-business applications. They match business challenges with Business and Integration patterns, use proven Application and Runtime patterns, populate the Runtime patterns with pre-tested Runtime Product Mappings, and establish best practice guidelines for application design, development and management. The large reusable assets are the composite e-business patterns, which combine several core business and integration patterns to provide a proven solution for a class of problems (e.g. e-marketplaces (http://www-106.ibm.com/developerworks/patterns/b2bemp/index.html.)

To be effective, we need to facilitate the reuse of these large assets in the context of methodologies and workproducts that the architects are familiar in using to design solutions. Such industrial-strength methodologies (http://www-306.ibm.com/software/rational/library/whitepapers/rup-bestpractices.html) typically span distinct phases—Inception, Elaboration, Construction and Transition. Each of these phases has a well defined set of activities and tasks that produce associated models which guide the architect to understand the requirements of the system and design a solution to meet these requirements. The primary phase in which reusable assets, best practices and experiences can be leveraged is the Elaboration phase wherein the requirements are understood and the solution is designed. As you move through the project lifecycle and iterate through the actual development of the solution, the assets that can be leveraged are smaller and more focused on the implementation of the solution (e.g. design patterns, coding guidelines). These latter phases are much better understood and well documented.

So how can large reusable assets be leveraged to design complex solutions? In order to make these assets and best practices reusable on real projects, we need a guide that embeds these best practices and experiences into an industrial-strength methodology and defines a step-by-step process for leveraging the large reusable assets.

To facilitate a short story in the next section, we focus on the Elaboration phase in which the solution to the problem is designed in three major steps. The first step is to establish the requirements of the system defined through use case models. The next step is to design a solution that meets these requirements through an architectural model which shows the logical design of the solution. The logical design is transformed into an operational physical design by defining the components that make up the logical system and the packaging of these components into applications that run on a physical infrastructure of servers, storage and networking. The physical design is primarily modeled using the component and operational models. Note that we will only cover the first two steps in order to show how to leverage large reusable assets.

The goal of the first step is to define the requirements for the solution and understand the complexity and scope of the solution. The process of outlining the solution requirements involves identifying both the functional and non-functional requirements and documenting architectural principles that will drive the solution. In most methodologies, the functional requirements are derived and documented in a use case model. Once these requirements are defined, it is important to start the process of leveraging reusable assets. We start by creating an inventory of potential reusable asset candidates. To be useful, these large reusable assets must define generic use cases that define the scope of applicable solutions in which they can be used. Matching the required used cases to these generic use cases is a sure way to find the right reusable asset. The unmatched use cases define the delta requirements that need to be addressed by extending the asset to a solution that addresses all the requirements.

The goal of the second step is to design the solution that meets the requirements of the system, and is captured by an Architecture model. In building the solution, the Architecture model typically goes through two stages. The first will identify the subsystems of the solution; we will refer to this as the Subsystem Architecture model. The second will denote the logical nodes within the solution; we will call this the Logical Architecture model. The matched large reusable asset can be used to seed both the subsystem and logical Architecture model. The seeded Architecture model can be extended to handle the delta requirements by using other patterns, frameworks, and best practices.

2 THE STORY (ABRIDGED VERSION)

To illustrate the use of the guide in practice, we discuss it in the context of a typical complex problem of modernizing disparate government agencies to facilitate collaboration and integration. This e-Government modernization targets the need for governments to collaborate across countries, agencies, regions, states and the private sector to determine incidents that have the potential of causing problems, and managing the incident to solve the problem. Agencies that participate in some aspect of the incident have information pertinent to the incident and subject matter experts that can resolve the incident. These experts are required to participate in a collaborative environment to work together to resolve the incident effectively and efficiently. Figure 1 captures these requirements as a use case model.

Figure 1: e-Government Requirements Use Case Model

Following the guide, we build an inventory of potential large reusable asset candidates. After a thorough investigation, we focus our attention on the Portal composite pattern (http://www-106.ibm.com/developerworks/patterns/portal/index.html.) This large reusable asset is promising because it tackles business and IT drivers that are close to the requirements and focus on collaboration, information sharing, and application access. The generic use case model for the portal composite pattern shown below highlights the business and integration patterns that the use cases are associated with:

Figure 2: Generic Use Case Model For Large Reusable Asset

Matching the intended solution to the Portal composite pattern tackles all of the requirements except those captured by the Generate Alert, User Provisioning, Inspect Cargo, Assess risk, and Find Agency Information use cases. These unmatched use cases will be the focus of our solution design after we have used the large reusable asset to seed the initial design. Note that this large reusable asset has taken care of a large percentage of the requirements, and so the 80/20 rule is intact – 80% of the solution can be seeded by leveraging the large reusable asset allowing us to focus on the 20% delta requirements.

The design of the solution begins with the Subsystem Architecture model depicting the functional blocks of the solution representing logical grouping of use cases. Figure 3 shows the case study’s Subsystem Architecture model after the Portal composite pattern has been applied. Note that the pattern is capable of handling a large percentage of the solution as shown by the dashed lines in the figure. The subsystems and integration points which were not absorbed by the Portal composite pattern represent the delta requirements that will be the focus of the rest of the solution design process.

The next step is to transition the Subsystem Architecture model into the Logical Architecture model. The large reusable asset should provide a logical architecture model which can be used to seed the solution. The Portal composite pattern provides a runtime pattern (http://www-106.ibm.com/developerworks/patterns/portal/access-sso-runtime.html) which is a middleware representation of the functions that must be performed, the network structure to be used, and the systems management features for most portal solutions.

Figure 3: Seeding the Solution with the Matched Large Reusable Asset

Figure 4 shows the Logical Architecture model for the e-Government case study. It shows the Portal composite pattern seed that was applied and the first step in extending the logical middleware to address one delta requirement (this extension is highlighted by the blue oval.) Note that the architecture model exposes the major middleware nodes, their roles and the interfaces between them. These logical nodes can then drive the physical model through best practices, usage guidelines, reference implementations and personal experience.

It is important to note that this story is abridged, and does not do justice to the complexity of creating large reusable assets, matching these assets to a set of requirements and the customization and extension of these assets to build complex solutions. For a more complete coverage of leveraging large reusable assets, please visit http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg247011.html?Open.

Figure 4: Seeding Logical Design With Large Reusable Asset and Extending For Delta Requirements

3 THE MORAL OF THE STORY

As the story shows, the larger the asset the more effective the reuse. However, for it to be effective, the large reusable asset must be integrated into the methodology and provide the necessary support to be able to match it early in the process, seed models through the project lifecycle and be integrated with the phases, activities, and tasks of the methodology.

In conclusion, the moral of the story – as you sow, so shall you reap!

 

About the author



space Mahesh Dodani is an e-business architect with IBM Software Group. His primary interests are in enabling individuals and organizations to tackle complex e-business industry solutions. He can be reached at dodani@us.ibm.com.

Cite this column as follows: Mahesh Dodani: “A Reuse Parable”, in Journal of Object Technology, vol. 3, no. 1, January-February 2004, pp. 77-82. http://www.jot.fm/issues/issue_2004_01/column7


Previous column

Next column