Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
beyond software architecture
Martin Fowler signature series book difference between marketecture and tarchitecture
who responsible for what early forces in solution development
problem domain competition legislation requirements process and practise customers
technology base persistence integration frameworks
target market initial bug review
implement with all stqkeholders so get a sense of who series what as priorities
classify bugs 1 = operational wont work - show stopper 5 = product improvement/enhancement
different cultures will classify differently compare to requirement - e.g. use of must, should and may
terminology creating results in the short run while working in the long run
don't just look at what customers want now - look at various information feeds to identify requirements in the future
must not harm ability to support existing customers projecting the future
markitect and architecture future view must be aligned otherwise product will fail
map views e.g market map feature/benefits technical architecture
different maps should highlight conflicts / challenges, e.g. feature not being achievable with a tech architecture
regularly review & maintain maps harnessing feedback
tech architects conferences journals training
market architects ... user conferences review 1st & 2nd line issue logs
talking with sales teams win/loss analysis
market analysts talk with advisory groups meet key customers
avoid when gathering info ... making promises making commitments being negative about product set expectations be judgemental on contributor/contribution
generating clarity form of communication larger projects - need more formality comunicate impacts
working in unison agree processes and principles that drive the project avoid filbert thinking of different groups involved make information available e.g maps
context diagrams and target products higher level views of the world technologies customers use and know potential parters and market synergies value proposition integration and extension options target platforms
marketecture = marketing architecture business model licensing selling model value proposition
tarchitecture = technical architecture(view that dev work with)
subsystems interfaces distribution of processes patterns
Release ManagementChapter 15
establishing a baseline all the versions of the different components in the product version name
release management what you're releasing
patch full releasee partial
who you're targetting beta
general release why they want it
new features performance improvements bug fixes deal with 'version 'skippers' - try make releases attractive
to large user base release identification
full or complete releases partial releaes patch releases variations
Release Management Influences on Tarchitecture recreate everything use existing solutions and infrastructure put version into architecture as early as possible components should know their dependencies messages and protocols should be versioned database and tables should be versioned internal components should understand external verssions support and testing implications on patches
serial numbers, registration and activation Security
Chapter 16 viruses, hackers and pirates
managing risk - cant eliminate see no evil, speak no evil need to consider ...
digital identity management transaction security software security information security
digital identity management authorization - whoo can do what
link to LDAP, AD RBAC - Role Based Access Control file system ACLs
authentication consider if open or closed system
transaction security auditability
proof of legislative compliance could spot check volume of activity from individual sources use audit information as product feature analyse system use for marketting
integrity use hashes on data to valid untampered encrypt hash keys rather than all data
confidentiality
encryption SSL algorithms stronger than SSL, but not as common
accountability non repudiation strength in accountability relates to strength in
authentication software security
techniques serial numbers and activations
digital sign licenses to combat reverse enineering code and creating illegal licenses
protect validation code license check more complex than code
checking boolean value store something encrypted that has to be
executed hardware binding
use hardware finger print use physical device - dongle / usb dongle strong solon but costly to manage
cost benefit remember lost people using illegal copy of s/w prob
wouldn't use if no copy making secure may impact legit users cost consideration to development obscurification can make dav/support more
challenging even certificate server can up op costs risk impact consideration
information security secret algorithms or secret keys back doors
maybe convenient for support, but real security risk not use durib support
security and marketecture authentication, business models and operations regulatory impact industry growth trust dispute resolution
Checklists Software Architecture
dependencies between subsystems clearly defined each team member working on a subsystem that they find
interesting each team member working in a way they believe will improve
productivity architecture is profitable
current release is focused on issues of evolution or maturity understand the level of technical debit incurred in the system, can
identify tech debit proper compliance with all in-licensed components architect can articulate principles driving the choices made team right size to accomplish goals
Product Development defined means to capture requirements product managers represent voice of the customer organisation has means to kill a product if necessary understand our competitors & know what is needed to win understand who we building the product for, and who we're
selling to have a useful change management protocol
difference between markitecture and Tarchitecture have a markitect have a tarchitect bug database with cliassifications tech staff meeting customers know how to interact with them context diagrams for the systems
Business and License Model Symbiosis team members can define business models in use and being
considered license agreements congruent to business model license agreeent specific to rights for the customer chosen appropriate approach to enforce business model technical implications of changing business models understood
and clearly communicated Portability
each platform has sufficient dev, qa, support and sales resources sufficient time perform ill teting each platforms market share is known so cost effectiveness can be
identified roadmap factors in major platform releases market driven matrix to target testing efforts
Deployment Architecture match target market ability to meet expected workloads operational policies considered sales models considered sales cycles infrastructure investment customer input
Integration and Extension support material is available consideration of own solution integrated with other solutions naming conventions etc to make API consistency performance and resource implications of using extensions/APIs
Brand and Brand Elements
all brand elements identified and approved brand elements internationalized error, diagnostic and log files have been checked and approved trademark and registered mark used properly brand elements can be replaced by partner?
usability tested all key functionality for usability capture conceptual model along with user mental models, system
metaphors system metaphors are clear means for sales/marketing to measure performance for reference
figures know when and how to throw h/w at the problem
Installation defined how subcomponents will be handled how installation meets rlicense requirements defined required skill to work with installation way to verify correctness of installation process adheres to platform guidelines avg user can install without referring to manual tested bot install and unistall
Upgrades considered all potential areas where an upgrade can cause pain &
mitigated? tested all migration paths? defined the migration path for alll customers? defined downtime of upgrade process defined how to rollback the upgrade process? tests included to confirm successful upgrade?
configuration have we defined all sys configuration?
security implications audit of changes?
documentation of allowable values documentation of implications of values
Logging Defined the purpose of each log file Log file utility suitable for target users Eliminate dev specific logs Following UI principles for I18N Logging is portable like rest of system Easy to parse
release managementchapter 15
know who were targeting releases to process for identifying releases sku's if required
Securitychapter 16
identified levels of security required Upgrade
Chapter 12 like installation only worse upgrade fears
pain of rework e.g. reworking integration ripple upgrades - move other components that have been fine,
more hardware needed data migration from old schema to new (good schema design can
reduce/avoid problems) data retention (need to recover archived data to production
version) certification (OAT, UAT etc processes) New APIs new features - cost & effort of learning to use them, motivation for
adoption inaccessible system - impact of needed down time reversion - hoow to rollback to the older version of the system in
the event of a problem making upgrades less painful
review install process - principles essentially the same keep the need for upgrades to a minimum, awareness of the
market rhythms upgrade readyness - check what needs to be changed, only change
what is necessary data migration - consider the steps needed and data being both
structured and semi structured deal with customers in very controlled and subtle manner quietly remove features if they not used and not needed.
deployment info can indicate this preserve user preferences and configuration during an upgrade how to handle upgrading from previous versions
go from ver-1 to ver and repeat to cross multiple versions select particular releases (commonly used) and provide
multi version jump in 1 step for multi version jumps, customer might have to do ver-1 to
ver before doing multi ver jump does the new version need to coexist with existing version
or is it a replacement market maturity and upgrades
early adopters are more tolerant of upgrades early adoption tolerance doesnt translate to pour upgrade process
tolerance - poor upgrade will result in early adopters stop adopting early
ultimately more money will be earned through upgrades than the initial release
Logs i want to know what is happening (goals)
Debugging and error logs
Error recovery - know what is wrong to apply corrections to env Performance tuning Capacity planning - insight into resource usage Insight into how users are using the system Config being used in operation System status
not just the facts - not just when, what, and steps. Otherwise not sufficient insight later
Performance hit for recording all the info in and out of every method etc
Time to execute methods Details such as the number of connections used/created Features used and not used
log format & management format
I18n of logs allow users easier use Start log entries with time stamp Make log traceable to location in code Log transaction ids
management standards & libraries Logging with flat files offers
Easy parsing Easy reading
Keep in mind ... Need to be in sensible location Sensibly named Don't put unreadable content into files If multiple files I'd to link them together
Management Support for dynamically change log thresholds Per thread logging - ensure different threads distinguished Log levels All exceptions are logged Ensure logs can be removed Log content can be sensitive so consider security Automatically forward - feature to get info together and
send Standards
W3C extended log format Common log format for web servers Platform dependent formats such as windows event logs
postprocessing log data Compact log files or rolling Multiple files - synchronise content Log viewers
logging services Internationalization unique Ids for each entry
Consolidate logs across multiple severs to get unified story of execution
Unified time ordering Can configure where to put log files
ConfigurationChapter 13
configurability - an element of usability Critical that config is usable Hard to use config increases operating costs Hard to tune - result lower performance, so higher cost Results in higher support calls More complex professional services Increase in customer frustration Architecture can contribute to ease of configuration
system context Contextual information Location of key files - directories - use of well known locations Bootstrapping data - known locations for files to provide
configuration necessary for app boot process Portability switches - settings to switch between different DBS for
example Compatibility controls - behaviour switches to support backward
compatibility Performance parameters - system tuning impacting performance Too many configuration options - can get over complex to setup.
initialise vs execution Configure during initialisation Configuration to impact execution Startup settings - meaning possible need to restart to get
configuration applied Modifying logging settings Implications of high availability Passing configuration info to built in components
setting the value Who should have the permissions to set config
User Role constrained
Expert system Another system
Audit trail of changes Human readable - easy Db - audit trail and permissions
setting the right value More params - increase the risk of miss use Need to ensure known legitimate values and impact of changes Make config files self documenting
configuration parameter heuristics make config files easy to modify, even when the rest of the system
is down
store all data in a single location - if you think multiple locations is necessary then justify it to a support person
use ann obvious location platform specific files such as .ini are fine, but why not use xml be careful of things like registry entries - they arent so portable make config information easy to capture and forward to support make it hard to get values wrong. if they are wrong stop and tell
user, or fall to default values abstract management of config to separate pieces of software such
as a sys context object objects structure possibly against
per computer per service instance per user per selectable profile
objects incorporate semantics of config values Installation
Chapter 11 out of the box experience (OOBE)
from the experience of retrieving media or downloading clear goal defined for install - e.g. average user able to install. What
is average user? customer fears
classic customer concerns too hard - e.g. shutting down processes in a specific way too complex - avoid sequences of complex steps too easy to break something - shouldnt leave the system in
an unstable or unknown state unknown amount of time - how much time should i make
available for a typical installl? too much data / too many forms - frustration from
repeating the entry of the same info. going through lots of steps before telling user they've forgotten key info
challenges in addressing installation: subcomponents - demand the user to preinstalll, or install as part
of solution in license requirements - licensed dependencies may dictate
constraints needing to be addressed by installation need to include EULA (End User LIcense Agreement) & need to
acknowledge agreement before continuing biz model - e.g. per user, volume, server spec partitioning installation responsibilities - which actions should be
done by components & consistency in approach ensure that the environment is suitable for the installation - e.g.
environment type environment restrictions (home/office) how app is acquired - rom / download etc
who is installing, and their permissions (roles) get devs to do install before they're fresh to product
how to install installation data collection & precondition verification
free space connections DB, net etc configuration of required entities (e.g. SQL Svr installed ok) access rights - can fail install, difficult to deal with
Installation provide indication of progress - even in command line visual map of steps and progress track progress in as log file (allows for chance to provide
recovery - min allow support to perform diagnosis) make install interruptable
make process self aware ability to auto resume assumption that installation will get undivided
attention - wrong particularly in enterprise env follow platform guidelines
exception is multi platform installation avoid forced reboots avoid unnecessary questions
post installation confirmation confirm installation done correctly
verify files in correct places possible self tests log results
post install cleanup e.g. temp files read me notes user registration (with incentive to do so)
finishing touches they don't read the manual
not an argument for not providing provides QA with concrete description of expected sys
behaviour well written manuals more likely to be read well done roadmap can help give indication of effort
test the install & unisintall not unusual for QAs not to properly test (un)install in agile envs - should include installer from iteration 1 make sure various optioons exercised in QA - users will automate - process to assess pre and post installl conditions test against platform guidelines make installation scriptable
poor install costs possible loss of business more support callls enterprise soluttions - comng with provision of field engineers to
install - may not be profitable building dependency matrix may help determine all possible
problems
UsabilityChapter 10
usability is about money Fundamentally deliver a solutin Understand customer needs From considerations such as data through put Means to establish user needs
Observation Interviews Questionnaires Direct experience
Help by ... mental models
Understand tasks and then will understand models of the task metaphors
Well chosen can help architecture Take into account how product is to be presented Book - Designing Object Orientated User Interfaces (Collins 1995)
tarchitectural influences on UI design Separation of layers Influencers
Cardinality Greater nos means more advanced visualisation
needs Feedback
Indication to user of activity Responses Progress meters Early validation Controlling acces to options depending on state
Explicit user models So easy for users to understand
Workflow support Reflection of good practise Wizards
Transaction support Designed to support user interaction
Error responses Internationalisation & localization Cancelling requests Undoing requests Compensating transactions
Can't always undo Timeouts Network availability
Reliability Performance Bandwidth
Shared resources
Failure recovery need for speed
what a maketect really wants Predictable performance over pure speed Number of confident sessions How many transactions on defined hardware Case studies to help answer Performance stats regularly recalc'd
responding to the user Provide means to cancel tasks Progress indications Feedback eliminates unnecessary work
performance and tarchitectural impact Move from ststeful to stateless potentially ups latency, but
better scaling More hardware not an excuse for sloppy development Course grained transactions will help Understand threading performance Use profiling to help Handle normal operations and failure conditions separately Cache results consider processes being able to run in the background self service capabilities eg tills, atms take advantage of development envs idioms reduce work - if capability implemented try make use of it