"Design Patterns" and "Building Permits"

by Jeff Tash

A valuable benefit of building a technology portfolio is discovering which products actually do, in fact, work together.

Nowadays, integration costs represent one of the largest and fastest growing IT budget expenses. One way to reduce this spending is by using a technology portfolio to improve communication, coordination, and control over IT product usage. By capturing the many different ways tools get used together in combination, a technology portfolio can help shed light on which products are used most effectively and which should be considered for possible replacement or retirement.

A simple measure of integration complexity can quickly be obtained by tallying the number of distinct products that need to interoperate in order for IT to deliver a successful application solution. Few, if any, software programs execute in isolation. Instead, applications run as code threads that weave their way through a complex tapestry of multiple interoperating products. These include database management systems, application servers, web servers, and various middleware offerings. Unfortunately, with many of today’s modern distributed application systems, the list of interoperating products itself can often grow to become quite long. The more products, the greater the complexity, and the higher the likelihood of downtime due to the failure of any single product. On the other hand, too few products limits innovation and effectiveness.

One way to reduce complexity is to eliminate redundancy through consolidation and standardization. Due to mergers, acquisitions, reorganizations, as well as plain old rapid technological change, it’s extremely common for an IT organization to have to support multiple database management systems, or multiple application servers, or multiple Web servers, etc. It’s also extremely costly. There’s the initial acquisition expense associated with the original purchase of each product, plus there’s the ongoing annual maintenance charge that generally runs between 15-20% of the purchase price per year. Worse still are the support costs. How do you measure the true cost of supporting product-specific expertise silos where an Oracle DBA (Data Base Administrator) cannot step in and replace a SQL Server DBA because both jobs require different training and involve extensive non-transferable product knowledge and skills? Heaven forbid we throw a DB2 DBA into this mix! Now multiply these costs by all the redundant products you’re currently supporting. Suddenly, you’re looking at some significant potential savings opportunities.

How can a technology portfolio help streamline software development and reduce integration costs? By supporting “design patterns.” A design pattern describes a set of products that work together in solving a specific class of software problem. For example, META Group defines a collection of nine core design patterns designed to drive reusabilty. These include: 1-tier transact; 2-tier transact; 3/n-tier transact; client/server publish; web publish; stream publish; real-time collaborate; store-&-forward collaborate; and structured collaborate.

Design patterns can be thought of as toolkits. Imagine you’re an application developer charged with the responsibility of building a Web-based sales report. Further assume that a design pattern has been defined and adopted that specifically details how to construct any application that requires “Web-based reporting.” This design pattern specifies a list of products, by type, that a developer needs to assemble in order to construct and deliver a Web-based report. The design pattern further goes on to include recommended product selections as well as suggestions, guidelines, and implementation instructions.

How do you get started using design patterns? One innovative, intriguing idea is to issue “building permits.” Whenever a new project begins, the development team must first receive a building permit. The request details the project’s scope along with a list of required products. A technology portfolio can suggest to developers proven “design patterns.” Meanwhile, a technology portfolio learns what tools developers need while simultaneously gaining a better understanding of how to construct new design patterns and improve existing ones.

By having a technology portfolio capture information describing which specific versions of what particular products truly do interoperate, application developers do not have to waste their time and effort trying to integrate products. Instead, stable computing platforms can immediately be setup and established for development, testing, and production. Besides performing interoperability tests, a technology portfolio can also ensure that products prescribed by a design pattern are indeed all certified to be duly and properly licensed for internal usage.

The adoption and use of design patterns and building permits will significantly reduce maintenance and support costs in the future as well as decrease development costs now. If you haven’t already done so, it’s time to begin investigating how these approaches can benefit your IT organization.