Developing solutions for large customers, also known as enterprise customers, is becoming more complex. Factors driving this increase in complexity include:

1. Exploiting new technologies, such as Internet or intranet applications
2. Integration of solutions with a wide array of legacy systems to achieve the desired business results
3. Interoperating with multiple applications
4. Solution customization for variations in customer business processes

Further, the development and delivery of these complex systems are becoming more time consuming and risky for both IBM and its customers. Reuse of assets can help reduce the cost and risk of software development.¹ Enterprise Solutions Structure (ESS) is focused on mitigating the costs and risks of building and deploying enterprise solutions, while making IBM's solutions and services more valuable to enterprise customers.

To serve our customers better by providing timely, adaptable, and customizable solutions and to increase our revenue and profitability on solution deployment contracts, we must focus on the creation, reuse, and maintenance of a spectrum of assets, which include methods, work products, business patterns, technology templates, and software components.

These assets need to be constructed within an overall architecture that is designed from the outset to accommodate a high rate of both business and technological change. Discipline must be applied to allow practitioners to base their solution development and delivery on standard solution architectures, methods, and tools. Enterprise Solutions Structure involves building, deploying, and evolving a set of reusable solution architectures, which, over time, can be populated with reusable software components. ESS is being used by Global Industries, IBM's solution organization, to develop solutions, and by IBM Global Services to integrate and customize solution assets for our customers, as well as to develop custom solutions.

ESS is a major initiative to establish a standard architectural framework for IBM architects and designers to develop and deliver solutions. It draws on experiences with building customer solutions to distill "best practice" structures, models, and methods that allow more effective creation and delivery of solutions. ESS is built upon the latest workproduct methods used in the SI/AD (Systems Integration/Application Development) organization and consulting competencies in IBM Global Services and, where it has been possible, is expressed in terms of the newly defined Architecture Description Standard (ADS).² As such, the intellectual capital contained within can be more easily disseminated to the practitioner community of IBM Global Services.

ESS provides a rich set of architectural building blocks for solution architects, and provides guidance on when and how to use this content to advantage. As part of an architect's "tool bag," ESS packages a predefined, strategic set of technical reference models (also known as technology templates) with recommended vendor product mappings. Presently, ESS has five technical reference models: (1) thin-client transactional, (2) collaboration, (3) business intelligence, (4) call center, and (5) mobile computing. ESS adds significant value to IBM's e-business (electronic business) computing strategy by providing a wealth of detailed information about practical implementation scenarios, for example:

• The aggregation of business logic, data access, and services into system building blocks (how to construct components)
• Component topologies (where to place components in the system)
• Component interactions (how to describe the overall system behavior)
• Security management
• Systems management
• Performance characteristics

ESS provides a breakthrough for both our solutions and services businesses as we develop and deliver solutions. The ESS architectural tool bag is useful for both the development of configurable and customizable solutions for a broad set of customers and for the development of one-of-a-kind, custom solutions for specific clients. For our solutions business, ESS enables faster time-to-market through reuse of proven architectural building blocks, decreased development risk and cost, easier integration of components across solutions, and optimal use of industry domain skills for the business problems. For our services business, ESS leads to faster delivery of industry solutions by smaller teams, improves the "win rate" on bids, increases practitioners' capabilities, and minimizes the risk in solution engagements. For our software product business, ESS enables effective integration of our products in solutions, and also identifies key requirements for product enhancements. For our customers, solutions that use ESS interoperate with and have consistent behavior with other ESS solutions, arrive earlier, are more flexible, and are more economical.

An asset-based solutions business

In late 1996, we surveyed 20 major solutions development projects in which IBM was involved, and we observed that "every project was an adventure." There was little reuse of assets, with too much custom development; tool support was inadequate. The bigger the project, the more these deficiencies mattered. For some, the problems were more technology-related. In particular, the move to the Internet as a delivery channel and a subsequent trend away from fat-client solutions threatened to render existing "stovepipe"³ applications prematurely obsolete.

What is different about developing and delivering business solutions compared to our traditional product and services businesses? To begin with, a solution is a combination of hardware, software products, assets, and services that together address a business problem. Like products, solutions are designed to be used by many customers, but are intended to be delivered through services engagements and to be substantially customized for each customer. A solution must provide a complete, integrated capability, including business applications and technical infrastructure, which can be integrated within an existing customer environment. Like traditional services engagements, a solution provides a capability that fits the customer's unique business and technical needs. But unlike labor-based services engagements, a solution uses an array of assets, including models, software, methods, tools, and other intellectual assets, to drive down the time and cost of delivery.

While software reuse offers the promise of decreased time to reach the marketplace, increased quality, and decreased development costs, these goals can be difficult to achieve in practice. Experience from a number of software reuse projects shows that to be successful, reuse must be applied systematically and be optimized to business goals, and three major areas must be addressed: architecture, process, and organization.¹ Enterprise Solutions Structure is focused on addressing the architecture and technical requirements for asset reuse and on the methods for creating and using assets.

