What is Software Architecture?

Software architecture is really just a fancy name for application design. It is not a static cookbook applicable to diverse applications, any more than "architecture" in the building sense is a single blueprint from which skyscrapers, single-family homes, apartment buildings, and airport terminals can be built. As in any design process, tools, technologies, materials, and methodologies are chosen to fit the problem at-hand: a number of factors must be considered during any application's design process in order to arrive at useful and efficient decisions about which technologies ought to be used to implement an application.

Making Design Decisions

Application design decisions involve:

• Cost-benefit analysis of fit between user-requirements and deliverable capabilities;
• Selection of deliverable capabilities based on negotiation between developers and users/application-custodians;
• Identification of technology-tiers needed to implement deliverable capabilities;
• Allocation of technology resources from which components, implemented in conformity with appropriate Design Patterns, will be delivered to populate each technology-tier;
• Selection of appropriate technology stack with which new components are to be implemented.

In selecting an appropriate technology stack, factors to consider include the following:

1. is a UI required?
2. does the required UI require greater complexity than HTML can reasonably & elegantly support?
3. does the application require multiple UIs (e.g., "ubiquitous access")?
4. what will the typical number of concurrent users be?
5. what will the maximum number of concurrent users be?
6. what fraction of application usage involves transactional functionality (writing of persistent data)?
7. what roles and permissions (security requirements) are involved?
8. are content-elements relational data, documents, or both?
9. is the application public-facing or internal to the organization?
10. is the application mission-critical?
11. how much application down-time is acceptable?
12. what is the application's expected lifespan?

It is likely that applications for which the answers to these questions differ radically would be most efficiently and effectively implemented using different sets of technologies.

What's the role of a Software Architect?

Martin Fowler explains in his 2003 Software article Who Needs an Architect? that a software architect who serves as "the person who makes all the decisions" is a greater risk and a lesser asset to an organization than a software architect who serves a "guide," whose "most important activity [...] is to mentor the development team," who serves as "a more experienced and skillful team member who teaches other team members to better fend for themselves yet is always there for the really tricky stuff."

Scope of This Document

This document is intended as a high-level technology guideline applicable to a narrowly-profiled set of applications that are typical of those implemented and maintained by IS&T-SIS at UC Berkeley. It assumes that:

