"data-driven design" entries
Microservices optimize evolutionary change at a granular level.
We just finished the first O’Reilly Software Architecture Conference and the overwhelming most popular topic was microservices. Why all the hype about an architectural style?
Microservices are the first post-DevOps revolution architecture.
The DevOps revolution highlighted how much inadvertent friction an outdated operations mindset can cause, starting the move towards automating away manual tasks. By automating chores like machine provisioning and deployments, it suddenly became cheap to make changes that used to be expensive. Some architects properly viewed this new capability as a super power, and built architectures that fully embraced the operational aspects of their design. The Microservice architectural style prioritizes operational concerns as one of the key aspects of the architecture.
Microservice architectures borrow a design aesthetic from Domain Driven Design called the Bounded Context. A bounded context encapsulates all internal details of that domain and has explicit integration points with other bounded contexts. Microservice architectures reify the logical DDD bounded context into physical architecture. For example, it is common in microservice architectures for services that must persist data to own their database: members of the service team handle provisioning, backups, schema, migration, etc. In other words, in microservice architectures, the bounded context is also a physical context. But that also means that this service implementation isn’t coupled to any other team’s implementation, clearing the path for independent evolution. I recently published some writing about the recent realization that architecture is abstract until operationalized. In other words, until you have deployed an architecture and upgraded parts of it, you don’t fully understand it.
Data-informed design is a framework to hone understanding of customer behavior and align teams with larger business goals.
Editor’s note: this is an excerpt from our forthcoming book Designing with Data; it is part of a free curated collection of chapters from the O’Reilly Design library — download a free copy of the Experience Design ebook here.The phrase “data driven” has long been part of buzzword-bingo card sets. It’s been heard in the halls of the web analytics conference eMetrics for more than a decade, with countless sessions aimed at teaching audience members how to turn their organizations into data-driven businesses.
When spoken of in a positive light, the phrase data driven conjures visions of organizations with endless streams of silver-bullet reports — you know the ones: they’re generally entitled something to the effect of “This Chart Will Help Us Fix Everything” and show how a surprise change can lead to a quadrillion increase in revenue along with world peace.
When spoken of in a negative light, the term is thrown around as a descriptor of Orwellian organizations with panopticon-level data collection methods, with management imprisoned by relentless reporting, leaving no room for real innovation.
Evan Williams, founder of Blogger, Twitter, and Medium, made an apt comment about being data driven:
I see this mentality that I think is common, especially in Silicon Valley with engineer-driven start-ups who think they can test their way to success. They don’t acknowledge the dip. And with really hard problems, you don’t see market success right away. You have to be willing to go through the dark forest and believe that there’s something down there worth fighting the dragons for, because if you don’t, you’ll never do anything good. I think it’s kind of problematic how data-driven some companies are today, as crazy as that sounds.”