HÖNNUN OG SMÍÐI HUGBÚNAÐAR 2015L10 ARCHITECTURE CONSIDERATIONS

AgendaGoalsArchitecture DriversNon-functional RequirementsConstraintsPrinciples

Reading

Brown: III Designing softwareChapters 21-25 (both included)

Goals of an Enterprise Architecture

Be robustBe performing and scalableTake advantage of OO design principlesAvoid unnecessary complexityBe maintainable and extensibleBe easy to testPromote reuse

Requirement Consideration

Goals based on business requirements• Support for multiple client types• PortabilitySupport 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?

Architecture Drivers

Architecture Drivers▪ Functional Requirements▪ Quality Attributes▪ Constraints▪ Principles

Architecture DriversWe must understand these drivers at a high-level

▪ Creativity can come from constraintsClear 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

Quality AttributesRequirements are easy to understand

▪ People can (mostly) explain the features they wantIt’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

response

The user waits until the transactionis done

waiting…

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 user waits until the transactionis done

waiting…

▪ 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▪ Companies must have Capacity Planning strategy for

successful growth

Performance

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

▪ Internationalisation (i18n)– What languages must be supported

▪ Localisation (L10n)– Does the software need to be adapted to local cultures

Non-functional Requirement

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▪ Identify explicit quantity:▪ How many concurrent users should the system support on

average? What about peak times?▪ What response time is deemed accceptable? Is this the

same across all parts of the system or just specific features?

▪ How exactly do we need to secure the system? Do we really need to encrypt the data or is restricted access sufficient?

▪ 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

Non-Functional Requirements

Constraints

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– Enough people without too many communication paths– Skillset and combination of skills– Hiring and training of new employee – scalability – Who can work with whom – social status problems

Organisation 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

Designand

Implementation

Features

TimeQuality

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

Beware of “best practices”▪ All systems are different▪ One strategy might work in some situation and not in others▪ What may be a good idea turns in practice not to be so good▪ Examples:▪ Java Entity Beans ▪ Resource Bundles▪ Too much Layering

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