How to architect software for business

What is software architecture?

Metaphor for making development decisions

• Blueprint of the software
• Turns the abstract into concrete systems and tasks necessary to be built

Generally affect things that are hard to change

• Do we use Fortran or Typescript?
• Should payload be an array of objects, or an object with many arrays?
• What does the data model look like?

Decision making around non-functional requirement prioritization

• Scalability?
• Performance?
• Extensibility?
• Reusability?

How do I get better at it?

Communication Skills

• Verbal and written
• Buy-in from stakeholders AND engineers is critical

Able to predict the future (kind of)

• Seeing potential pitfalls for specific paths
• Knowing what will build off of what you're designing now

Experience

• Seeing previous successes, and probably more importantly, seeing previous failures

Confidence

• You can do it.

Why is it different for business?

• Communicating with many different stakeholders
• Businesses may have different priorities
• Contractual obligations
• Financial concerns
• Unannounced plans
• Existing software is likely not ideal for ideal architecture
• Interrupts can and do happen that alter your course
• Time is especially critical

Practice Makes... Above Average

Turns the abstract concept into practical experience

• Architecture is not something I think you can start on your own
• Experience pitfalls, and successes

Learn from EVERYONE

• Anyone can teach you something, find a mentor, find a person with different talents than you, watch and learn
• Listen to and leverage other ideas
• An idea coming from three peoples’ best idea is almost always better than one coming from an individual

Where do I begin?

Abscract components

I need a concept for managing assets for the frontend

• Part of an existing service?
• New service?
• 3rd Party service?
• Service?

Iterate

• Nothing is perfect the first time, and nothing is perfect the 400th time either
• Know when you can cut a “final” architecture for something

Know it all (as opposed to learn it all)

Understand the system broadly and holistically

Understanding interactions helps you avoid pitfalls

Knowledge is confidence

You set the work for the future and you need to explain the work to many different people

You will still be wrong, no one is always right

• Failure is critical to improvement
• Be accountable

Soothsaying. Crystal Balls. Time Machines.

Think 𝓧 months out for new features, or problems

• Never block yourself with decisions now that you already know is coming later
• Try to never block yourself with decisions now that you think are coming later

𝓧 is incredibly variable

• Company values/culture/speed
• How important is the feature as a whole? Is new work dependent on this? Will it ever be touched again?
• Is there already something on the roadmap that may leverage this?

Most Important Things

What non-functional attributes are critical to the architecture?

• Scalability, Performance, Extensibility, Reusability
• All of these could be valuable, but if everything is most important, nothing is.

Leverage known restrictions, hunt for unknown restrictions

• A completely green field with open space to work sounds appealing, but is challenging.
• Restrictions breed creativity” - Forcing function
• Sniff out engineering constraints with your knowledge