I NFORMATION T ECHNOLOGY U NIVERSITY OF S OUTH F LORIDA P OLYTECHNIC

SOFTWARE ARCHITECTURE IN PRACTICE SECOND EDITION

-CHAPTER 1THE ARCHITECTURE BUSINESS CYCLE

8/29/2011

Enterprise Software Architecture

WEEKS AGENDA
Context for studying software architecture
Terminology to clear things up Software architecture and the enterprise Software architecture as part of the software engineering process What is software architecture? Where do architectures come from?

The architecture business cycle (ACB)

Architects influences Architects tasks Influences from environment to architecture and vice-versa Process rules for creating architectures Product rules for creating architectures

8/29/2011

Enterprise Software Architecture

IMPORTANT TERMINOLOGY - ENTERPRISE

What is an enterprise?
An enterprise is a complex, socio-technical system that comprises interdependent resources of people, information, and technology that must interact with each other and their environment in support of a common mission1. Example of enterprises include:
Companies Government Not-for-profit Companies Parts of companies, such as divisions or individual programs.

Enterprises have the following in common1:

All enterprises are man-made systems. All enterprises use resources of people, material, machines, information, and knowledge. All enterprises produce a product, provide a service, or do both. All enterprises have customers who derive value from the product or service. All enterprises have a goal, e.g., profitability and growth.
8/29/2011 Enterprise Software Architecture 3

IMPORTANT TERMINOLOGY - ENTERPRISE

If an enterprise is seen as a product, then, like all other products, it must be engineered. In all other engineered product, design is a key element; therefore, if an enterprise is to be engineered, then it must be designed! Design, specifically engineering design, can be defined as follows:
A systematic, intelligent process in which designers generate, evaluate and specify designs for devices, systems or processes whose form(s) and function(s) achieve clients objectives and users needs while satisfying a specified set of constraints2.

Generating, evaluating, and specifying an enterprise design is a massive task, unusual for a single person; therefore, an enterprise design team is required. Members of this team include (among others, e.g., project managers):
Enterprise Architect
Architects the enterprise using a holistic approach that includes the enterprises strategy, processes, information, and organizational structure.

Software Architect
Architects software systems; in this context, the software system is key to the enterprises success, e.g., the Microsoft Windows OS, which is essential to the success of the Microsofts enterprise. This is the focus of this Course!!
8/29/2011 Enterprise Software Architecture 4

SOFTWARE ARCHITECTURE AND THE ENTERPRISE

Before getting too deep into the study of software architecture, it must be well understood how it supports the enterprises design:
In a broad context, software architecture represents a high-level, black-box, design of the software system to be built. The software system must not only meet the specified functional requirements (i.e., what the system must do) but in also has to meet other non-functional requirements that address the goals of the enterprise, such as
Cost Quality Schedule

Therefore, software architects must take into account the overall enterprise design to create systems that are consistent with the enterprises strategy, processes, information, and organizational structure.

When we connect all of the information provided so far, the concept of Enterprise Software Architecture should start making more sense by now! From this point forward, well use the term Software Architecture.
8/29/2011 Enterprise Software Architecture 5

SOFTWARE ARCHITECTURE AND THE DEVELOPMENT PROCESS

Now that we know how software architecture relates to the overall enterprise design, we need to understand how software architecture relates to the development process of software systems. The software engineering body of knowledge defines 5 key phases for the development of software systems:
Requirements Design Construction Testing Maintenance

Requirements: initial stage concerned with the elicitation, analysis, specification, and validation of the software requirements. Design: analyzes, evaluates, and specifies the design of the software system (based on its requirements) by performing two key activities with different levels of abstractions; the software architecture and the detailed design. Construction: the software design is implemented in code. Testing: implemented code is verified and validated against the requirements. Maintenance: supports the long-term evolution of the software.
8/29/2011 Enterprise Software Architecture 6

WHAT IS SOFTWARE ARCHITECTURE?

Software designers have been taught to build systems based exclusively on the technical requirements. Traditionally, the requirements document is tossed over the wall into the designers cubicle, and the designer must come forth with a satisfactory design. This nave approach to software design has been addressed by software designers through constant iterations and collaborations between designers and requirement analysts. Software architecture has emerged as the design activity that attempts to corrects inefficiencies of the traditional over the wall spec approach. Software architecture encompasses the structures of large software systems
The architectural view of a system is abstract, distilling away details of implementation and concentrating on the behavior and interaction of blackbox elements.
8/29/2011 Enterprise Software Architecture 7

WHAT IS SOFTWARE ARCHITECTURE?

Software architecture is
(1) the activity as part of the software design phase that is concerned with modeling the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them; and, (2) the result of such activity.

Key portions of the definition are:

Structures
This emphasizes that a plurality of structures may be needed to properly and accurately design a software system.

Externally visible properties of system elements

This places focus on the quality of software elements, such as performance, security, usability, etc.

Relationships among elements of the software system.

This places focus on interfaces between system elements.

Software architecture is both considered a process and a product.

8/29/2011 Enterprise Software Architecture 8

WHERE DO ARCHITECTURES COME FROM?

An architecture is the result of a set of business and technical decisions. These decisions are influenced by:
Stakeholders Developing Organization Background and experience of Architects Current Technical Environment

