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

Business and License Model Symbiosisrelates to chapter 4 of the book

common software business models time based access or usage

perpetual support, upgrades normally excluded maintenance fee typically 15-30% can create costs for supporting all versions if not

careful maybe required if product is embedded into larger

solution e.g. runtime libraries, hardware devices annual

effective from installation, or first use usually includes updates and patches tech support / consulting maybe additional renewal maybe automatic, renewal maybe different

price to initial purchase common for enterprise solutions

rental essentially same as annnual common in some industries e.g. software testing changing rental features may allow penetration into

smaller/lower cost markets may not include updates and patches - additional

contract for these subscriptions

same as annual/rental but with slightly different rights

common for backend services more likely to include patches and upgrades

what happens if user uses outside of period? grace period for payment? cut off usage- although very server track and charge for usage - creates complex

architecture demands e.g. like car rental per user license

volume seat licensing for enterprise contractual base - agree estimated volume

OEM Original Equipment Manufacturer

transaction measurable units of work could be each piece of executed software - known as tie and

die fees can be calculated different ways

flat fee percentage fees sliding fees (volume discounting) processing fees (post processing calculated fee

charged) ways of working out transaction value

prices reflects value price should reflect effort price to support positioning prices reflects competitive landscape pricing should be clear pricing reflects market maturity harder to raise the price, compared to lower for

same product metering

resource managed constraints

concurrent resource management eg concurrent users or sessions need clarity of user/session definition users not equal to sessions

identified resource management e.g. named users x out of y plugins active at once

consumptive resource management number of hours usage of a resource could define a resource - e.g. no times a function is

invoked need to enable understanding for user on their likely

usage consumption reporting on consumption

hardware software could be free - but hardware non functional

without s/w per cpu - or other h/w element - but problem when coming

to virtualisation proportion of revenue base

percentage of revenue created or costs saved need to agree comparative benchmarks agreement on calculated benchmarks need to consider min revenue gain/save not very popular as it compels customer to track details

unrestricted services offered based on-top of existing framework or OS services

software is free, but charge for each service e.g. email, spam filter

rights associated with business model clarity of rights figure 4.1 common matching of licensing to rights

architectural support for the business model time based access or usage

commonly dont disable but stop updates transaction

define a transaction possible challenges eg distributed transactions relationship between transaction and business model need an audit trail uniquely name transactions implications of transaction states, lifecycle and duration

metering authentication of users how many users counting concurrent users (not session) users gone or just inactive?

hardware

need architecture to capture appropriate info consider costs of the architecture on the customer implications of changes on revenue e.g. performance improvement

on hardware based licensing consideration as to whether or not to have copy protection scheme

- tighter hardware ties reduce rate of piracy eg game cartridges questions to consider

what is target market - what does it value what are your objectives relative to target market your business model effect of business model on tech architecture pricing model

enforcing licensing models honour system

still protected by contract law implications on relationship with customer revenue risk?

home grown license managers tend not to be industrial strength - therefore easy to defeat commonly needed for session based licensing in some cases this is fine and doesnt need to be iron clad

3rd party or professional license managers considerations for OS support check cracker web sites to determine license manager

strength how easy to integrate & volume capabilities operational requirements the license manager introduces license distribution capabilities/constraints

the client market maturity influences on the business model

emerging market - easy for force model on customers mature market - need licensing model(s) to allow max share and

revenue better to be able t support multiple models

considerations for license models different modules maybe licensed differently some licenses could be geographically constrained e.g. site license

(field-of-use model) period of license - month, quarter, year etc implications to license payments - e.g. SMB or SOHO perhaps needs

online credit card payment renewal support Technology In Licensing

chapter 5 Contracts

basics terms

usage or grant duration of term or other kkey dates territory - where llicennse ca be used

specific use - constraints oon application exclusivity - how much the licnesee may allow others to use

solution sublicense - can you license 3rd party solution with your

solution into another product termination - agreement withdrawal

from 30days to 1year possible notice of withdrawal possible financial clauses e.g. bankruptcy

renewal risk of false sense of security auto renewal - could pay too much or too little

