4 ms·

A lot of technical architecture comes down to minimizing complexity. When considering an approach, ask "how can we make this simpler?" As a matter of process

A lot of technical architecture comes down to minimizing complexity. When considering an approach, ask "how can we make this simpler?" As a matter of process it is important to consider many different approaches together with the team, and weigh benefits and drawbacks of each approach in order to make the best decision. Another big part of the job is to build and promote a shared technical vision among the team. This can involve establishing a technical roadmap, and principles/ethos which will be most effective if arrived at in a collaborative manner.

mateuszserafin 6y ago
Or putting in other words - keeping technical debt in check (as it comes mostly to non functional requirements)
kakwa_ 6y ago
Architecture is also really useful in another regard: making the right (or at least "good enough") decisions on things that will be really painful to change later. Think for example the choice of programing language or the DB technology used. Architecture must strike the correct balance between vague guidelines and over-specification upfront. It should provide a framework which ensure homogeneity between components without restricting the teams/developers excessively. On this subject, I found this presentation (by Stefan Tilkov): https://www.youtube.com/watch?v=PzEox3szeRc https://www.youtube.com/watch?v=PzEox3szeRc Also, I'm currently reading "Designing Data-Intensive Applications", which is quite interesting and full of insight on the architecture trade-offs for data management and querying.
- bluGill 6y ago
  Note that sometimes the right DB is one specific one. Other times it is enforcing everyone use a DB abstraction so that you can switch DB. If you choose the later make sure you have 3 databases at all times to enforce using the abstraction. Ideally one isn't sql. Likewise sometimes you choose the language (or maybe two), sometimes you choose an inter language communication protocol and allow any language. Either can be good or bad. The right answer for you is important. Some choices above are hard to undo if you are wrong. However the hardest to undo often have significant advantages if it all works out.
  - kakwa_ 6y ago
    Moving from a DB engine to another, even if technically possible (right abstractions and everything), is often extremely painful once you have a few years of data. (I'm currently involved in migrating quite a few large DBs, and it's a pain for everyone: SREs, support teams and the customers). But yes, there is no "one size fits all", it depends pretty much on how your org is operating.
    - bluGill 6y ago
      That isn't the only reason to support more than one engine. Sometimes you don't need to move data to change the engine. If you sell a product that needs a database you probably want an abstraction so you can use the customer's database and schema.
  - montroser 6y ago
    I agree with the idea that you should take most seriously the decisions that will be hardest to undo. However, using a database abstraction layer in this way is counter to optimizing for simplicity, and in a way is not making a decision at all. If you are using a database abstraction layer so thoroughly that you really can switch between different database implementations, then you are almost certainly not leveraging the strengths of any underlying database engine to begin with. So you are limiting your performance, at the same time as introducing complexity.
    - bluGill 6y ago
      That is exactly the trade off. Which is why sometimes it is wrong despite the obvious advantages of being able to change
barrkel 6y ago
Or if you can't minimize complexity - because the problems are irreducibly complex - try and contain and partition the complexity, so that there's a limit on the complexity that developers need to be aware of when working on any given area. Complexity partitioning is fractal, from functions to objects to modules to services to deployments. The architectural focus is higher up the stack. Avoiding complexity spillage, where distributed areas of a large application share global invariants, is a challenge, particularly when trying to scale up the development team, which will force one's hand on splitting out modules and services or service-like things (e.g. FaaS jobs).

mateuszserafin 6y ago

Or putting in other words - keeping technical debt in check (as it comes mostly to non functional requirements)

kakwa_ 6y ago

Architecture is also really useful in another regard: making the right (or at least "good enough") decisions on things that will be really painful to change later. Think for example the choice of programing language or the DB technology used. Architecture must strike the correct balance between vague guidelines and over-specification upfront. It should provide a framework which ensure homogeneity between components without restricting the teams/developers excessively. On this subject, I found this presentation (by Stefan Tilkov): https://www.youtube.com/watch?v=PzEox3szeRc https://www.youtube.com/watch?v=PzEox3szeRc Also, I'm currently reading "Designing Data-Intensive Applications", which is quite interesting and full of insight on the architecture trade-offs for data management and querying.

bluGill 6y ago
Note that sometimes the right DB is one specific one. Other times it is enforcing everyone use a DB abstraction so that you can switch DB. If you choose the later make sure you have 3 databases at all times to enforce using the abstraction. Ideally one isn't sql. Likewise sometimes you choose the language (or maybe two), sometimes you choose an inter language communication protocol and allow any language. Either can be good or bad. The right answer for you is important. Some choices above are hard to undo if you are wrong. However the hardest to undo often have significant advantages if it all works out.
- kakwa_ 6y ago
  Moving from a DB engine to another, even if technically possible (right abstractions and everything), is often extremely painful once you have a few years of data. (I'm currently involved in migrating quite a few large DBs, and it's a pain for everyone: SREs, support teams and the customers). But yes, there is no "one size fits all", it depends pretty much on how your org is operating.
  - bluGill 6y ago
    That isn't the only reason to support more than one engine. Sometimes you don't need to move data to change the engine. If you sell a product that needs a database you probably want an abstraction so you can use the customer's database and schema.
- montroser 6y ago
  I agree with the idea that you should take most seriously the decisions that will be hardest to undo. However, using a database abstraction layer in this way is counter to optimizing for simplicity, and in a way is not making a decision at all. If you are using a database abstraction layer so thoroughly that you really can switch between different database implementations, then you are almost certainly not leveraging the strengths of any underlying database engine to begin with. So you are limiting your performance, at the same time as introducing complexity.
  - bluGill 6y ago
    That is exactly the trade off. Which is why sometimes it is wrong despite the obvious advantages of being able to change

barrkel 6y ago

Or if you can't minimize complexity - because the problems are irreducibly complex - try and contain and partition the complexity, so that there's a limit on the complexity that developers need to be aware of when working on any given area. Complexity partitioning is fractal, from functions to objects to modules to services to deployments. The architectural focus is higher up the stack. Avoiding complexity spillage, where distributed areas of a large application share global invariants, is a challenge, particularly when trying to scale up the development team, which will force one's hand on splitting out modules and services or service-like things (e.g. FaaS jobs).