Becoming an Architect

Copyright © 2007, Rob Daigneau, All rights reserved
Becoming an ArchitectBecoming an Architect

OverviewOverview
• The Discipline of Architecture
• Architectural Decisions and Their
Consequences
• Components of Typical
Architecture Plans
• The Skills Required
to do the Job
• The Passage from Developer
to Architect

About MeAbout Me
• Principal of ArcSage, Inc.
• Addison WesleyAddison Wesley author
– Currently working on Service Design PatternsService Design Patterns
book
• Chief Architect
• Director of Architecture

The Discipline of Architecture

What Does It Mean To Be
An Architect?
No agreement

LetLet’s start here …’s start here …
2. A person who designs
and guides a plan or
undertaking.
1. A person
who designs
buildingsbuildings and advises
in their constructiontheir construction.
From Webster’s Dictionary

Let’s replace a few words …
2. A person who designs
and guides a planguides a plan or
undertaking related to
software systemssoftware systems
designdesign..
1. A person
who designs
software systemssoftware systems and
advises in the design ofthe design of
such systemssuch systems.

What isWhat is
Architecture?Architecture?

Fundamental organizationorganization of a system
embodied in its componentscomponents,
their relationshipsrelationships to each other and the
environment,
and the principlesprinciples governing its design and
evolution
IEEE 1471-2000

Booch, Kruchten, Reitman,
Bittner, Shaw
the set of significant decisionssignificant decisions about
the organization of a software system
Selection of the structural elementsstructural elements and
their interfacesinterfaces by which a system is composed
BehaviorBehavior as specified in collaborations among
those elements

Architecture is generally concerned
with design at higher levels of
abstraction …
• Emphasis is on
general
organization,
relationships

… Architecture might also look at
“lower level concerns”
• These types of
architects may look at
“the How’s”
• The altitude at which
architects fly can be
contentious
• Get your RACI
right

The Many Species ofThe Many Species of
ArchitectsArchitects
More
Strategic
More productsFewer products
CTOCTO
More
Tactical
• Product Architect
– Typically leads design of one
or a few products
– Tends to be more “hands on”
• Enterprise Architect
– Aligns use of technologies with
strategic business initiatives
– Drives for consistency in product
design, methodologies, tools, etc.,
across the enterprise
– Provides oversight
• CTO
– Highest level of oversight
– Manages budgets, SLAs, and
contracts
EnterpriseEnterprise
ArchitectArchitectProductProduct
ArchitectArchitect
• Others: e.g. Infrastructure, Data, etc.

The Influence ofThe Influence of
ArchitectureArchitecture
Architecture Plans
and Principles
Detailed
Design
Project
Plans
Team
Structures
Business
Requirements
Business strategy,
tactics, and trends
SLAs and
Technical
Requirements

When Do Architects Typically GetWhen Do Architects Typically Get
Involved?Involved?
The Traditional ViewThe Traditional View –– Booooooo !!!!!Booooooo !!!!!
Product
Definition
Requirements
Analysis
Technical
Design
Implementation Test Rollout

When Do Architects Typically GetWhen Do Architects Typically Get
Involved?Involved?
The Agile ViewThe Agile View
Product Definition
Requirements Analysis
Technical Design
Implementation
Test
Release
Product Definition
Technical Design
Implementation
Test
Product Definition
Technical Design
Implementation
Test
Release Release
Iteration 1 Iteration 2 Iteration 3

ArchitecturalArchitectural
DecisionsDecisions
and Theirand Their
ConsequencesConsequences

Architecture is like ConcreteArchitecture is like Concrete
…… once it sets,once it sets,
itit’s really hard’s really hard
to changeto change

Quality of ServiceQuality of Service
AttributesAttributes
• Adaptability
– Maintainability, Extensibility
• (Resource) Efficiency
• Interoperability
• Manageability
• Availability
• Performance
– e.g. Throughput, Response Time
• Scalability
• Robustness, Resilience
• i.e. Fault tolerance, Disaster Recovery
• Security
– Authentication, Authorization, Privacy, etc.

Compatible GoalsCompatible Goals
Many goals do not oppose each other, e.g. …
AdaptabilityAdaptability
InteroperabilityInteroperability ManageabilityManageability
PortabilityPortabilityLocalizationLocalization

You CanYou Can’t Have it All’t Have it All
• All architectural
decisions have positive
and negative
consequences
• A movement to
optimize one thing may
cause a trade-off on
something else

