The Next Wave

Component-based development -- creating applications from reusable parts--is the next great wave in software engineering. Building with components isn't new, as the approach has been in use for several years. But today is a major turning point in the life of this technology. For the first time, the pieces are in place for component-based development to enter the mainstream of software engineering in commercial IS organizations.

The primary reasons for this are:

• Widespread acceptance of a single dominant component standard: Microsoft's Component Object Model (COM), which underlies the ActiveX technologies.

• A large third-party market in client components, addressing a broad range of problems.

• An emerging market in server components, allowing the creation of reusable business objects.

• Broad tool support for creating components and component-based applications, for modeling component-based software architectures, and for automating testing of components and applications.

Using components requires making decisions with long-lasting impact, the most obvious of which is choosing a component model. This choice determines which pool of components an organization is able to select from, what tools can be used to assemble applications using components, and how that organization will create its own components. And although giving any single company too much control of the software infrastructure leaves nearly everyone a little nervous, there's no doubt that COM will remain the most widely used component model. Given the commanding position of Microsoft's operating systems and the large head start the company has in components, this dominance is a foregone conclusion. Other approaches to components exist, such as JavaBeans and CORBA, and they will certainly play a role, but the great majority of components will continue to be COM-based for the foreseeable future.

Component-based development is not an excuse for forgetting everything we know about effective software engineering, however. With components, a well-designed architecture can mean the difference between success and failure. Tools for modeling a component-based architecture and for testing the resulting software are available, and they can make component-based development significantly more productive and reliable.

After several years of experience, component-based development has come of age. Components will become an important part of most new applications in the future, including web-based software (where components will be all but required for powerful applications), client/server systems, and even packaged applications. As corporations build new applications and customize the ones they buy, components will become a competitive imperative, allowing developers to produce high-quality software more quickly. Organizations that ignore this transformation will find themselves at a disadvantage as their competitors use component technology to deploy more reliable systems in less time.

According to Gartner Group's Roy Schulte, ``By 1999, component software will be the dominant method of new application development (0.7 probability)''. Now is a major turning point for component-based development, and it is fueling the industrial revolution of software. The next great wave is upon us: components are moving into the mainstream.

It has been a long time in coming, but the industrial revolution of software is finally upon us.

- Bill Gates, February 1997

Building better software in less time is the goal of every IS shop. Every significant advance in software development, whatever its source, aims at that goal. In the last forty years, advances such as high-level languages, database management systems, object technology, and more have helped us improve the way we create software. The next major innovation in software development is here, and it is having a profound effect on the way we develop systems. That innovation is component-based development.

Component-based development means assembling applications from components: reusable, executable packages of software that provide their services through well-defined interfaces. Building software with components means creating applications in whole or in part from existing pieces. Although it's by no means required, component-based applications are often assembled using a visual tool, and the majority of developers using components today are creating applications with straightforward tools such as Visual Basic and PowerBuilder. The components they use may have been written internally or purchased from third parties, but in either case, the result is the same: more reliable applications produced in less time. Component-based development still requires programming--it's technology, not magic--but by building on what's already available, it makes the process of software development faster and easier. Within the next few years, developing with components will become a standard part of the way applications are written in every commercial IS shop.

``Componentware will help address the issues of both speed to market and flexibility in ways that are superior to those in the past,'' according to the Gartner Group. They predict that ``by 2001, at least 60 percent of all new applications development will be based on assemblies of componentware, increasing both speed to market and the ability to cope with change.'' Within just the last year, Microsoft reports a 500% increase in the number of independent software vendors producing components for Windows and Windows NT. And Microsoft is hardly the only vendor convinced of the importance of components. A host of major vendors have endorsed a component-based approach, including IBM, Sun, Oracle, Netscape, and more. Organizations that ignore this tremendous change in software development will find themselves at a disadvantage as their competitors use component-based development to more quickly develop and deploy new systems.

Now is a key moment--a major turning point--in the life of this technological innovation. Here's why:

• Widespread acceptance of a standard component model. Several choices exist, but Microsoft's Component Object Model (COM) is the runaway leader in market share today. COM underlies all of the ActiveX technologies, including today's most popular kind of component, ActiveX Controls. Having a single leading standard, especially one promulgated by a vendor with the muscle of Microsoft, makes the decision to use component-based development much easier. It also makes the decision to support components much easier for tool vendors. Today, for example, virtually all popular development tools for Windows and Windows NT can make use of components that conform to the ActiveX standards, and sometimes to other component standards as well. This widespread industry support means that users have a broad range of choices in which tools to use.

