1. Introduction
API (Application Programming Interfaces) play a key role in our digital world. API are both interfaces, the famous “plugs” that let others connect and use your capacities (data, services) and contracts (service contracts) that brings decoupling and a form of modularity. API have become a buzzword and I must say that I talk about API a lot in my writings, including my blogposts. Let me first recall very briefly why API matter so much in our digital VUCA world.
- Architecting digital and information systems around API is a strategic necessity. It is a way to foster future reuse and to increase flexibility and agility, thanks to decoupling. It requires to think about capabilities more than functions. Capabilities must be designed and exposed with anticipation (long-term), but functions and services may be assembled both quickly and outside. I love this quote from Chet Kapoor, the former CEO of Apigee: “We need API because we do not known the future.
- “API first” is a complete mindset change, which is necessary to deliver modularity. Designing API requires outside-to-inside thinking: you need to put yourself in the shoes of the API users and to write a piece of code for a final use that you do not know. This leads to co-design with a developer community, which you must learn to grow by thinking in “product mode”, like a software editor
- APIs are the lego blocks of innovation. Innovation spurs from the meeting of needs and capacities. APIs enable the construction of a “situation potential” (I refer you to Francois Jullien or to my last book) and the wide distribution of these capabilities. APIs are the lingua franca of innovation software ecosystems. To innovate and to leverage the full potential of software communities, one must speak this language.
- Last, API are critical tools for software system modernization. Unless you are part of a brand-new company – like a startup –, digital transformation necessarily implies the constant replacement and modernization of your software assets. This is achieved through service-oriented architecture (SOA) both for construction and de-construction. To replace or kill the “mammoth” (monolith), one must “slice the mammoth” and leverage APIs to perform a smooth transition from the old to to new.
In this list, the technical aspects of API are not critical. One does not need to be a software developer to understand the benefits and the relevance of API-thinking. Indeed, every business leader needs to understand this list, because it describes a new mental model about leveraging software ecosystems, and the contributions of other players to reach your own goals. The “Why API” is first and foremost a business strategy issue. It starts with two simple ideas: (1) the world is changing constantly – especially the landscape of digital opportunities (2) there are more smart people outside your company than inside – to borrow the famous quote of Bill Joy – so one must think as software as a platform.
However, the “How to API” has to be co-designed with software developers, both inside and outside. The world of telcos (telecommunication companies) is a great example to learn from. In the early 2000s a number of large, worldwide telcos, decided to expose their services through API. Very significant sums of money were spent to create catalogs of web services to lure developers to build new applications on top of the capabilities of the networks. However, nothing big happened; the “software culture” difference produced a service catalog that did not appeal the majority of the web & mobile development community. To develop an API strategy, one cannot pick a “if you build it, they will come” strategy; on needs to grow a community of engaged developers. Today’s post is about the new book of Jeff Lawson, “Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century”. Jeff Lawson is the CEO of Twilio, a unicorn that delivers API to developers, to interface with the various telcos of the world enabling – for instance – the easy delivery of SMS messages. I have decided to share a short review of Jeff Lawson for three reasons:
- He is de facto one of the best experts about API, software ecosystems and understanding how to bring value with a platform to a community of developers. All the four points about API that I have briefly outlined in the beginning are clearly explained and illustrated by Jeff Lawson.
- His great book is about the “Ask Your Developer” mindset, which is a critical requirement to succeed in the 21st century. This is not a book for technical readers, it is a wide-audience book that should speak to all roles in a company. This is not a naïve praise of software developers but an analysis of how digital innovation works – the foreword is signed by Eric Ries – and a plea for a role distribution that is different from what most companies do today
- This book is a treasure trove of relevant pieces of advice to companies that need to become “software companies”, which is probably the case of the overwhelming majority of companies. API, cloud, microservices are the software flavors of the moment; the success of Twilio is based on mastering these “new” ways of software development.
2. Ask Your Developers
As usual, I will not propose here a complete book review; I will focus about the “Ask Your Developer” mindset, which is the backbone of the book. The book is not intended first for developers or for technical persons, but for business managers. The “Ask Your Developer” mindset is about asking the right questions to the right persons, about understanding the software ecosystems that all companies are part of : “Now, a Software Person is not necessarily a developer—it’s anybody who, when faced with a problem, asks the question: “How can software solve this problem?” That’s because being a Software Person is a mindset, not a skill set”; “This book, as well as the Ask Your Developer mindset, isn’t really about software. It’s about people—the software developers and businesspeople who need to work together to hear customers’ needs and answer them”. I strongly recommend to read “Ask Your Developer: How to Harness the Power of Software Developers and Win in the 21st Century”. Jeff Lawson writes about his personal story, his previous positions – including his job at Amazon Web Services – and the fascinating adventure of Twilio. He also gives many examples about companies that get this mindset right, such as Amazon or ING : “One of those rivals is located just across town—ING, whose roots reach back to the 1700s and which manages more than $1 trillion in assets. It’s about as far from a startup as you can get, and it competes in an industry that is notoriously stodgy, risk-averse, and highly regulated. Yet ING has become one of the most innovative software development organizations in the world”. Because Twilio delivers communication API to many companies in the world, which are at the heard of digital customer relationship and engagement, Jeff Lawson has a great view of Digital Transformation as it happens in his customer companies. His messages are, from my point of view, spot on. As he notices, the current acceleration of digital transformation caused by the COVID crisis makes this message even more urgent than before: “Customers will become accustomed to these digital experiences, and expectations will just continue to rise quickly. Companies that get this right will have loyal, engaged, productive customers. Those that don’t will struggle even more than before the COVID-19 crisis”. My short summary of this book will focus on the three key messages that Jeff Lawson underlines in his book: “Company leaders who build industry-changing software products seem to do three things well. First, they understand why software developers matter more than ever. Second, they understand developers and know how to motivate them. And third, they invest in their developers’ success”.
2.1 Software is Eating the World, Hence Digital Transformation is a Mandate
This quote shows the strong message of Jeff Lawson about software ecosystems. To succeed in one’s digital transformation, each company must understand and reuse much of the software capabilities that are already here – which is one of the reasons why one should Ask Their Developers – but it must also build its own differentiating capabilities : “But in fact companies succeed at digital transformation not just by using software but by building software. Startups like Uber, Lyft, Airbnb, and Spotify have become household names because they’re really good at building software”. The book gives a great testimony about Amazon realization of itself as a software company: “But Jeff came back with an answer most of us didn’t expect. “Amazon,” he said, “is not a retailer. We’re a software company” … “Our business is not what’s in the brown boxes,” he said. “It’s the software that sends the brown boxes on their way”. The success of many startups, Amazon included, comes from their capacity to leverage the new – and constantly increasing – powers of modern software tools : “These two trends became apparent in the early 2000s. Suddenly startups that were great at building software, and had no legacy infrastructure or storefronts to deal with, began springing up. These digital native companies focused their early energy on creating great customer experiences, and they used their software-building expertise to their advantage. The new playing field was digital, and they brought an A-game”. Bringing an “A-game” is about talent, bringing in and keeping, the best software skills. So there are two sides to the “Ask Your Developer” mindset: one is about getting more value from your existing talents, the other is about creating an environment that attracts and nourishes these talents : “I’ve talked about why it’s so important, and easier, for companies to become software builders. To do that, you need talent. In the coming decade, the winners will be companies that build the best software—which really means, the companies with the best software developers”. As mentioned previously, the “Ask Your Developer” transformation is enterprise-wide and needs to reach every position in the company: “Ask Your Developer isn’t just a skill set—it’s a mindset. Over the last decade, I’ve met so many people who exhibit this mindset, in every function—from finance to customer support, from marketing to operations, from sales to product—who are building the future of their respective companies as digital businesses”.
2.2 Writing Software is a Creative Activity
As a software developer myself (I should write amateur software developer these days), I must confess a bias: I was delighted to read about the importance of creativity in software development. Although a Math major, I could not agree more with Jeff Lawson: “Writing software is more similar to making music or writing a book than it is to doing math or science”. One could write an entire blogpost about this statement because it holds the VUCA key of digital transformation. There are many domains where software development is more like maths than music. I started my career and PhD dissertation on compiler design, where mathematical skills and abstraction is the rule of the game. But as we turn into the 21st century and as we focus on human-centric software where user experience design is the key to success; creativity, experience and aesthetics (the sublimation of practice) become the key success factors, hence the analogy with music. Jeff Lawson offers many quotes from one of the most revered software thinker in the industry: “I’ve always thought that engineering is one of the most creative jobs in the world,” Amazon’s CTO, Werner Vogels, says. “Every day you get to create something new. Engineering is an extremely creative profession. Not all engineers are trained to become creative players. But it can be taught over time”. It is important to notice that creativity does not preclude discipline and the use of tools – a statement that I make each time I hear criticism about the “software factory” term – as we shall later see, the book covers in depth the need for automation and the importance of DevOps practices.
Once you understand the importance of creativity, you derive that context is critical: developers must understand the “why” to perform their jobs fully. In my own book, “the lean approach to digital transformation”, I recall our experience at AXA’s digital agency, where we found that it was mandatory for developers to be given not only the user stories, but also the pain points that were detected during the design thinking phase. Good agile practices require user stories to be descriptive and user-centric (hence the name), but the problem that the product is trying to solve should be fully disclosed to the developers: “Enabling the developer to deeply understand what the user needs, and then letting them meet it, is what sharing problems is all about”. This is one of the main message of this book : you should bring talents with technical and software skills as early as possible in the design of a product: “I’m convinced the key to building a world-class engineering culture is bringing developers into the big problems you’re trying to solve, and leveraging their full brains. It’s not too hard to tell if that’s happening in your company. When you see a developer, ask what they’re working on, and what customer problem it’s going to solve”. This mindset, of bringing a technology view early into the business discussion, works both ways: it produces better solutions and it produces better engagement. This is underlined by Werner Vogels: “Engineers sometimes need help to realize that nontechnology companies are filled with important, challenging, and difficult technology problems that would be really cool to work on. “I’m finding there are a lot of very interesting challenges in every large corporation”.
2.3 Winning the Software Race is Hard, this is a Competitive World
I have written my recent blogposts reviewing books that notice that digital transformation is hard and that succeeding with the new “digital offerings” is definitely a challenge for most. This is not a surprise for Jeff Lawson: “Building software is incredibly hard, and building a culture of digital innovation is even harder”. On the one hand, this is the good news that we noticed earlier, much is available about how to do software development right, small startups demonstrate this all the time. On the other hand, good software development requires talents, experience (lots) and the proper tools and environment. The 21st century is indeed very competitive, it is not enough to churn good software, you need to do it fast: “Another challenge is speed. Digital natives can turn a great idea into production code in a matter of weeks—or even days. They roll out new iterations every day. For traditional companies, keeping up means speeding up. “You can no longer afford to spend six months or twelve months in development before you launch,” Vogels says”. Speed is critical, and it requires discipline, skills and practices. There is no quality versus speed trade-off in this new world, both are mandatory: “As I’ve noted, the cadence of software innovation is faster than ever before. Turning customer insights into products is happening at a lightning speed in this digital era. Yet there’s often this question of whether teams should move quickly to capture opportunities and respond to customer needs, or whether they should move more cautiously, ensuring that everything works properly, scales well, and is bug-free. However, at really good software companies, this is a false dichotomy”.
The focus on the developers’ “environment” is critical: the whole company is part of the software development environment. The complexity of our VUCA world means that the idea of “software development in an isolated (organizational) box” is practically over (as noticed earlier, there are still domains where full specifications and waterfall development are practical and deliver value, but they are more the exception than the rule). Becoming a software company is an enterprise-wide transformation: “If you want to become a software builder, you need to start by changing the mindset of the entire organization. It’s not enough to just hire a bunch of new developers, or to change the way developers do their jobs. None of that will work unless you also change the culture around them”. Transforming the company is a strategic endeavor because success requires to develop new software capabilities: “you can’t buy differentiation. You can only build it” ... “Looking ahead, the companies that harness the power of software to deliver the best digital customer experiences will survive and thrive in the digital age”. In this post, I will not cover the talent shortage topic although it is today in the top of mind of most CIOs that I know, myself included. However, Jeff Lawson talks about the obvious shortage of talents that the COVID crisis has even worsened: “There’s a shortage of developers in the world. In 2019, there were four times as many open software jobs as there were new computer science graduates”. In the spirit of the global advice to link developers and business as much as possible, he sees the recruitment of software talents as a key priority for senior business management: “when you’re recruiting top technology talent, they should be involved. Ideally your CEO already knows why technology is important to the company, intends to work closely with your top technologists, and therefore already intends to be part of the recruiting process”.
2.4. In the Digital World, Doing and Thinking should be Mixed
Breaking the Taylorism in favor of cross-functional teams and adopting the “Ask your developer mindset” is, as we stated above, both a way to unlock more creativity, innovation and efficiency, and also the best way to become attractive to software talents : “If you’re having trouble hiring great technical talent, or worse yet, you hire them but they’re leaving before they add value—Ask Your Developer can help you create the conditions to attract and retain great developers by unlocking their intrinsic motivation to build”. Creating cross-functional teams with diversity in skills and profile is better achieved when the team members focus on problems first. Diving onto the solution is probably the most common errors in many companies since it produces second-rate quality products and frustrated teams. The deep exchange about customer problems is the best glue to grow collective intelligence: “the key to getting businesspeople and developers to work well together is for the businesspeople to share problems, not solutions”. As you build your software development team, the fundamental ask of your developers, your architects, and your technical leadership is to pick the right areas to build. This is clearly one of the strong points of Amazon: “Business leaders like Andy Jassy provided leadership guidance and wisdom, but really created an environment for technical leaders to flourish and add business value, not just code”.
Eventually, this is all about tacit knowledge. People with software development experience can make better and faster decisions not because they bring more knowledge to the discussion, but less. This is a critical trait of complex situations: you cannot summarize everything on the Powerpoint, nor should you. Companies need to rely on experience and delegate the decision closer to the ground. Jeff Lawson uses the term “bikeshedding” to characterize those meetings where there is an avalanche of technical details that make it hard to focus on the real issues, something that most of us have seen in our professional lives. This is often the consequence of a lack of experience, and the fear of missing out : “Bikeshedding, therefore, is the tendency for nonexperts in charge to expend a lot of calories on unimportant details, because they lack the context to make the most important decisions”.
2.5. Intrinsic Motivation Rules in the 21st Century
2.6. Modern Digital Organizations are Continuous Learning Organizations
Because technology is constantly changing, a modern software development organization is foremost a place of continuous learning: “An open, learning environment is one where the organization is receptive to not having all of the answers, is comfortable with uncertainty, and strives to get better every day”. Jeff Lawson was trained as a lawyer, he is repeatedly promoting in his book the Socratic method of learning, through asking many questions : “ We want to teach employees how to teach themselves. That’s the essence of a learning environment. We’re building a mindset, a way of analyzing and solving problems. The Socratic method is as effective with business problems as it is with complex legal cases”. Asking questions about customer problems is the easiest way to create a common perspective : “You can do this, too—it’s easy. Another thing to ask your developers: during product reviews, start the conversation with the customer problem”. This leads naturally to the lean roots of learning through problem solving: “The way you get there is repeatedly asking “Why?”” and its “Five whys” practice. This is the best way to learn continuously from operations problem, through “blameless postmortem : “We, and many other software companies, do this via a ritual called the “blameless postmortem.” The purpose of the blameless postmortem is to dig below the surface of some kind of bad outcome to the true root cause, and address that as an organization”.
The focus on constant and iterative learning is emphasized with the reference to Lean Startup and leads to numerous explanations about how Agile software development is implemented at Twilio: “While there are many ways to implement Agile development, they all revolve around three main ideas: anticipating change, chunking up work, and maintaining close collaboration between the business and developers”. Anticipating change is clearly the landmark of 21st century development. One should expect changes during the development process and organize oneself to welcome such changes as (differentiation) opportunities. The second agile principle underlined by Jeff Lawson is about small value delivery increments, popularized as sprints: “chunking up work as you go, into units that are manageable, predictable, and implementable … This process is designed to make each work item predictable in scope and time to implement, giving a high degree of confidence to the work”. This is the key ingredient of agility: breaking into small manageable units and not reverting to the fallacy of adding more resources : “Who wouldn’t want more budget and head count!? The reason is that throwing more people at the problem, especially if a project is in progress and running behind, is not likely to help. In fact, it’ll probably further delay the project”.
2.7. Innovation Requires Experimentation, Experimentation Requires Best-In-Class Infrastructure.
The Lean Startup approach is a learning engine that delivers units of learning through controlled experiments. Controlled means that, through innovation accounting, assumptions are made explicit, then validated or invalidated through experiments carried with a minimal viable product. Innovation requires experimentation: “This is how innovation works: experimentation is the prerequisite to innovation. The more quickly and cheaply you can run experiments, the faster you’ll eventually find something that works”. Experimentation is required because the world is too complex, and nobody knows what is going to work for the customer or not: “That’s the essence of experimentation. It’s also the essence of the Lean Startup revolution started by Eric Ries, who wrote the foreword to this book. If you can try things in a low-risk way and quickly learn about your customers’ needs, why wouldn’t you ?“. The unpredictability of digital successes apply to everyone, including Amazon: “In his 2015 letter to Amazon shareholders, Bezos reminded investors that three of Amazon’s biggest successes—Marketplace, Prime, and Amazon Web Services—began as experiments, and that, when they were conceived, nobody knew whether they would work or not”. Consequently, Jeff Lawson has made Twilio into a very impressive experimentation engine: “At Twilio we’re always trying to run as many experiments as possible. We ship new versions of our product over 120,000 times per year—more than 300 times per day”.
Experimentation requires both speed (to run many of them) and discipline (to learn, you need to be clear about your assumptions). It is critical to write your assumptions down:” Having a hypothesis, and a set of assumptions to prove or disprove, is great—but you need it in writing so you can track progress. At Twilio, one of our core values is “Write it down,” and experiments are a great place to exercise such a practice”. Discipline is a critical: “You build products for your customers. It’s not like, ‘Let’s go build some technology in the wild and see what happens with it,’” Werner Vogels says. “You need a very strong mechanism to make sure that you know exactly what you’re going to build for your customers.”
Fast and robust experimentation requires to invest into great infrastructure: “To make your developers successful, you need to invest in infrastructure”. First-class infrastructure is about capacity and speed of execution, it is also about flexibility and speed of development. Without surprise, Twilio have moved to DevOps: “This combination was crucial as we started to embrace a methodology called DevOps in building our developer platform. Even if you don’t work directly in technology you might have heard the term DevOps without really understanding what it is”. There is no surprise because production platforms are the innovation engine, the place where experiments happen, in our digital world. The time of the lab environment is over, you need to build your production infrastructure so that it may be used to run safely the multiple innovation iterations : “In short, by providing platforms and processes that helped developers build faster while still having guardrails to ensure that customers and the company were protected from truly bad outcomes, Rossi made sure that when developers moved fast, they didn’t break things too much. It turns out, great infrastructure is the foundation of innovation”. This is top reason why Google is attractive to software developers and should be looked at as a source of inspiration : “Ever wonder why engineers flock to companies like Google? Sure, the pay is good. But the support infrastructure is world-class. It’s one thing to coddle developers with free lunch and tricycles, but Google really coddles developers with great infrastructure on which to build. When your tools direct nearly all of your energy toward the task at hand—serving customers and being creative—it’s magical. The opposite is also true—when you’re fighting your tools, it’s a real morale hit”.
2.8. Customer-Centricity for Everyone
As stated earlier, customer-centricity is the best way to unite a diverse team around a common and sensible goal: “For a team to develop the intrinsic drive of a startup, they need organizing principles that articulate their purpose. I typically start by defining the customer they’re serving”. This applies at all scales in the organization, down to the product development squad: “Defining customer, mission, and metrics is the foundation of the small team”. Customer-centricity has become a very fashionable buzzword, but it remains a very demanding mindset which requires practice to develop the necessary behaviors : “Customer centricity, as the name implies, is creating an organization that constantly self-corrects to put customers at the center of our decisions. Like a gyroscope that resists being moved off-center, a customer-centric organization resists the many forces that attempt to deprioritize customers. But it’s incredibly hard to do, and that’s where it’s helpful to learn from the masters”.
Because Jeff Lawson works in B2B, he takes customer-centricity to a deep level of customer empathy (“walking in your customer shoes”) which he describes through the concept of hospitality: “Hospitality is the foundation of my business philosophy. Virtually nothing else is as important as how one is made to feel in any business transaction. Hospitality exists when you believe the other person is on your side. The converse is just as true. Hospitality is present when something happens for you. It is absent when something happens to you. Those two simple prepositions—for and to—express it all”. Hospitality reveals the key concept of customer experience, which is much larger than the service that company is delivering: “Service is the technical delivery of a product. Hospitality is how the delivery of that product makes its recipient feel. Service is a monologue—we decide how we want to do things and set our own standards for service. Hospitality, on the other hand, is a dialogue”.
Developing this customer-centric mindset requires to share the “voice of customer” throughout the organization. Customer-centricity cannot be delegated to some department, it is the common soul for all teams : “But by putting engineers directly into the flow of customer feedback, you achieve two things. First, you humanize your customers. Instead of being a requirements document, the developers get to hear straight from customers not just what they need, but why they need it”. This last quote is especially meaningful for me, because I have witnessed first-hand the power of sharing the customer (issues) testimonies across multiple teams when I was developing set-top boxes at Bouygues Telecom. Earlier in my career, I had witnessed the terrible situation that Jeff Lawson describes when companies overengineer their organization and specialize roles: “ But in a cruel irony, these are the types of companies that are often most likely to separate customers from the people building the product. Business-to-business companies, for example, typically employ armies of salespeople, customer success advocates, customer support agents, and domain-expert product managers as buffers between customers and the development team”. Customer-centricity starts with listening and observing. Here also, I find the following anecdote related in the book to hit close to home. I have had the humbling experience to discover, many months after completion, what users were really doing with the piece of software that I had written. Iterative and repeated observations and conversations with users is the only way to avoid this: “Back in the software shop, Ben and the others were writing programs with the assumption that their applications would fill the entire screen on a trader’s terminal. But in fact our application was in this little teeny corner of the window and they had nine other things going. They’re viewing my stuff on this tiny little window, so everything looks terrible and they can’t read it. I realized that things like font size mattered, and contrast mattered. It made me realize that the choices I was making as a developer were wrong. It was really enlightening.”
2.9. Software as a Service and Software Platforms
As told in the introduction, reading this book will also help you to learn about Twilio and how it was born from the desire to simplify the developers’ experience when building software products that embed communication services : “Our software would abstract one hundred years of complexity that the industry had accumulated and present it as a simple API for developers”. Jeff Lawson explains how he went to call and interview prospective customers – software developers – to find out which kind of API would be useful. He then moves to the software platform development phase at Twilio, and how they had to optimize the delivery through automation. Here is an illustrating example of the search for automation – which is how you achieve the capacity to experiment: “Jason grabbed two platform engineers, and they automated a bunch of steps in our development process. Their work slashed development time in half—from forty days to twenty days. The impact gets magnified because we develop about two hundred new Java services per year. Yes, we spent money on those two platform engineers. But their work saved us four thousand person-days per year”.
Thinking your software product as a platform is part of the “new” digital mindset: it tells how you propose your services to others, but also how you integrate other players services into your systems. Platforms plays two critical role in the software ecosystems : they act as market places (interfaces) to support the dynamic interplay of cooperation and they hide complexity by hiding (through service APIs) the underpinning of what is exposed in the platform : “The future of platforms will be allowing software developers to focus only on their features and their customers, and not about all the underlying systems that are required to bring software from somebody’s head to the cloud to a device and to an experience for a customer”. Jeff Lawson uses the supply chain analogy to emphasize this point : “As I noted in Chapter 1, I believe every company that’s going to survive and thrive in the digital economy needs to build software. Thus, your supply chain matters. If your digital supply chain is better than your competitors’, you’ll be in a much stronger position to succeed”. The book quotes Amazon Web Services as a perfect illustration of the platform approach: “Its sales have grown from practically zero in 2007 to an annualized $40 billion as of the first quarter of 2020. From zero to $40 billion in twelve years, which is pretty much unprecedented growth. That’s why it’s obvious that this business model—the platform business model—represents the next big thing in software.
2.10. Modular Architecture, API and micro-services
The power of APIs to achieve loose coupling through abstraction (encapsulation of complexity) is why they are so useful to build resilient, future-proof and modular systems, as explained in the introduction. Modular systems aim at being more resilient because the amount of information and knowledge that must be shared decreases. Jeff Lawson emphasizes this point : “I believe the goal isn’t better collaboration; it’s actually less collaboration. Great companies don’t say: “I need better customer support.” They say: “We should reduce the need for customers to contact customer support.” In the same way, great companies reduce the need for teams, and individuals, to collaborate by standardizing or productizing the interactions between the groups”. The COVID crisis has shown that modular architectures are more resilient “ The crisis also showed how much faster it has become to build and deploy software. Software building blocks, microservices, and APIs have radically accelerated the process”. This way of thinking about modularity and API was made famous at Amazon : “In 2000 Amazon had a giant monolithic mess of engineers and code powering the fast-growing retail business. Engineers were stepping all over each other, and the coordination energy to get anything done was massive. Things were slowing down, so Bezos wrote the “two-pizza team” memo proposing that they divide the company into small teams in order to move faster .. if teams were organized into startup-like sizes, if they owned their road maps and they owned their code so they could move quickly, they could act like startups again, just as they had in the early days of Amazon, when Jeff remembered they could feed the whole team with two pizzas”. The power of the small team approach it to be able to focus fast on a customer problem (“That’s the power of a small team—there are no proxies; you’re just directly solving customer problems with your code”) provided that the modularity of the complete system’s architecture leaves enough autonomy to the team.
This quest for small team autonomy has led to the concept of microservices. The team runs its own system, from development to operations (hence, with DevOps practices), to deliver its own units of value through APIs: “These microservices were delivered not as a pile of code, nor as a website, but as a web-based API. APIs are well-defined interfaces that enable code to talk to other bits of code. Once a team builds and exposes an API to others, it’s important that they teach other teams how to use it via documentation that’s accurate and up to date. So at Amazon, an internal culture of API documentation arose. One team could find another team’s API documentation and start using their services, often without even needing to talk. This enabled the teams to effectively work together, solving the coordination problem”. Once the SOA (service-oriented architecture) patterns emerges, it is a great blueprint to separate between what you build and what you source : “My rule of thumb is that for anything that gives you differentiation with customers, you should build. Software that faces your customers, you should build. … But for most back-end operations, and for things that won’t give you any differentiation with customers, you should buy. You aren’t going to build your own email. Or your own database software”.
The development of microservices is not the result of planed and careful design, it emerges from a Darwinian process of experiment and usage consolidation. This means that duplication of effort is a temporary byproduct: “This may be part of why I’m often asked how we prevent duplicate work in our small, empowered teams culture. My answer is: we don’t”. The key insight is that sharing/ reuse / mutulization emerges from experience, not from design. To focus too early on reuse at the design phase places too strong a complexity burden on the teams’ journeys: “We allow our teams to charge ahead and lead the way. Then, as technical leaders and architects, we watch for the patterns to emerge. When we see multiple teams all inventing similar things you can step in, observe the trend, and staff a team to go solve that problem for everybody—thus achieving efficiency. That’s the essence of platforms. But instead of trying to perfectly plan it out from the top, let teams organically show you the path”. This the reason why system architecture is a continuous process. Notice that Twilio inherited this view from Amazon, as stated by Werner Vogels: “Amazon also prefers speed and doesn’t obsess about duplication, … We allow teams to just do a lot of things themselves, even if that duplicates some functionality. We’re willing to exchange that for moving fast”.
4. Conclusion
I will conclude this book review with the emphasis about three key ideas:
- Taylorism is counter-productive, diversified roles must collaborate and thinking and doing are mixed in the development process.
- Ask your developer does not mean “leave it to your developer” – it means: (a) to grow cross-functional teams (b) to ask the doers as early as possible in the product lifecycle.
- Micro services are both a system architecture pattern (about modularity and API) and an enterprise organization pattern (about networks of autonomous teams). It is not something that you design, it is something that you grow. It grows from usage, but it requires constant care (refactoring) similar to gardening.
No comments:
Post a Comment