Software Architecture

• Software Architecture
• Need for Software Architecture
• Objectives of Software Architecture
• Types of IT Architecture
• Architectural patterns and Styles
 A blueprint that satisfies the requirements of a
software application
 Example software application:

Travel Reservation application that

 Shows various options to complete a trip
 Allows to select specific option
 Allows to book/view/cancel reservations
 States the problem clearly
 Specific needs and constraints
 Verifiable and measurable
 Focusses on what to be done. Not how the
problem is solved.
 Customer needs to book a ticket (belongs to what)
 What interface, tools, database used is not part of the
requirements (this belongs to how part)
 Functional Requirements
 Booking a Ticket
 Cancelling a Ticket
 View the Status of a waiting-list ticket
 Non-Functional Requirements
 Performance ( the booking page should be loaded
under a second)
 Scalability (Must support 20 concurrent users)
 Security (The customer details must be secured)
 Dividing the complexity
 Using a number of
 sub-systems (Payroll, HR, Sales, Purchase for ERP)
 Interfaces (Interfaces to communicate with Payment
Gateways)
 Software Architecture is the blueprint covering
 Sub-systems
 interfaces
 Interaction between subsystems
To meet the requirements
38 years of construction – 147 builders 0 architects
160 rooms – 40 bedrooms, 6 kitchens, 2 basements, 950 doors
65 doors to blank walls, 13 staircases abandoned, 24 skylights in floors
No architectural blueprint exists
https://www.youtube.com/watch?v=bUIa9bZ3JDs
• Tallest building in the
world
• At over 828 metres
• more than 160 stories
• Constructed in five years
(from 2004 -2009)
• Floor area 309,473 m2

Adrian D.
Smith
(Architect)

William F.
Baker
(Structural
Engineer)
 Different Modules
 Registration
 Loan enquiry
 Loan Approval

 Interfaces between layers of application

 presentation
 Business
 Data Access


 Customer Officer
Infrastructural
services layer
Presentation layer

Login Register Login Application

Security
View Loan Details Approve Loans Payments

Cryptography
Business layer
Access Control service
Authorization Authentication
Logging Services Interface
Audit Trail

Business layer Framework

Data Access Registration Loan Enquiry Loan Approval process

Payment process Reporting Service Batch Process

Error
Handling
Data Access Layer
Validation Data Access Manager

Policy Data Base

Injection
Identity DB Loan DB
 Rooms to Subsystems
 Doors to Interfaces
 Specifications and topology of the land to the
platform used

 Architecture is blueprint that forms the basis for

 Design, Development
 Interior designers can develop design of each room
of the blueprint provided by civil architect
 Software designers develop detailed design based
on the blueprint given by the s/w architect
 Recurring problems (Rather than develop
design from scratch)
 Interior designers take into account the
available constructs (size, budget), furniture to
solve recurring problems of each type of room
(bedroom, bathroom, hall)
 Software designers develop detailed design of
each layer and sub-system of an application
based on established design patterns.
 IEEE 1471-2000

 Software architecture is the fundamental organization of

a system, embodied in its components, their relationships
to each other and the environment, and the principles
governing its design and evolution
 Simple Applications
 Few modules
 few interfaces
 one or two people can build
 Large Enterprise application
 Complex system
 Large number of modules and interfaces
 Several hundred person years of effort needed
 Application evolve over a period of time,
requirements may change over a period
 Analogy: Simple House vs Skyscraper
 Need for architecture is apparent when the
complexity of the application increases
 Trade-offs (CTQ)
 Cost - limited budget
 Time – limited time to deliver the product
 Quality – effectiveness measured and controlled

 Architecture must ensure – available options

are analyzed decisions are made to satisfy the
stakeholder goals
 Architecture – balance CTQ
 Incompatibilities surface much later phases
 Fixing issues identified during the construction
and testing stages of development are
expensive and need significant effort to correct
them.
 Satisfies the functional requirements of the
users
 Meets the non-functional requirements
 Allows to construct with available technologies
and industry practices
 Enables development to be based on
