Deriving an Application Infrastructure Strategy

From the previous sections of this chapter, it is quite clear that for an organization to economically support an evolving application portfolio, an application infrastructure strategy must exist. The right application infrastructure strategy ensures that an organization can accommodate short-term tactical and long- term strategic business considerations efficiently and effectively, the byproduct being the organization's technical agility .

The difficulty lies in deriving an application infrastructure strategy that will work for your organization. From my personal observations and experiences, in most cases organizations have a habit of identifying application infrastructure solutions in the context of a single business solution. An application infrastructure strategy cannot be based on a single business solution. Also, it must be adaptive to existing technology infrastructure investments within an organization.

The best approach to identifying an application infrastructure strategy that can be adopted by your organization is to assess existing strategies that have been proven successful and are advocated by the leading technical research organizations, such as the Gartner and Meta Groups. These organizations have investigated the topic of application infrastructure in great detail, and their research is based on exposure to many types of technical environments.

Note

The 80/20 rule applies to application infrastructure in the same way it applies to the software development life cycle, where the 80 represents the analysis and design efforts, and the 20 represents the development, testing, and deployment efforts.

The derivation of an application infrastructure strategy is always based on a series of activities, so you have the option to select those activities that will be acceptable culturally and technically, and hence sustainable by your organization. The activities discussed in this chapter have been derived and distilled from an accumulation of research investigating the techniques for deriving an organization's application infrastructure. As illustrated in Figure 8.2, the application infrastructure strategy proposed in this chapter consists of the following activities:

Figure 8.2. The activities for deriving an organization's infrastructure requirements.

• Recognizing infrastructure patterns , which can be used to resolve business requirements with an infrastructure pattern or combinations of patterns previously identified and defined. An infrastructure pattern describes an end-to-end set of infrastructure components required for a class of applications, encompassing services such as the network, application server, middleware, database server, and storage mechanisms.

• Developing a technology taxonomy , which identifies the emerging, critical, inconsistent, and redundant technologies within an organization.

• Identifying the Enterprise Application Integration (EAI) types, challenges, successes, and failures within an organization.

For these activities to be conducted , an application infrastructure team must be formed . This team should include senior socio-technical staff as well as IT and application architects from different technology-dependent segments of an organization. The term socio-technical staff refers to people who are qualified to synthesize usability engineering with software design and development. The multidisciplinary skills possessed by socio-technical staff members should include software engineering, human computer interaction (HCI) design techniques, and mechanisms for implementing social frameworks in computing environments. The formation of this team is the first step in creating a visible organizational framework to continually evaluate an organization's application infrastructure against emerging technologies.

To learn about other social frameworks that benefit an organization's software development effort, see "J2EE Software Development Methodologies," p. 35 .

Recognizing Infrastructure Patterns

In general, a pattern describes a problem that occurs repeatedly in a given environment over time and then describes a solution to that problem in a manner that the solution can be reused for that problem's context. When this general definition of a pattern is applied to the context of application infrastructure, an infrastructure pattern is the information, knowledge, the "what is" and "how to" that are characteristic to an existing class of applications, which are identified to facilitate solution reuse toward future applications in the same class. In essence, infrastructure patterns are blueprints to how business problems can be cost effectively resolved through the rapid mapping of business requirements to infrastructure designs.

As illustrated in Figure 8.3, an infrastructure pattern captures experience, best practices, and the end-to-end reuse of technology infrastructure for a given type of business pattern.

Figure 8.3. The elements of an infrastructure pattern.

Referencing Figure 8.3:

• The Interface strata defines the primary points of interaction of an application, person-to-system as well as system-to-system.

• The Functional strata defines the elements of an application related to data manipulation.

• The Physical strata defines all the elements of an application related to physical connectivity, storage, and processing.

• The API layer defines the technologies used to provide the application programming interface (API).

• The Presentation layer defines the technology used to provide the primary points of interaction.

• The Application Server layer defines the software that will execute the business logic.

• The Integration Server layer defines the integration software that connects different applications together, reformatting and routing data as necessary.

• The Database Server layer defines the RDBMS that will store and provide access to the application data.

• The Server layer defines the application server hardware, operating system, and any high-availability solutions employed to support the application.

• The Storage layer defines the hardware employed for supporting the RDBMS, including any vendor-based backup and recovery solutions.

• The Network layer defines the hardware, software, and any services employed to provide connectivity between the application's devices.

Cataloging Organizational Infrastructure Patterns

Infrastructure patterns are typically perceived to be technology driven because their objective is to support the technologies from which business solutions are implemented. However, because technology-based business solutions should always be driven by business requirements as opposed to technology, this also implies that infrastructure patterns should be business driven.

For this reason, to recognize infrastructure patterns, you have to

1. Observe your business use cases for your organization's application portfolio.

2. Categorize the use cases according to a common theme for the type of business problem they are solving.

3. Extract the following elements that have been applied to implement the associated business application:

   • Technology infrastructure utilized (physical, functional, and interface)

   • The challenges, best and worst practices experienced (if available)

   • The project plan, including the predicted and actual cost model

   • The types of skills and resources employed

4. Develop an infrastructure pattern using the elements that are common denominators to a specific type of business application.

The objective for this exercise is to categorize and catalog the infrastructure patterns that coexist within your organization. Even though organizations have unique business application scenarios, you can leverage some common infrastructure patterns proposed by the Meta Group as categorization templates. The following are some examples:

