what is architecture ?

What is Architecture ?

2

Technology Issues

Ability to deal with organizational or product complexity in a timely manner

Ability to adopt a disruptive technology that is not feasible today

Desire for systems or family of applications to have qualities or characteristics such as a high level of integration, evolvability, and understandability

Desire to reduce development, maintenance, and operating costs of system or applications.

3

Architecture

“Architecture is an instrument whose central function is to intervene in man’s favor”

James Fitch, 1972

4


5


A collection of software and system components, connections, and constraints.

A collection of system stakeholders' need statements. A rationale which demonstrates that the components,

connections, and constraints define a system that, if implemented, would satisfy the collection of system stakeholders' need statements.

6

Architecture as a tool to communicate with stakeholders

For designers and implementors, the architecture provides their "marching orders." The architecture establishes constraints (plus exploitable freedom) on downstream development activities.

For testers and integrators, the architecture dictates the correct black-box behavior of the pieces that must fit together.

For technical managers, architecture provides the basis for forming development teams corresponding to the work assignments identified.

For project managers, architecture serves as the basis for a work breakdown structure, planning, allocation of project resources, and tracking of progress by the various teams.

For designers of other systems with which this one must interoperate, the architecture defines the set of operations provided and required, and the protocols for their operation, that allows the interoperation to take place.

7

Architecture as a tool to understand a system For technical mangers, architecture is basis for conformance

checking, for assurance that implementations have in fact been faithful to the architectural prescriptions.

For maintainers, architecture is a starting point for maintenance activities, revealing the areas a prospective change will affect.

For new project members, the architecture is usually the first artifact for familiarization with a system's design.

For those inheriting the job of architect after the previous architect's untimely departure, the architecture is the artifact that (if properly documented) preserves that architect's knowledge and rationale.

For re-engineers, architecture is the often first artifact recovered to understand existing system

8

What does a good Architecture provide ?

It is at a high-enough level of abstraction that the system can be viewed as a whole.

The structure must support the functionality required of the system. Thus, the dynamic behavior of the system must be taken into account when designing the architecture.

The structure must conform to the system qualities (also known as non-functional requirements): Performance, security, reliability requirements associated with current

functionality Flexibility, extensibility requirements associated with accommodating future

functionality at a reasonable cost of change. These requirements may conflict, and tradeoffs among alternatives are an

essential part of designing an architecture. At the architectural level, all implementation details are hidden.

9

From Requirements to Architecture

From requirements specification to architecture Decompose software into modules with interfaces Specify high-level behavior, interactions, and non-functional properties Consider key tradeoffs

Schedule vs. Budget, Cost vs. Robustness, Fault Tolerance vs. Size, Security vs. Speed

Maintain a record of design decisions and traceability Specifies how the software product is to do its tasks

10

Architecture vs Design

Differences between Architecture and Design Architecture is concerned about higher level issues components vs procedures interactions among components vs interfaces constraints on components and interactions vs algorithms,

procedures and type

11

Architecture vs Design

Architecture is concerned with a different set of structural issues

Large-grained composition vs procedural composition Component interactions (protocols) vs procedural/task

interactions (pc, rpc, msgs, etc) Information content vs data types and representations

12

How to document Architecture

Views approach UML Free form diagrams + text Paper napkins

13

Architectural Roles

Role Descriptions The Architect says: I decide how the building will look and function.

The Engineer says: I will make sure the building will be structurally sound

The Scientist says: I do research and invent, to further knowledge.

The Builder says: I will build the building.

14

Technology Architecture

Combined Architecture and Engineering Function

Determine what technologies will be used

Determine how the technologies will be used

Verify that the technologies are used correctly

15

Architect Role and Responsibilities

An architect is someone who designs or develops architectures

Architectural or Technological Vision

Conceptualizing and Experimenting with Alternatives

Creating Models and Component and Interface Documents

Validates Technologies to Meet Requirements

16


Architectures are seldom embraced without challenges

Sell architectures to various stakeholders

Navigates Network of Influence to Ensure the Success of a Architecture

