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