fees/payment terms deployment restrictions non coompetition clauses access to source code e.g. escrow marketing - uuse of logos

get expert legal advise licensing risks/rewards of licensing elements of a solution

reduce, manage or eliminate complexity (taking solution from SME)

risk-reliance on 3rd party, if they evolve in different direction

risk-supplier changes focus meaning no longer got capability

risk-provider goes bust promotion of component based software

risk-s/w becomes to interwined in own solution to undo/replace

allow you to concentrate on the value add elements risk-configuration complexity increases risk-incompatible business models (from simple export

restrictions on the 3rd party lib) risk-can mitigate with licenses such as GPL

can obtain protection by licensing technology protected by patent risk-indemnity, legal exception from liabilities from using

the component risk-doesnt exclude you from 3rd party patent disputes

reduce time to market by reusing technology risk-doesn't always provide faster time to market - need to

invest time to leverage technology vendor is creating something of a higher quality than you can

achieve risk-presumption doesn't prove to be the case code may have been pushed & pulled a lot before reaching

arket vendor created components are lighter and consume fewer

resources e.g. memory risk-may prove to be heavier than expected

risk-may not be tuneable to own requirements may relieve some burden of technology currency - as vendor

continues to improve product risk-updates arent provided as quickly as needed risk-support dropped for elements or OSes

component is start of the art and use will future proof your application

risk-sounds like resume driven design licensing technology cheaper than starting from scratch

risk-calculation based on providing equivelent, but don't need everything considered in calculation

risk-license fee changes can destroy economics licensing components will reduce service and support costs

risk-of adding more problems and work arounds to address 3rd party

risk-if multiple 3rd parties who do you engage? Could result in infighting between your suppliers

when business models collide, negotiations ensue honouring license agreements

need to ennsure technical terms are understoood and clearly defined

APIs ca 3rd party app APIs be drectly exposed? support - how clients dealt with, directly/indirectly? Branding - can 3rd party logos be used etc

managing in-licensed technology create adaptor or wrappper e.g. JDBC

open source licensinghttp://www.opensource.org

license fees licensing economics

PortabilityChapter 6

perceived advantages of portability claim-we can address a new market segments

careful as platform alone doesn't provide full market segmentation

claim-demonstrates that we can meet customers idiosyncratic needs

reflects tech skill - not what customers want what if customer has chosen platform for specific features it

offers true drivers for portability

portable code is cool learning nuances of different versions of an OS can be

tiresome 1 or 2 early customer demand different solutions

business case for portability primary driver should be profitability consider the following points

cost of training developers,QA, support in developing and supporting multiple platforms

cost of purchasing hardware & software for each supported platform

testing time to ensure product works on a lll platforms complexity of multiple release cycles (testing as OS releases

occur) identify the following before adopting platforms

sufficient revenue for that platform take into account al costs inc dev, testing and support sufficient organisation resources to support all platforms impact of platform release cycles on own processs

creating portable applications use a interpreted language

interpreter insulates from OS differences if native language - ensure compiler available on all target

OS ensure devs know to isolate platform dependencies

use standards based persistent storage make business logic portable closer to the user means less portability

backends typically more portable UIs greater levels of differentiation, from resolution

onwards use XML for standardized interop comms between subsystems avoid hiding the power of a specific platform in the name of

portability if a platform is strong at something don't ignore it

matrix of pain remove configurations eg some combinations of OS and DB

don't warrant investment for support rank order configurations

level of use in market, i 1 in 1000 is it worth supporting?

what the most valuable customers using what are the combinations that will be most heavily

marketed what will be easiest to support what will allow you to achieve highest level of

coverage in testing make the final cut of supported combinations of platform

beware the promises you make - could end up with commitments to support combinations that aren't cost effective

Deployment ArchitectureChapter 7

deployment choices customer site

consultants often deploy of enterprise class supplier may subcontract to SI

traditional approach application service provider (ASP)

provides service of app may not offer tech support eg large enterprise solutions

managed service provider extends ASP model additional services to core app SLAs common

