Importance of Software architecture

Software Architecture
Presented by Steve EssichPresented by Steve Essich
https://www.linkedin.com/in/sessich/https://www.linkedin.com/in/sessich/

Introduction to Software Architecture
Agenda
• VisionVision
• ValueValue
• What is Software Architecture?What is Software Architecture?
• Documenting a Software ArchitectureDocumenting a Software Architecture
• Characteristics of an ArchitectCharacteristics of an Architect

Vision
• Maximize the value of the solutions built forMaximize the value of the solutions built for
customerscustomers
 Utilize the depth and breadth of the technical portfolio andUtilize the depth and breadth of the technical portfolio and
resource pool.resource pool.
• Distinguish solutions from those ofDistinguish solutions from those of
competitorscompetitors
 Explore innovative and novel approachesExplore innovative and novel approaches
• Leverage assets created during projectsLeverage assets created during projects
 Repeat success by creating reference architecturesRepeat success by creating reference architectures

Vision(continued)
• Encourage cross-selling / up-sellingEncourage cross-selling / up-selling
 Harness the imagination and experience of the technicalHarness the imagination and experience of the technical
staff by improving communication about opportunitiesstaff by improving communication about opportunities
across the firm’s technical communityacross the firm’s technical community
• Promote long-term relationships withPromote long-term relationships with
customerscustomers
 Provide a foundation for the future with the delivery of aProvide a foundation for the future with the delivery of a
well architected solution.well architected solution.
• Improve communication with stakeholdersImprove communication with stakeholders
regarding technical issues and decisionsregarding technical issues and decisions
 Enable debate, therefore improving overall qualityEnable debate, therefore improving overall quality

Vision(continued)
• Move toward a solution focus from aMove toward a solution focus from a
technology biastechnology bias
 Look at the delivery organization as a toolbox containingLook at the delivery organization as a toolbox containing
diverse and complimentary toolsdiverse and complimentary tools
• Identify technical areas that needIdentify technical areas that need
enhancementenhancement
 Increase customer value and enhance our deliveryIncrease customer value and enhance our delivery
capabilitiescapabilities
• Harness and focus developer creativity byHarness and focus developer creativity by
providing necessary constraintsproviding necessary constraints
 Define best practices, standards and guidelinesDefine best practices, standards and guidelines
• Improve the firm’s ability to scale up byImprove the firm’s ability to scale up by
creating an architecture practicecreating an architecture practice

• VisionVision
• ValueValue
• What is Software Architecture?What is Software Architecture?
• Documenting a Software ArchitectureDocumenting a Software Architecture
• Characteristics of an ArchitectCharacteristics of an Architect
Agenda

Value
• Reduce operating costs for development andReduce operating costs for development and
supportsupport
 Lower the number of latent defects / LOCLower the number of latent defects / LOC
 Reduce the cost of removing defectsReduce the cost of removing defects
 Positive impact on costs during warranty periodsPositive impact on costs during warranty periods
• Reduce the customer’s cost of ownership forReduce the customer’s cost of ownership for
productsproducts
 Defect repair (outside warranty periods) is expensive.Defect repair (outside warranty periods) is expensive.
 Increased customer satisfactionIncreased customer satisfaction
 Increased product lifespanIncreased product lifespan

Value (continued)
• Enhance customer retention, encourageEnhance customer retention, encourage
extensions to existing productsextensions to existing products
 Well architected solutions are easier to extend, therebyWell architected solutions are easier to extend, thereby
extending the product lifespan and the relationship with theextending the product lifespan and the relationship with the
firm.firm.
 Building new software and extending existing systems isBuilding new software and extending existing systems is
higher margin work than fixing defects.higher margin work than fixing defects.
• Higher staff productivity & improved retentionHigher staff productivity & improved retention
 More efficient use of staffMore efficient use of staff
 Reduction in the time spent repairing defectsReduction in the time spent repairing defects
 Increased employee satisfactionIncreased employee satisfaction

Value (continued)
• Improved estimates and more predictableImproved estimates and more predictable
schedulesschedules
 Reduces the risk of project work, especially fixed price projectsReduces the risk of project work, especially fixed price projects
