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.
You are drawing too much of a distinction between “business units” and “tech teams” I think. An org with a lot of software dev discipline is going to apply that discipline to everything, not just software dev. It’s a lot more meta than just “bug-free code” or “lots of documented design” or other best practices that we followed in the tech world 15-20 years ago. It’s the combined tech/business process that is disciplined now.
Business units that own particular products are dominated by managers who have strong discipline. Often the business is actually part of a larger tech org instead of the other way around. The discipline forces them to to think about their product as a service that supports other products. The product is a series of tech efforts, iterating to a longer-term vision.
Too many companies are still seeing IT as an expensive part of a non-tech business. To keep the cost of software devs low, they lower their hiring standards. The lack of discipline leads to crap code.
The winners see tech _AS_ the business. Walmart was a logistics software company that also happened to own their own warehouses, trucks and retail outlets. The next airline that takes over the world will be a software company that just happens to own airplanes. Think Uber. Go watch tech talks by Uber folks. They have had real-world success with real automobiles (you can even lease cars from them) but they are at their core a tech company. My wife works for an insurance company in HR and has started speaking the identical Scrum/Agile/lean lingo as I do as an SDM.
Think about how many of Amazon’s products are actually platforms for other products. AWS is the most common example used. It has grown to hundreds of distinct products that are actually layered on top of the original few (you can easily lose a day just browsing the product listings and descriptions on AWS, start with Snowmobile). There are many other examples. Echo uses / exposes Alexa, and AWS sells the underlying bits of Alexa as services. Echo also uses shopping carts, checkout, Amazon music, product search, and on and on. Amazon video lets Amazon produce original content. But AWS includes “Elastic Transcoder” which will sell you video transcoding services by the minute, $0.03/min of HD video encoded, no servers needed. Echo is also a platform for 3rd party devs, who can use other AWS technologies to build their products, such as Code Commit, Code Deploy, Cloud Formation, etc. It’s getting pretty exponential right now.
My read on inequality across firms is that the firms that are winning are the ones where all of management, not just IT management, is subject to disciplined processes that were originally honed in the hyper-competitive world of tech (Agile / Kanban). The process is applied as much to Accounting as it is to an SDE. The amount of organizational capital available to each worker in such an environment is sky-high, and thus so are the wages.
“I reiterate my view that a firm’s software development can only be as disciplined as its business units. ”
That’s like saying functional sub groups within an organization can’t be disciplined until the entire business unit is.
Ultimately, software is just a set of instructions.Any observations here about software are really management principles. They are just as useful in any complex system of dependencies. They could be applied to a rebuilding a power grid in Puerto Rico, or building a car, or running a coffee shop. A service oriented architecture is just a way to compartmentalize bigger problems into smaller ones. Eliminating as many dependencies as possible isn’t just a good idea in software.
There’s a trap here. The trap is that is the “visible disciplined rules” are how the business actually works, AND that the business CAN work with visible disciplined rules in its market.
There was an automation case study some 20 years ago that found automation of a particular concern failed because of some odd real world issues. For example, accurately quoting up front was a way to go out of business very quickly – all quotes were optimistic lies and all vendors and customers knew it. Getting customer data from salespeople was not possible because a great deal of it was personal, and in effect belonged to the salesperson rather than the firm. Accurate scheduling was a pointless exercise because every customer on every project would make so many changes that the initial schedule lost all meaning before the project even got going.
Note that some of these can’t be fixed by applying discipline inside the org – if the market is run on lies, you must lie. If schedules are fiction, they are fiction.
It’s worth noting that Google has abandoned various services (because they couldn’t make money) and I imagine Amazon has too – why? Because business is a search process and you by definition don’t know what you’ll find.
To some degree, walmart’s success is a kind of green field effect (they could impose discipline on a new kind of market) – likewise for Amazon. Note that neither walmart nor amazon has had any effect on car sales. Why? Because that’s an existing market full of bizarre rules – you don’t get to impose discipline. Even the automakers don’t get to impose discipline.
So perhaps Freddie Mac was badly managed. But it may also be that any entity in that market *HAD* to be “badly managed” to stay in the business. In other words, if you didn’t make ad-hoc weird deals with originators, they’d go to a competitor, or to congress.
Likewise with the airline example – large airlines have been software entities that happened to fly planes for a long time. That has made them more efficient – but cannot change the realities of unions, safety rules, regulation, weather, the physics of airplanes, the geopolitical rules (which are much more complicated than most realize), limitations of the airspace system, and sometimes local political issues which can be oddly reflected in national regulations.
Just because you have a perfect optimizer, doesn’t mean that the result is profitable or even useful.