• A large third-party component market is in place. According to the Giga Information Group, the market for ActiveX controls amounted to $240 million in 1996 and will grow to $3.3 billion by 2001. Microsoft says that there are now over 2,000 commercially available ActiveX controls. These are critical facts, because a primary benefit of component-based development is the ability to buy proven, tested software from component vendors. Today's large and growing component market means that developers can choose from an ever-larger set of components in building their applications. And according to the Gartner Group, ``the number of component providers can be expected to grow dramatically during the next few years.'' Also, major software vendors such as Lotus and Progress have begun to create and sell components, joining the many smaller vendors that were the first entrants in this market. Lotus has even mounted a major advertising campaign in the general IS media for its component offerings.

• The types of components available are expanding rapidly. The size and growth rate of today's component market isn't the only exciting thing about component-based development. When components first appeared, they were primarily simple user interface elements--buttons, sliders, list boxes, and the like. Today, however, much more powerful choices are available, including components such as calendars, spreadsheets, stock tickers, voice recognition software, and many, many more. In fact, Gartner Group maintains a catalog of third-party components to help their clients make appropriate selections from this large marketplace.

• Components are moving off the desktop and beginning to play an important role in creating server applications. Often referred to as business objects, server components wrap specific business functions into reusable packages. According to Giga, the percentage of components deployed on the server will more than double by 2001. Major vendors of packaged software for servers, such as SAP, are ``componentizing'' their applications in some ways to permit greater reusability and customization. And some organizations are beginning to develop their own reusable business objects targeting their specific needs.

• Components are a key part of web-based applications. Any web application that requires significant client-side processing relies on components. Whether written in Java or packaged as ActiveX controls, components running inside web browsers are the only way to perform powerful web-based processing on clients. As the web continues its remarkable expansion, the use of components will expand along with it.

• It has now become significantly easier to create components. Until recently, for example, ActiveX controls were largely written in C++, which meant that the number of developers skilled enough to create them was somewhat limited. With the release of Visual Basic 5.0 this year, however, Microsoft has made it possible to write ActiveX controls in Visual Basic. This puts creation of ActiveX controls within reach of the mass of developers. Many other tools also either support or will soon support this ability, including PowerBuilder and Borland's Delphi. While easier control development will undoubtedly help third-party component vendors, the real beneficiaries will be component creators in IS organizations who are now much more able to develop components for internal reuse.

• A critical mass of component-based developers exists. Many organizations have been building at least some component-based applications for several years with good results. The skills needed to create those applications are no longer rare.

• Powerful tools have become available for designing and testing component-based applications. Successful component-based development requires more that just slapping together some nifty components. The fundamentals of good software engineering are every bit as important in component-based development as in traditional approaches. Creating a well-thought-out architecture, using an iterative development process that assumes you won't get everything right the first time and accommodates change, and effectively testing each major iteration are still essential parts of the process. Like any other kind of software development, successful component-based development depends on good architecture and effective tools. Several vendors, including Microsoft, Rational and others, provide products for modeling and testing components and component-based applications. In fact, Microsoft provides its Visual Modeler tool as a standard part of Visual Basic 5.0 Enterprise Edition. Many vendors also provide repositories for storing and locating components.

``The technical component market is exploding,'' says Gartner Group, and ``during the next five years leading application development organizations will move from building applications from scratch to assembling them from components.'' Component-based development has become popular because the benefits of this approach are so compelling. Among them are:

• Component-based development can produce applications more quickly. Assembling an application from components, then writing only the code required for new features is much faster than writing the entire application from scratch. As hardware designers have known for years, building on existing components is a very effective way to increase productivity.

• Component-based development can result in higher quality, more reliable software. Creating an application that's largely constructed from existing components means that much of the application's code has already been tested. While testing of the complete application is still required, component-based applications can be more reliable than those developed using traditional techniques simply because the code within each component is already known to work.

• Component-based development lets developers focus more on business problems. Building a component-based application using, say, Visual Basic is significantly easier than building an object-oriented application in C++. While this does not mean that programmers are no longer needed--far from it--component-based development lets those programmers spend more of their time addressing the business problem they're solving rather than worrying about low-level programming details.