Evaluating Trade-offs PartEvaluating Trade-offs Part
11
Your GoalYour Goal
Faster DeliveryFaster Delivery
Lower CostLower Cost
Lower ComplexityLower Complexity

Some goals naturally compete against each
other
PerformancePerformance
AdaptabilityAdaptability
SecuritySecurity
Evaluating Trade-offs PartEvaluating Trade-offs Part
22
PortabilityPortability

• (Strategic) Architecture Plans
• (Tactical) Product Architecture
• Guidelines, Principles, and
Standards
Components of Typical
Architecture Plans

• Watch out for the tendency
to dive deep early on
– Can get stuck
– Won’t see big picture
• The Power of Abstraction
(business and technical)
– Iterative top-down decomposition
approach is “faster”
– Increases chance of understanding
dependencies
Be Careful of SubmariningBe Careful of Submarining

Strategic Architecture PlansStrategic Architecture Plans
-- Guiding PrinciplesGuiding Principles
• Key concepts to guide …
– The selection of technologies
– Future decisions made for
• Detailed (Physical) Design
• Deployment/Execution Architecture
• Operations Architecture
• Influenced by
– Business and Technical
Requirements
Examples
• QOS Attributes
• Buy vs. Build Philosophy
• When/where to use Open Source
• Approach used for Product Evaluations
• Use of OO, SOA, AOP, etc.

• High level description of
– Major Subsystems and Integrations
• Usually
– Looks out several years
– Shows evolution from “As-is” to
“To-Be” architecture in several
diagrams and narratives
– Shows how business
capabilities mapped to
subsystems
• Functions as a
communication device
-- Architecture RoadmapsArchitecture Roadmaps
Marketing
System
CRM
General
Ledger
eCommerce
Application
Enterprise Resource Planning
Product
Catalog
Order &
Fulfillment
Inventory
Distributors

• Pertains to …
– Deployment Architecture
– Operations Architecture
– Frameworks, Developer tools,
languages, etc.
• Techniques
– Formal Approaches
• RFIs, RFPs, Vendor Bake-offs
– Proof-of-Concepts and
Pilot Projects
--
Evaluation and Selection ofEvaluation and Selection of
TechnologiesTechnologies

--
Product Release StrategiesProduct Release Strategies
• Outlines how business
capabilities are fulfilled over
multiple product releases
• Aligned with Architecture
Roadmaps
• Agile tends to focus on
immediate iteration
– Does Agile forsake strategy? NO !!
• Might not be managed by the
Architect
– Depends on the organization

The Product Architecture PlanThe Product Architecture Plan
–– Technical RequirementsTechnical Requirements
• i.e. “Non-functional” Requirements
– Identifies system requirements that are not specific to the
business (i.e. functional) requirements
– The “ilities” we discussed above

• Precedes physical design
• Might be considered an analysis tool
– Supports use-cases or user stories
– Used as input to physical design
The Product ArchitectureThe Product Architecture
Plan -Plan - Logical ModelsLogical Models
• Defines High Level …
– Organizational Structures
– Relationships, interactions
– Responsibilities
– Behaviors
• Platform independent
Customer
Contract Order
ProductPricing

• Helps business and technology
stakeholders
– Get better understanding of problem domain
– Identify flaws, issues, and challenges early
– Explore alternatives
• Techniques
– Domain-Driven Design
• High level Class Diagrams
– Flowcharts, Workflows
– High Level Entity Relationship Diagrams
Submit
Order
Fraud
Check
Credit
Check
Decrement
Inventory &
Provision
G/L Entry
Fulfillment
Plan -Plan - Logical ModelsLogical Models

Plan -Plan -
Identification of Logical LayersIdentification of Logical Layers
• Addresses “Separation of Concerns”
Marketing
Service
Customer
Service
Order
Service
Domain Model
Data Access
Application
Database
– Shows how logic will be segmented
by purpose
• Doesn’t show detailed
interfaces
• Benefits of layering
– Promotes maintainability through
high cohesion
– Allows independent evolution of logic in different layers
– Facilitates reuse or sharing of logic
Infrastructure

Web/App Server
Application
App Server
Marketing
Service
Customer
Service
Order
Service
Domain Model
Data Access
Database Server
Order
Database
Customer
Database
Marketing
Database
• a.k.a. Execution Architecture
• Shows how layers are
deployed to physical tiers
• Hardware, Capacity plans
– Server sizing (CPU, Memory, Disk)
– Network topology
• Design of Logical
Environments
– Development, Integration, QA, Staging,
Production
The Product Architecture Plan -The Product Architecture Plan -
Deployment ArchitectureDeployment Architecture
Infrastructure

