Beyond software architecture

? beyond software architectureMartin Fowler signature series bookdifference between marketecture and tarchitecturewho responsible for whatearly forces in solution developmentproblem domaincompetitionlegislation requirementsprocess and practisecustomerstechnology basepersistenceintegrationframeworkstarget marketinitial bug reviewimplement with all stqkeholders so get a sense of who series what as prioritiesclassify bugs1 = operational wont work - show stopper5 = product improvement/enhancementdifferent cultures will classify differentlycompare to requirement - e.g. use of must, should and may terminologycreating results in the short run while working in the long rundon't just look at what customers want now - look at various information feeds to identify requirements in the futuremust not harm ability to support existing customersprojecting the futuremarkitect and architecture future view must be aligned otherwise product will failmap views e.gmarket mapfeature/benefitstechnical architecturedifferent maps should highlight conflicts / challenges, e.g. feature not being achievable with a tech architectureregularly review & maintain mapsharnessing feedbacktech architectsconferencesjournalstrainingmarket architects ...user conferencesreview 1st & 2nd line issue logstalking with sales teamswin/loss analysismarket analyststalk with advisory groupsmeet key customersavoid when gathering info ...making promisesmaking commitmentsbeing negative about productset expectationsbe judgemental on contributor/contributiongenerating clarityform of communicationlarger projects - need more formalitycomunicate impactsworking in unisonagree processes and principles that drive the projectavoid filbert thinking of different groups involvedmake information available e.g mapscontext diagrams and target productshigher level views of the worldtechnologies customers use and knowpotential parters and market synergiesvalue propositionintegration and extension optionstarget platformsmarketecture = marketing architecturebusiness modellicensingselling modelvalue propositiontarchitecture = technical architecture(view that dev work with)subsystemsinterfacesdistribution of processespatternsBusiness and License Model Symbiosisrelates to chapter 4 of the bookcommon software business modelstime based access or usageperpetualsupport, upgrades normally excludedmaintenance fee typically 15-30%can create costs for supporting all versions if not carefulmaybe required if product is embedded into larger solution e.g. runtime libraries, hardware devicesannualeffective from installation, or first useusually includes updates and patchestech support / consulting maybe additionalrenewal maybe automatic, renewal maybe different price to initial purchasecommon for enterprise solutionsrentalessentially same as annnualcommon in some industries e.g. software testingchanging rental features may allow penetration into smaller/lower cost marketsmay not include updates and patches - additional contract for thesesubscriptionssame as annual/rental but with slightly different rightscommon for backend servicesmore likely to include patches and upgradeswhat happens if user uses outside of period?grace period for payment?cut off usage- although very servertrack and charge for usage - creates complex architecture demands e.g. like car rentalper user licensevolume seat licensing for enterprisecontractual base - agree estimated volumeOEMOriginal Equipment Manufacturertransactionmeasurable units of workcould be each piece of executed software - known as tie and diefees can be calculated different waysflat feepercentage feessliding fees (volume discounting)processing fees (post processing calculated fee charged)ways of working out transaction valueprices reflects valueprice should reflect effortprice to support positioningprices reflects competitive landscapepricing should be clearpricing reflects market maturityharder to raise the price, compared to lower for same productmeteringresource managed constraintsconcurrent resource managementeg concurrent users or sessionsneed clarity of user/session definitionusers not equal to sessionsidentified resource managemente.g. named usersx out of y plugins active at onceconsumptive resource managementnumber of hours usage of a resourcecould define a resource - e.g. no times a function is invokedneed to enable understanding for user on their likely usage consumptionreporting on consumptionhardwaresoftware could be free - but hardware non functional without s/wper cpu - or other h/w element - but problem when coming to virtualisationproportion of revenue basepercentage of revenue created or costs savedneed to agree comparative benchmarksagreement on calculated benchmarksneed to consider min revenue gain/savenot very popular as it compels customer to track detailsunrestrictedservices offered based on-top of existing framework or OSservicessoftware is free, but charge for each service e.g. email, spam filterrights associated with business modelclarity of rightsfigure 4.1 common matching of licensing to rightsarchitectural support for the business modeltime based access or usagecommonly dont disable but stop updatestransactiondefine a transactionpossible challenges eg distributed transactionsrelationship between transaction and business modelneed an audit trailuniquely name transactionsimplications of transaction states, lifecycle and durationmeteringauthentication of usershow many userscounting concurrent users (not session)users gone or just inactive?hardwareneed architecture to capture appropriate infoconsider costs of the architecture on the customerimplications of changes on revenue e.g. performance improvement on hardware based licensingconsideration as to whether or not to have copy protection scheme - tighter hardware ties reduce rate of piracy eg game cartridgesquestions to considerwhat is target market - what does it valuewhat are your objectives relative to target marketyour business modeleffect of business model on tech architecturepricing modelenforcing licensing modelshonour systemstill protected by contract lawimplications on relationship with customerrevenue risk?home grown license managerstend not to be industrial strength - therefore easy to defeatcommonly needed for session based licensingin some cases this is fine and doesnt need to be iron clad3rd party or professional license managersconsiderations for OS supportcheck cracker web sites to determine license manager strengthhow easy to integrate & volume capabilitiesoperational requirements the license manager introduceslicense distribution capabilities/constraintsthe clientmarket maturity influences on the business modelemerging market - easy for force model on customersmature market - need licensing model(s) to allow max share and revenuebetter to be able t support multiple modelsconsiderations for license modelsdifferent modules maybe licensed differentlysome licenses could be geographically constrained e.g. site license (field-of-use model)period of license - month, quarter, year etcimplications to license payments - e.g. SMB or SOHO perhaps needs online credit card payment renewal supportTechnology In Licensingchapter 5Contractsbasicstermsusage or grantduration of term or other kkey datesterritory - where llicennse ca be usedspecific use - constraints oon applicationexclusivity - how much the licnesee may allow others to use solutionsublicense - can you license 3rd party solution with your solution into another producttermination - agreement withdrawalfrom 30days to 1yearpossible notice of withdrawalpossible financial clauses e.g. bankruptcyrenewalrisk of false sense of securityauto renewal - could pay too much or too littlefees/payment termsdeployment restrictionsnon coompetition clausesaccess to source code e.g. escrowmarketing - uuse of logosget expert legal adviselicensing risks/rewards of licensing elements of a solutionreduce, manage or eliminate complexity (taking solution from SME)risk-reliance on 3rd party, if they evolve in different directionrisk-supplier changes focus meaning no longer got capabilityrisk-provider goes bustpromotion of component based softwarerisk-s/w becomes to interwined in own solution to undo/replaceallow you to concentrate on the value add elementsrisk-configuration complexity increasesrisk-incompatible business models (from simple export restrictions on the 3rd party lib)risk-can mitigate with licenses such as GPLcan obtain protection by licensing technology protected by patentrisk-indemnity, legal exception from liabilities from using the componentrisk-doesnt exclude you from 3rd party patent disputesreduce time to market by reusing technologyrisk-doesn't always provide faster time to market - need to invest time to leverage technologyvendor is creating something of a higher quality than you can achieverisk-presumption doesn't prove to be the casecode may have been pushed & pulled a lot before reaching arketvendor created components are lighter and consume fewer resources e.g. memoryrisk-may prove to be heavier than expectedrisk-may not be tuneable to own requirementsmay relieve some burden of technology currency - as vendor continues to improve productrisk-updates arent provided as quickly as neededrisk-support dropped for elements or OSescomponent is start of the art and use will future proof your applicationrisk-sounds like resume driven designlicensing technology cheaper than starting from scratchrisk-calculation based on providing equivelent, but don't need everything considered in calculationrisk-license fee changes can destroy economicslicensing components will reduce service and support costsrisk-of adding more problems and work arounds to address 3rd partyrisk-if multiple 3rd parties who do you engage? Could result in infighting between your supplierswhen business models collide, negotiations ensuehonouring license agreementsneed to ennsure technical terms are understoood and clearly definedAPIs ca 3rd party app APIs be drectly exposed?support - how clients dealt with, directly/indirectly?Branding - can 3rd party logos be used etcmanaging in-licensed technologycreate adaptor or wrappper e.g. JDBCopen source licensing feeslicensing economicsPortabilityChapter 6perceived advantages of portabilityclaim-we can address a new market segmentscareful as platform alone doesn't provide full market segmentationclaim-demonstrates that we can meet customers idiosyncratic needsreflects tech skill - not what customers wantwhat if customer has chosen platform for specific features it offerstrue drivers for portabilityportable code is coollearning nuances of different versions of an OS can be tiresome1 or 2 early customer demand different solutionsbusiness case for portabilityprimary driver should be profitabilityconsider the following pointscost of training developers,QA, support in developing and supporting multiple platformscost of purchasing hardware & software for each supported platformtesting time to ensure product works on a lll platformscomplexity of multiple release cycles (testing as OS releases occur)identify the following before adopting platformssufficient revenue for that platformtake into account al costs inc dev, testing and supportsufficient organisation resources to support all platformsimpact of platform release cycles on own processscreating portable applicationsuse a interpreted languageinterpreter insulates from OS differencesif native language - ensure compiler available on all target OSensure devs know to isolate platform dependenciesuse standards based persistent storagemake business logic portablecloser to the user means less portabilitybackends typically more portableUIs greater levels of differentiation, from resolution onwardsuse XML for standardized interop comms between subsystemsavoid hiding the power of a specific platform in the name of portabilityif a platform is strong at something don't ignore itmatrix of painremove configurations eg some combinations of OS and DB don't warrant investment for supportrank order configurationslevel of use in market, i 1 in 1000 is it worth supporting?what the most valuable customers usingwhat are the combinations that will be most heavily marketedwhat will be easiest to supportwhat will allow you to achieve highest level of coverage in testingmake the final cut of supported combinations of platformbeware the promises you make - could end up with commitments to support combinations that aren't cost effectiveDeployment ArchitectureChapter 7deployment choicescustomer siteconsultants often deploy of enterprise classsupplier may subcontract to SItraditional approachapplication service provider (ASP)provides service of appmay not offer tech supporteg large enterprise solutionsmanaged service providerextends ASP modeladditional services to core appSLAs commontransactional (web services)not too common in enterprise presentlylikely to grow with growth of web servicescustomer influences on deployment architecturescontrol and integrationcustomer need to controlassurance of support when neededlong term retention & mgmt of dataconsider this when looking at MSP and ASPincreasing level of integration more likely to be on customer sightdata security/privacy and peak loadstype of data impact leakage risk considerationscost effectiveness - equip to peakloadcosts and vendor confidencecost to lease less than purchase for level of usecustomer perception - secure etc?market viabilitymarket perceptions of approachcustomer skills and experiences and geographical distributiondeployment will dictate support skills neededif customer to host - need to impart capability to customerif outsourced - need ability to manage suppliercorporate influences on deploymentsales cycletime and no steps to realise a salecorrelates to solution complexity and sizeif want shorter cycle consider ASP modelonce sale completed often want rapid deploymentuse xSP as stepping stone to self hostingflexibilitycustomer sit installation less likely to be unto dateif not unto date need to support older versionsinfrastructure investmenthow much investment needed for creating xSP offeringcash flowgeographical distributionsupport global - therefore language used in supportservice not pricechoosing software deployment architecturedeployment architectures and distribution of workinformation appliancehardware and softwareease of linux as appliance ossimplifies complex solutiondeployment choice influence on software architectureflexible, parameterized, or no integration optionsgreatest demand when deployed to client siteupgrade policycustomer site approach needs careful planningMSP and able to deploy more regularly and easilydata protection and accesscustomer site = customer problemhosted - more complex and proceurual, evidennce etcmigration optionsfuture of consumer s/wIntegration & Extensioncustomer control - driving forceyou cant predicate, but can planprovision of integration points is planning for expected future demandscustomers don't want "we can't do that"larger solutions built from multiple smaller solutionsdeliver more value by combining data with other systemsincrease switching costs - greater cost to move away from your solution - realised by customer integrating your solution closely to their otherscreate a product ecosystem - e.g. other suppliers providing plugins solutionapis will also help test the systempeople adopting/supporting your API is commitment to you in the long termlayered business architectures - logical structuresuser interfaceservices layerdomain model layerpersistent data layervariations on a themecreating layered business architecturesintegration & extension at business logic layerstechnologies & locus of controlintegration through APIsplatform preferences - platforms have variationsmarket segment preferences - markets show preference to approachpartner preferencesnaming conventionssecurity & session dataapis with session id requirements are momre complex than those withoutability to manage sessions through interfacesexpose only what customers need - expose more and creates more work to maintainAPI stabilised over multiple releaseshard to predict API needsbe prepared to take several releases to get rightextension through registrationregister components and drive extensions through callback modelmeans own app retains controlsimilar to observer design patternor through publish/subscribe modeldefine registration modeldefine tech detail e.g. when and howuse of configurationapplication restartprovision of interfacesdefine event modelwhat events availablewhen they occurnotification formatinformation provided in the callbackdefine execution control semanticscalls are blocking or notthread considerationsprocess controlsdefine resource management policiesdefine error/exception protocolsintegration & extension of persistent dataviewsdecouples application/physical schemauser fieldsavoid cost/effort of establishing additional toolsnot semantically meaningfullack of proper data modellinghook tablesneeds careful coordination in apps various layersidentify events associated with DBs CRUD operationslink to own data through common keyuse GUIDs not auto incremental fieldsdifficult to sustain relational integritycan extend transaction execution timespreadsheet pivot tablesrelies on strong spreadsheet productsextract based approachETL and old scriptstell them whats going onnot very desirable in most casesby pass of validation rulesfailure to protect transactionalitycost of schema changes to sustain backward compatibilityBusiness ramificationsprofessional servicesprovision of expertise to integrateconsider releationship to product managersconsider working with SItraining programspotential to improve customer satisfactionpotential to reduce support costsinclude training on integration aspectsconsider all possible audiences from users to SIs to orgs building pluginscertificationconsider ...product ecosystemcompetitive edgecurrencymore technical shorter training life valueneeds programme to be sustainedprofessional recognitionindependent certificationacademic credentialsuser communityneeds nurturinghelp understand how users are really using the productcommunity websiteeducational materialsunofficial examplesadditional knowledge basemailing listuser conferenceslicense agreementsmanaging APIs over multiple releases(plenty of) warning of changesprovide 1 release of overlap2 full releases before a change removed as minbackward compatibility layersautomated testing tools that identify or convert calls to depricated APIsRelease Managementestablishing a baselineall the versions of the different components in the productversion namerelease managementwhat you're releasingpatchfull releaseepartialwho you're targettingbetageneral releasewhy they want itnew featuresperformance improvementsbug fixesdeal with 'version 'skippers' - try make releases attractive to large user baserelease identificationfull or complete releasespartial releaespatch releasesvariationsRelease Management Influences on Tarchitecturerecreate everythinguse existing solutions and infrastructureput version into architecture as early as possiblecomponents should know their dependenciesmessages and protocols should be versioneddatabase and tables should be versionedinternal components should understand external verssionssupport and testing implications on patchesserial numbers, registration and activationin addition to controlling usage can see what users are using what featuresregistration means more targeted marketingactivation tied to a machine fingerprintSecurityviruses, hackers and piratesmanaging risk - cant eliminatesee no evil, speak no evilneed to consider ...digital identity managementtransaction securitysoftware securityinformation securitydigital identity managementauthorization - whoo can do whatlink to LDAP, ADRBAC - Role Based Access Controlfile system ACLsauthenticationconsider if open or closed systemtransaction securityauditabilityproof of legislative compliancecould spot check volume of activity from individual sourcesuse audit information as product featureanalyse system use for markettingintegrityuse hashes on data to valid untamperedencrypt hash keys rather than all dataconfidentialityencryptionSSLalgorithms stronger than SSL, but not as commonaccountabilitynon repudiationstrength in accountability relates to strength in authenticationsoftware securitytechniquesserial numbers and activationsdigital sign licenses to combat reverse enineering code and creating illegal licensesprotect validation codelicense check more complex than code checking boolean valuestore something encrypted that has to be executedhardware bindinguse hardware finger printuse physical device - dongle / usbdongle strong solon but costly to managecost benefitremember lost people using illegal copy of s/w prob wouldn't use if no copymaking secure may impact legit userscost consideration to developmentobscurification can make dav/support more challengingeven certificate server can up op costsrisk impact considerationinformation securitysecret algorithms or secret keysback doorsmaybe convenient for support, but real security risknot use durib supportsecurity and marketectureauthentication, business models and operationsregulatory impactindustry growthtrustdispute resolutionUpgradeChapter 12like installation only worseupgrade fearspain of rework e.g. reworking integrationripple upgrades - move other components that have been fine, more hardware neededdata 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 APIsnew features - cost & effort of learning to use them, motivation for adoptioninaccessible system - impact of needed down timereversion - hoow to rollback to the older version of the system in the event of a problemmaking upgrades less painfulreview install process - principles essentially the samekeep the need for upgrades to a minimum, awareness of the market rhythmsupgrade readyness - check what needs to be changed, only change what is necessarydata migration - consider the steps needed and data being both structured and semi structureddeal with customers in very controlled and subtle mannerquietly remove features if they not used and not needed. deployment info can indicate thispreserve user preferences and configuration during an upgradehow to handle upgrading from previous versionsgo from ver-1 to ver and repeat to cross multiple versionsselect particular releases (commonly used) and provide multi version jump in 1 stepfor multi version jumps, customer might have to do ver-1 to ver before doing multi ver jumpdoes the new version need to coexist with existing version or is it a replacementmarket maturity and upgradesearly adopters are more tolerant of upgradesearly adoption tolerance doesnt translate to pour upgrade process tolerance - poor upgrade will result in early adopters stop adopting earlyultimately more money will be earned through upgrades than the initial releaseChecklistsSoftware Architecturedependencies between subsystems clearly definedeach team member working on a subsystem that they find interestingeach team member working in a way they believe will improve productivityarchitecture is profitablecurrent release is focused on issues of evolution or maturityunderstand the level of technical debit incurred in the system, can identify tech debitproper compliance with all in-licensed componentsarchitect can articulate principles driving the choices madeteam right size to accomplish goalsProduct Developmentdefined means to capture requirementsproduct managers represent voice of the customerorganisation has means to kill a product if necessaryunderstand our competitors & know what is needed to winunderstand who we building the product for, and who we're selling tohave a useful change management protocoldifference between markitecture and Tarchitecturehave a markitecthave a tarchitectbug database with cliassificationstech staff meeting customers know how to interact with themcontext diagrams for the systemsBusiness and License Model Symbiosisteam members can define business models in use and being consideredlicense agreements congruent to business modellicense agreeent specific to rights for the customerchosen appropriate approach to enforce business modeltechnical implications of changing business models understood and clearly communicatedPortabilityeach platform has sufficient dev, qa, support and sales resourcessufficient time perform ill tetingeach platforms market share is known so cost effectiveness can be identifiedroadmap factors in major platform releasesmarket driven matrix to target testing effortsDeployment Architecturematch target marketability to meet expected workloadsoperational policiesconsidered sales modelsconsidered sales cyclesinfrastructure investmentcustomer inputIntegration and Extensionsupport material is availableconsideration of own solution integrated with other solutionsnaming conventions etc to make API consistencyperformance and resource implications of using extensions/APIsBrand and Brand Elementsall brand elements identified and approvedbrand elements internationalizederror, diagnostic and log files have been checked and approvedtrademark and registered mark used properlybrand elements can be replaced by partner?usabilitytested all key functionality for usabilitycapture conceptual model along with user mental models, system metaphorssystem metaphors are clearmeans for sales/marketing to measure performance for reference figuresknow when and how to throw h/w at the problemInstallationdefined how subcomponents will be handledhow installation meets rlicense requirementsdefined required skill to work with installationway to verify correctness of installationprocess adheres to platform guidelinesavg user can install without referring to manualtested bot install and unistallUpgradesconsidered 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 processdefined how to rollback the upgrade process?tests included to confirm successful upgrade?configurationhave we defined all sys configuration?security implicationsaudit of changes?documentation of allowable valuesdocumentation of implications of valuesLoggingDefined the purpose of each log fileLog file utility suitable for target usersEliminate dev specific logsFollowing UI principles for I18NLogging is portable like rest of systemEasy to parserelease managementchapter 15know who were targeting releases toprocess for identifying releasessku's if requiredSecuritychapter 16identified levels of security requiredLogsi want to know what is happening (goals)Debugging and error logsError recovery - know what is wrong to apply corrections to envPerformance tuningCapacity planning - insight into resource usageInsight into how users are using the systemConfig being used in operationSystem statusnot just the facts - not just when, what, and steps. Otherwise not sufficient insight laterPerformance hit for recording all the info in and out of every method etcTime to execute methodsDetails such as the number of connections used/createdFeatures used and not usedlog format & managementformatI18n of logs allow users easier useStart log entries with time stampMake log traceable to location in codeLog transaction idsmanagementstandards & librariesLogging with flat files offersEasy parsingEasy readingKeep in mind ...Need to be in sensible locationSensibly namedDon't put unreadable content into filesIf multiple files I'd to link them togetherManagementSupport for dynamically change log thresholdsPer thread logging - ensure different threads distinguishedLog levelsAll exceptions are loggedEnsure logs can be removedLog content can be sensitive so consider securityAutomatically forward - feature to get info together and sendStandardsW3C extended log formatCommon log format for web serversPlatform dependent formats such as windows event logspostprocessing log dataCompact log files or rollingMultiple files - synchronise contentLog viewerslogging servicesInternationalization unique Ids for each entryConsolidate logs across multiple severs to get unified story of executionUnified time orderingCan configure where to put log filesConfigurationChapter 13configurability - an element of usabilityCritical that config is usableHard to use config increases operating costsHard to tune - result lower performance, so higher costResults in higher support callsMore complex professional servicesIncrease in customer frustrationArchitecture can contribute to ease of configurationsystem contextContextual informationLocation of key files - directories - use of well known locationsBootstrapping data - known locations for files to provide configuration necessary for app boot processPortability switches - settings to switch between different DBS for exampleCompatibility controls - behaviour switches to support backward compatibilityPerformance parameters - system tuning impacting performanceToo many configuration options - can get over complex to setup.initialise vs executionConfigure during initialisationConfiguration to impact executionStartup settings - meaning possible need to restart to get configuration appliedModifying logging settingsImplications of high availabilityPassing configuration info to built in componentssetting the valueWho should have the permissions to set configUserRole constrainedExpert systemAnother systemAudit trail of changesHuman readable - easyDb - audit trail and permissionssetting the right valueMore params - increase the risk of miss useNeed to ensure known legitimate values and impact of changesMake config files self documentingconfiguration parameter heuristicsmake config files easy to modify, even when the rest of the system is downstore all data in a single location - if you think multiple locations is necessary then justify it to a support personuse ann obvious locationplatform specific files such as .ini are fine, but why not use xmlbe careful of things like registry entries - they arent so portablemake config information easy to capture and forward to supportmake it hard to get values wrong. if they are wrong stop and tell user, or fall to default valuesabstract management of config to separate pieces of software such as a sys context objectobjects structure possibly againstper computerper service instanceper userper selectable profileobjects incorporate semantics of config valuesInstallationChapter 11out of the box experience (OOBE)from the experience of retrieving media or downloadingclear goal defined for install - e.g. average user able to install. What is average user?customer fearsclassic customer concernstoo hard - e.g. shutting down processes in a specific waytoo complex - avoid sequences of complex stepstoo easy to break something - shouldnt leave the system in an unstable or unknown stateunknown 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 infochallenges in addressing installation:subcomponents - demand the user to preinstalll, or install as part of solutionin license requirements - licensed dependencies may dictate constraints needing to be addressed by installationneed to include EULA (End User LIcense Agreement) & need to acknowledge agreement before continuingbiz model - e.g. per user, volume, server specpartitioning installation responsibilities - which actions should be done by components & consistency in approachensure that the environment is suitable for the installation - e.g.environment typeenvironment restrictions (home/office)how app is acquired - rom / download etcwho is installing, and their permissions (roles)get devs to do install before they're fresh to producthow to installinstallation data collection & precondition verificationfree spaceconnections DB, net etcconfiguration of required entities (e.g. SQL Svr installed ok)access rights - can fail install, difficult to deal withInstallationprovide indication of progress - even in command linevisual map of steps and progresstrack progress in as log file (allows for chance to provide recovery - min allow support to perform diagnosis)make install interruptablemake process self awareability to auto resumeassumption that installation will get undivided attention - wrong particularly in enterprise envfollow platform guidelinesexception is multi platform installationavoid forced rebootsavoid unnecessary questionspost installation confirmationconfirm installation done correctlyverify files in correct placespossible self testslog resultspost install cleanup e.g. temp filesread me notesuser registration (with incentive to do so)finishing touchesthey don't read the manualnot an argument for not providingprovides QA with concrete description of expected sys behaviourwell written manuals more likely to be readwell done roadmap can help give indication of efforttest the install & unisintallnot unusual for QAs not to properly test (un)installin agile envs - should include installer from iteration 1make sure various optioons exercised in QA - users willautomate - process to assess pre and post installl conditionstest against platform guidelinesmake installation scriptablepoor install costspossible loss of businessmore support calllsenterprise soluttions - comng with provision of field engineers to install - may not be profitablebuilding dependency matrix may help determine all possible problemsUsabilityusability is about moneyFundamentally deliver a solutinUnderstand customer needsFrom considerations such as data through putMeans to establish user needsObservationInterviewsQuestionnairesDirect experienceHelp by ...Reduced training costsReduced support and service costsReduced error costsIncreased productivityIncreased customer satisfactionIncreased maintainabilitymental modelsUnderstand tasks and then will understand models of the taskmetaphorsWell chosen can help architectureTake into account how product is to be presentedBook - Designing Object Orientated User Interfaces (Collins 1995)tarchitectural influences on UI designSeparation of layersInfluencersCardinalityGreater nos means more advanced visualisation needsFeedbackIndication to user of activityResponsesProgress metersEarly validationControlling acces to options depending on stateExplicit user modelsSo easy for users to understandWorkflow supportReflection of good practiseWizardsTransaction supportDesigned to support user interactionError responsesInternationalisation & localizationCancelling requestsUndoing requestsCompensating transactionsCan't always undoTimeoutsNetwork availabilityReliabilityPerformanceBandwidthShared resourcesFailure recoveryneed for speedwhat a maketect really wantsPredictable performance over pure speedNumber of confident sessionsHow many transactions on defined hardwareCase studies to help answerPerformance stats regularly recalc'dresponding to the userProvide means to cancel tasksProgress indicationsFeedback eliminates unnecessary workperformance and tarchitectural impactMove from ststeful to stateless potentially ups latency, but better scalingMore hardware not an excuse for sloppy developmentCourse grained transactions will helpUnderstand threading performanceUse profiling to helpHandle normal operations and failure conditions separatelyCache resultsconsider processes being able to run in the backgroundself service capabilities eg tills, atmstake advantage of development envs idiomsreduce work - if capability implemented try make use of itBrand & Brand Elementsbrand elementsnamesphysical location of system componentsfolder naming for element storagesuggest company name/product name/component nameallow for the addition of new componentssale of single componentsgood meaningful namesrecommend not let devs namemarketing - positive associationsinternationalization considerationsconfiguration and logs may contain brand elementserror, diagnostic and info messages may contain brand elementsnames are volatile, especially in 1st releasegraphicsicons and splash screensmay need outside designer supportbrand coloursvoice brandinguse of trademark symbollegal rightsregistration of trademarkslogansbranding elementsavoid changing when internalizingbrannded elements can be far reaching so changing can create significant workwhen to use tm symbolmanaging in-license brandsproduct areas to consider when changingsubsystem namessource code repositoriesQA and tech support tracking systemsphysical location or componentsnaming and structure of APIserror, information and diagnostic infoQA and auto testingsales collateralcare if using other branding elementsProduct DevelopmentChapter 2Product Development Processesconcept proposalget business data together to support proposalfeasabilityproduct proposal/business planjustify the productharden requirementscan be divided into segmentsmarket analysisfinancial analysisproduction descriptioncompetitive annalysis & product differentiationproduct positioningmarketing strategychannel strategysupport modelimpact analysis, busiess model, revenue forecastcost analysiscritical risksproduct extensions and futuresdevelopment planget requirement prioritiesmarketing needsdevelop architectural conceptsget clarity of requirementsidentify documentation and other artefacts neededtake into account supporting activities e.g. QA and tech authordevelopmentproduct development starts to look at after development is completedevelopment process based on several factorssizegeographic distributionproduct characteristicssee Journey of the Software Professional for more detailprocess overlaps e.g. development, alpha testing, tech doc etcfinal quality assurancemeasurements to allow decision of when to shipshipping decision is a collaborative activityin addition to testing QA offersmonitoring and enforcement of dev processescollecting & publishing testing metricsassist dev with rot cause analysishelp support wit workaroundshelp support replicate customer issuessupport daily build process and source codesupport dev and design to aid testingcontributing testing requirementseasy to blinded by automated tests - e.g. automated test cant assess impact of removing h/w if you have a h/w dependencyprelaunchmaybe parallel to other processeslaunchprocesses (it isn't like that)product development may be waterfall like, that doesn't bind development process to non agile approachesstage gated approaches doesn't equal waterfallnot a lll stages are equalaugmenting the product development processsuccessive freezingprocess of focussing, then stopping things becoming a moving targetrequirementsnot stopping development - but agreeing breakpoints for change controlchange management protocolsformality of allowing change controllenient = noneenables proper preparation for changerecycle binif bitten off too much - put stuff hereCrucial Product Management Conceptsfour Ps of marketingproduct (offering)pricenot correlated technical difficulty!best is when aligned with customer value perceptionplace (distribution channel)direct through web?through partners?promotion (advertising and marketing)markettotal available markettotal addressable marketmarket segmentationS shaped curve of adoptioninnovators, late majority, laggards etccan impact architecturewhole productgeneric productexpected productaugmented productpotential producttarget productposition and positioningbrandmain messagerolemanaging projects developing a productseparation so that failing projectscan be pulledsupporting the process of marketingMRDs - Marketing Requirements Documentpricing etcbig picture perspectiveSoftware ArchitectureChapter 1Why Architecture Matterslongevitystabilitydegree & nature of changeprofitabilitysocial structureboundariessustainable, unfair advantageCreating an Architecturechallenge of providing vs time to marketPatterns and Architecturejump start architecturedraw on existing knowledgeArchitectural Evolution and Maturation - Feature vs CapabilityArchitectural Care and FeedingTechnological Currencykeep with tech improvementseasy to keep upto date if regularly managedcould have licensing/support issues if not managedTechnical Debitpragmatism for getting a release outif not managed - then cost escalates - cost + interestif not managed can lead to need a rewriteKnown BugsLicense Complianceprinciplesencapsulationinterfacesloose couplingappropriate granularityhigh cohesionparameterizationaka configurabilityIoCdeferraldon't make decision til need togood architecture limit impacts of deferralcreating architectural understandinguse of architecture diags to communicateappropriate use of modelsavoid need to resort to codethe teamability of team to support architecturekeep team small when creating architecture - benefits from highly cohesive teamgrow team out from this initial core ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download