Architect’s Guide to Bootstrapping a 

Software Project

About Me

1st Career

About Me

2nd Career

Architecture: "The things that are hard to change"

Or simply,

This talk is about application architecture, not as much enterprise architecture.

The important stuff, whatever that happens to be.

Ralph Johnson

Overview

  • People
  • Process
  • Product

The Profit

http://bit.ly/1SdTRYG

Marcus Lemonis

serial entrepreneur

gazillionaire

Project

Architects straddle the line

between technology and business

This guy was an architect

who didn't care about the business

People

Stakeholders

These are the people we need to keep happy

We may think stakeholders are like this:

... but the reality is far different

We can help them help us better.

We just need to manage their expectations.

Misleading stakeholders almost always

leads to a change in status.

And never forget the 2nd Golden Rule:

"He who has the gold, makes the rules."

Stakeholder relations

  • Don't take stakeholders for granted
  • Always think about their interests
  • Work to manage their expectations
  • Under-promise and over-deliver to delight them
  • Over-promise and under-deliver at your own peril

Project Managers

Project managers may seem friendly

but don't jerk 'em around!

Like stakeholders

we need to manage their expectations

It's far better to be transparent and open

than surprise them a week before release

Their success is driven by the project

not making them look bad

We need to mentor them a bit in the tech

to decrease the risk of misunderstanding

Project manager relations

  • Work to make them look exceedingly competent
  • Help them understand the limitations of the tech
  • Help them understand the inputs, processes and outputs
  • Never use their technical ignorance against them

Developers

Architectural thinking is all about trade-offs

Developers are generally engaged in tactical thinking about solving a problem in front of them...

without regard to the enterprise and architectural concerns

They should be thinking tactically while minding strategic goals

Architects know developers well

because we started out as developers

HBO's Silicon Valley

This background makes us ideally suited to

do it all wrong when working with them

"I'm the architect and you're just a developer"

"I'll do the thinking, you do the coding"

"I'll stay away, then parachute in to save the day"

Just remember the first Golden Rule...

Most developers really want to learn more

Create a culture of learning to foster a passion for our craft

They don't want to be talked at or down to

Create a collegial culture where everyone contributes and benefits

Developer Relations

  • Clearly define and honor architectural boundaries
  • Don't make decisions that add to developer's pain
    • Be an active coder to experience & alleviate their pains
  • Don't always try to prove you're the smartest on the team
    • Help make the developers smarter
    • Invite them make you smarter
  • Every day, groom them to take your job
  • Be the humble servant, not the master

Users

The sad user story

  • We rarely use our own software
  • BAs & Product Owners are often user proxies
  • Stakeholders may act as user proxies
  • We may never actually meet a real user

When real users are unavailable

Construct a persona for a typical user

Personas 

  • Imagine a particular user of the application
  • Be specific about that user's demographics and attitudes
  • What does that user expect?
  • What would delight that user?
  • What would frustrate that user?

We should always prefer a group of real users to personas

even though real users can be a pain in the backside!

Another thing about users is

they demand more, but hate complicated

User relations

  • Those pesky users make or break an app's success
  • Get to know some real users
  • Delight them when you can, but never disappoint them
  • Help shape their expectations
  • Remember: The customer is always right

Us

If I just think about it long enough, I can ...

... do a great Big Bang architecture design

http://bit.ly/1Sp3nby

Problem with an upfront Big Bang design is

we know least about the problem at start

 

  • Loosely coupled components are deployed
  • Features are released
  • Application is about routing between components

Favor an

evolutionary architecture

Defer architectural decisions until the last responsible moment

Venkat Subramaniam

Physician, heal thyself

  • Even if you are the smartest person in the room, don't keep trying to prove it to everyone

  • Help define, then accept, limitations of your role
    • No one cares on which line you think curly braces should go
  • Almost everyone cares why you made a particular architectual choice
    • Document justifications to avoid Ground Hog day anti-pattern
    • Accept that you will be constantly second guessed
  • In the end, your job is to help make everyone else successful
  • Be the humble servant, always grooming developers to take your job

Process

Decision fatigue refers to the deteriorating quality of decisions made by an individual, after a long session of decision making. It is now understood as one of the causes of irrational trade-offs in decision making.

https://en.wikipedia.org/wiki/Decision_fatigue

Decision Fatigue

The risk of a wrong decision is preferable to the terror of indecision.

Maimonides

Technical debt’s effect on software development is roughly analogous to friction in mechanical devices.

https://www.computer.org/csdl/mags/so/2016/01/mso2016010066.pdf

Friction

When you keep hitting walls of resistance in life, the universe is trying to tell you that you are going the wrong way. It's like driving a bumper car at an amusement park. Each time you slam into another car or the edge of the track, you are forced to change direction.

Suzy Kassem, Rise Up and Salute the Sun

Automation

If it hurts, do it more frequently, and bring the pain forward.

 Jez Humble, Continuous Delivery

Testing leads to failure, and failure leads to understanding.

Burt Rutan

development

Choose an agile development process...

There's less uncertainty about what we're doing

It provides mechanisms for addressing tech debt

Low friction, effective communications...

reduce # of decisions individuals have to make

Guide developers on patterns and practices

Like writing tests

and pair programming

Choosing the right languages & frameworks

to help decrease decision fatigue

