Another lesson we've learned is that 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.

There is another lesson here: Giving developers operational
responsibilities has greatly enhanced the quality of the services, both
from a customer and a technology point of view. The traditional model
is that you take your software to the wall that separates development
and operations, and throw it over and then forget about it. Not at
Amazon. You build it, you run it. This brings developers into contact
with the day-to-day operation of their software. It also brings them
into day-to-day contact with the customer. This customer feedback loop
is essential for improving the quality of the service.

On idea development

If an idea is deemed worthy of investigation, we exploit our service development approach to scope and prototype the idea quickly.
With a new radical service, you try to go into prototype mode pretty
quickly, and then you start iterating on that until you feel that you
understand your business problem. The small-team concept means that you
have a continuous feedback loop where you try to understand the impact
for the customer.

That's in general how requirements are being refined, with the
customer in the loop. It is also very important to try to determine at
the outset what the success criteria should be, and how they can be
measured.

This fast response to new ideas is enabled through the loosely
coupled services model, both in technology and at the developer and
operations level. From the outside, the services in our platform may
appear chaotic, but chaotic in a good sense—in that we try not to
impose a rigid structure on the different functional pieces, but we
expect there to be order when looking at it from a different dimension.
Thinking about this whole system as a big deterministic system would be
unrealistic. Life is not deterministic, and a large-scale distributed
system such as Amazon has many organic and emerging properties that can
come to life only if you do not constrain it.