What is Architecture ?
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.
2
Architecture
“Architecture is an instrument whose central function is to
intervene in man’s favor”
James Fitch, 1972
3
What is Architecture ?
4
What is Architecture ?
 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.
5
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.
6
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
7
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.
8
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
9
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
10
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
11
How to document Architecture




Views approach
UML
Free form diagrams + text
Paper napkins
12
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.
13
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
14
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
15
Architect Role and Responsibilities
 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
16
Architect Role and Responsibilities
 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
17
Architect Role and Responsibilities
 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.
18
Architect Role and Responsibilities
 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.
19
Architect Role and Responsibilities
 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
20
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)
21
Technology Architecture Team
 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
22
Technology Architecture Team
 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
23
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
24
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
25
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
26
Project Participation
 Design
 More than concept less than detailed design
 Developer Education
 Guidance with Tools and Technology
 Communicate Vision for Product and
Requirements
27
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
28
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
29
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.
30
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.
31
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.
32