established engineering principles to achieve
the CTQ objectives.
• Manage complexity
• by separation of concerns
• Resolve issues related to functional requirements
• By defining set of layers, modules, interfaces that will work
together
• Addressing of non-functional requirements
• Performance – Caching
• Scalability – architecture can scale to meet the future demand
• Exploit technology platform capabilities to reduce the cost
• OS, VM-Ware, Databases
• Leverage reusable assets and frameworks
• Using frameworks – e.g. using Struts to develop web applications
• In-house developed libraries
• Lower the impact
• Must be agile to changing business requirements,
operating constraints, technology environment
• Use best practices and lessons learnt in developing
similar applications
• Visual representation of layers, modules, sub-
systems to enable easy validation and confirmation
by stakeholders
• Provide foundation for developers
• To elaborate the architecture
• Generate design artifacts
• Usage of consistent terminology
• among architects, designers, and developers
• Represented in many views
• No single view can cover various aspects
• Each view focus on specific aspect
• Deployment View
• Logical View
• The views used depend on the type of
architecture.
 Enterprise Architecture
 Business Architecture
 Solution Architecture
 Technical Architecture
 Infrastructure Architecture
 Defines the collection of models that define the
structure required for an organization to meet its
objectives

 Scope :
 business
 IT systems need to support the business
 Policies and principles for governance

 Who :: Enterprise Architects

 Who :: Enterprise Architects
 What do they
 Deal with future business stated from interactions
with CXOs and other stakeholders
 Insights into business trends, technology trends
 regulations and compliance requirements
 Translates Business Strategy to IT Strategy
 Decisions related to migration, retiring applications
 Ensure IT applications aligned with the business
processes
 Models that represent EA :
 Business model
 Application model
 Information model
 Infrastructure model

 Frameworks for defining EA

 Zachmann’s
 TOGAF
 FEAF
 TEAF
 C4SIR/ DoD
 Blueprint of the business concerns of IT systems
 Involves developing model based on:
 Business drivers
 Business rules
 Business processes

 The Business Architecture is mapped to

Technology Elements

 Who : Business Analysts or Business Consultants

 Who : Business Analysts or Business Consultants
 What do they :
 Looks at Current Business Strategy, Business processes,
rules and policies to come up with the Business
Architecture
 define AS-IS business architecture
 develop TO-BE by having vision for the future state of the business

 Frameworks for developing BA

• TOGAF’s ADM – Phase B
• IBM’s Business Architecture description
• Microsoft Motion
 Solution to the business problem that is to be implemented
by IT systems
 Business problem stated as set of business requirements
 Mapping of functionality in IT systems to technical elements
 Who : Solution Architects
 What do they :
• focus on specific area from both functional and technical
perspectives
• Evaluates “Build” and “Buy” options
 Views to describe
 what the solution is
 how a solution is implemented

 Mainframe Applications (Old architectures)

 Processing
 Data
 Connection

 Enterprise Applications
 conceptual view
 logical view
 physical view
 More views are needed to cover the functional and non-functional
needs of an application
 Is critical for domain intensive solutions (banking, financial
services, insurance, etc.)
 Understanding the domain and mapping the business and
workflows to technical elements, and integration is the key
to success
 IEEE 1471-2000 is a standard for software architecture
 Blueprint of the solution described in terms of
 technical elements
 Their structure
 Relationship with each other
 Technology platform

 Who : Technical Architects

 What do they :
• focus on specific technologies like .Net and J2EE
• Uses Design patterns, frameworks
 Needed to revisit technical architecture for a given set of
functional and non functional requirements
 Many alternatives/products to solve the same problem
 Reusable components and frameworks available
 Technologies outdated
 Support for products withdrawn
 Blueprint for the
 Hardware
 OS
 Network
 Messaging
 Security

 Who : Infrastructure Architects

 Who : Infrastructure Architects

 What do they :
 Review Technical Architecture
 Sizing and capacity planning of application hosting
 Storage systems
 Identification of systems for
 Provisioning
Fault-tolerance
 Application deployment and security compliance
 In the Text Book:
