Previous column

Next column

---

Software Architecture John D. McGregor, Clemson University and Luminary Software, U.S.A.

COLUMN PDF Version

Abstract

Software architecture has received much attention in the past few years. This is not a block diagram that gives a rough functional decomposition of the system. It is a multi-perspective, quality-based approach to ensuring that software is built to fit its purpose. In this edition of Strategic Software Engineering we will consider how software architecture provides strategic support to the organization.

1 INTRODUCTION

This column began in the last issue with no overview of its scope and I would like to provide that now. As the name “Strategic Software Engineering” implies, I intend to discuss aspects of software engineering that assist a company in achieving and maintaining strategic advantage. As software becomes omnipresent in products in all domains, we have increasing opportunities to not only help achieve the vision of our companies but also to help shape what that vision is. Since “strategy” is not a prominent idea in technical education and training, I hope this column will raise awareness and provoke discussion.

In the last issue I provided an overview of the software product line strategy. This approach to software-intensive product development has allowed a number of companies to achieve strategically significant objectives that have affected their market position. In this issue I will discuss the strategic impact of modern software architecture approaches. In future issues I will talk about topics such as domain-centric development, the range of development process models, and the strategic implications of testing. I look forward to hearing from readers with differing opinions or who have suggestions for topics.

The software architecture practiced today is not your mom’s architecture. The days of drawing a simple block diagram to identify separate functional units or handcrafting each individual application are over [Lloyd 99]. Today’s software architecture provides a more comprehensive, but also more exacting, model of the completed system. Software architecture techniques support sophisticated analyses of the system before it is implemented. These techniques, such as Attribute Driven Design (ADD) [Bass 03], ensure that the software implemented using the architecture is fit for its intended purpose.

There are a number of examples of using architecture for strategic purposes. The Common Object Request Broker Architecture (CORBA) is one well-known example. CORBA was used to bridge together various legacy systems, integrate systems written in multiple languages, and facilitate interaction between machines with different hardware architectures. This was intended to provide legacy systems with new life while allowing new applications to be quickly integrated giving the company a strategic advantage over companies that modified legacy systems. In this column I will explore a more recent example: a very brief case study on the Eclipse open source IDE platform.

In this column I will provide an overview of modern software architecture concepts. Then I will show how software architecture can have strategic impact. I will conclude by suggesting some actions that archiects can take to influence business strategy.

2 OVERVIEW OF SOFTWARE ARCHITECTURE

