Unit-1

Software Architecture
 Topics to be discussed
• Software Architecture
• Need for Software Architecture
• Objectives of Software Architecture
• Types of IT Architecture
• Architectural patterns and Styles
 Software Architecture
• 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
Live Examples: Makemytrip, Travelocity, Expedia
 Software Requirements
• States the problem clearly
• Specific needs and constraints
(web app and also mobile app; 1sec response time;
budget limit, time to market, etc.)
• 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)
 Software Requirements
• 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)
 How s/w Requirements are
implemented?
• 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
 THE NEED OF ARCHITECTURE
The Winchester “Mystery” House

1837 – 1881) 1840 –1922

 THE NEED OF ARCHITECTURE
The Winchester “Mystery” House

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
 ARCHITECTURE
Simple House to the Tallest Building in the world
 ARCHITECTURE
Burj Khalifa
• 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)
 Loan Management System
• 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
Analogy: House to Software Project
• 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
Analogy: House to Software Project
• 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.
 Software Architecture defined

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
 Need For Software Architecture
• 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 Software Architecture
• 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
 In the Absence of Architecture
• 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.
 A Well-Architected Solution
• 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.
 Objectives of Software Architecture
• Manage complexity
• by separation of concerns (e.g class interface vs implementation,
different layers for presentation, business logic, data access)
• 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
 Objectives of Software Architecture
• 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
 Objectives of Software Architecture
• No single view can cover various aspects
• Represented in many views
• Each view focus on specific aspect
• Deployment View
• Logical View
• The views used depend on the type of
architecture.
 Types of IT architecture

Enterprise Architecture
Business Architecture
Solution Architecture
Technical Architecture
Infrastructure Architecture
 Enterprise 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
 Enterprise Architecture
 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
 Enterprise Architecture
 Models that represent EA :
– Business model
– Application model
– Information model
– Infrastructure model

 Frameworks for defining EA

• Zachmann’s
• TOGAF
• FEAF
• TEAF
• C4SIR/ DoD
Zachmann’s Framework
 Zachmann’s Framework

• Executive Perspective (Scope Contents) –

– an executive summary for a planner or investor who wants an overview or estimate of the scope of the
system, what it would cost, and how it would relate to the general environment in which it will operate.
• Business Management Perspective (Business Concepts) –
– depict the final building from the perspective of the owner, who will have to live with it in the daily routines
of business.
– They correspond to the enterprise (business) models, which constitute the designs of the business and show
the business entities and processes and how they relate.
• Architect Perspective (System Logic) –
– requirements representations from the designer's perspective.
– They correspond to the system model designed by a systems analyst who must determine the data
elements, logical process flows, and functions that represent business entities and processes.
• Engineer Perspective (Technology Physics) –
– represent the builder's perspective, with sufficient detail to understand the constraints of tools, technology,
and materials. The builder's plans correspond to the technology models, which must adapt the information
systems model to the details of the programming languages, input/output (I/O) devices, or other required
supporting technology.
• Technician Perspective (Tool Components)
– These correspond to the detailed specifications that are given to programmers who code individual modules
without being concerned with the overall context or structure of the system. Alternatively, they could
represent the detailed requirements for various off-the-shelf (COTS) procured rather than built.
• Enterprise Perspective or (Operations Instances)
TOGAF Framework
 Business Architecture
 Blueprint of the business concerns of IT systems
 Involves developing model based on:
 Business drivers (vital for the continued success and growth of a
business – data analytics, expanding market, economic conditions,
trade-agreements)
 Business rules
Business rules are lists of statements that tell you whether you may or may not do
something or that give you the criteria and conditions for making a decision.
Business requirements are what you need to do to enable the implementation of
and compliance with business rules.
e.g: Car Rental system :
Business Rule: before renting need a valid driver’s license
Business Requirement: Manually inspect driver's license OR
Scanner to read driver's license for validity OR
Card reader for driver to insert driver's license when driving through a checkpoint.
 Business Architecture