• The Transaction category supports business use cases requiring read/write access to data records. This category of use cases can consist of the following types of infrastructure patterns:

  • Single- tier transactions ” A single-tier batch or online transaction processing (OLTP) application with all processing performed on the host.

  • Two-tier transactions ” A fat client on the desktop communicating directly with a back-end database server or a Web server that intertwines CGI/ASP/JSP presentation and application logic.

  • Three/ n-tier transactions ” A thin, presentation-logic client communicating with server-based application logic, which in turn communicates with a back-end database server.

• The Publish category supports business use cases for read-only access to information and data, such as data warehousing applications and viewing files from a Web browser. This category of use cases can consist of the following types of infrastructure patterns:

  • Client Server Publish ” A business intelligence fat client, such as a reporting or analysis tool communicating with a back-end database.

  • Web Publish ” A Web browser interacting over HTTP to enable read-only access to structured documents.

  • Stream Publish ” The support for one-way real-time publishing of streaming content, such as audio, video, and text to a player client (Windows Media Player, RealAudio clients , and wireless Internet devices).

• The Collaboration category supports business use cases for person-to-person communication centered on shared documents or groups of documents, as opposed to strictly data (Transaction category). This category of use cases can consist of the following types of infrastructure patterns:

  • Real-time collaborate ” Similar to the Stream Publish pattern, but allowing bidirectional transmission of audio, video, chat, and voice versus one-way publishing transmission.

  • Store-and-forward collaborate ” Supports the ad hoc sharing of documents using the store-and-forward characteristics of e-mail to transfer "attachments" between members of a workgroup or just storing on a shared file server.

  • Structured Collaborate ” Supports workflow or document management systems.

The Advantages of Cataloging Infrastructure Patterns

If you have categorized and cataloged your organization's application portfolio, you can use the derived infrastructure patterns as a reference or blueprint to develop your future applications. By using an internally recognized and established infrastructure pattern, you can do the following:

• Leverage architecture, technology, components, products and the infrastructure configuration to applications that fall into a specific pattern.

• Efficiently map business requirements to proven IT business solutions.

• Estimate project-related development, implementation, and support costs.

• Estimate the length of a software development life cycle.

• Comprehend the challenges and skilled resources required.

• Embrace any best practices and turn bad practices into learning experiences.

• Recognize the skilled resources and responsibilities associated with a pattern.

Developing a Technology Taxonomy

In general, the role of a taxonomy is to abstract a set of categories that intelligently subdivide and address all areas of a specific subject area. Similarly, a technology taxonomy can be used to categorize and subdivide an organization's technology. By defining the rules for a category's membership and its boundaries, the infrastructure team can develop a common syntax and semantics that will be used to classify an organization's common set of technologies. Alternatively, you can leverage a taxonomy from a technology research organization, where the categories have been preselected for the industry type your organization belongs to. A generic technology taxonomy is illustrated in Figure 8.4.

Figure 8.4. The categories of a technology taxonomy.

For an organization to have a successful technology taxonomy, it is important to ensure the taxonomy is stable and not misinterpreted. It can be validated using the following guidelines:

• Ensure all the technologies that are relevant to the infrastructure derivation effort are categorized.

• Ensure all the boundaries for the technology categories and subcategories are clearly and semantically defined.

• Validate whether the category and subcategory definitions will stand the test of time.

Through the development of an in-house technology taxonomy and its technical categories/subcategories, an organization can

• Identify major technology trends.

• Identify the currently deployed technologies and component architectures and how they are employed toward business applications.

• Understand why and when technologies should be combined.

• Recognize which technology areas are mission critical.

Identifying Enterprise Application Integration (EAI) Types

Much of the application infrastructure to support Enterprise Application Integration (EAI) activities today is focused around preventing application stovepipe and silo scenarios, by enabling business events (transactions) in one application to be available to other applications. However, sharing business events among applications is just one type of integration, and it does not resolve other types of integration voids that are becoming more integral to an overall organizational application infrastructure strategy. The following are additional types of integration:

• Analytic integration ” Focuses on getting salient historical information about a business process out of an application and into an analytic infrastructure, such as a data warehouse, data mart, or reporting/analysis tool. All too often, applications come bundled with proprietary tools, databases, and report-builders for analyzing the information gathered within their applications.

• Directory integration ” Ensures all configuration, user, and security information used by applications is written, accessed, and updated from an enterprise directory. This type of integration is important today because it is the basis from which an organization can achieve a single sign-on solution as well as a unified user profile administration mechanism.

• Content integration ” Enables organizations to share unstructured information (white papers, calendar entries, tasks , e- mails , and so on) across applications.

• Portal integration ” Provides access and interaction of relevant information, applications, and business processes to select audiences in a highly unified and personalized manner. Portals present content and business applications in the context of portlets , which are application objects in the portal's framework. Portlets are typically provided by vendors that specialize in providing a specific business functionality, such as the following:

  • Robust searches across structured and unstructured repositories

  • Integration with existing mail and scheduling systems, such as Microsoft Exchange and Lotus Notes

  • The taxonomy of intellectual properties

  • Content management and aggregation support

  • Access to internal and syndicated business-related data feeds

  • User personalization

  • Application integration and development within the context of an application services layer (that is, Application Server)

The reason for assessing EAI is that many application infrastructure solutions are available in the marketplace ; the objective is to select those that will ease the current and future integration efforts and also be interoperable with each other. The types of integration efforts that your organization can expect to be derived from the previous application infrastructure activities are as follows :

• Infrastructure patterns ” Provide a blueprint showing how specific classes of applications have been designed and implemented. Hence, they provide insight into what types of infrastructure patterns will potentially require integration (pattern chain) in the future to meet a specific business requirement.

• Technology taxonomy ” Provides an understanding of the types of integration efforts that may arise based on the current technology infrastructure.