transactional (web services) not too common in enterprise presently likely to grow with growth of web services

customer influences on deployment architectures control and integration

customer need to control assurance of support when needed long term retention & mgmt of data consider this when looking at MSP and ASP increasing level of integration more likely to be on

customer sight data security/privacy and peak loads

type of data impact leakage risk considerations cost effectiveness - equip to peakload

costs and vendor confidence cost to lease less than purchase for level of use customer perception - secure etc? market viability market perceptions of approach

customer skills and experiences and geographical distribution deployment will dictate support skills needed if customer to host - need to impart capability to customer if outsourced - need ability to manage supplier

corporate influences on deployment sales cycle

time and no steps to realise a sale correlates to solution complexity and size if want shorter cycle consider ASP model once sale completed often want rapid deployment use xSP as stepping stone to self hosting

flexibility customer sit installation less likely to be unto date if not unto date need to support older versions

infrastructure investment how much investment needed for creating xSP offering

cash flow geographical distribution

support global - therefore language used in support service not price

choosing software deployment architecture

deployment architectures and distribution of work information appliance

hardware and software ease of linux as appliance os simplifies complex solution

deployment choice influence on software architecture flexible, parameterized, or no integration options

greatest demand when deployed to client site upgrade policy

customer site approach needs careful planning MSP and able to deploy more regularly and easily

data protection and access customer site = customer problem hosted - more complex and proceurual, evidennce etc

migration options future of consumer s/w

Integration & Extension customer control - driving force

you cant predicate, but can plan provision of integration points is planning for expected future

demands customers don't want "we can't do that" larger solutions built from multiple smaller solutions deliver more value by combining data with other systems increase switching costs - greater cost to move away from your

solution - realised by customer integrating your solution closely to their others

create a product ecosystem - e.g. other suppliers providing plugins solution

apis will also help test the system people adopting/supporting your API is commitment to you in the

long term layered business architectures - logical structures

user interface services layer domain model layer persistent data layer variations on a theme

creating layered business architectures integration & extension at business logic layers

technologies & locus of control integration through APIs

platform preferences - platforms have variations market segment preferences - markets show preference to

approach partner preferences naming conventions security & session data

apis with session id requirements are momre complex than those without

ability to manage sessions through interfaces expose only what customers need - expose more and

creates more work to maintain API stabilised over multiple releases

hard to predict API needs be prepared to take several releases to get right

extension through registration register components and drive extensions through callback

model means own app retains control similar to observer design pattern or through publish/subscribe model define registration model

define tech detail e.g. when and how use of configuration application restart provision of interfaces

define event model what events available when they occur notification format information provided in the callback

define execution control semantics calls are blocking or not thread considerations process controls

define resource management policies define error/exception protocols

integration & extension of persistent data views

decouples application/physical schema user fields

avoid cost/effort of establishing additional tools not semantically meaningful lack of proper data modelling

hook tables needs careful coordination in apps various layers identify events associated with DBs CRUD operations link to own data through common key use GUIDs not auto incremental fields difficult to sustain relational integrity can extend transaction execution time

spreadsheet pivot tables relies on strong spreadsheet products extract based approach

ETL and old scripts tell them whats going on

not very desirable in most cases by pass of validation rules failure to protect transactionality cost of schema changes to sustain backward compatibility

Business ramifications professional services

provision of expertise to integrate consider releationship to product managers consider working with SI

training programs potential to improve customer satisfaction potential to reduce support costs include training on integration aspects consider all possible audiences from users to SIs to orgs

building plugins certification

consider ... product ecosystem competitive edge currency

more technical shorter training life value needs programme to be sustained

professional recognition independent certification academic credentials

user community needs nurturing help understand how users are really using the product community website educational materials

unofficial examples additional knowledge base

mailing list user conferences

license agreements managing APIs over multiple releases

(plenty of) warning of changes provide 1 release of overlap

2 full releases before a change removed as min backward compatibility layers automated testing tools that identify or convert calls to depricated

APIs Release Management

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 in addition to controlling usage can see what users are using what

features registration means more targeted marketing activation tied to a machine fingerprint

Security 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