For theFor the
Engineers/Developers -Engineers/Developers -
Physical DesignPhysical Design• Detailed design
– Services, Major Interfaces, Classes
– Use of Design Patterns
– Integrations
• Messages, Triggering Events,
Transforms, etc.
• Usually Platform specific …
– e.g. Database schemas,
Language specific class design
• Agile cautions against
“Big Design Up Front” (BDUF)

Guidelines and StandardsGuidelines and Standards
• Coding Standards
• Source Code Management
– Versioning
– Branch and Merge approaches
• Testing
– Unit testing, Integration, Regression,
Performance, Stress, UAT
• Production Rollout and
Rollback Procedures
• Governance
– Change control over Service
Contracts, Interfaces, business logic
• Many of these may not be done
by the architect … often a shared
responsibility; depends on the
organization

The SkillsThe Skills
RequiredRequired
to do theto do the
JobJob

TheThe “Easy” Skills“Easy” Skills
• Abstraction
– Business and technical concepts
• OO Concepts
– e.g. Encapsulation, Inheritance, Composition, Polymorphism,
Inversion of Control
• Analysis and Modeling Techniques
– e.g. UML, DFD, ERD, Network Diagrams
• Relational Databases
– Normalization, Transaction and Concurrency Management, Data Integrity

TheThe “Easy” Skills“Easy” Skills
• SDLC Methodologies
– Prescriptive (e.g. Waterfall, RUP) vs. Adaptive approaches (e.g. Agile)
• Estimating
• Project management
– Task planning, schedule estimation, monitoring, reporting, risk
management, budget management, etc.
• Business concepts,
knowledge of problem domain

The Hard Skills are the SoftThe Hard Skills are the Soft
SkillsSkills
• Mentoring,
Consulting,
Coaching,
Delegation
– Wise architects let people choose their
own paths
– Architects shouldn’t drive everything
– Wisdom acquired from own mistakes

The Hard Skills are the SoftThe Hard Skills are the Soft
SkillsSkills
• Persuasion,
Influence
– May not have authority
• Politician,
Negotiator,
– Must …
• Be Pragmatic
• Able to Compromise

Develop Patience, LetDevelop Patience, Let
GoGo
• Seek to understand “their”
Fears, Uncertainty, and
Doubts (i.e. FUD)
– Empathasize, develop trust
• If you’re trying to introduce
change …
– Recognize that progress might only be
made in inches rather than miles
– Every little step in the right direction is a
good thing.
• Architecture initiatives often
have a lower priority

The PassageThe Passage
fromfrom
DeveloperDeveloper
toto
ArchitectArchitect

Architects andArchitects and
DevelopersDevelopers
Effective Architects areEffective Architects are
full members of thefull members of the
development teamsdevelopment teams

Should Architects Code?Should Architects Code?
• It depends …
– What kind of Architect are you?
– How big is your product and your team?
• Are Product Architects actually
Lead Developers?
– a.k.a. Application Architect ?
– Emphasis for these architects may be more on detailed
design
– May not pay as much attention to other aspects of
Architecture plans
• Perhaps we should be asking
“How much
should architects code?”

Why ItWhy It’s Good To Keep’s Good To Keep
CodingCoding
• Abstractions will only take
you so far
– Many developers need to see code
– Code helps to find flaws
• Helps to tear down the
Ivory Tower
– Increases credibility
– Helps you understand developer
perspective
• Allows you to cut through
vendor hype
… or staying in shape

A Parable from Star TrekA Parable from Star Trek
Dangers
– When you’re on the
front-line,
who’s
watching to see that
the ship stays on
course?
– A problem of
bandwidth
• The senior-most officers couldn’t delegate
– Were always members of the landing parties

Architects Should Be Like FlightArchitects Should Be Like Flight
DirectorsDirectors
• Mission Control had many senior engineers
The Flight Director
– Coordinated work of
specialists
• Solicited recommendations
and decisions
• Didn’t do their work
– Made the final call when
necessary
– Was accountableaccountable

WhatWhat’s Happening to Me?’s Happening to Me?
• Changes …
– Keeping up with trends, changes in
languages, frameworks, tools, etc.
will be harder
– Your coding skills may slip
– Will probably be in more meetings
and have to deal with more politics
• Let Go
– Resist impulse to jump in because
you think you can get it done faster

Becoming an Architect

More Related Content

Similar to Becoming an Architect

Recently uploaded

Becoming an Architect

Editor's Notes