small increments within existing limits, aiming for long-term transformation • Introduce new ideas (tech, method, process) into existing projects and development efforts in a bottom-up fashion • Avoid anything too disruptive • “Innovation coin” to limit number of changes • Slow, but possibly lasting change • Incorporates existing staff • Minimizes risk related to disruption • Risk of little effect in terms of architecture transformation
tried out in isolation to gain experience and create convincing stories • Decouple technical innovation from existing projects • Apply new tech and architecture approaches to smaller sample projects • “Design thinking“ and similar methods • Minimize risk to existing efforts • Possibly little effect
“legacy engineers” to “ninjas”1 • Existing Staff is trained, coached and allowed to work on projects to acquire state-of-the-art know-how • Intermediate steps are left out (e.g. from mainframe to cloud) • Staff may be extremely motivated or highly frustrated • High likelihood of employee churn (possibly desired) (1)please don’t ever use this unironically
used as role models to drive transformation • Follow architectural approaches that are used by (more) successful companies • Hire new staff with experience in tech (possibly former employees) • Possibly very convincing to business people • Risk of cargo-culting, i.e. mistaking correlation for causation
created using new architecture approaches in a completely separated organization • Create “innovation lab” or similar to drive business and tech innovation • Explicitly avoid any ties to existing rules and regulations • Risk of “lipstick on a pig” products • Risk of problems integrating new and old business models • Frustration for existing, “old- fashioned” staff
introduced as part of a business-driven project that has its own, non- tech related justification • Cost of architectural transformation as necessary part of development effort • Justification due to business-tech drivers (e.g. Cloud/SaaS, mobile) • Do the right thing and don’t talk about it • Chance (and challenge) to prove architecture benefits • Risk of hiding or playing down actual costs
used as a means to be an attractive employer • Pick “hot” technologies, i.e. those that interesting potential employees are interested in • Positive influence of new employees in terms of know-how, experience • Challenge of judging competence • Risk of frustrated developers
changes are driver for architecture and vice versa • Create organization and process with intended architecture in mind • Enforce architecture that leads to desired organization and process • Chance of most impactful transformation • High risk of frustration on all levels
stilkov
wa6sn
amixedcolor
yoshidashingo
okiyuki99
sioncojp
inariku
.png){kind=avatar}
masspeaks
birgitta410
.png){kind=avatar}
oidfj
sergicalsix
orimanabu
lynnandtonic
inesmontani
tammyeverts
keavy
tmiket
addyosmani
matthewcrist
jdejongh
jacobian
nikkihalliwell
shpigford
sstephenson