Technical Architect,
Infrastructure Architect are given
as separate roles

 Technical Architects need to know the limitations of the infrastructure in place

 Infrastructure Architects need to know the products hosted on the infrastructure
 Architectural style :
o A set of architectural properties exhibited by an
element or component of architecture.
o Provides an abstraction for an element or component
with defined set of architectural properties
o Is represented in terms of components, connectors and
constraints related to control and data flow
o Seven commonly used architectural styles
 Architectural Pattern :
o Originated from OO community
o Solution to recurring problems encountered in many
projects
o Description of element and relation types together
with a set of constraints on how they are used
o Described in terms of context, problem, solution
with a supporting rationale
o Architectural pattern – coarse grained –at the level of
subsystem
o Design Patter – fine grained -- at the level of classes
 Architectural styles Description
Pipes and Filters Data flow is central.
Components have input, output, called filters
Connectors join the components, called pipes
Components filter/read input, process, generates
output that will be transmitted to the next
component through the connector (pipe)
Analogy – pipe usage in unix
ps –ef | grep test
Objects Data encapsulation
OO Approach.
Object encapsulates data and its operations.
Components are instances of classes (Objects)
Connectors are method calls invoked on objects.
Example: Objects in OO language
 Architectural styles Description

Implicit invocation Event driven approach

Component invocations are implicit.
Generate Signals or Events
Connectors are callbacks
Receiving Components – binding - static /dynamic
Analogy – Event based UI (Java awt)
Layering Separation of concerns through layers
Components are Layers
Connectors are protocols that define how the layers
interact with each other (Service Interface OSI stack)
Example – N-tier web application, OSI Stack
Repositories Central data structure that is widely accessed.
Components Central data structure, and elements
that access it
Connectors mechanisms to interact with Central data
structure.
Examples: Database and Blackboard
 Architectural styles Description
Interpreters Virtual machine is central to this.
Separates invoking element from execution element
Gives Portability and extensibility
Component – invoking element, interpreting element
and execution element together
Connector – command language of the invoking
element
Analogy – execution of scripting languages like
perl, executing .class files on JVM etc.
Process Control Tuning from information state to targeted future
state
Component – elements that process and control
information
Connector – input, output, feedback loop
Example: Cruise Control
 Synonymous to architecture styles
 Many architecture styles also referred as architectural
patterns
 What is common?
 Abstraction of elements with specific architecture properties

 What is different?
 architecture styles focus on components, connectors,
and their interaction. But not on rationale.
 architectural patterns require:
 Rationale
 Capture common use
 Aesthetic (a clever solution)
 Provides context, problem, solution
 Layers
 Context: Decomposition of a complex system
 Problem: To handle multiple levels of abstraction
 Solution: Group elements into layers with each layer
interacting with the next layer

 Pipes and Filters

 Context: Data flow with multi-step processing
 Problem: Sequential stages in data processing
 Solution: Components defined with inputs, outputs and
processing. Output of one component feeds the input of
the next stage
 Blackboard
 Context: Algorithmic problem solving not feasible
 Problem: Multiple problem solving agents to cooperate
 Solution: problem solving agents uses the shared memory
(blackboard) to interact with.

 Broker
 Context: Distributed system with autonomous interacting
components
 Problem: To loosely couple interacting components
 Solution: Uses a mediator component to connect clients to
servers
 Model –view controller
 Context: UI changes frequently, need to be ported to different
devices with a different look-and-feel
 Problem: Model to allow changes to UI without affecting the
functional part
 Solution: Separate application into model, view, and controller

 Presentation abstraction control

 Context: Interacting components that use Agents
 Problem: Model interactive components as a set of cooperating
agents.
 Solution: Structure the model as a tree with presentation,
abstraction, and control agents
 Microkernel
 Context: Components with stable core functionality that need
to be adapted over time
 Problem: Coping with functional and technology changes
 Solution: Encapsulate core services in a microkernel component

 Reflection
 Context: System providing modification of its own persistence
 Problem: Expose modifiable elements while hiding core
elements
 Solution: Mechanism to allow change of structure and behavior