Asset-based solution development and deployment. The major objective of ESS is to enable reuse of solution assets. The traditional "green field" development starts "from scratch": a set of requirements is analyzed and a solution that meets those requirements is developed and deployed. This traditional path is shown in Figure 1 by the arrow that begins at the top left (with requirements) and ends at the right (with solutions).

Figure 1

By contrast, asset-based solution development and deployment takes advantage of architecture and design assets by "harvesting" them from the development and deployment of each solution and reusing them with subsequent solution developments and deployments. This asset-based path is shown in Figure 1 by the arrow beginning in the middle and looping clockwise back to the top left (the solution development box). This implies that the asset-based solution development process not only has the requirements but also has the harvested assets as input, whereas the traditional custom solution development process does not have this advantage of assets as sources and thus must be developed completely from scratch each time.

The need for a flexible solution architecture. To serve our enterprise customers better by providing timely, adaptable, and customizable solutions, while increasing our revenue and profitability on solution deployment contracts, an approach different from creating a series of disjoint and unrelated solutions is needed. Rather than misuse our creative abilities in "reinventing the wheel" on every project, we must focus on the creation, reuse, and maintenance of assets. These assets need to be constructed within an overall architecture that is designed from the outset to accommodate a high rate of both business and technological change. Discipline must be applied to "encourage" practitioners to base their solution development on a standard solution architecture, methods, and tools. Gartner Group recognizes the importance of these elements; according to Gartner Group,⁴ by the year 2000, less than 25 percent of software development organizations will have the necessary infrastructure to consistently leverage a solutions architecture. As a result, these organizations will be placed at a competitive disadvantage. In a recent report,⁵ Gartner Group asserts that 60 percent of IS (information systems) departments will find that their IT (information technology) architecture becomes obsolete faster than they can replan it, because of business and technology changes. Enterprise Solutions Structure supports building, deploying, and rapidly evolving such a set of solution architectures, which can be populated with reusable components.

ESS description

The focus of the ESS work is to capture best practices from real-life projects, to identify those elements of solution architecture that are being invented repeatedly, and to collect the "proof points" and key design trade-offs. In other words, ESS has a real-world, "business problem" focus. It addresses business solution architectural issues, not just infrastructure and platform. Additionally, we are paying attention to legacy integration and to the management of business change on an ongoing basis. Our architectural patterns are designed from the outset to meet the needs of large enterprises with respect to both performance and scalability.

The architecture toolkit. The top of Figure 2 shows solution development; the bottom shows the harvesting and reuse of assets. Requirements are shown at the left; solutions are shown at the right. The outer rectangle, labeled ESS, reflects the important concept that ESS encompasses not only the asset harvesting and reuse process, but also an improved and accelerated solution development process.

Figure 2

The four corners of the diagram contain the four major steps that surround the many steps implied within the solution development, asset harvesting, and reuse processes:

1. Analyze (the requirements) to begin the solution development
2. Deploy (a solution) to complete the solution development
3. Harvest (assets from the solution and also from products) to begin the harvest/reuse process
4. Reuse (assets) to complete the harvest/reuse process

ESS provides a toolkit for architects. It consists of a way of describing architecture assets, based on IBM's new standard,² and a method for reusing these assets; architecture content in the form of business process patterns and technical reference models; and a tool that organizes the content.

The elements of this toolkit have been integrated into IBM's new integrated methods for asset-based application development and deployment. The major activity for the first phase of ESS has been the harvesting of best architecture practices to create a set of technical reference models and contributing to the development of IBM's new standards for describing architectures and the new asset-based methods. In future phases, ESS will concentrate on deploying and refining the technical reference models; creating work products for specifying application architecture; exploring the use of requirements to link business processes to application architecture; and developing methods for creating reusable software components and assembling customizable, configurable solutions from software components. Following is a description of the major ESS assets:

1. Architectural content

   Business reference models: ESS delivers a standard approach for business modeling, including a standard language (and constructs).

   Technical reference models: ESS provides and promotes a set of packaged technical reference architectures, based on best-of-breed experience, which function as the starting point for adaptation for solutions development. These define and describe, for major solution categories, the detailed componentry required along with their relationships and interactions. Design guidance is provided that shows how to choose the specific components suitable for an implementation. Currently five technical reference models are provided:

   • Thin-client transactional--transacting business with customers and vendors
   • Collaboration--partnering to make better business decisions
   • Business intelligence--analyzing data to make decisions to improve business results
   • Call center (fat-client transactional with legacy)--handling customer service interactions
   • Mobile computing--disconnected or wireless connection from enterprise to remote user

2. Catalog of architectural content: ESS also provides a structured means of cataloging the architectural assets in a consistent, extensible framework using a schema based on IBM's Architecture Description Standard. This enables the use of the assets at the appropriate time in the design process, supports customization of the assets as needed, and allows new assets to be added.

