{"id":465,"date":"2021-09-14T16:23:24","date_gmt":"2021-09-14T16:23:24","guid":{"rendered":"https:\/\/fde.cat\/index.php\/2021\/09\/14\/10-principles-for-architecture-at-salesforce\/"},"modified":"2021-09-14T16:23:24","modified_gmt":"2021-09-14T16:23:24","slug":"10-principles-for-architecture-at-salesforce","status":"publish","type":"post","link":"https:\/\/fde.cat\/index.php\/2021\/09\/14\/10-principles-for-architecture-at-salesforce\/","title":{"rendered":"10 Principles for Architecture at Salesforce"},"content":{"rendered":"<p><em>co-written by <\/em><a href=\"https:\/\/medium.com\/@thefutureian\"><em>Ian\u00a0Varley<\/em><\/a><\/p>\n<p>Software engineering can\u2019t be reduced to a set of rules. Rather, it\u2019s about understanding the problems we\u2019re trying to solve, and making trade-offs among competing priorities. It\u2019s nuanced work that requires experience and lots of <a href=\"https:\/\/engineering.salesforce.com\/118-why-writing-matters-for-engineers-8ffdeaa40e68\">clear communication<\/a>.<\/p>\n<p>That said, there are some things we think are true across the board\u200a\u2014\u200asome principles that apply broadly to all of the decisions we make. Here we lay out 10 principles that we encourage our software architects to embody and aspire to, not because it is easy, but because it is hard (a la <a href=\"https:\/\/en.wikipedia.org\/wiki\/We_choose_to_go_to_the_Moon\">JFK\u2019s 1962 speech<\/a> about going to the moon), and not because they are <em>rules<\/em> but because they guide our software toward more success down the\u00a0road.<\/p>\n<p>So, to the principles:<\/p>\n<p><strong>Speak for Trust<\/strong>: This is not surprising if you\u2019ve been around Salesforce at all. Trust is our number one value. When making decisions, we often think about delivering new features to our customers quickly, which is important! But we also need voices pushing for building lasting trust with those customers. That\u2019s one important consideration for our senior individual contributors (ICs) like architects\u200a\u2014\u200ato think about building software the right way, from the outset, even in the face of product deadlines.<strong>Technology Serves Customers<\/strong>: There are usually many layers between us and customers, and while sometimes necessary at our scale, it has downsides. Figuring out what\u2019s going on with real customers when they use our software can feel like a game of telephone. We ask our architects to be aware of customer pain and frustration, even through all of these\u00a0layers.<strong>Champion Long-term Value<\/strong>: The software architect is sometimes the only one in the room with the knowledge of the consequences our actions might have in 5 or 10 years. Lean into that! Avoid getting caught up in the pressure to ship something for the short term and instead think about the long term impact of decisions being made right\u00a0now.<strong>Complexity is Debt<\/strong>: Our systems are complicated (duh), even more so on the inside than from the outside. Treat every bit of complexity added to our system as highly\u00a0suspect.<strong>Make Architecture An Equal Partner<\/strong>: Too often, individual contributors (ICs) think they\u2019re not really allowed in the room when important decisions are being made, instead leaving that to management and product. We\u2019re here to tell you that this is wrong and unhelpful; as we\u2019ve laid out in the previous few principles, architects bring a really unique perspective here: thinking long term and factoring in technical ideas. Work to make your presence\u00a0known.<strong>Communicate the \u201cWhy\u201d<\/strong>: e.g. write it down! Software tends to last a lot longer than you think it will. Once you realize that a large part of successful software engineering is actually more like archaeology, you\u2019ll be more inclined to leave better records of your thinking for posterity. Your future self, not to mention the rest of the team, will thank you. (<em>Listen to more on this topic in our podcast episode, \u201c<\/em><a href=\"https:\/\/engineering.salesforce.com\/118-why-writing-matters-for-engineers-8ffdeaa40e68\"><em>Why Writing Matters for Engineers<\/em><\/a><em>.\u201d)<\/em><strong>Overcome Silo<\/strong>s: Big companies don\u2019t always have the right incentive structures for building shared value. But it\u2019s the architect\u2019s job to push back against this. That often involves trading in favor of global good rather than what\u2019s locally optimal, and doing the work to build relationships and reuse across organizational silos.<strong>Design Still Matters<\/strong>: Sure, modern software delivery is agile. But that\u2019s not an excuse for skipping planning and design! You still need to answer the major questions, and lay out the theory of a system. If you constantly wobble the underlying architecture of a system, you get an emergent pile of mismatched metaphors, partially implemented abstractions, and half baked solutions. Don\u2019t spend months coding to save hours of planning.<strong>Everything Evolves<\/strong>: Building systems isn\u2019t just about envisioning perfection. You have to move from here to there, and that\u2019s often the most difficult, awkward part of any project. Don\u2019t just think about end states, think about decomposability, flexibility, staging, and paths from one place to\u00a0another.<strong>Don\u2019t Be a Jerk<\/strong>: Human understanding keeps things running smoothly in software engineering. If nobody likes working with you, everything is going to be harder. The \u201chuman\u201d side of software engineering is just as important, if not more important, than the technical side.<\/p>\n<p>Changing personal behaviors is hard, and changing company culture is even harder. We hope these 10 principles offer ways of thinking about software engineering that help move the needle on\u00a0both.<\/p>\n<p><em>Like what you just read? Join our <\/em><a href=\"https:\/\/careers.mail.salesforce.com\/tpil-blogs\"><em>Talent Network<\/em><\/a><em> to scope out open software engineering roles at Salesforce and come join the conversation!<\/em><\/p>\n<p><a href=\"https:\/\/engineering.salesforce.com\/10-principles-for-architecture-at-salesforce-82105d5399a8\">10 Principles for Architecture at Salesforce<\/a> was originally published in <a href=\"https:\/\/engineering.salesforce.com\/\">Salesforce Engineering<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>\n<p><a href=\"https:\/\/engineering.salesforce.com\/10-principles-for-architecture-at-salesforce-82105d5399a8?source=rss----cfe1120185d3---4\">Read More<\/a><\/p>","protected":false},"excerpt":{"rendered":"<p>co-written by Ian\u00a0Varley Software engineering can\u2019t be reduced to a set of rules. Rather, it\u2019s about understanding the problems we\u2019re trying to solve, and making trade-offs among competing priorities. It\u2019s nuanced work that requires experience and lots of clear communication. That said, there are some things we think are true across the board\u200a\u2014\u200asome principles that&hellip; <a class=\"more-link\" href=\"https:\/\/fde.cat\/index.php\/2021\/09\/14\/10-principles-for-architecture-at-salesforce\/\">Continue reading <span class=\"screen-reader-text\">10 Principles for Architecture at Salesforce<\/span><\/a><\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","footnotes":""},"categories":[7],"tags":[],"class_list":["post-465","post","type-post","status-publish","format-standard","hentry","category-technology","entry"],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":544,"url":"https:\/\/fde.cat\/index.php\/2022\/02\/22\/the-unified-infrastructure-platform-behind-salesforce-hyperforce\/","url_meta":{"origin":465,"position":0},"title":"The Unified Infrastructure Platform Behind Salesforce Hyperforce","date":"February 22, 2022","format":false,"excerpt":"If you\u2019re paying attention to Salesforce technology at all, you\u2019ve no doubt heard about Hyperforce, our new approach to deploying Salesforce on public cloud providers. As with any big announcement, it can be a little hard to cut through the hyperbolic language and understand what\u2019s going\u00a0on. In this blog series,\u2026","rel":"","context":"In &quot;Technology&quot;","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":585,"url":"https:\/\/fde.cat\/index.php\/2022\/02\/22\/the-unified-infrastructure-platform-behind-salesforce-hyperforce-2\/","url_meta":{"origin":465,"position":1},"title":"The Unified Infrastructure Platform Behind Salesforce Hyperforce","date":"February 22, 2022","format":false,"excerpt":"If you\u2019re paying attention to Salesforce technology at all, you\u2019ve no doubt heard about\u00a0Hyperforce, our new approach to deploying Salesforce on public cloud providers. As with any big announcement, it can be a little hard to cut through the\u00a0hyperbolic language and understand what\u2019s going on. In this blog series, we\u2019ll\u2026","rel":"","context":"In &quot;Technology&quot;","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":778,"url":"https:\/\/fde.cat\/index.php\/2023\/10\/30\/sre-weekly-issue-396\/","url_meta":{"origin":465,"position":2},"title":"SRE Weekly Issue #396","date":"October 30, 2023","format":false,"excerpt":"View on sreweekly.com A message from our sponsor, FireHydrant: DevOps keeps evolving but alerting tools are stuck in the past. Any modern alerting tool should be built on these four principles: cost-efficiency, service catalog empowerment, easier scheduling and substitutions, and clear distinctions between incidents and alerts. https:\/\/firehydrant.com\/blog\/the-new-principles-of-incident-alerting-its-time-to-evolve\/ Translating Failures into\u2026","rel":"","context":"In &quot;SRE&quot;","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":619,"url":"https:\/\/fde.cat\/index.php\/2022\/08\/10\/architectural-principles-for-high-availability-on-hyperforce\/","url_meta":{"origin":465,"position":3},"title":"Architectural Principles for High Availability on Hyperforce","date":"August 10, 2022","format":false,"excerpt":"Infrastructure and software failures will happen. We idolize four 9s (99.99%) availability. We know we need to optimize and improve Recovery-Time-Objective (RTO, the time it takes to restore service after a service disruption) and Recovery-Point-Objective (RPO, the acceptable data loss measured in time). But how can we actually deliver high\u2026","rel":"","context":"In &quot;Technology&quot;","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":538,"url":"https:\/\/fde.cat\/index.php\/2022\/02\/01\/behind-the-scenes-of-hyperforce-salesforces-infrastructure-for-the-public-cloud\/","url_meta":{"origin":465,"position":4},"title":"Behind the Scenes of Hyperforce: Salesforce\u2019s Infrastructure for the Public Cloud","date":"February 1, 2022","format":false,"excerpt":"Salesforce has been running cloud infrastructure for over two decades, bringing companies and their customers together. When Salesforce first started out in 1999, the world was very different; back then, the only practical way to provide our brand of Software-As-A-Service was to run everything yourself\u200a\u2014\u200anot just the software, but the\u2026","rel":"","context":"In &quot;Technology&quot;","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":615,"url":"https:\/\/fde.cat\/index.php\/2022\/07\/28\/five-security-principles-for-billions-of-messages-across-metas-apps\/","url_meta":{"origin":465,"position":5},"title":"Five security principles for billions of messages across Meta\u2019s apps","date":"July 28, 2022","format":false,"excerpt":"At Meta, our messaging apps help billions of people around the world stay connected to those who matter most to them. This scale brings potential threats from criminals and hackers, so we have a responsibility to keep people and their data safe. We\u2019re sharing a set of principles to ensure\u2026","rel":"","context":"In &quot;Technology&quot;","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/posts\/465","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/comments?post=465"}],"version-history":[{"count":0,"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/posts\/465\/revisions"}],"wp:attachment":[{"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/media?parent=465"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/categories?post=465"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/tags?post=465"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}