3 ms·

FWIW, I worked at a trading firm that had a very tidy and long-lived ESB that I found to be a joy to work with. -but- My experience there 100% confirms what y

FWIW, I worked at a trading firm that had a very tidy and long-lived ESB that I found to be a joy to work with. -but- My experience there 100% confirms what you say about it not being something that scales well. It was a relatively modestly sized firm by headcount, as trading firms go, and there was a corporate culture of absolutely intense inter-team and inter-departmental communication. One absolutely would not dream of subscribing to an event stream without first talking to the team that maintained the program that published it. Any changes to the event stream - both the grotty little details about what was being published and how, and the grotty little details about what was being consumed and how - would be preceded by a discussion among all the people who were working with it, to make sure that everyone involved continued to have a complete picture of the interactions involving it. That level of communication, which I do believe was essential to the bus's long term success, just wouldn't scale to a large company. Nor could it have been maintained at a company that had a more relaxed attitude in general. Nor could it have been maintained at a company where programmers are allowed to believe that most of their time at the office can be spent with hands on a keyboard.

the_af 6y ago
> That level of communication, which I do believe was essential to the bus's long term success, just wouldn't scale to a large company What would though? An ESB could be a way to enforce a standard and slow down gung-ho devs & teams using ad hoc solutions for every problem. But say an ESB is not the solution -- what is? As the company grows, overhead and friction become more important. I'm not sure "every piece connecting to every other piece in whatever way" would help with scale, rather than compounding the problem...
- mumblemumble 6y ago
  IMO, there is no software solution, because it's not a software problem, it's a social problem. As far as specific things to try go, domain-driven design is my personal favorite off-the-shelf mental framework for dealing with these sorts of things. Especially the concept of bounded contexts. Embrace Conway's Law; recognize it's not a criticism, per se, it's also a scaling strategy.
  - the_af 6y ago
    Fair enough. I agree partially: it's a social problem. Thing is, software engineering deals with social problems too: those related to development. I've never seen DDD successfully used in any company I've worked in, but that's probably a shortcoming of my own experience. (Likewise, I've never seen TDD or Agile or lots of things people often mention in their blogs successfully used. Again, this is probably my own problem!). addendum: to be fair I've never seen a completely working ESB either. Always a plan to build or deploy one, never the finished thing ;)
    - deleted 6y ago
      [deleted]
    - mumblemumble 6y ago
      I doubt it's your own problem. The thing about methodologies like DDD and Agile is that they're not just a development practice. They're also (in my opinion much more importantly) frameworks for how the entire company interacts with the dev team. I see them fail more often than not, too, and one thing that's consistent about every failed implementation I've witnessed first-hand is that non-developers who are involved in or influence product development weren't engaged with, bought into, or properly trained in the framework.

the_af 6y ago

> That level of communication, which I do believe was essential to the bus's long term success, just wouldn't scale to a large company What would though? An ESB could be a way to enforce a standard and slow down gung-ho devs & teams using ad hoc solutions for every problem. But say an ESB is not the solution -- what is? As the company grows, overhead and friction become more important. I'm not sure "every piece connecting to every other piece in whatever way" would help with scale, rather than compounding the problem...

mumblemumble 6y ago
IMO, there is no software solution, because it's not a software problem, it's a social problem. As far as specific things to try go, domain-driven design is my personal favorite off-the-shelf mental framework for dealing with these sorts of things. Especially the concept of bounded contexts. Embrace Conway's Law; recognize it's not a criticism, per se, it's also a scaling strategy.
- the_af 6y ago
  Fair enough. I agree partially: it's a social problem. Thing is, software engineering deals with social problems too: those related to development. I've never seen DDD successfully used in any company I've worked in, but that's probably a shortcoming of my own experience. (Likewise, I've never seen TDD or Agile or lots of things people often mention in their blogs successfully used. Again, this is probably my own problem!). addendum: to be fair I've never seen a completely working ESB either. Always a plan to build or deploy one, never the finished thing ;)
  - deleted 6y ago
    [deleted]
  - mumblemumble 6y ago
    I doubt it's your own problem. The thing about methodologies like DDD and Agile is that they're not just a development practice. They're also (in my opinion much more importantly) frameworks for how the entire company interacts with the dev team. I see them fail more often than not, too, and one thing that's consistent about every failed implementation I've witnessed first-hand is that non-developers who are involved in or influence product development weren't engaged with, bought into, or properly trained in the framework.