5 ms·

Layers in Software: From Data to Value

104 points by dedalus 7y ago

ericand 7y ago
Summarized well by these lines: > Back in the day, front end, back end, operations, and DBAs separated because they needed different skills. Now we accept that a software team needs all the skills. We group by responsibility instead — responsibility for business value, not for activities > We once layered by serving data to software. Now we layer by serving value to people. This is a nice narrative for the rise of developer products, where there used to not be a market.
- vvanders 7y ago
  Andy Grove's High Output Management(hate the name, like the book) also talks about this tension between teams that focus on the business unit and the horizontal teams that support(if I recall correctly he groups in marketing, finance, and others) the business units. You get large advantages in having teams built around specialized functions, however at the cost of lower cohesion. Business verticals will trade all sorts of advantages for that cohesion. There's tension in finding the right mix, the book covers it much better than I can but it's interesting to see parallels in tech stacks as well.
  - insulanus 7y ago
    > however at the cost of lower cohesion Is that cohesion within the team, or across teams (in the company as a whole)?
bvrmn 7y ago
> Interfaces between teams updated with every application change. Dev products do not solve issues of bad architecture. It will be same struggle but in more strong form.
mikece 7y ago
"Back in the day, front end, back end, operations, and DBAs separated because they needed different skills. Now we accept that a software team needs all the skills." If the problem domain is adequately handled by generalists that's not a problem. But in situations requiring specialized skills it means needing to rely more on specialty contractors who keep your system from crashing when you go past the complexity threshold. As a specialist contractor it's very much in my interest to promote teams with "all the skills" because it means I won't be wanting for work.
- dashwav 7y ago
  IMO the argument isn't that you have 5 generalists, but rather that you might have 1 FE engineer, 2 software engineers a DBA and a Devops engineer (or at least 5 Software engineers that are more or less 'specialists' in those domains) This allows you to have a self-contained micro-team that can approach each value-add opportunity from the perspective of the overall solution, without any of the bureaucracy of communicating with someone outside of the team.
gfs78 7y ago
Fluffy words. The developer version of the agilistas discourse.
bvrmn 7y ago
Also this comes to mind. Most of successful IT companies do not use external services for core components and prefer inhouse solutions.
Silhouette 7y ago
Software is more than CRUD applications for business automation, but even for those, I'm not sure how accurate the characterisation here is, particularly regarding external dependencies. SaaS/cloud/this-week's-buzzword has done well for a few very successful businesses, particularly the handful of giants providing the infrastructure it runs on, but outsourcing everything you can think of is hardly universal.

104 points by dedalus 7y ago

Summarized well by these lines: > Back in the day, front end, back end, operations, and DBAs separated because they needed different skills. Now we accept that a software team needs all the skills. We group by responsibility instead — responsibility for business value, not for activities > We once layered by serving data to software. Now we layer by serving value to people. This is a nice narrative for the rise of developer products, where there used to not be a market.

vvanders 7y ago
Andy Grove's High Output Management(hate the name, like the book) also talks about this tension between teams that focus on the business unit and the horizontal teams that support(if I recall correctly he groups in marketing, finance, and others) the business units. You get large advantages in having teams built around specialized functions, however at the cost of lower cohesion. Business verticals will trade all sorts of advantages for that cohesion. There's tension in finding the right mix, the book covers it much better than I can but it's interesting to see parallels in tech stacks as well.
- insulanus 7y ago
  > however at the cost of lower cohesion Is that cohesion within the team, or across teams (in the company as a whole)?

bvrmn 7y ago

> Interfaces between teams updated with every application change. Dev products do not solve issues of bad architecture. It will be same struggle but in more strong form.

mikece 7y ago

"Back in the day, front end, back end, operations, and DBAs separated because they needed different skills. Now we accept that a software team needs all the skills." If the problem domain is adequately handled by generalists that's not a problem. But in situations requiring specialized skills it means needing to rely more on specialty contractors who keep your system from crashing when you go past the complexity threshold. As a specialist contractor it's very much in my interest to promote teams with "all the skills" because it means I won't be wanting for work.

dashwav 7y ago
IMO the argument isn't that you have 5 generalists, but rather that you might have 1 FE engineer, 2 software engineers a DBA and a Devops engineer (or at least 5 Software engineers that are more or less 'specialists' in those domains) This allows you to have a self-contained micro-team that can approach each value-add opportunity from the perspective of the overall solution, without any of the bureaucracy of communicating with someone outside of the team.

gfs78 7y ago

Fluffy words. The developer version of the agilistas discourse.

bvrmn 7y ago

Also this comes to mind. Most of successful IT companies do not use external services for core components and prefer inhouse solutions.

Silhouette 7y ago

Software is more than CRUD applications for business automation, but even for those, I'm not sure how accurate the characterisation here is, particularly regarding external dependencies. SaaS/cloud/this-week's-buzzword has done well for a few very successful businesses, particularly the handful of giants providing the infrastructure it runs on, but outsourcing everything you can think of is hardly universal.