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 processespatternsRelease ManagementChapter 15establishing 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 activationSecurityChapter 16viruses, 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 resolutionChecklistsSoftware 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 requiredUpgradeChapter 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 releaseLogsi 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 problemsUsabilityChapter 10usability is about moneyFundamentally deliver a solutinUnderstand customer needsFrom considerations such as data through putMeans to establish user needsObservationInterviewsQuestionnairesDirect experienceHelp by ...mental 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 it ................
................

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

Google Online Preview   Download