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:
- components and frameworks,
- systematic accumulation of architectural experience, and
- architectural methodology.
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
- Table manipulation
- Information distribution
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.