Architect’s Guide to Bootstrapping a Software Project

When the opportunity arises for development of a new application, or the modernization of an old one, the architect is faced with a myriad of often conflicting choices. There are so many choices there's a significant risks of falling into analysis paralysis or simply defaulting to safe solutions. (“No one ever got fired for choosing IBM.“) On the other side of risk adversity lies RDD - Resume Driven Design - where all the newest, riskiest technologies are thrown into the mix just so the app development will be hot and sexy.

This session explores some architectural trade-offs and lays out a road map for successfully architecting a new project, with key emphasis on targeting accidental complexity and launching the project on the right course while preserving plenty of alternatives.

Suppose you've just been assigned to be the architect on a new development project. The new CTO has no love for the status quo process the organization has been (not) delivering software. (Not delivering software is exactly why there is a new CTO.)

You've been emailed half a dozen Powerpoints outlining the business needs. It's clear the business stakeholders care about two things: Time-to-market and functional effectiveness. Otherwise, they don't care about any of the technical gobbledygook the developers usually use when discussing projects. The developers love all the new languages and technologies and will hate implementing some boring CRUD app for the 99th time.

After years of yearning for a greenfield project, now's your chance to shine - or fall on your keister. Where to start? In this session, we'll develop an architectural road map for successfully bootstrapping your new project without getting yourself boxed into a bad place.