dynamically
 Service-Oriented Architecture (SOA) is an architectural
style that supports communication between services.
 Service :
 Is a logical representation of a repeatable business activity that has a
specified outcome (e.g., check customer credit, provide weather data,
consolidate drilling reports)
 Is self-contained/autonomous
 Access through a well-defined interface
 Coarse-grained
 Stateless
 Loosely coupled
 Communicate via messages
 May be composed of other services
 Is a “black box” to consumers of the service
 Service provider and service consumer applications are
loosely coupled by the use of service contract and data
contract.

 Service Contract
 Interface to use the service
 Defines message types exchanged between the service provider and
service consumer
 One or more operations to exchange messages (request-reply
exchanges)
 Data Contract

 Formal agreement between a service and a client that

abstractly describes the data to be exchanged.
 To communicate, the client and the service do not
have to share the same types, only the same data
contracts
 A data contract precisely defines, for each parameter
or return type, what data is serialized (turned into
XML) to be exchanged.
Service Consumer

Service Registry

Service Provider
 Service contract is an interface.
 Data contract is an agreement.
 Service model :
 Key aspect : service consumers and service providers
are loosely coupled to each other.
 Service Registry : registry where the services register
 Service Provider : publishes the service in the Service
Registry
 Service Consumer : locate a service from the registry,
invoke operations on the service
Users

Mail Order form

transport Courier company Mail order company
Courier company

Dispatching

Courier Delivery Courier Delivery

 Mail-order companies (Service Providers)
provide goods by mail
 Mail-order service providers publish catalog of
goods in a news paper (Service registry)
 Service consumers, browse the catalog (at
service registry) to select a product
 Different types of orders the consumer can
place is defined by service contract. The mail
order form with items selected, payment, and
shipping details is a data contract.
 The mail order form is placed in an envelop with an
address the courier company can understand. The
courier company sends it to the mail-order company
(service call)
 In response to the order, the mail-order company
ships the goods to the consumer
 the courier company performs
 Routing the request
 Delivering the response
 Can also transform the content (A soft copy can be
processed).
 Enterprise Service Bus (ESB) performs routing,
transformation needed in SOA
 Structural Programming (Pascal, C, etc.)
 Object Oriented Programming (Smalltalk, C++, Java,
etc.)
 Client Server applications (Visual Basic-rich UI
supported)
 N-Tier Applications (3 tier web applications)
 Distributed Objects (CORBA, Java-RMI)
 Component Models (lifecycle support, EJBs)
 Service Oriented Architecture
 Micro services (current trend)
Service – Oriented Architecture

Component model

Distributed Objects

N-tier Applications

Client / Server Applications

Object –Oriented Programming

Structured Programming
 To be more efficient and competitive in the
market, IT must align with the business needs
 Reviewing several projects in different
organizations brought out several drivers
 Business to adapt to the changing market place

 Business Drivers

 Technology Drivers
 Business
1. Rapid business process changes
2. Reduction of process cycle times
3. Promotion of business through multiple channels
4. Protection of investments in legacy applications
5. Lower total cost of ownership

 Technology
1. Application modernization
2. Technology change management
3. Integration and interoperability for enterprise wide
heterogeneous applications
4. Support by product vendors
Dimensions that enable business transformation
are:
 Reuse (How many reusable components are
available)
 Integration (How easy it is to integrate with
other systems)
 Agility (agile infrastructure to make changes
with ease and minimal effort)
Reusability:
 By using services

 Corse-grained reusable functionality

 SOA – functionality exposed as set of services

 Services orchestrated by a set of business

process services
 Changes to the business functionality or
orchestratation do not impact the other
applications
 Complexity, agility are better managed in SOA
Integration:
 Hub-Spoke model

Hub –
 Centralized

 Accepts Messages from different

applications connected via
spokes
 Message validation,
transformation, routing
 Asynchronous Message delivery

 Single Point of Failure (Hub)

 Expensive proprietary products

Integration:
 Enterprise Service Bus
(EBS) integrates service
providers and consumers
 Better than Hub-Spoke
model
 Distributed services for
