Robert C. Martin described the single responsibility principle: “Gather together those things that change for the same reason. Separate those things that change for different reasons.” Clear separation of concerns, minimal coupling across domains of concern, and the potential for a higher rate of change lead to increased business agility and engineering velocity.
This is another characteristic of the disciplined approach to software development that Tim O’Reilly describes at Amazon. I didn’t include it in my previous post. Thanks to a reader for the pointer.
Thanks also to a commenter, who sends a link to a memo.
There are without question pros and cons to the SOA approach, and some of the cons are pretty long. But overall it’s the right thing because SOA-driven design enables Platforms.
SOA stands for “service-oriented architecture.”
O’Reilly explains SOA, as does Zack Kanter.
each piece of Amazon is being built with a service-oriented architecture, and Amazon is using that architecture to successively turn every single piece of the company into a separate platform — and thus opening each piece to outside competition.
Thanks yet again to another commenter for the link.
I reiterate my view that a firm’s software development can only be as disciplined as its business units. I have a hard time picturing Freddie Mac in the late 1980s and early 1990s (when I was there) having a culture to do SOA, even if you gave the IT department all of 2017-vintage technology to work with. The dependencies across business units were extremely tight, with decisions made by the people negotiating terms with loan originators having downstream effects on folks servicing defaulted loans years later as they tried to determine what recourse Freddie had, if any, back to the originator in order to compensate for losses. In practice, this was handled in an informal, ad hoc manner. To get to the point where you could have executed SOA, you would have needed business units to understand and buy into a much more explicitly documented business process. That is what I cannot picture happening.
Recently, some economists have been struck by the high degree of inequality across firms. I can imagine that one source of inequality would be in the ability of management teams to take advantage of highly disciplined processes for software development. The skill and culture of the management team might be more important, and more unequal across firms, than was the case a few decades ago.