UpgradeChapter 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

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 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 Usability

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 ... Reduced training costs Reduced support and service costs Reduced error costs Increased productivity Increased customer satisfaction Increased maintainability

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

Brand & Brand Elements brand elements

names physical location of system components

folder naming for element storage suggest company name/product name/component

name allow for the addition of new components sale of single components good meaningful names

recommend not let devs name

marketing - positive associations internationalization considerations configuration and logs may contain brand elements error, diagnostic and info messages may contain brand

elements names are volatile, especially in 1st release

graphics icons and splash screens

may need outside designer support brand colours voice branding use of trademark symbol legal rights registration of trademark

slogans branding elements

avoid changing when internalizing brannded elements can be far reaching so changing can

create significant work when to use tm symbol

managing in-license brands product areas to consider when changing

subsystem names source code repositories QA and tech support tracking systems physical location or components naming and structure of APIs error, information and diagnostic info QA and auto testing sales collateral

care if using other branding elements Product Development

Chapter 2 Product Development Processes

concept proposal get business data together to support proposal feasability

product proposal/business plan justify the product harden requirements can be divided into segments

market analysis financial analysis production description competitive annalysis & product differentiation product positioning marketing strategy channel strategy support model

impact analysis, busiess model, revenue forecast cost analysis critical risks product extensions and futures

development plan get requirement priorities marketing needs develop architectural concepts get clarity of requirements identify documentation and other artefacts needed take into account supporting activities e.g. QA and tech

author development

product development starts to look at after development is complete

development process based on several factors size geographic distribution product characteristics see Journey of the Software Professional for more

detail process overlaps e.g. development, alpha testing, tech doc

etc final quality assurance

measurements to allow decision of when to ship shipping decision is a collaborative activity in addition to testing QA offers

monitoring and enforcement of dev processes collecting & publishing testing metrics assist dev with rot cause analysis help support wit workarounds help support replicate customer issues support daily build process and source code support dev and design to aid testing contributing testing requirements

easy to blinded by automated tests - e.g. automated test cant assess impact of removing h/w if you have a h/w dependency

prelaunch maybe parallel to other processes

launch processes (it isn't like that)

product development may be waterfall like, that doesn't bind development process to non agile approaches

stage gated approaches doesn't equal waterfall not a lll stages are equal

augmenting the product development process successive freezing

process of focussing, then stopping things becoming a moving target

requirements not stopping development - but agreeing breakpoints for

change control change management protocols

formality of allowing change control lenient = none enables proper preparation for change

recycle bin if bitten off too much - put stuff here

Crucial Product Management Concepts four Ps of marketing

product (offering) price

not correlated technical difficulty! best is when aligned with customer value perception

place (distribution channel) direct through web? through partners?

promotion (advertising and marketing) market

total available market total addressable market market segmentation

S shaped curve of adoption innovators, late majority, laggards etc can impact architecture

whole product generic product expected product augmented product potential product target product

position and positioning brand main message

role managing projects developing a product separation so that failing projectscan be pulled supporting the process of marketing MRDs - Marketing Requirements Document pricing etc big picture perspective

Software ArchitectureChapter 1

Why Architecture Matters longevity stability

degree & nature of change profitability social structure boundaries sustainable, unfair advantage

Creating an Architecture challenge of providing vs time to market

Patterns and Architecture jump start architecture draw on existing knowledge

Architectural Evolution and Maturation - Feature vs Capability Architectural Care and Feeding

Technological Currency keep with tech improvements easy to keep upto date if regularly managed could have licensing/support issues if not managed

Technical Debit pragmatism for getting a release out if not managed - then cost escalates - cost + interest if not managed can lead to need a rewrite

Known Bugs License Compliance

principles encapsulation interfaces loose coupling appropriate granularity high cohesion parameterization

aka configurability IoC

deferral don't make decision til need to good architecture limit impacts of deferral

creating architectural understanding use of architecture diags to communicate appropriate use of models avoid need to resort to code

the team ability of team to support architecture keep team small when creating architecture - benefits from highly

cohesive team grow team out from this initial core