• Create reusable assetsCreate reusable assets
 Leverage assets created for one project across other projectsLeverage assets created for one project across other projects
in the verticalin the vertical

What is Software Architecture?
• Software architecture is the collection ofSoftware architecture is the collection of
decisions affecting the system’s qualitydecisions affecting the system’s quality
attributes; which have global effects andattributes; which have global effects and
are hardest to change.*are hardest to change.*
* Arnon Rotem-Gal-Oz
• Software architecture providesSoftware architecture provides
the frame within which the designthe frame within which the design
(code) is built.*(code) is built.*

What is Software Architecture? (continued)
• Software architecture is the fundamentalSoftware architecture is the fundamental
organization of a system, embodied in itsorganization of a system, embodied in its
components, their relationships to each othercomponents, their relationships to each other
and the environment, and the principlesand the environment, and the principles
governing its design andgoverning its design and
evolution.*evolution.*
* IEEE 1471-2000

• The software architecture of a program orThe software architecture of a program or
computing system is the structure orcomputing system is the structure or
structures of the system, which comprise thestructures of the system, which comprise the
software elements, the externally visiblesoftware elements, the externally visible
properties of those elements,properties of those elements,
and the relationships betweenand the relationships between
them.them.*
* Software Architecture in Practice

• Software architecture…Software architecture…
 Identifies the technologies that will be usedIdentifies the technologies that will be used
 Defines the main components of a system and theirDefines the main components of a system and their
relationships.relationships.
 Defines how the components interact with eachDefines how the components interact with each
other, and with the outside world.other, and with the outside world.
 Is complex and can’t be described in a one-Is complex and can’t be described in a one-
dimensional fashion.dimensional fashion.
 Is driven by the need to satisfy quality factorsIs driven by the need to satisfy quality factors
 Constrains the design and the implementation.Constrains the design and the implementation.
• Thereby focusing creativity and innovation.Thereby focusing creativity and innovation.

• Every system has an architectureEvery system has an architecture
 Even if it is accidental.Even if it is accidental.
• Architecture is about making choices…Architecture is about making choices…
 Early in the product development lifecycleEarly in the product development lifecycle
 That if delayed would be expensive or significantlyThat if delayed would be expensive or significantly
degrade quality.degrade quality.
 In response to (conflicting) requirements.In response to (conflicting) requirements.
• Architecture is about strategy, structure andArchitecture is about strategy, structure and
purpose.purpose.
 Tends to be abstractTends to be abstract

• The Architecture is a blueprint for the project!The Architecture is a blueprint for the project!
 Team selectionTeam selection
 Documentation organizationDocumentation organization
 Work breakdown structureWork breakdown structure
 Scheduling, planning, budgetingScheduling, planning, budgeting
 Unit testing and integrationUnit testing and integration

What is Software Architecture?
• All Architecture is design…All Architecture is design…
 But not all design is architectureBut not all design is architecture
• Design focuses on…Design focuses on…
 The internal structure of componentsThe internal structure of components
 The configuration of previously identified tools andThe configuration of previously identified tools and
technologiestechnologies
 Algorithms, procedures and data types.Algorithms, procedures and data types.
• Design w/o architecture may produce solutions that…Design w/o architecture may produce solutions that…
 Don’t address non-functional requirementsDon’t address non-functional requirements
 Incur high-levels of unintentional technical debt.Incur high-levels of unintentional technical debt.
not

Software Quality

Rules of Thumb for Architecture
• Created by a single architect or a smallCreated by a single architect or a small
group with an identified leadergroup with an identified leader
• Start with functional and non-functionalStart with functional and non-functional
requirements, along with prioritizedrequirements, along with prioritized
quality factors.quality factors.
• Documented with the needs of allDocumented with the needs of all
stakeholders in mindstakeholders in mind

(continued)
• Actively reviewed by stakeholdersActively reviewed by stakeholders
• Evaluated for satisfaction ofEvaluated for satisfaction of
requirements and quality factorsrequirements and quality factors
• Suitable for incremental implementationSuitable for incremental implementation
• Decomposed into software componentsDecomposed into software components
that adhere to the modularity principlesthat adhere to the modularity principles