message routing,
transformation, and event
handling
 Capabilities for loose
coupling between service
providers and consumers
Agility:
 Organization Mergers acquisitions

 Collaborative arrangements with other enterprises

 Business Restructuring may cause the business

applications to be moved to different/newer
applications (within organization or outside
organizations like partner organizations)
 Services allow business process and orchestration
independent of the technology used to implement
an application
Components that support the reuse, integration, and
agility:
 Services

 ESB

 Orchestration
Services
 Basic reusable components of SOA

 Coarse-grained business functionality

 Service Contract
 Consumers invoke an operation published (in the
service contract) by the service
 Data Contract
 Consumers provide data as per the data contract

 Autonomous
Services
 Loosely coupled

 Stateless

 Composability

 Discoverable

 Can be implemented by different technologies

(webservices SOAP over HTTP)
 WSDL to describe

 Invoked using xml messages

 SOAP envelop over HTTP

SOAP over HTTP is more popular. But not mandatory to
become a service.
The following must be met to become a service
 Service boundaries explicit, interact with others
through message passing
 Autonomous in terms of data isolation and loose
coupling
 Interactions based on service contract, data contract
and associated policies
 Service compatibility based on policy expression (WS-
Policy) when service contract cannot fully specify all
aspects of a service
Enterprise Service Bus
 Acts as a mediator between service provider and service
consumer
 Allows services to interact with each other
 Across locations, different transports, across organization
boundaries
 Provides integration capabilities – routing, transformation
and delivery between providers and consumers
 Better than Hub and Spoke model
 ESB is an architectural pattern. Does not impose specific
implementation
 Different vendors have different tools to support ESB
concepts – routing, transformation and delivery
Orchestration
 Brigs Agility
 A business process consists of set of services, a
workflow is defined that invokes services at different
stages of a workflow
 To execute the business process, the workflow is
orchestrated
 Controls process level integration and automation of
services
 Business Process Execution Language (BPEL) is a
language to specify business process as a workflow
 Many vendors support BPEL and have orchestration
engine
 Technology providers are defining SOA reference
models
 Products to support the standards
 Standard bodies worked SOA standardization
 World Wide Consortium (W3C) published XML,
SOAP to interoperate web technologies (Any
hardware and any software can work together
across web)
 Web Services are based on W3C standardization
 W3C also published Service Modeling Language
(SML) for creating complex services
 Organization for the Advancement of Structured
Information Standards (OASIS) has developed
 WS-Transaction, WS-Reliability
 Reference model for SOA
 For SOA,
 Service Component Architecture (SCA)
 Assembling services to create a solution
 Separates the role of programmer vs assembler
 Life-cycle management at architecture level rather than code
level
 Service Data Objects (SDO)
 Open SOA Collaboration (group of 18 s/w vendors)
 The SOA reference model has 3 views
 Service eco-system view (related to participants of
SOA)
 Realizing services view (requirements for SOA)
 Owning view (related to governance and
management )
 OMG developed standards for modelling
 BPMN (Business Process Modeling Notation) for business
processes
 UML(Unified Modeling Language) for service and component
modeling
 CWM (Common Warehouse Meta-model) for modeling
Database and BI)
 Platform independent view based on MDA (Model Driven
Architecture)
 MDA offers the capability to design a SOA solution through
models, minimizes the effort invested in specific technologies or
protocols
 an UML profile for SOA and a meta model specification
SOAML (stereotypes – ServicePoint, ServiceChannel, Service
Contract, ServiceInterface)
 SOA adaptation resulted in significant improvement to meet
enterprise needs
 SOA based projects estimated to reach hundreds of billons
 SOA not limited to Enterprise Architecture. It is becoming part of the
Cloud computing (SaaS)
 Cloud *-as-a-service and SOA are not incompatible, It is a logical
progression
 Improving business process
 Automating steps in business process
 Providing right information at the right time to clients
 Gartner states
 SOA used when large new business applications
 Integrating some combination of purchased packages, legacy applications,
services from other business units
 Advanced SOA: addition of business event and event driven
architecture (EDA) to request/reply interactive business model