• Component-based development can be cheaper than traditional development. Because component-based development allows building more reliable applications in less time, it can save money.

• Component-based development allows easy mixing and matching of languages and development environments. Components written in one language can be easily used from another language or even another machine. The component model provides a standard packaging scheme that makes this transparency possible.

• Component-based development offers the best of both alternatives in the build vs. buy decision. Rather than buying into a complete and perhaps less-than-perfect packaged solution, an organization can purchase only the required components, then combine them into a customized solution. Doing this lessens risk, because the purchased components have already been extensively used and tested, while at the same time allowing the organization to build a customized solution to meet its unique needs. This is an especially attractive approach for server components. In fact, we may see server applications packaged entirely as groups of components in the not-too-distant future, with each component complementing the others to provide a complete, highly-customizable service.

Componentware, the promise of assembling quality software from off-the-shelf components, is the only software development technology on the horizon that might have a dramatic enough impact on programmer productivity to eventually address the software shortage.

-Avron Barr and Shirley Tessler, Stanford Computer Industry Project

A Component Taxonomy">

As the figure above shows, components today can be grouped into four categories, and various component technologies address each of those categories. The categories and their relevant technologies are:

• In-process client components. This style of component must run inside a container of some kind--it can't run on its own. Popular choices for containers today include PowerBuilder, Visual Basic, and web browsers such as Netscape Navigator. A developer is usually able to manipulate this style of component visually, allowing her to build an application from components by dragging them onto a form, then writing the code needed to make them work together. The leading technologies for creating in-process client components are Microsoft's ActiveX Controls (which are based on COM), IBM's OpenDoc, and Sun's JavaBeans.

• Standalone client components. Any application that exposes its services in a standardized way to other software can be used as a component. Many Windows desktop applications do this, including Excel, Word, CorelDraw, and more. By far the most common technology used for this purpose today is Automation, which is another application of Microsoft's COM.

• Standalone server components. A process running on a server machine that exposes its services in a standardized way can also qualify as a component. This kind of component is accessed via remote procedure calls or some other kind of network communication. The most visible technologies supporting this option are Microsoft's Distributed COM (DCOM) and the Object Management Group's Common Object Request Broker Architecture (CORBA). Sun's Java environment also supports this option using Remote Method Invocation (RMI).

• In-process server components. Given a suitable container, in-process components can also be useful on servers. An obvious choice for a server-side container is a transaction server. The Microsoft Transaction Server (MTS) is an example of this kind of container, and it requires developers to create transaction programs as ActiveX (i.e., COM-based) components. Other vendors are following suit, and we will see other component-based transaction servers shipping soon. Sun has also announced Enterprise JavaBeans, a model for in-process components targeted to run in various kinds of server-side containers.

ActiveX is Microsoft's brand name for a range of technologies, all of which are built using COM. Despite the range of options for component models, COM will remain the most widely used choice by a wide margin. To see why, it's useful to compare the various component technologies just described.

The largest part of the component market today consists of in-process client components, and the overwhelming majority of those components are ActiveX controls. There's a simple reason for this dominance: ActiveX controls are the best fit for Windows, and Windows dominates the desktop. Virtually all Windows programming tools support ActiveX controls, and Microsoft's relentless promotion of ActiveX has made it a very well-known technology. As long as Microsoft maintains its grip on desktop operating systems, the choice it dictates for desktop components-ActiveX controls-will be the overwhelming favorite of component builders.

What about the competition? OpenDoc is a beautiful, elegant technology, but it has already been left at the gate. Some OpenDoc components are available for OS/2 and the Macintosh, the technology's primary target platforms, but OpenDoc makes up only a tiny part of today's component market. Apple, one of the technology's original creators, has recognized this lack of success and decided to stop promoting OpenDoc. Its other parent, IBM, hasn't given up yet, but it's hard to imagine any way for OpenDoc to become a significant part of this market.

There's a stronger case to be made for JavaBeans. A bean is a component like any other, but it's written in Java. Since Java programs are typically compiled into a machine-independent bytecode, then interpreted by a Java Virtual Machine, the same component executable can run on any system with a Java VM. Given the tremendous surge of interest in Java, this in practice means that a Java bean can run nearly anywhere, since Java VMs have become widely available. The JavaBeans technology is quite new, and there aren't yet many beans available. Still, Java and Java-based technologies are riding a tremendous wave of enthusiasm, and we will surely see some components written as beans.

