Lecture 08Architecture Considerations

Agenda Goals Architecture Drivers Non-functional Requirements Constraints Principles

Reading Brown: III Designing software– Chapters 21-25 (both included)

Goals of an Enterprise Architecture Be robust Be performing and scalable Take advantage of OO design principles Avoid unnecessary complexity Be maintainable and extensible Be easy to test Promote reuse

Requirement Considerations Goals based on business requirements– Support for multiple client types– Portability

Support for multiple client types– Does we need to support different client types?– Do we need abstraction layer?

Portability– Does the application need to be independent of

a particular middleware, like databases?– Do we need abstraction layer?

ARCHITECTUREDRIVERS

Architectural Drivers Functional Requirements Quality Attributes Constraints Principles

Architectural Drivers We must understand these drivers at a

high-level– Creativity can come from constraints

Clear VISION– Architecture is about STRUCTURE and VISION– Must be communicated

Will help in the decision process– When faced with a decision, the vision will tell

you

Quality Attributes Requirements are easy to understand– People can (mostly) explain the features they

want It’s the non-functional requirements that

are more tricky– The “ilites”

Performance Performance is about how fast something

is– This must always be a consideration

Applies on multiple levels:– Hardware specification– Network setup and security– Architecture of the software– The programming of the software– Protocols used– Middleware and containers

Performance Response Time is the amount of time for

the system to process a request from the outside

server processing…client request

network

response

The user waits until the transactionis done

Performance Responsiveness is how quickly the

system acknowledges a request as opposed to processing it

server processing…client request

network

responsewaiting…

The user sees that the system isdoing something

Performance Latency is the minimum time required to

get any form of response, even if the work to be done is nonexistent

nothing…client request

network

response

The overhead of the request andnetwork transfer

Performance Throughput is how much stuff you can

do in a given amount of time

t1 t2time

records processed…

Performance Load is a statement of how much stress a

system is under

Performance Load sensitivity is an expression of how

the response time varies with the load

Performance Efficiency is a performance divided by

resources Capacity of a system is an indication of

maximum effective load

Scalability The measure of how adding a resource

affects the performance– Vertical: Make the hardware faster, more

memory etc– Horizontal: Get more hardware – scaling out

How many concurrent transaction can the system handle– Request per second or per minute

Availability The degree to which your software is

operational– Measured in terms of “nines”– 99.99% per year - four nines, uptime in terms

of percent Usually specified in Service Level

Agreements (SLA) 99.99% is downtime:– Daily: 8.6s– Weekly: 1m 0.5s– Monthly: 4m 23.0s– Yearly: 52m 35.7s

Security Overall all security issues are vital– Authentication and authorization– Hardware access restrictions on network levels– Firewalls– Open Web Application Security Project

(OWASP)– Security Roles for people– Securing sensitive information, for example

encrypting data

Disaster Recovery Response to failures– Disk crash, faulty network card etc– Network downtime

External disaster – force major– Fires, earthquake

Business Continuity Plan– Specifies how a business can recover from

disasters

Monitoring Infrastructure to track activities in the

system– Hardware capacity, such as disk space,

memory, CPU load– System transactions

Monitoring software– SNMP standard– Viewing tools

Auditing Traceability of what happens in the system– Logging of events– Software to track changes

Some software must allow for external auditing– All transactions are logged– All changes to record data is logged– Any event can be viewed

Software Requirements Flexibility– The ability for non-technical people to modify

business rules within the system Extensibility– The ability to extend and modify software for

new needs Maintainability– Think about the cost of running software over

some time

Other Requirements Legal, regulatory and compliance– Laws that regulate industries

Internationalization (i18n)– What languages must be supported

Localization (L10n)– Does the software need to be adapted to local

cultures

NON-FUNCTIONALREQUIREMENTS

Non-Functional Requirements The challenge is to capture the non-

functional requirement Instead of asking how much availability (-

ability) ask specific questions– “How much downtime can you tolerate?”– “How many users are there max?”– “How much do you expect to sell?”

Non-Functional Requirements Categorize non-functional requirements– Sometimes the best solution is really not what

is needed– Sometimes features are not required to begin

with Use MoSCoW– Must, Should, Could, Wont

CONSTRANTS

Constraints Time and budget constraints– There is always a deadline

Technology constraints– Approved technology – Technology Stack

Existing System and Interoperability– Middleware or standards used

Target Deployment Platform– Must run in Windows or Linux

Constraints Technology Maturity– Established middleware or bleeding edge

Open Source– Use of proprietary software or open source

Vendor Relationship– Firms make partnerships with technical

vendors Past Failures– We tried this technology and it did not work

and we don’t want it

Constraints Internal Intellectual Property– Developed in house and must be used

Corporate Policies– Reports, memos, approvals

Consultants– Have all the answers, of course

People Constraints People set constrains– Size of Teams – Two Pizza Teams are common– Skillset and combination of skills– Hiring and training of new employee –

scalability – Who can work with whom – social status

problems

Organization Constraints Politics– Obstacles, people protecting their turf

Strategic software or tactical– Affect priority and resource allocations

Communications paths– Conway’s Law

Access to support– Are you important enough?

Risk Management All projects have risks– Track risk by two metrics: likelihood (0-100)

and impact (0-5)– Highest risk is the highest likelihood x impact– For each have a mitigation plan, i.e. explain

how you react if risk becomes reality Risks examples– External vendor does not deliver, hardware is

not there on time, development problems, politics, bugs

Practical Considerations Solutions are designed and implemented

according to time schedule and budget– Hardest part is management of people

Practical Considerations Risk is in feature creep and things out of

control

PRINCIPLES

Principles Guidelines for how to work– Keeps development effort uniform

Development Principles– Coding standards– Automated unit tests– Static analytic tools– Build strategy– Deployment strategy

Principles Architecture Principles– Layering– Business Logic– Statelessness– High Cohesion, Low Coupling or SOLID– Persistence strategy– Domain model– HTTP protocols– Consistency strategy

Summary Goals– High-level vision for the architecture

Architecture Drivers– Quality, Performance, scalability, etc.

Non-functional Requirements– Capturing

Constraints– We always have to work within some boundary

Principles