How to architect software for business
September 17th, 2020 by Nick Alston – Staff Engineer
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
Share