But the trade-off for JavaBeans developers is that beans can't take full advantage of the local operating system without losing their portability. The result is that the majority of client component creators will choose to build ActiveX controls, simply because it allows them to create the most powerful components for Windows, the world's dominant desktop operating system. Some client-side Java beans will certainly be available, especially for use in web applications . Still, because of the overwhelming preeminence of Windows, ActiveX controls will remain the dominant client component architecture for the foreseeable future.

The situation is more interesting for server components, both because it's a newer market and because there's no single dominant operating system. For standalone server components, the competition is between CORBA, produced by the Object Management Group (OMG), Sun's Java/RMI combination, and Microsoft's DCOM. For in-process server components, the leading technologies are Sun's Enterprise JavaBeans and Microsoft's COM-based ActiveX components. And once again, the Microsoft technologies are the heavy favorites in the race.

CORBA-based products provide good solutions for some kinds of problems, but building a component market hasn't been one of them. The initial OMG standards were quite loosely defined, making it difficult to write components that could be used with different vendors' products. Not surprisingly, then, there are very few CORBA components available today. The OMG is tightening up some of the key standards in this area, so it's possible that we'll see CORBA-based components play more of a role in the future, especially on Unix servers. Still, OMG's initial inability to agree on a number of fundamental issues has left its technology in a weakened position.

Java-based server components are more attractive, especially in the diverse operating system environment that characterizes the server market today. The attraction of being able to write a component once, then deploy it everywhere, is sure to motivate the creation of some Enterprise JavaBeans and other Java-based server components. At the same time, however, Windows NT is likely to commandeer a large part of the server market over the next few years. The reasons commonly cited for NT's predicted popularity-increased ease of use, better integration with Windows clients, and improved price/performance-still hold even for applications and components written in Java. It's unlikely, then, that the use of Java to create server software will slow the growth of NT. And once NT becomes a large part of the server market, the benefits of writing server-side ActiveX components become much stronger, just as they are on the desktop today.

ISVs who choose DCOM can build on the knowledge they've gained creating desktop ActiveX components-it's a natural evolution. Also, DCOM will ship with every copy of Windows and Windows NT, making it ubiquitously available. Software AG and others are porting Microsoft's DCOM code to MVS and various versions of Unix, and the Open Group plans to begin distributing that code as well. Once this occurs, it's likely to increase even further the rate at which DCOM becomes widely available on non-Microsoft operating systems.

As component-based development becomes a key part of every organization, choosing the right component model is a critically important decision. This choice will likely have more long-term impact on an organization than the choices made for programming languages or development tools. Microsoft's COM is the only component model that effectively covers all four kinds of components today. It also has a commanding lead in today's largest component market, in-process client components for Windows. And as Windows NT gains in popularity, COM-based server components will grow along with it.

This is not to say that other kinds of components won't exist-they surely will. In fact, predicting yet another Microsoft victory gets tiresome. But there's no way around it: as long as Windows and Windows NT remain so popular, ActiveX-based components will be the safest bet.

There's no way to build a web application with significant client-side processing without using components. According to Giga, the single largest motivation for the deployment of new ActiveX controls will be for the creation of web applications. If a user just loads a simple HTML page into his web browser, no components need be involved--the browser just displays whatever is on that page. It's even possible to include relatively simple scripts in the page, written in languages such as JavaScript or VBScript, that allow the user to perform some basic interactions. But to go beyond this, to create a web application of any substance, components are essential.

To see why, think about what a powerful web application does. First, it accepts input from its user through some sort of GUI, much like a traditional client/server application. It's possible to create that GUI using JavaScript or VBScript running in the browser, but there are limits to what these scripting languages can provide. Building truly powerful user interfaces requires using components. Those components, typically packaged today as Java applets or as ActiveX controls, can be downloaded from a web server when needed, as shown in the figure above. Once loaded into the web browser, the components can carry out whatever client side processing this application requires, whether it's as simple as verifying user input or as complex as providing services to investors.