The architecture of a software system defines its structure. In fact, it defines several structures, each of which comprises elements and the relationships among those elements. The elements may be computational entities related by control flow or business entities connected by semantic constraints. (The software architecture web page at the Software Engineering Institute, http://www.sei.cmu.edu/architecture/definitions.html, has a large number of definitions. Take your pick.)

The basic architecture design process consists of a systematic decomposition of elements into aggregates of more detailed elements. In Figure 1 the initial monolithic element is decomposed into a Model, Controllers, and Views elements. Each of the new elements contributes to the total behaviors that the original element had.

Figure 1 - Architectural decomposition

Using an approach such as ADD, the architect chooses a specific decomposition in order to enhance certain of the qualities the final product should possess. Each decomposition also usually degrades certain qualities as well. In Figure 1, the Model-View-Controller decomposition is chosen to make the system more modifiable. Specifically to enhance the ability to add new views on the model. The decomposition also degrades performance because of the overhead of the Model notifying Views when a change has occurred. This is an acceptable trade-off for the architect since the system only operates in human time as opposed to being a “real-time”, i.e. computer time, system.

The architecture creation process seeks to develop a system with specified functionality and specified levels of certain qualities, which have been prioritized. Beginning with a monolithic structure that embodies all of the required functionality, represented by the box on the left in Figure 1, the architect systematically decomposes the functionality and allocates it to members of the newly created structure.

Figure 2 - Further decomposition

The decomposition process continues, as shown in Figure 2, until the members of the architectural structure are sufficiently fine-grained. That point is reached when the optimum mix of quality levels is achieved. Then, individual teams can be assigned to design and implement each “chunk” of the architecture.

The drawings in Figure 1 and Figure 2 intuitively show the elements and relationships in our simple architecture but they are not very specific. The drawing in Figure 1 communicates to those who already know the story of MVC but it does not have sufficient detail for the novice to understand. A number of architecture description languages have been developed [Luckham 95][Allen 94] that support detailed specifications of architectures; however, these have never gained widespread acceptance. Many of the concepts represented in these languages have been incorporated into the latest version of the Unified Modeling Language, UML2.0[OMG03]. Figure 3 illustrates some of the notation for the information in the decomposition on the right in Figure 1.

Figure 3 - UML architecture diagram

In Figure 3, the UML diagram provides additional information about the provides/requires and signals/catch interfaces for each module. Each small rectangle on the boundary of a larger rectangle represents a port, an abstraction of an interface which hides exactly how the interface is related to the module, the bigger rectangle. Each “lolipop” and “cup” represent a provides and requires defintion respectively. This shows diagrammatically the relationships among modules but does not provide the details of the required and provided behaviors. I am not trying to give a tutorial on UML2.0 or architecture documentation. This diagram should be sufficient for the references that I will make later in the column.

This still captures only a small fraction of the information needed. In this case, largely information about the static structure. The architect creates various diagrams to depict the component structure, component communication, and the component deployment. The architecture description contains several “views” of the architecture that serve to provide different types of information about the structure of the software. One of the dynamic interactions among the static architectural elements from Figure 1 is shown in Figure 4 using a UML sequence diagram.

Figure 4 - A change to the Model is propagated

While this describes basic architecture design actions, it does not realistically portray the typical architecture development approach. In most cases, the architect begins with a pre-defined, i.e. reference, architecture. This may be the proverbial “de facto industry standard”, such as J2EE for e-commerce, web-based applications or it may truly be a requirement such as the Command, Control, Communications, Computer, Intelligence, Surveillance, and Reconnaissance (C4ISR) architecture framework for certain military systems in the United States. These reference architectures provide a high-level decomposition that sets the basic levels of design qualities but leaves room for the architect to perform low-level decompositions that further differentiate the quality attribute values for their product.

Selecting a specific reference architecture leads to the use of components that have been developed with that architecture as a design base. The commercial community that grows around an architecture is an important factor in selecting which architecture to choose. The larger and more diverse the community, the more likely that components can be purchased to speed product development. Also patterns, books of advice and examples, and other assets are available for that architecture.

The architecture development process is part creative construction and part management planning. The architecture business cycle [Bass 03] provides the opportunity for the organization to think at a strategic level about the competition, trends in their domain, and the evolution of technology. In the next section I will provide some examples of these activities.

3 STRATEGIC USE OF SOFTWARE ARCHITECTURE

In any company, architects help translate business strategy into technical strategy. In companies that produce software-intensive products , the architect can have input into business strategy [Malan 02]. This ensures the architecture fits the corporate strategy and it helps the company take advantage of strategic opportunities provided by the architecture. Porter describes strategy as “defining a company’s position, making trade-offs, and forging fit among activities”[Porter 96]. I want to examine a number of architecture-related situations in terms of that definition.

Strategic Planning

Architecture can serve as a vehicle for positioning the company. Maccari and Galal define an architecture view, termed the architectonic view, which provides a means for explicitly representing the actual and planned evolution of the architecture [Maccari 02]. This view considers the system being architected as a set of layers that divide the modules of the architecture according to the likelihood the module will change. This can be based both on historic data and forecasts for technology and domain changes. Figure 5 shows the architectonic view of the MVC where the addition or deletion of a View is most likely change to the system. This view can capture strategic information from domain studies and other business intelligence.

Figure 5 - Architectonic view of MVC

The architecture can provide a strategic roadmap for the company’s products, perhaps as a product line [McGregor 04]. Architecture analysis techniques provide a means of validating the direction of the evolution of the architecture and the products.

Enterprise Architectures

An enterprise architecture is used to provide top level executives with an integrated view of the totality of their Information Technology (IT) enterprise. An enterprise architecture shows how all of the facets of an organization’s computing environment fit together. While the enterprise architecture encompasses more than software architectures, it does provide a context in which software architectures are coordinated.

In a series of articles Malveau describes how an enterprise architecture bridges the gap between business and technical strategies. He makes the point that “crucial high-level business decisions should not be contrained by technical concerns.[Malveau 04]” I agree but with the emphasis on the “should.” In fact, technical concerns sometimes do need to be considered in companies whose chief business is the development of software-intensive products. Telecommunications and, most recently automotive, executives are finding that their companies have become software dependent. They are adopting strategies that flow from standard architectures in their domain. Several automobile manufacturers including BMW, VW, and DaimlerChrysler announced plans to create, and market, a standard software architecture for automobile electronics, AUTOSAR [Hansen 03].

The Zachman Framework for Enterprise Architecture [Zachman 87], Figure 6, provides a context in which the input from technical staff is blended with input from executives to establish the information technology strategy for an organization. The framework guides the enterprise architects to trade-offs that must be made among the information represented in each cell of the table. By resolving these trade-offs, there is close fit among the activities represented in the cells.

For example, consider the Application Architecture cell, at the intersection of the two arrows in Figure 6. Adjacent cells relate the application architecture to business processes, up, the system design, down, logical data model, left, and distributed architecture, right. The row provides an architectural view while the column represents a hierarchical relationship from abstract to concrete, from domain to implementation.

Figure 6 - Zachman Framework for Enterprise Architecture

Reference Architectures

Choosing a reference software architecture, say the J2EE architecture, as the starting point for a product or product line has strategic implications. For one thing, when you choose a reference architecture you join a community, something like marrying into a family. The community has a history and a culture.

• A major consideration in selecting one architecture over another is the availability and expense of artifacts. The community that builds up around an architecture will have a “cultural” bias about how the community operates. Consider the availability and cost of artifacts for the J2EE environment and for the CORBA environment. The selection of one community over another has major cost implications. The J2EE community has much more of a low-cost, open source history than does the CORBA community.
• One of the technical concerns that should significantly influence business decisions is the company’s prior investment and required future investment in staff expertise. Most product development requires technical knowledge and skill that can not be developed within the development schedule for a single product. Technical managers make investment decisions in advance of product requirements. The complexity of reference architectures and their accompanying infrastructure require substantial time to learn. A business decision to adopt a different strategic direction that will make obsolete much of the technical knowledge of the development staff and require substantial investment in acquiring new expertise must include consideration of these costs.
• Although the time between releases of versions of a reference architecture is relatively long, the amount of change is often rather large. The anticipated sequence of releases has strategic significance since it influences the refresh rate of the development assets. Major, frequent changes to the architecture requires that assets be modified often. Suppliers work to the latest version of a standard. Not upgrading to the latest version can make it difficult to purchase components and can signal to customers that obsolecence is just ahead. I have had success with a view in the architecture that captures release dates for technologies, products, and standards. It can be combined with the architectonic view shown in Figure 5.
• The appropriateness of the reference architecture and its generality affect the applicability to a wide range of products. Earlier I described a decomposition technique that ensured that the architecture possessed the required qualities. When a reference architecture is to be selected, its qualities are already determined. The candidate architectures must be evaluated, using a technique such as the Architecture Trade-off Analysis Method (ATAM) [Bass 03], to determine which most completely supplies the quality levels that products built from the architecture are expected to possess. For example, I once had a client who was using the J2EE architecture for an application that consisted largely of streaming video. The transaction-orientation of J2EE was resulting in very poor performance for the video feed.

Architecture as Product

After you have optimized delivery to your primary markets, the next strategy is to position yourself as a supplier to your competitors. For example, Nokia has achieved a strategic advantage in the cellular phone industry by establishing their architecture and component libraries, the S60 platform, as a product that provides several competing cell phone manufacturers a large percentage of the software needed for their cell phone products [Nokia 04]. They have provided a platform and an architecture that have attracted additional independent suppliers who provide products based on the architecture. Nokia has made this a strategic approach by providing an architecture and component libraries for several different types of cell phones. Because of its position as supplier, Nokia is now in a position to chart the direction of future evolution not only of their own products but of those of their competitors as well. They have achieved a close fit between their activities as a producer of products and as a supplier of parts.

4 CASE STUDY: ECLIPSE

Eclipse is an open source project producing a platform upon which integrated development environments can be built. This is a project with an architecture that is intended to enhance the quality of supporting distributed development and maintenance of behaviors. Beyond a basic core functionality, behaviors are added to Eclipse by defining and implementing a plug-in. A plug-in is a package that combines code that implements the functionality being added to Eclipse and an xml-based manifest that provides configuration information. The manifest describes extensions to menus, functionality that must be present for the plug-in to work correctly, and new windows that will be part of the Eclipse view. Figure 7 shows a screen print of Eclipse I took recently while using the Java Development Tools (JDT) perspective. The task list at the bottom right of the screen is a plug-in that can be removed, not only from the screen but from the product.

Figure 7 - Eclipse interface

The Eclipse architecture is defined to faciltate the addition of new plug-ins and the removal of irrelevant ones. The plug-in is deployed by creating a sub-directory, in the plug-ins directory, into which is placed the implementation files as well as the manifest. Plug-ins are bound to Eclipse at start time for an instance of Eclipse. A plug-ins directory is searched and each sub-directory that contains the manifest is processed to bind the new behaviors into the running instance. More details on the Eclipse project can be found at http://www.eclipse.org.

Eclipse was initiated by IBM a number of years ago and more recently was released to the open source community. The plug-in architecture is a strategic move to support a broad spectrum of development purposes. Eclipse is a part of IBM’s e-commerce on demand strategy. The ease of extension provided by the architecture is intended to allow IBM to remain visible in niche markets where it can not satisfy every tool request but it can provide the basis upon which others develop their products. The open source nature of Eclipse allows IBM to create implicit relationships with other tool vendors through mutual dependence on a common architecture.

The Eclipse architecture has made possible a rapidly expanding new market for both new and existing products. A recent visit to just one web site located 50 Eclipse plug-ins available either as open source or as commercial products. For example, the latest version of AcmeStudio [Acme 04] is now built as an Eclipse plug-in. The granularity of a plug-in allows small, non-profit organizations as well as large companies to participate in the marketplace.

Several strategies come together here. The strategy of open source is well known and provides many benefits. The Eclipse project has chosen an architecture that facilitates the integration of contributions from a diverse group. The strategy of providing a configurable tool for developers builds the community of users who will, at some point, be in the market for commercial goods and services.

5 ACTION LIST

Lets consider some steps that you might take to increase the strategic value of your software architecture.

• Develop a comprehensive, modern, validated software architecture for every product you build. Too many companies still neglect this first, and most fundamental step. Use UML, as shown in Figure 3, or similar architecture description notations so that the architecture description is precise and unambiguous.
• Coordinate the individual software architectures in your organization. Use software product line techniques for sets of products that are closely related. Use enterprise architecture techniques to organize in-house activities and products.
• Ensure close fit among product development activities by organizing around the architecture. Use ADD or similar architecture design techniques to establish traceability between the software architecture and corporate priorities.
• Ensure that trade-off decisions are traceable to the qualities and ultimately the strategic objectives of the organization. Provide architectural views that show the mapping between corporate strategic goals and architectural decisions and the evolution of the architecture.
• Scan the environment continually for emerging technology trends, industry consortia that form around a specific technology such as the Object Management Group (OMG) and stay current with software architectures that are defined by domain specific groups for a particular domain such as automotive or telecommunications.

6 SUMMARY

The software architecture is a key ingredient in a software-intensive product development effort. It provides a means of defining and achieving corporate strategic objectives. I have illustrated several ways in which this is accomplished. Finally I listed some possible actions that can be taken by those who wish to have a strategic impact in their company.

REFERENCES

[Acme 04] AcmeStudio http://www-2.cs.cmu.edu/~acme/AcmeStudio/AcmeStudio.html.

[Allen 94] Robert Allen and David Garlan. „Formalizing Architectural Connection”, Proceedings of the 16th International Conference on Software Engineering, May 1994.

[Bass 03] Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice, Addison-Wesley, 2003.

[Clements01] Paul Clements and Linda Northrop: Software Product Lines: Practices and Patterns, Addison-Wesley, 2001.

[Hansen 03] Paul Hansen. “Software as Product”. Automotive Industries, Oct. 2003.

[Lloyd 99] P.T.L. Lloyd and G.M. Galambos. “Technical reference architectures”, IBM Systems Journal, v 38, n 1, 1999.

[Luckham 95] David C. Luckham and James Vera. “An Event-based Architecture Definition Language”, IEEE Transactions on Software Engineering, v 21, n 9, pp 717 – 734, Sept 1995.

[Maccari 02] Alessandro Maccari, Galal H. Galal. « Introducing the Software Architectonic Viewpoint”. WICSA 2002, pages 175 – 189.

[Malan 02] Ruth Malan and Dana Bredemeyer. Strategy Architect Competency Elaboration, http://www.bredemeyer.com/pdf_files/StrategyCompetency.PDF, 2002.

[Malveau 04] Raphael Malveau. “Bridginging the Gap: Business and Software Architecture, Part 1 – 4”, http://www.cutter.com/research/2004/edge040113.html.

[McGregor 04] John D. McGregor: “Software Product Lines”, in Journal of Object Technology, vol. 3, no. 3, March-April 2004, pp. 65-74. http://www.jot.fm/issues/issue_2004_03/column6

[Nokia 04] Nokia, http://www.nokia.com/BaseProject/Sites/NOKIA_MAIN_18022/CDA/Categories/Phones/technologies/

[OMG01] Object Management Group: Model Driven Architecture, Doc # ormsc/2001-07-01, Object Management Group, 2001.

[OMG03] Object Management Group: OMG Unified Modeling Language Specification Version 1.5, Object Management Group, 2003.

[Porter 96] Michael E. Porter. “What is Strategy?” Harvard Business Review, Nov. – Dec. 1996.

[UML 03] Object Management Group. Unified Modeling Language 1.5, 2003.

[Zachman 87] John A. Zachman. “A Framework for Information Systems Architecture”, IBM Systems Journal, vol. 26, no. 3, 1987.

About the author

Dr. John D. McGregor is an associate professor of computer science at Clemson University and a partner in Luminary Software, a software engineering consulting firm. His research interests are software product lines and component-base software engineering. His latest book is A Practical Guide to Testing Object-Oriented Software (Addison-Wesley 2001). Contact him at johnmc@lumsoft.com.

Cite this column as follows: John D. McGregor: “Software Architecture”, in Journal of Object Technology, vol. 3, no. 5, May-June 2004, pp. 65-77. http://www.jot.fm/issues/issue_2004_05/column7