(continued)
• Isolate dependencies on COTSIsolate dependencies on COTS
 Or external systemsOr external systems
• Separate production and consumption ofSeparate production and consumption of
datadata
• Use a small number of interactionUse a small number of interaction
patternspatterns

Documenting a Software Architecture
• The perfect architecture is useless unless itThe perfect architecture is useless unless it
is effectively communicated.is effectively communicated.
 Appropriate level of detailAppropriate level of detail
 Without ambiguityWithout ambiguity
 Organized for ease of useOrganized for ease of use
 Tailored to the audience and their purposesTailored to the audience and their purposes
• You cannot create a single comprehensive model ofYou cannot create a single comprehensive model of
a reasonably complex software system.a reasonably complex software system.

Introduction to Views
• You must partition the documentation into separateYou must partition the documentation into separate
but interrelated views.but interrelated views.
 Each view represents one or more structural aspects of anEach view represents one or more structural aspects of an
architecture.architecture.
• Benefits of Views include…Benefits of Views include…
 Separation of concernsSeparation of concerns
 Communication with stakeholder groupsCommunication with stakeholder groups
 Management of complexityManagement of complexity
 Improved developer focusImproved developer focus
• Drawbacks of Views include…Drawbacks of Views include…
 InconsistencyInconsistency
 Selection of the wrong set of viewsSelection of the wrong set of views
 View fragmentationView fragmentation

View Catalog
• Logical or Functional ViewLogical or Functional View
 Decomposes the system into functional elements.Decomposes the system into functional elements.
• Includes the architecturally significant elementsIncludes the architecturally significant elements
• Layers, components.Layers, components.
• Describes each elements’ responsibilitiesDescribes each elements’ responsibilities
 Describes the relationships and interactions betweenDescribes the relationships and interactions between
elements.elements.
• Data or Information ViewData or Information View
 Represents the data model for the systemRepresents the data model for the system
 Relates the data model back to Logical View elementsRelates the data model back to Logical View elements

View Catalog (continued)
• Process or Concurrency ViewProcess or Concurrency View
 Represents the systems processes, threads, andRepresents the systems processes, threads, and
concurrency control mechanisms.concurrency control mechanisms.
 Maps elements of the Logical View to processes andMaps elements of the Logical View to processes and
threads.threads.
• Implementation or Development ViewImplementation or Development View
 Represents the organization of the system in terms ofRepresents the organization of the system in terms of
packages for design and implementation.packages for design and implementation.
 Identifies standards and guidelines to be used during theIdentifies standards and guidelines to be used during the
design and implementation.design and implementation.

View Catalog (continued)
• Deployment ViewDeployment View
 Describes the physical environment in which the system willDescribes the physical environment in which the system will
run. (For example:run. (For example: nodes, connections and storage)nodes, connections and storage)
 Identifies the technical requirements for each elementIdentifies the technical requirements for each element
 Maps Logical View elements across nodes.Maps Logical View elements across nodes.
• Operational ViewOperational View
 Describes how the system will be operated, administeredDescribes how the system will be operated, administered
and supported when running in the production environment.and supported when running in the production environment.
 Includes information about…Includes information about…
• Installation / upgradesInstallation / upgrades
• Data migrationData migration
• Operational monitoring and controlOperational monitoring and control
• Configuration managementConfiguration management
• Backup and restoreBackup and restore

Characteristics of an Architect
• GeneralistGeneralist
 Experience with multiple technologies.Experience with multiple technologies.
 Appreciation of multiple disciplinesAppreciation of multiple disciplines
 Awareness of personal strengths and weaknessesAwareness of personal strengths and weaknesses
• LeaderLeader
 Able to make technical decisions after seekingAble to make technical decisions after seeking
meaningful inputmeaningful input
• CommunicatorCommunicator
 ListenerListener
 Able to effectively communicate with a variety ofAble to effectively communicate with a variety of
audiences, tailoring the message appropriatelyaudiences, tailoring the message appropriately

