
Layers in Software: From Data to Value - dedalus
https://blog.jessitron.com/2019/11/05/layers-in-software-from-data-to-value/
======
ericand
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
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
> however at the cost of lower cohesion

Is that cohesion within the team, or across teams (in the company as a whole)?

------
mikece
"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
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.

------
Silhouette
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.

------
gfs78
Fluffy words. The developer version of the agilistas discourse.

------
bvrmn
> 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.

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

