Layers in Software: From Data to Value

Summarized well by these lines:<p>&gt; 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<p>&gt; We once layered by serving data to software. Now we layer by serving value to people.<p>This is a nice narrative for the rise of developer products, where there used to not be a market.

&quot;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.&quot;<p>If the problem domain is adequately handled by generalists that&#x27;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&#x27;s very much in my interest to promote teams with &quot;all the skills&quot; because it means I won&#x27;t be wanting for work.

Software is more than CRUD applications for business automation, but even for those, I&#x27;m not sure how accurate the characterisation here is, particularly regarding external dependencies. SaaS&#x2F;cloud&#x2F;this-week&#x27;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.

Fluffy words. The developer version of the agilistas discourse.

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

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