3. Methods support: ESS adds value to existing methods by optimizing the reuse of business and technical reference models.

4. Product positioning and gap analysis: ESS recommends the selection of the best products for implementation of the components in the reference models and gives criteria for selection when there is more than one product suite to choose.

5. Deployment education materials: ESS provides materials to assist skills transfer to our solutions and services community.

Other significant features. ESS places particular emphasis on the processes by which we will introduce and maintain an asset-reuse approach within the IBM solutions and services communities, rather than simply generating new assets from scratch. In the past, information assets have become buried under the weight of newer materials within a very short period of time. ESS establishes a common asset framework; a living asset repository that has extensive and effective cross referencing and indexing to support the analysis and design process, and yet is maintainable over time with direct input from the solution and services community. ESS provides the basis for building reusable assets that deliver the cross-platform benefits of IBM's e-business software products.

The ESS audience. ESS addresses the broad requirements of the IBM solutions and services business units in their goal to meet customer business needs. Particular emphasis is placed on the solution development and solution delivery aspects.

The major users of ESS are:

• Solution development architects, designing replicable business solutions
• Services architects, working on replicable solution deployment projects, custom solution development projects, and IT architecture projects for customers

The ESS papers in this issue

Some of the ESS papers in this issue describe the major elements that have been produced to date; other papers help position areas of future focus in ESS. Figure 3 helps illustrate each paper's focus within the overall ESS context. In the area of solution development, we have papers on solution customization, a standard for architecture description, and experiences in reusing technical reference architectures. In the area of asset harvesting and reuse, we have a paper on a standard for business architecture description and another on technical reference architectures.

Figure 3

Because ESS is focused on solutions, it is appropriate to start with the business architecture of solutions. McDavid's paper, "A Standard for Business Architecture Description," introduces the subject of business patterns and shows how these patterns help provide a context for an application architecture in terms of the business problem it solves, thereby improving the communication between the business domain experts and the application developers. The paper lays the groundwork for a key work in the next phase of ESS, namely articulating the variations on the business domain architecture and relating these to the set of application architectures and technology architectures.

A subject that is critical to the success of ESS is the definition of a standard for the description of architecture. Thus, it is appropriate to include the paper by Youngs et al., "A Standard for Architecture Description," in this special ESS issue. In addition to providing a standard description for our ESS technical reference models, the Architecture Description Standard also improves the communication between application developers and infrastructure specialists.

The paper "Technical Reference Architectures," by Lloyd and Galambos, describes in detail the five technical reference models (thin-client transactional, collaboration, business intelligence, call center, and mobile computing) that have been created in ESS from best practices of a number of solutions and services teams. The paper explains how an architect can easily reuse elements from these technical reference models.

The next paper, Leishman's "Solution Customization," shows where we are headed with ESS in the future to support the creation of software components to enable the rapid assembly of customizable and configurable solutions. This will require analysis of the function that should be common, and designing the solution to accommodate the variability that will be necessary to support multiple customers.

Rounding out the ESS portion of this issue is the paper by Harris, Rothwell, and Lloyd, "Experiences in Reusing Technical Reference Architectures," which describes the encouraging results of the use of the technical reference models in actual customer engagements.

Concluding remarks

Enterprise Solutions Structure is a major initiative to establish a standard architectural framework for IBM architects and designers to develop and deliver enterprise solutions. It draws on experiences with building customer solutions to distill "best practice" structures, models, and methods that support more effective creation and delivery of solutions. ESS provides a rich set of architectural building blocks for solution architects, and guidance on when and how to use this content to advantage. ESS adds significant value to IBM's e-business computing strategy by providing a wealth of detailed information about practical implementation scenarios.

ESS provides a breakthrough for both our solutions and services businesses as we develop and deliver solutions. The ESS architectural tool bag is useful for the development of configurable and customizable solutions for a broad set of customers and for the development of one-of-a-kind, custom solutions for specific clients. For our solutions business, ESS enables faster development through reuse of proven architectural building blocks, decreased development risk and cost, easier integration of assets across solutions, and optimal use of industry domain skills for the business problems. For our services business, ESS leads to faster delivery of industry solutions by smaller teams, improves the win rate on bids, increases practitioners' capabilities, and minimizes the risk in solution engagements. For our software product business, ESS enables effective integration of our products in solutions, and also identifies key requirements for product enhancements. For our customers, solutions that exploit ESS interoperate with and have consistent behavior with other ESS solutions, are available more quickly, are more flexible, and are more economical.

Acknowledgments

The authors would like to thank Andy Patterson for his vision and leadership, especially in the early part of the project; Rock Angier for his deep, strategic thinking; and Tim Lloyd for delivering the results. We thank Deborah Leishman for her vision of how ESS should support a solutions business. We thank Burnie Blakeley for the figures he developed for the ESS papers in this issue, and we thank the reviewers, including Burnie Blakeley and John Fetvedt, for their constructive comments.

Cited references and notes

Accepted for publication November 10, 1998.