So, You Want Software Reusability?

Seemingly forever, reusability has been software's fountain of youth-like elusive goal. Yet, reality has almost always been the exact opposite. Since the beginning of programming time, most software has been incredibly brittle. Developers walk around their code like they're stepping on egg shells, constantly afraid that a small change in one portion of a program will create unexpected changes in behavior somewhere else.

Architecture represents the collective wisdom of the software industry on how to achieve reusability. It began with the simple notion of separating data and process. That lesson is as valuable today as it's ever been, but the concept of Data Architecture and Business [Process] Architecture has evolved over time.

The concensus today, manifested by the object-oriented revolution, is that Data ought to consist not only of properties (i.e., data fields) that describe real-world entities, but also the operations one can perform against those entities. By organizing the programming logic associated with an object's behavior directly with its data, object-oriented facilitates reusability by making code much easier to locate when changes need to be made. Additionally, by supporting the metadata relationships of inheritance and composition (i.e., objects made up of other objects), object-oriented enables development by exception. This allows for reuse by extending code created to support generic cases with new code defined to handle special cases.

As important as business objects are, data does not exist in isolation. Rather, business objects get created and manipulated as a byproduct of Business Processes. A business process is defined in terms of business events and business rules. Note that there is always a time element associated with a business process. That is, there's a starting point, an ending point, and some number of intermediary steps in between. An enterprise is essentially defined by its underlying collection of business processes. As such, the specification and control of business processes is seen by business people as absolutely essential. Unfortunately, there's still no body of knowledge associated with business processes that's comparable to the role object-oriented plays with respect to business data. The key missing piece is an ability to easily support development by exception. In other words, there's no simple, intuitive way to modify and extend an existing generic business process in order to accomodate a special case.

Business solutions, referred to as Applications, consist of some combination of data and process. Defining how to put these pieces together is the job of Application Architecture. In creating applications, there are two key issues that need to be addressed. The first involves partitioning which means determining which portion of executable code runs on which platforms. There are various ways of partitioning processing that range from fat clients to thin clients depending on how much of the code runs on the front-end versus how much runs on the back-end. In between are various ways of handling interprocess communication, some based on remote procedure calls, others based on object request brokers, and still others that depend on asynchronous message transmission. The second key issue involving Application Architecture pertains to integration. The challenge in building inherently flexible systems is to figure out how to compose new applications that can leverage existing business logic and functionality and combine it with either newly built services or 3rd-party purchased services.

Bottom line, it's impossible for an enterprise to reuse what it doesn't know it owns. Technology Architecture is responsible for modeling, documenting, and communicating whatever it is that already exists. Unfortunately, the task of controlling technology portfolios has not received high priority. As such, it's not unusual to find multiple costly examples of IT organizations owning different redundant products that deliver essentially equivalent overlapping functionality. As the software industry evolves toward a service-oriented Application Architecture, the problems resulting from a lack of a Technology Architecture will become greatly exacerbated.

So, if you want software reusability, then focus on Architecture:

• Data Architecture
• Business [Process] Architecture
• Application Architecture
• Technology Architecture