The user's input is eventually sent across the network to a web server. The server very likely uses the information the user supplied to dynamically generate an HTML stream that's sent back to the client and displayed. Today, a common way to do this is by running an application on the server that is accessed via the Common Gateway Interface (CGI), an approach that typically doesn't use components at all. But increasingly, vendors are allowing server-side web applications to use components to carry out their functions. Microsoft's Internet Information Server, for example, supports the use of Active Server Pages (ASPs). An ASP can contain a server-side script that creates and uses available components on the server, including MTS components. Server components can now easily be part of this side of a web application, too.

Only a minority of web applications use components today. Within the next few years, however, this number will increase dramatically. On the client side, components are essentially the only way to run complex functions in browsers. And on the server side, web applications can get the benefits of components--faster, cheaper, easier development--just like any other application. As the number of web-based applications increases, so will the use of components in those applications.

Components bring with them most of the benefits of object technology. While it's not their most important benefit, objects can encourage reuse of existing code. Components achieve this in spades, as the size of today's component market makes clear. But plenty of other schemes exist to accomplish reuse, as well, and we've heard for years that objects would usher in an age of extensive reuse. Before components appeared, this promise never quite came true. Yet according to IDC, "Component-based software development will allow organizations to make good on the original promises of object technology: extensive reuse, increased productivity, and significantly higher software quality.''

How are components different? Why have they succeeded in creating a large off-the-shelf market where objects did not? To answer these questions, it's useful to compare components to two popular mechanisms for reuse today: ordinary procedural libraries and object-oriented class libraries.

Libraries have long been a popular way to package code for reuse, and there may be some situations where they are still the best choice. But where it is feasible to package code into components, it's usually a better choice for a number of reasons. First, because components often allow developers to assemble applications visually, they can be easier to use than traditional libraries. And since the programmer is still able to write code that invokes a component's methods (i.e., the functions it exposes), it's possible to access that component's services just as if it were a conventional library. Also, component models such as Microsoft's COM provide much better version control than do traditional libraries. And finally, as the use of components grows, the programmer's environment will consist more and more of nothing but components. Packaging what might otherwise be libraries into components allows the programmer to use all kinds of services in a consistent way, even those running on remote machines.

Libraries grew up as a way to package code written in procedural languages like Fortran and C. With the rise of object-oriented languages, libraries of procedures morphed into libraries of objects. Called class libraries, they have become the foundation for reuse in object-oriented languages such as C++ and Smalltalk. Class libraries have proven to be a very effective mechanism for reuse in many situations, and many commercial class libraries are available. And as with conventional procedural libraries, there are situations where reuse via a class library is the right solution. Still, components are often a better approach.

For one thing, components are generally much easier to use than class libraries. Using a class library often requires understanding how the various pieces of the library fit together, something that can be a complex undertaking for powerful class libraries. Using a component is typically much simpler. For client components, the programmer can often just use a development tool's visual interface to place the component where it's needed, then write any necessary code to use the component's services. While class libraries can sometimes be more powerful, components are much simpler to understand and use.

Components can also allow cross-language reuse. Component architectures typically define interactions with their clients that aren't dependent on the language either is written in. It's very common, for example, to see components written in C++ used with PowerBuilder or Visual Basic. Class libraries, on the other hand, generally require the programmer reusing them to write in whatever language the class library itself is written in. Since most class libraries today are in C++ or Smalltalk, this can impose a burden on programmers who are already conversant in simpler tools such as Visual Basic.

Finally, unlike typical class libraries, components allow distributing reusable code in an executable format--source isn't required. For the companies that sell those components, this is a great benefit, as it's hard to imagine that a large market in third-party components would ever have arisen if every vendor was required to divulge their source code. For the customers that use those components, however, this is less of a benefit. For relatively simple client-side components such as calendars, the absence of source isn't a serious problem. For server-side components, however, customers may well want the source for components that provide key business functions, if only to customize it when needed. Still, given the success of companies like SAP in selling packaged server applications as configurable binaries, it's not unreasonable to expect that server-side components might follow the same model. And for components developed internally, the ability to distribute components without source might actually be an advantage--it ensures that the programmers using those components can't modify the code, which means that whatever business rules a component implements are properly enforced.

First-generation component-based developers often took a straightforward approach: buy or build some components, then glue them together using a favorite visual development environment. What they learned shouldn't come as much of a surprise: this approach only works for relatively small or short-lived applications. Successful component-based development of sophisticated applications requires an effective application architecture, the proper controlled iterative development approach, and high-quality testing.