Business processes
a series of steps performed by a group of stakeholders to achieve a
concrete goal.
Examples:
1. product assembly process, a quality assurance process, a
corrective/preventive maintenance process
2. Register, select products, provide payment, ship - ordering
process

 The Business Architecture is mapped to Technology

Elements

 Who : Business Analysts or Business Consultants

 Business Architecture
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 Architecture
 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
 Solution Architecture
 The Views used to describe the architecture covers:
 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
 Solution Architecture
 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
 Technical 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
 Infrastructure Architecture
 Blueprint for the
 Hardware
 OS
 Network
 Messaging
 Security

 Who : Infrastructure Architects

 Infrastructure Architecture
 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
 Enterprise Architects

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

 Infrastructure Architects need to know the products hosted on the infrastructure
 Architectural Styles and Patterns
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 Styles and Patterns
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
 Architecture styles
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
 Architecture styles
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
 Architecture styles
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/current state to targeted
future state
Component – elements that process and control
information
Connector – input, output, feedback loop
Example: Cruise Control
 Architecture Patterns
 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
 Architecture Patterns
 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
 Architecture Patterns
 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
 Architecture Patterns

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
 Architecture Patterns
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 of agents. Each
agent manages its presentation, abstraction, and
control agents.
Abstraction – Similar to model of MVC
Presentation – (View + Control) of MVC
Control – Communication between Agents
E.g. Flight control system – one agent tracking a landing flight
and displaying on the radar. Another agent tracking a flight
that is about to take off and displaying it on the radar.
 Architecture Patterns
 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
 Examples:
 idl2java compilers that generate code for stubs and skeletons,
 Generating proxies for classes that can do logging and security checks
 Java serialization
 Service Oriented Architecture
 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 Oriented Architecture
 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)
 Service Oriented Architecture

 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 Oriented Architecture contd…

• 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
Mail-Order Business
 Mail Order Service

• 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.
 Mail Order Service
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
Evolution of SOA
 Evolution of 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)
 Drivers for SOA
• IT must align with the business needs to be
more efficient and competitive in the market
• Reviewing several projects in different
organizations brought out several drivers
• Business need to adapt to the changing
market place
– Business Drivers

– Technology Drivers
 Drivers for SOA
Business Drivers
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
 Drivers for SOA
Technology Drivers
1. Application modernization
2. Technology change management
3. Integration and interoperability for
enterprise wide heterogeneous
applications
4. Support by product vendors
 Dimensions of SOA
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)
 Dimensions of SOA
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
orchestration do not impact the other
applications
• Complexity, agility are better managed in SOA
 Dimensions of 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
 Dimensions of SOA
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
 Dimensions of SOA
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
 Key components of SOA
Components that support the reuse, integration,
and agility:
• Services
• ESB
• Orchestration
 Key components of SOA
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
 Key components of SOA
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
 Key components of SOA
(Services contd.)
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
 Key components of SOA
Enterprise Service Bus (ESB)
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
 Key components of SOA
Orchestration
Orchestration
• Brings 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
 Perspectives of SOA
• Technology providers are defining SOA reference
models and Products to support them
• Standard bodies worked on SOA standardization
• World Wide Web 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
 Perspectives of SOA
• Organization for the Advancement of Structured Information
Standards (OASIS) has developed
– WS-Transaction, WS-Reliability
– Reference model 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)
• SCA, SDO put forth by IBM and supported by Open SOA
Collaboration (group of 18 s/w vendors).
• OASIS standardizing the SCA,SDO, Reference Model for SOA
 Perspectives of SOA
The SOA reference model (proposed by OASIS) 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 )
 Perspectives of SOA
OMG (Object Management Group) 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
 Perspectives of SOA
OMG (Object Management Group) standards (contd.)
• an UML profile for SOA and
• a meta model specification SOAML
• UML Profile, SOAML defines stereotypes for –
– ServicePoint,
– ServiceChannel,
– Service Contract,
– ServiceInterface
 Future Trends
• 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
 Future Trends
SOA Improves the business process by
– Automating steps in business process
– Providing right information at the right time to clients
• Gartner states
– SOA used when large new business applications need to
be developed
– 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 the
request/reply interactive business model