Consults and Provides Guidance to the Development Team

Consultant to Business and Management Teams

Communicates to all Interested Parties

17


Knowledge of organization's product domain and relevant technologies and development processes.

High tolerance of ambiguity and ability to work at an abstract level.

Combination of Strategist and Technologist

18


Organizational Politics

Architectures will have a diverse stakeholders and are to be used by many developers – to gain and maintain sponsorship the architect must be an influencer.

Understand both business and personal objectives. Listening, networking, articulation and selling a vision over the life of an architecture are important.

19


The architect is a consultant who is committed to the success of others.

Must create conceptual solutions for business customers. This includes the ability to clearly articulate the solution in a common vernacular.

Development teams are the users of an architecture, its not their job to make a architecture successful, but rather satisfy their specific functionality, schedule and quality requirements.

20


A few things that an Architect is not......

Project Manager... but can provide clarity to complex dependencies or scheduling issues

Quality Assurance Technician... but can assist is integration evaluations

Guarantor that an application is programmed perfectly... but can provide development platform or architectural insights

Firefighters... but we can assist with prevention and recovery

21

Technology Architecture Team

“Conceptual integrity must proceed from one mind, or from a very small number of agreeing resonant minds”

Fredrick Brooks – Mythical Man-Month (1995)

22


Combined Architecture and Engineering Function Concept and Functional Vision Construction Philosophy and Direction

Ensure that the development teams have the guidance needed for success Architectural Clarity Landscape Guidance Consistent Practices

23


Quality Reviews and Consultant Services End-to-End Technical Quality (Verification v. Validation) Architectural Conformance

Maintenance Reviews Compatibility Assessments Team Guidance

Continuous Process Improvement Modifications to Architecture as Applications or Systems Evolve

24

Organization Pitfalls for Technology Architecture Teams

Leadership Issues Architecture flounder without leadership or executive sponsorship

Individual Agenda Strong opinions about directional issues with teams

Divided Attention Development vs. Strategic Direction

Ivory Towers Avoid setting direction in a isolation

25

Critical Success Factors for Architecture Teams

Small dedicated full-time team to create and deploy the architecture

Complementary skills

Communications

Goodwill between Architecture, Management, and Development Teams, Production Support

26

Execution for Technology Environment

Inventory Applications and assign architect to each initiative

Identify technologies patterns

Develop standards from existing patterns or technology requirements

Communicate architecture to the development teams

27

Project Participation

Design More than concept less than detailed design

Developer Education Guidance with Tools and Technology Communicate Vision for Product and

Requirements

28

Project Participation

Supervision Confirm Plans (Partnership with Management) Confirm Implementation (Partnership with Technical Lead) Confirm Quality (Partnership with Quality Assurance)

Post Development Review Confirm Architecture Modify Existing

29

Architecture Reviews

Meets Requirements for Application Confirm technology or products meets the needs of the

system of application

Meets Infrastructure Requirements Confirm Architecture Modify Existing

Meets Quality Requirements Consistent with Enterprise Requirements

30

Tactical Benefits

Cost Reuse of existing tools Redeployment of development resources Reduction of training costs

Quality Engineering Personal Participate in Verification and

Validation process. End-To-End Quality is a team function.

31

Summary

A planned architecture will provide a framework to deal with organizational or product complexity

An effective architecture will enable the adoption of things not feasible today

A consistent architecture will ensure that applications possess qualities or characteristics such as a interoperability, evolvability, and understandability

A practiced architectural approach will reduce development, maintenance, and operating costs of system or applications.

32

Reference

Architecture Teams: Malan, Bredemeyer

The Role of the Architect : Malan, Bredemeyer [June 2000]

The Software Architect’s Profession: Sewell and Sewell [2002]

How to Lead, Follow, and Get Out of the Way: Malan, Bredemeyer, Branson [Enterprise Architecture Conference Boston, March 2001]

US Department of Energy – Technology Architecture Perspective [January 2001]

Software Architecture Documentation in Practice: Documenting Architectural Layers : Bachmann et al.