While there has been growing use over the last several years of the word "architecture" in the context of software development , it is not always clear what the phrase "architectural software development" really means. Applying the term to software can be confusing because of all the non-software uses of the word currently seen in the computer industry - client/server architecture, for example.
One way through the confusion is to define architecture in a way that is consistent with other IS (and even non-IS) usage of the term. In all uses of the word "architecture," the common theme is understanding of common component configurations. For example, client/server architecture addresses common hardware/system software platform component configurations and the networks that link them. Building architects understand how to configure the structural components that comprise a building. In the same way, all design and engineering disciplines address recurring components and recurring arrangements of these components that work.
By extension, then, software architecture addresses common software components and common interactions among these components. As client/server architectures are created from a finite number available hardware, network, and systems software components, and buildings are architected from a finite number of available structural components, architected software applications are created by choosing and adapting standard application software components into configurations that met specific sponsor requirements.
Given a component definition of architecture, an obvious prerequisite for an architectural approach to software development is that standard application software components exist. Since there is currently no commonly accepted list of such components, identifying candidate components is clearly a first order of business.
One way to begin creating this list is by recognizing that architectural components typically span a number of different application types. For example, the client/server architecture can support a wide variety of systems across many different industries, and a typical office building can house many different kinds of businesses. Thus, we might start by looking for software components that support a wide variety of application areas in the same way that network architectures or building components presently do.
Let's consider a concrete example. Delinquency collections and repair dispatch are, on the surface, very different applications. In a delinquency collections operation, office workers call people who are behind in their payments. In a repair dispatch operation, technicians load up their vans with tools and parts and drive to repair sites. Who can imagine two applications any more different? Yet if you look at design details for systems supporting these applications, you see enormous commonalties, centered around workflow functionality. Both applications are essentially workflow-dominated applications. The system assigns a worker to perform a particular task according to a particular priority based on particular skills, assists with the completion of the tasks, follows up on the results, and provides a variety of other common support services.
Because of the commonalties between these two applications, a substantial proportion of both be created through architectural reuse of common workflow-related objects such as task, work-queue, resource, tool, skill, worker, work-group, schedule, and so on. This, then, points to the essence of application software architecture: understanding of the commonalties between applications leads to architectural understanding, and this architectural understanding in turn leads to large-scale reuse of generic architectural components. To return to the workflow example, after developing many systems that control assignment and completion of tasks, developers begin to understand the commonalties that underlie these systems. With sufficient vision and motivation, development organizations will leverage this understanding by developing and reusing common software components to provide for generic workflow functionality, rather than developing workflow functionality from scratch with each new system.
Looking at this progression carefully, it becomes clear that there are three important aspects of architecture that must be addressed by an organization wishing to fully leverage architectural reuse. These aspects are:
The most obvious aspect of architecture is components and frameworks, as already discussed. Certain applications - what are generally called workflow applications - are centered around control of tasks. The task object is a dominant component of the application architecture. Once the developer has recognized the importance of task control to meeting the overall business requirements of the application, the application can, in large part, be created by adapting common workflow objects to the particulars of the business process being supported.
For example, in delinquency collections, the primary task is making a telephone call. In repair dispatch, the primary task is completing a work order. Rather than crafting objects called "call" and "work order" - objects that intermix generic and domain specific behaviors and data - the developer can allocate the generic task behaviors to generic task objects, placing only domain-specific behaviors and data into domain objects. With a sufficiently robust framework, the main specific aspects of the tasks will be isolated from the basic structure of the application. Thus, changes to the domain-specific aspects of the application will not require large-scale changes to the application architecture.
Organizations that routinely develop large-scale commercial software applications have begun to identify a number of architectural frameworks that recur across applications in the MIS domain. These frameworks provide a set of generic components that account for a good proportion of the robust functionality of a business application. Workflow is just one of the component frameworks that have been identified. There are a number of others, including:
Data Interchange. Acquisition of information from outside of the organization and the immediate "reaction" of the organization to this information. A familiar example is a transactional event such as acceptance of an order. Generic data interchange design issues include exception resolution functionality, reference to organizational business policy, effective dating, reversals, overrides, reconciliation of controlled counts and values, audit trail, and a host of others.
Consultation. Interaction with the application to glean information about specific database entity or object occurrences. Basic information needed for direct access is already known. For example, an inquiry can be the access of an organizational database, image base, or knowledge base to answer a specific question about a single customer. This is often associated with a customer service business process.
Search. Access of information about a relatively large number of related entity occurrences within available databases. Information needed for direct access is not known in advance. Updates to information (e.g. a late charge) may be triggered by a search. This is often associated with decision support, information warehouse, and scheduling and aging business processes.
Table Manipulation. Direct addition and change of data occurrences displayed as tables or records. Examples are maintaining reference tables, correcting operational data tables due to unexpected problems, and manipulating data tables such as spreadsheet-based financial models. Substantial functionality is often required to provide security, controls, and audit trail for changes to sensitive data.
Representation. Interaction with an application based on a metaphor of entity properties. A common example is representing a data structure as its paper equivalent, e.g. a document, file folder, or book. Other examples include word processing systems and geographical information systems. Technology is permitting graphic and audio metaphors to become increasingly powerful in supporting business processes.
Information Distribution. Processing of extracts created within the other frameworks to create final-form reports, documents, and output data files, along with the dissemination of these outputs to their proper destination. Electronic mail is a common example.
But where does architectural understanding of components and frameworks like these come from, and how is it best disseminated to developers? For example, how will developers of a repair dispatch system learn the basics of workflow, other than through the school of hard knocks? Mere availability of a reuse library isn't enough - mere availability of repair dispatch objects, without understanding of the generic aspects of workflow, will not guarantee success in creating a workflow application, especially if these objects are freely intermixed with a host of other objects in the reuse library. This brings us to the second important aspect of application architecture, systematic accumulation of architectural expertise.
A mechanism is needed to help disseminate architectural understanding throughout development organizations, and, eventually, the entire software development community. For example, one company, American Management Systems (AMS), has created a tool called DesignPro that is a collection of over 500 design features that AMS experience has shown to promote product excellence and customer satisfaction. These features are organized into an overall architectural framework. There is, for example, a chapter on the common features of workflow functionality.
Such tools are not unlike the design handbooks seen in virtually every engineering discipline. For example, when an automotive engineer encounters a particular design issue (for example, dealing with transmission of power), he or she will not (and, indeed, is not permitted to) address the issue in isolation from the relevant experience of past generations of automotive designers. Instead, engineers access relevant design experience by referencing design handbooks. Several researchers have noted that a major difference between software engineering and more mature engineering disciplines is the availability of such handbooks. AMS's handbook is typically used in a number of different ways - as a facilitation tool during requirements gathering, as a starting point for prototyping, as a ready reference during design, and as a design review checklist. AMS experience is that such a design handbook, serving as a mechanism for pooling hard-won experience in successful design, is an important step in evolving towards architectural development approaches.
This brings us to the third aspect of architecture - architectural methodology. Architectural methodology has some important differences from traditional process-based methodology. With process-based, non-architectural approaches (including systems analysis and design, data driven design, object-oriented design, and the like), development generally has the following steps:
In contrast, architectural development has the following steps:
For example, let's consider how fully evolved architectural development of a repair dispatch application might proceed. Developers would quickly recognize repair dispatch as a workflow-centered application. They would gather requirements by walking through a formal workflow model with the sponsor to match the domain terminology of repair dispatch to the generic terminology of the workflow model. This would account for a good proportion of the requirements analysis and design phases of traditional approaches and proceed much faster. Developers would then adapt standard workflow components to actually create the application. Very few if any components would be created from scratch. The final result would be very robust and would look to the sponsor to be fully customized to their business, yet from the developer's point of view would be mostly generic. I have personally seen in practice that an architectural approach to development can dramatically improve integration, flexibility, reuse, and development productivity.
This approach may seem to be a very radical change from standard software engineering practice, yet this is exactly how the engineering process occurs in other engineering disciplines. A major issue, however, is how to transition to an architectural approach when the components and models needed for this approach aren't yet available. Design handbooks like AMS's DesignPro seem to be an important part of the answer. They provide the essential linkage between architectural concept and specific software components.
The software development community at large also needs to recognize that traditional approaches to reuse are essentially archaeological approaches. In archaeology, software artifacts are dumped into repositories and various carrots and sticks are employed in the attempt to get developers to scavenge through them. Let's ask ourselves - and answer honestly - how much use would a repair dispatch domain object called "work order" be to developers of a delinquency collection application, even if it contained considerable workflow functionality? Not much, it must be admitted; potential reusers would have to spend too much time separating out the domain specifics. This is why, despite four decades of hype, software archaeology has yet to produce meaningful levels of reuse. The better approach is to recognize and separate domain specifics from generic behaviors at design time - an architectural approach. This in turn requires a common, architectural understanding of what is generic and what is domain-specific.
A better approach to software development is clearly needed. Burgeoning hardware technology and business need are together propelling applications to higher and higher levels of complexity. This complexity is in turn driving ever higher project failure rates. Software engineers need to better emulate the standard practices of other, more mature engineering disciplines, who have wrestled with the issue of managing complexity far longer than we. Indeed, society at large has evolved architecture as the preeminent approach to dealing with extreme complexity. Architectural approaches are key to meeting the challenges of building the complex, large-scale, mission critical client/server applications that represent the next stage in the evolution of information systems.
Copyright 1995, AMS Inc.