Characteristics of an Architect (continued)
• Delivery focusedDelivery focused
 Act as a driving force for the delivery of tangibleAct as a driving force for the delivery of tangible
results throughout the product lifecycle.results throughout the product lifecycle.
• Organize resources and contribute to planningOrganize resources and contribute to planning
 Architectural decisions drive…Architectural decisions drive…
• The skill sets required for the project.The skill sets required for the project.
• The identification and sequencing of tasks.The identification and sequencing of tasks.
• Keen interest in the business domainKeen interest in the business domain
 The architect is an advocate for the customer andThe architect is an advocate for the customer and
the delivery of a solution.the delivery of a solution.

• Understands the importance of the softwareUnderstands the importance of the software
development processdevelopment process
 Key participant in the definition of the SDP.Key participant in the definition of the SDP.
• Skilled participant in the elicitation andSkilled participant in the elicitation and
documentation of requirementsdocumentation of requirements
 Especially non-functional requirementsEspecially non-functional requirements
• Significant experience in the use of relevantSignificant experience in the use of relevant
technologiestechnologies
 At least some of the relevant technologiesAt least some of the relevant technologies

• Ability to recognize a good design orAbility to recognize a good design or
implementationimplementation
 Or a poor one.Or a poor one.
• MentorMentor
 Mentor developers in design and implementationMentor developers in design and implementation
• Aware of organizational politicsAware of organizational politics

Mantras for the Architect*
• It DependsIt Depends
 Architects make decisionsArchitects make decisions
 First the architect must identify the optionsFirst the architect must identify the options
 Then the architect must evaluate the optionsThen the architect must evaluate the options
• Requirements Are Lord Over AllRequirements Are Lord Over All
 Requirements are what the customer decides theyRequirements are what the customer decides they
want / need.want / need.
 Requirements drive the architecture, which drivesRequirements drive the architecture, which drives
the design, which drives the implementationthe design, which drives the implementation
 Customers don’t really know what they want / needCustomers don’t really know what they want / need
so requirements change.so requirements change.
* Microsoft .NET: Architecting Applications for the Enterprise

Mantras for the Architect (continued)
• Program To An InterfaceProgram To An Interface
 Keep the interface and implementation separateKeep the interface and implementation separate
• Keep It Simple But Not SimplisticKeep It Simple But Not Simplistic
 Simple and concise is usually equivalent to greatSimple and concise is usually equivalent to great
and well done.and well done.
 But simplistic is just as dangerous as tooBut simplistic is just as dangerous as too
complicated.complicated.
 Just complicated enough, but no more.Just complicated enough, but no more.

• Inheritance Is About PolymorphismInheritance Is About Polymorphism
 Inheritance enables reuse, but reuse should beInheritance enables reuse, but reuse should be
viewed as a side effect.viewed as a side effect.
 Use of inheritance for reuse alone is gratuitousUse of inheritance for reuse alone is gratuitous
• No SQL Outside of the DALNo SQL Outside of the DAL
 The use of SQL (or any other similar queryThe use of SQL (or any other similar query
language) outside of the Data Access Layerlanguage) outside of the Data Access Layer
should be avoided at all costs.should be avoided at all costs.

• Maintainability FirstMaintainability First
 If a software system can’t be maintained itIf a software system can’t be maintained it
will probably have a short and miserablewill probably have a short and miserable
existence.existence.
• All User Input Is EvilAll User Input Is Evil
 Murphy was a userMurphy was a user

• Optimize LastOptimize Last
 Donald Knuth said premature optimizationDonald Knuth said premature optimization
is the root of all software evil.is the root of all software evil.
 Design the system for extendibility andDesign the system for extendibility and
maintainability.maintainability.
 Optimize only when you’ve identified aOptimize only when you’ve identified a
deficiencydeficiency
• Security and Verifiability Are By DesignSecurity and Verifiability Are By Design
 If it’s important it needs to be consideredIf it’s important it needs to be considered
from the beginning.from the beginning.

Importance of Software architecture

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Importance of Software architecture

Similar to Importance of Software architecture (20)

Recently uploaded

Recently uploaded (20)

Importance of Software architecture

Editor's Notes