• The architect role at SIS is filled by a "guide" rather than by a solo decision maker (cf. SA role discussion, above)
• Application programmers should not repeatedly implement functionality that can be re-used across multiple use-cases (cf. Domains discussion, below).
• Using services provided by a programming language or deployment container is more efficient (and usually a better choice) than local implementation (cf. Domains discussion, below).
• An appropriate Project Implementation Environment is defined, implemented, and utilized to increase efficiency and reduce risk in software development efforts (cf. Project Implementation Environment, below.
• The technologies listed are appropriate to the application profile described; they are not recommended as implementation solutions to applications that fit other profiles.

Team

A very wide range of technologies is available to implement the technology-tiers of a modern application. No single developer can reasonably be expected to maintain expertise in all of them. Programming is therefore a lot like swimming: it's dangerous to do it alone.

Assembly of a team that collectively possesses the skills and expertise necessary to implement a project, and empowerment of team members to use and develop their expertise is critical to success. Assuming that one developer can singlehandedly implement a modern, object-oriented software application of any complexity is an almost certain guarantee of project failure.

A single person might fill more than one role on a team. Team members in addition to those listed in the diagram might include:

• Application Assembler
• Application Designer
• Application Deployer

The J2EE Platform Specification describes team roles from a more general perspective (cf. section 2.10 of the specification).

Practices

The practices listed in the graphic illustration are a subset of those developed for the methodology known as Extreme Programming. These are practices that have been debated, tested, refined, and found by software development experts to:

• increase efficiency of software developers, as individuals and as a team;
• mitigate risk of failure by identifying and addressing problems earlier and more decisively in the development process;
• facilitate effective management of application development by allowing regular, incremental evaluation of working software; and continuous improvement of the development process by which software is created.

Adherence to agreed-upon practices by all team members is critical to efficient working relationships and to interoperability of contributed components.

Tools

Without appropriate tools, developers are needlessly handicapped in performing their work. A "basic environment for good programming," according to Mary and Tom Poppendieck's book Lean Software Development includes:

• Automated Build Process
• Automated Testing
• Coding Standards
• Version Control

Widely used, well-supported, powerful, open-source or low-cost tools are available to provision this environment, such as:

• Ant (automated build process)
• JUnit, Canoo, JMeter, Cactus (automated testing)
• Jalopy (facilitated adherence to coding standards)
• CVS, Subversion (SVN) (code repository & version control)

These and related technologies are easily and affordably usable when developers work in the (free) Eclipse IDE.

Use of open-source software "where feasible" is a recommendation of the 2004 California Performance Review

Types of Technology Changes

A variety of technology change types are included in this discussion:

• Service packs and patches
• Version changes (generally upgrades; occasionally rollbacks)
• Replacement of component technologies in a technology platform
• Introduction of new components in a technology platform
• Introduction of new technology platforms to be employed in conjunction with platform(s) already in use
• Change of technology platform
• Development methodology changes
• Development process changes

These types of changes, listed roughly in order of increasing magnitude, generally require increasingly thorough and deliberate analysis by increasingly inclusive segments of an organization prior to adoption.

Criteria to Evaluate in Exploring a Proposed Technology Change

A broad set of critera, addressing the multi-faceted concerns of an organization, must be carefully explored by knowledgable team members before a responsible proposal to change a technology is put forward. Principal criteria are summarized as follows:

• What benefits to the organization will accrue from the proposed change? These benefits may include:
  • improved application performance
  • greater application security
  • facilitated integration between applications
  • reduction of barriers to potential developers (e.g., reduction of skill-level necessary to participate in application development, or facilitated access to powerful tools)
  • reduced development time
  • better fit between organization's technology stack and skills of desirable, recruitable employees
• Will the change facilitate integration with extra-organizational projects and applications?
• Is the change driven by fundamental evolution of the technology platform being used?
• Is the change necessary in order to maintain compatibility with other technologies employed by the organization?
• Is a change necessary due to changes in the level of support for or use of the technology to be deprecated?
• Is the proposed change sufficiently proven, utilized, and supported to yield a risk-of-adoption level acceptable to the organization and appropriate to the benefit conferred by the proposed change?
• What is the licensing cost differential associated with the proposed change?
• What are the costs of training staff associated with the introduction of the new technology?
• What are the costs of refactoring some or all existing applications (whichever is, in fact, necessary) that have already been built using the technology to be deprecated?
• How does the proposed technology change compare with other possible change paths?
• What are the costs associated with failing to implement the proposed change?

Technology Change Proposal Evaluation

Participants charged with addressing a proposal for change of technology are drawn from broader and more inclusive sectors of an organization in proportion to the complexity and scope of a change (cf. Types of Technology Changes, above).

A generally applicable list of organizational roles that ought to be represented in evaluation of a proposed technology change follows:

• Technology Architect(s)
• Senior developer(s)
• Manager(s) responsible for developer resources (including recruitment and staff-development)
• Manager(s) responsible for implementing deliverables
• Manager(s) responsible for IT infrastructure

Proposals for technology changes, which address and/or weigh the criteria listed above, will most frequently be brought forward by Technology Architect(s), whose responsibility is to monitor and evaluate trends in technologies, architectures, frameworks, and tools in the context of organizational needs and user requirements.

Technology change may be motivated by technical or functional considerations. Technology Architect(s) or senior developers are the most likely roles to propose the need for technology changes when that need is motivated by technical concerns. Those whose responsibility in the organization includes budget, IT resource performance, IT resource functionality, or other organizational needs and user requirements are the most likely roles to bring forward concerns related to their scope(s) of responsibility, and may thus initiate consideration of technology change necessary to address those concerns.