Date post: | 15-Apr-2017 |
Category: |
Software |
Upload: | olafur-andri-ragnarsson |
View: | 389 times |
Download: | 0 times |
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