This interview with the CTO of amazon has some interesting elements. I'm trying to look at it in perspective of things at work place. First interesting piece that grabs attention is this.
"There were many complex pieces of software combined into a single system. It couldn't evolve anymore. The parts that needed to scale independently were tied into sharing resources with other unknown code paths. There was no isolation and, as a result, no clear ownership."
It seems to happen with any software that starts small & simple and starts to grow rapidly. We have examples of the two extremes in our systems. One that was started with all high funda architecture that promised to scale to any levels of complexity in requirements and the other where everything was done in a minimalistic fashion, just satisfying the requirements at the moment and evolving over time. Both approaches have ended up in complex mammoth frameworks and platforms.
"It's not only the technology side that was improved by using services. The development and operational process has greatly benefited from it as well. The services model has been a key enabler in creating teams that can innovate quickly with a strong customer focus. Each service has a team associated with it, and that team is completely responsible for the service—from scoping out the functionality, to architecting it, to building it, and operating it."
It might be possible to do this with a purely service oriented business model like Amazon's. How will you do this with a product oriented business model where the development life cycle is quite big?
Jack Welch, in one of his books, says that he pushed for a fundamental change the mindset of people in GE. They were used to thinking in silos of their own verticals like marketing, engineering, sales and services. He put the barriers of different verticals down and hoped that there will be more cross functional synergy and result in better products. But even today, at the grass root level, we still feel significant gap between the actual developers and the end user. A huge layer of managers and leaders with all kinds of keywords prefixed to their designation who add almost little value in the sense that they are bogged down by the system they created, always spending time in solving problems that are purely due the system itself. Why should the software development process be so complex that it requires so many people to manage it?
Read the full interview here