As always, creating the correct architecture remains a critical part of the development process. Components can improve that process in several ways, but for significant software systems, the quality of the software architecture is much more likely to influence a project's success than the set of available components. Having lots of components to choose from is helpful, but it's not enough.

In fact, the real power in component-based development comes from intelligent assemblies of hierarchies of components. In computer hardware, for instance, the hierarchy is chips, then boards, then systems. Often hierarchies in one generation of hardware become components in the next, as when whole boards get put on a chip. Similarly, the key to the power of software components lies in large-scale integration and reuse, not solely with the individual components themselves. Components composed of other components allow thinking about problems at the appropriate level of abstraction. Without this, we wind up thinking about individual transistors instead of chips and boards.

But creating correct, reusable component hierarchies requires designing correct architectures. The alternative--piecing together a complex system from a catalog of parts--won't work for anything beyond the simplest applications. Component technology and good architecture are intimately related.

Tools can help. Modeling tools focused on component-based development can be an effective means of understanding the problem and arriving at the correct solution. While modeling tools alone aren't enough--there's no substitute for ability and experience--they can greatly increase the chances of success.

Component-based development also does not remove the requirement for testing. If anything, it does the reverse, increasing the demand for this potentially expensive part of the process. Rather than following the traditional waterfall model--analyze everything, design everything, code everything, then test everything--component-based development is typically iterative. In iterative development, each of these steps is performed several times. The first iteration produces a running system that's only a subset of the complete solution, but still allows the developers to find and fix any major problems that show up. The next iteration gets closer to the final solution, and so on.

Iterative development also implies testing everything on each iteration to ensure the application is progressing--not regressing--in quality. The only practical way of achieving this is through automated testing, and it's another example of where good tools are an essential part of successful component-based development. Without automated test tools, doing the extensive, repetitive testing required by iterative development just isn't practical.

It's possible to get by with nothing more than a basic mechanism for assembling components, but only for small or short-lived applications. Major applications require a well-constructed architecture and comprehensive testing, and powerful tools can greatly contribute to the overall success of the endeavor. These tools exist and it makes sense to use them.

By 1999, component software will be the dominant method of new application development (0.7 probability).

- Roy Schulte, Gartner Group

• Component-based development will play an important role in nearly every commercial IS organization. How effectively an organization can create and modify its software has become a critical part of achieving success. By allowing easier development of more reliable, more maintainable applications, components can greatly improve this process.

• Choosing a component model is a critical decision. This choice determines which pool of components you'll be able to select from, what tools you can use to assemble applications using components, and how you'll create your own components.

• Microsoft's COM, the basis of DCOM and the ActiveX technologies, will remain the most widely used component model. The commanding position of Windows and Windows NT, together with the large head start Microsoft has in components, make this a foregone conclusion. Other component models certainly won't go away--JavaBeans are an excellent solution in some cases, and CORBA-based components will also play a role--but the bulk of the component market will focus on COM.

• The pieces are in place today to let component-based development become a mainstream approach for software development. In some situations, such as web-based applications, using components will be required to build powerful client software. In others, components will just be very attractive, allowing the construction of better applications in less time. And building better applications in less time is the very definition of competitive advantage.

• Even with components, there's no substitute for a good software engineering process. Component-based development is not an excuse for building applications by casually slapping together a few parts. Architecture matters, and as with other approaches to software development, good tools for modeling that architecture and for testing the result can be the difference between success and failure.

David Chappell is Principal of Chappell & Associates (www.chappellassoc.com), an education and consulting firm in Minneapolis, Minnesota. Through his seminars, videos, CD-ROMs, and books, he has helped tens of thousands of IS professionals understand and make better decisions about the rapidly changing world they live in. In his career, he has worked as a senior software engineer at Cray Research, chaired a US national standardization group, and been a keynote speaker at conferences in the U.S. and Europe. Today, David presents seminars on component technologies, distributed objects, and related topics around the world. In addition, he is a member of the Object Management Group, a columnist for Object magazine, and a frequent guest on the Computer Channel. His most recent book, Understanding ActiveX and OLE, was published in 1996. David holds a B.S. in Economics and an M.S. in Computer Science, both from the University of Wisconsin-Madison. He can be contacted at david@chappellassoc.com.