Stakeholders are entities that have a stake on the software system, including customers, end users, developers, testers, managers, maintainers, etc.
Stakeholders have different concerns that need to be addressed by the architecture
Cost, memory utilization, availability, network usage, reliability, performance, short time to market, etc.

These concerns and properties determine the overall design of the architecture. The underlying problem is that each stakeholder has different contradicting concerns and goals. Rarely requirement documents capture these, so architects often have to fill in the blanks and mediate conflicts.
8/29/2011 Enterprise Software Architecture 9

WHERE DO ARCHITECTURES COME FROM?

The developing organization influences the architecture through its current state, policies, procedures, controls, etc.
For example, an organization with abundance of idle programmers skilled in clientserver communication may influence the architect to design the system using a client-server architecture to maximize resource utilization. An organization with distributed teams may prompt architects to decompose the system in such way that teams across different geographical locations can become more efficient.

The influence that organizations have on architecture can be classified as:

Immediate business Long-term business Organizational Structure

Experience and expertise from architects influence the software architecture:

Previous successful architectures tend to be reused Educational background and training influence architecture Knowledge of styles and patterns influence architectures
8/29/2011 Enterprise Software Architecture 10

WHERE DO ARCHITECTURES COME FROM?

Architectures are influenced by the current technical environment
Current trends influence software architectures. For example,
Object-oriented technology, service-oriented, cloud computing, parallel processing, etc. The environment that is current when the architecture is designed will influence that architecture.

All of these influences on the software architecture are rarely well documented, therefore, software architects need to:
Identify and actively engage all stakeholders to elicit their needs and expectations. Understand constraints, manage expectations, negotiate priorities, and make trade-offs.

It is evident that software architects need more than technical skills:

Negotiation, diplomacy, and communication skills are essential.
8/29/2011 Enterprise Software Architecture 11

WHAT IS THE ARCHITECTURE BUSINESS CYCLE?

From our definition of software architecture, it is important to emphasize again on the externally visible properties of architectural elements. Addressing these are a major task of software architects.
Consider designing a system that is fast, secure, portable, testable, and maintainable. These visible properties are derived from system stakeholders; therefore, by incorporating them in the software design, the architect takes care of stakeholders concerns. Other considerations that drive architectural designs are business and social influences. Providing an architecture that supports technical, business, and social influences a major role of the software architect.

Software architecture is then, the result of technical, business, and social influences.
However, since the system to be built is based in its software architecture, then, software architecture in turns affects the technical, business, and social environments that subsequently influence future architectures.

This cycle of influences, from environment to the architecture and back to the environment is called the Architecture Business Cycle.
8/29/2011 Enterprise Software Architecture 12

ARCHITECTURE BUSINESS CYCLE

It is easy to imagine how the external environment influence the software architecture, but how does the architecture influence the external environments?
The architecture influences the structure of the developing organization.
Architectural components are used to identify teams and units of work. Teams identified develop expertise and can be reused in future projects. These teams can become embedded in the organizations structure. Schedules and budgets are made consistent with identified architectural units of work.

The architecture influences the goals of the developing organization.

Architecture that result in successful systems allow companies to establish a foothold in a particular market. Therefore, organizational goals can change to maximize the potential earnings in that market by creating other systems that reuse the architecture.

The architecture influences customer requirements

A generic architecture that can be reused to quickly create a high-quality system can cause customers to sacrifice some of their requirements in return for software that can meet their basic needs quickly, reliably, and at lower cost.

8/29/2011

Enterprise Software Architecture

13

ARCHITECTURE BUSINESS CYCLE

The Architecture Business Cycle is presented below.

8/29/2011

Enterprise Software Architecture

14

ARCHITECTURE TASKS
Software architecture is an activity performed as part of the software design phase. This activity has several tasks that need to be performed:
Creating the Business Case for the System Understanding Requirements Creating or Selecting the Architecture Communicating the Architecture Analyzing or Evaluating the Architecture Implementing Based on the Architecture Ensuring Conformance to an Architecture

What makes a good architecture?

Architectures can be evaluated, but only in the context of specific goals. Several rules of thumb exists create good architectures. These rules can be classified as: process or product.

8/29/2011

Enterprise Software Architecture

15

PROCESS RULES FOR CREATING GOOD ARCHITECTURES

The architecture should be the result of a single architect or a small group of architects with an identified leader. The architect should have the functional requirements for the system and an articulated, prioritized list of quality attributes that the architecture is expected to satisfy. The architecture should be well documented, with at least one static view and one behavioral view, with a notation that can be well-understood by all stakeholders. The architecture should be circulated to the systems stakeholder, who should be actively involved in its review. The architecture should support incremental development of the system.

8/29/2011

Enterprise Software Architecture

16

PRODUCT RULES FOR CREATING GOOD ARCHITECTURES

The architecture should feature well-defined components whose functional responsibilities are allocated on the principle of information hiding and separation of concerns. Each architectural component should have a well-defined interface. These interfaces should allow their respective development teams to work largely independently of each other. Quality attributes should be achieved using well-known tactics. Components that produce data should be independent from components that consume data. This helps design systems that are modifiable. For concurrent systems, the architecture should feature well-defined processes or tasks that do not necessarily mirror the component structure. The architecture should feature a small number of simple interactions patterns so that the system can do similar things the same way to increase consistency during software development.

8/29/2011

Enterprise Software Architecture

17