All developers not the same

  • Some love JavaScript; others hate it
  • Some love DevOps; others hate it
  • Some love heads down coding; others love socializing
  • Some love writing tests; others hate it
  • Some will love you; others will hate you. 

Your job is to help make each developer successful.

In return, they'll help make you successful.

Don't sweat it.

build and deploy

How many environments?

Minimum of three: Dev, QA, Prod

Four would be better: Dev, QA, Staging/UAT, Prod

Discipline and feature toggles can alleviate need for staging

What does "environment" mean anyway?

Continuous Integration / Delivery

https://www.openmakesoftware.com/images/ReleaseEngineer/CI-CD.png

reduces decision fatigue and lowers friction through automation of the mundane

Bootstrapping decisions

Web services not UI

Dev

We'll assume we'll start with a layered monolith for now

Defer what you can and try to keep the cost to change low

Stage

QA

Prod

the power of hello world

HelloWorld.groovy

class HelloWorld {
    static final String DATE_FORMAT_PATTERN = 'MM-dd-yyyy'

    LocalDate currentDate
    String dateFormat

    String greet(String name) {
        name = name ?: 'there'
        currentDate = currentDate ?: LocalDate.now()
        dateFormatP = dateFormat ?: DATE_FORMAT_PATTERN

        String dateStr = currentDate.format(DateTimeFormatter.ofPattern(dateFormat)
        "Hello $name. Today's date is $dateStr"
    }
}

HelloWorldSpec.groovy

class HelloWorldSpec extends Specification {
    HelloWorld helloWorld

    void setup() {
        helloWorld = new HelloWorld()
        helloWorld.dateFormat = 'MM-dd-yyyy'
        helloWorld.currentDate = LocalDate.of(2016, Month.APRIL, 15)
    }

    @Unroll
    void "When providing a name, Hello #name will be output as #output"(String name, 
                                                                        String output) {
        
        expect:
            output == helloWorld.greet(name)

        where:

        name || output
        Jack || "Hello Jack. Today's date is 04-15-2016"
        null || "Hello there. Today's date is 04-15-2016"
        ''   || "Hello there. Today's date is 04-15-2016"
    
    }

    // more tests omitted
}

HelloWorldIntSpec.groovy

class HelloWorldIntSpec extends Specification {
    static ApplicationContext appCtx

    HelloWorld helloWorld

    void setupSpec() {
        appCtx = new GenericGroovyApplicationContext("classpath:Spring/Beans.groovy")
    }

    void setup() {
        helloWorld = appCtx.getBean(HelloWorld)
        helloWorld.currentDate = LocalDate.of(2016, Month.APRIL, 15)
    }

    void "verify Spring injected default pattern"() {
        
        when:
            String output == helloWorld.greet(name)

        then:
            helloWorld.dateFormat
            output == "Hello Jack. Today's date is 04-15-2016"
    
    }

}

Default date format is defined in Spring

What can I do with a few baseline decisions and three artifacts?

  • Document architecture, setups, and justifications in Confluence
  • Create JIRA epics and initial stories
  • Develop API and UI locally using selected tools
  • Verify Lint, CodeNarc, or other quality measurement tools
  • Create a Git repo to house it
  • Configure build job to build it and run unit tests
  • Integrate Slack webhooks informing channel of build failures
  • Verify remote build and test
  • Manually do artifact repo provisioning, then script it
  • Manually do DEV provisioning, then script it
  • Configure job to run smoke tests
  • ...

Product

Build - Measure - Learn

from the essential The Lean Startup by Eric Ries

The MVP [minimum viable product] is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time.

 Eric Ries, The Lean Startup

What architectural pattern should we use?

Architectural Patterns

This is typically a monolithic app

Architectural Patterns

Architectural Patterns

Architectural Patterns

Architectural Patterns

Architectural Patterns

This is the antithesis to the monolithic app

7 Principles of Microservices

Architecture Agility

The ability to respond quickly to a constantly changing environment

Microservices bring complexity

Microservices bring complexity

Avoid complexity until you really understand domain

http://martinfowler.com/bliki/MonolithFirst.html

Start with a monolith

Divide it along it bounded contexts

The disappearing monolith

  1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up​
  2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

​Martin Fowler, http://martinfowler.com/bliki/MonolithFirst.html

Always ask, "How will we test this?"

Measure everything

Process. Performance. Failure rates. Everything.

Minimize complexity by resisting RDD

RDD = Resume Driven Design

Finally, work hard and play hard

You will have earned it.

Summary

  • People
  • Process
  • Product

Questions?

Resources

  • People
    • ​https://en.wikipedia.org/wiki/Stakeholder_management
    • http://www.romanpichler.com/blog/10-persona-tips-agile-product-management/​
  • Process
    • ​http://gen2.ca/DBHS/Articles/TOK/DecisionFatigue.pdf
    • https://www.computer.org/csdl/mags/so/2016/01/mso2016010066.pdf
  • Product
    • ​http://martinfowler.com/bliki/MonolithFirst.html
    • Building Microservices, Sam Newman, O'reilly
  • Anything from Neal Ford & Mark Richards & Matt Stine & Venkat

All animated GIFs from giphy.com

Thanks!

Feel free to connect with me

  • LinkedIn
    • linkedin.com/in/jackfrosch
  • Twitter
    • @jackfrosch
  • Email
    • jackfrosch@gmail.com