MongoDB Blog
Articles, announcements, news, updates and more
MongoDB Hackathon is Here
December 13, 2021
Developer
MongoDB World 2022 Call for Speakers - 5 Tips For a Successful Submission
MongoDB World is back in New York City on June 7-9 2022, and Call for Speakers is open until January 18! We are looking for speakers who can inspire attendees by introducing them to new technologies, ideas, and solutions. If your team is building amazing things with MongoDB, we want to hear about it. Are you passionate about a topic but have no speaking experience? Not a problem. We welcome first-time speakers and encourage speakers from underrepresented groups in technology to apply. We offer outline workshops, slide design training, and one-on-one coaching with a professional speaker coach for all accepted speakers. Additionally, we have an anonymous grading process and your speaker information is hidden from the committee during grading, so we grade the submissions based on content only. Our reviewers have to review a lot of submissions every year. Here are 5 tips for a submission that will stand out from the crowd: Review sessions from previous events — Take a look at our past talks at MongoDB.live 2021 to get an idea of what types of talks we accepted. We also love to hear about topics that are new or unique from what we already have. Have a simple and clear session title — The title is the first thing that our reviewers will see. Puns, creative wordplay, and “hooks” in titles are okay, but make sure that if all someone knew was the title, they still would have some idea what the presentation is about. Include key takeaways in your description — The description is what will convince us to accept your talk. Use the description to explain what the problem is. How did you solve it? Include tons of examples of what you’d talk about. For help developing your description check out the free MongoDB University course and learn more about writing abstracts here . Tell us more in the notes section — Use the notes section to explain the details of your talk in a bit more conversational way. Share your experience with the problem, give us the outline of your talk, or explain why MongoDB World would be less without your talk. Select the right track and session format — We have 8 tracks at MongoDB World this year and 3 different session formats (session, lightning talk, tutorial). Make sure to read the descriptions for each track and submit to the right one for your talk. We review every talk and do our best to move talks to other tracks, but sometimes they can fall through the cracks. Selecting the right track and session format will ensure that your talk is reviewed properly. Call for Speakers is open until January 18, 2022. Don’t miss your chance to be a part of MongoDB World and submit your proposal today! Learn More
Data and the European Landscape: 3 Trends for 2022
The past two years have brought massive changes for IT leaders: large and complex cloud migrations; unprecedented numbers of people suddenly working, shopping and learning from home; and a burst in demand for digital-first experiences. Like everyone else, we are hoping that 2022 isn’t so disruptive (fingers crossed!), but our customer conversations in Europe do lead us to believe the new year will bring new business priorities. We’re already noticing changes in conversations around vendor lock-in, thanks to the Digital Markets Act, a new enthusiasm for combining operational and analytical data to drive new insights faster, and a more strategic embrace of sustainability. Here’s how we see these trends playing out in 2022. Digital markets act draws new attention to cloud vendor lock-in in Europe We’ve heard plenty about the European Commission’s Digital Markets Act , which, in the name of ensuring fair and open digital markets, would place new restrictions on companies that are deemed to be digital “gatekeepers” in the region. That discussion will be nothing compared to the vigorous debate we expect once the EU begins the very tricky political business of determining exactly which companies will fall under the act. If the EU sets the bar for revenues, users, and market size high enough, it’s possible that the regulation will end up affecting only Facebook, Amazon, Google, Apple, and Microsoft. But a European group representing 2,500 CIOs and almost 700 organisations is now pushing to have the regulation encompass more software companies. Their main concern centers around “distorted competition” in cloud infrastructure services and a worry that companies are being locked into one cloud vendor. A trend that will likely increase in 2022 that pushes back on cloud vendor lock-in is embracing multi-cloud strategies. We should expect to see more organisations in the region pursuing multi-cloud environments as a means to improve business continuity and agility whilst being able to access best of breed services from each cloud provider. As we have always said …”it’s fine to date your cloud provider….but don’t ever marry them.” The convergence of operational and analytical data The processing of operational and analytical data is almost always contained in different data systems, each tuned to that use case and managed by separate teams. But because that data lives in separate places, it’s almost impossible for organisations to generate insights and automate actions in real time, against live data. We believe 2022 is the year we’ll see a critical mass of companies in the region make significant progress toward a convergence of their operational and analytical data. We’re already starting to see some of the principles of microservices in operational applications, such as domain ownership, be applied to analytics as well. We’re hearing about this from so many of our customers locally, who are looking at MongoDB as an application data platform that allows them to perform queries across both real-time and historical data, using a unified platform and a single query API. This results in the applications they are building becoming more intelligent and contextual to their users, while avoiding dependencies on centralized analytics teams that otherwise slow down how quickly new, data-driven experiences can be released. Sustainability drives local strategic IT choice Technology always has some environmental cost. Sometimes that’s obvious — such as the energy needs and emissions associated with Bitcoin mining. More often, though, the environmental costs are well hidden. The European Green Deal commits the European Union to reducing emissions by 55% by 2030, with a focus on sustainable industry. With the U.N. Climate Change Conference (COP26) recently completed in Glasgow, and coming off the hottest European summer on record, climate issues have become top of mind. That means our customers are increasingly looking to make their technical operations more sustainable — including in their choice of cloud provider and data centers. According to research from IDC , more than 20% of CxOs say that sustainability is now important in selecting a strategic cloud service provider, and some 29% of CxOs are including sustainability into their RFPs for cloud services. Most interesting, 26% say they are willing to switch to providers with better sustainability credentials. Historically, it’s been difficult to make a switch like that. That’s part of the reason we built MongoDB Atlas — to give our customers the flexibility to run in any region , with any of the three largest cloud providers, and to make it easy to switch between them, and even to run a single database cluster across them. Publicly available information about the footprint of individual regions and even single data centers will make it simpler for companies to make informed decisions. Already, at least one cloud platform has added indicators to regions with the lowest carbon footprint. So while we hope 2022 will not be as disruptive as the years gone by, it will still bring seminal changes to our industry. These changes will also prompt organisations toward more agile, cohesive and sustainable data platform strategies as they seek to gain competitive advantage and exceed customer expectations. Source: IDC, European Customers Engage Services Providers at All Stages of Their Cloud Journey, IDC Survey Spotlight, Doc #EUR248484021, Dec 2021
Engagement Management at MongoDB: Meet Lalitesh Pal
I sat down with Lalitesh Pal , Senior Engagement Manager at MongoDB, to learn more about the Engagement Manager role and why joining the EMEA team is an exciting opportunity. Jackie Denner: Hi, Lalitesh. It’s great to meet you! Thanks for sharing some insight into Engagement Management at MongoDB with me. Can you start by telling me a bit about the Engagement Manager role? What are Engagement Managers responsible for? Lalitesh Pal: Engagement Management is a services sales role within the Professional Services organization at MongoDB. We ensure customers understand the value of MongoDB technology and drive the adoption of our technology in line with MongoDB best practices. Engagement Managers are engaged in the sales cycle early on in the process, typically right after the Account Executive has done their qualification. An Engagement Manager will then help gather the learning needs, drive the right services proposal, and determine how MongoDB can help customers develop applications on top of our data platform. Since a lot of MongoDB customers are new, or are new business units within existing customers, Engagement Managers also prepare tailored enablement plans to enable them with our technology, helping them become self-sufficient in the long run. JD: What skills and experience make someone successful in the Engagement Manager role? LP: Engagement Manager is a key role that enables our Sales team and helps further proliferate MongoDB product adoption in our customer base. To be really successful, you need techno-functional skills combined with strong commercial proposal and sales experience. If you have a winning and stretch mindset , you can ensure success is guaranteed. Needless to say, an Engagement Manager needs to have the collaborative spirit and be able to orchestrate things amongst multiple stakeholders - both internal and external. Finally, Engagement Managers need to feel confident working hand-in-hand with Account Executives to ensure that MondoDB is well-presented and positioned with the customer. I have been in services sales for about 7 years out of my 14 years of work experience. Engagement Managers need to understand technology on a high level. At the end of the day, the most successful Engagement Managers have a sales mindset and are able to connect with business stakeholders and explain the value of MongoDB Professional Services. It’s important to note that Engagement Management is not a delivery role. There are two aspects of Professional Services at MongoDB: one is services sales, the other is delivery. Engagement Managers work with a customer up until the deal is closed and have their own individual quarterly quotas. Once the deal is closed, an internal kickoff takes place with a Regional Delivery Manager and Project Manager who handle all aspects of delivery. JD: What is interesting and exciting about this role? LP: As an Engagement Manager, you’re not just a champion to your Account Executives and MongoDB, you’re also adding immense value to the customer and are their trusted advisor. In some cases, customers may reach out to you before reaching out to their Account Executive. For the customer, you are someone who is turning their ideas into reality by providing a way to make it happen. What really excites me about this role is the impact Engagement Managers have on our customers and the trust that we are able to build, which further reinforces the partnership spirit with them. JD: What learning and growth opportunities are there for someone in Engagement Management? What does the next career step look like? LP: Engagement Managers are currently aligned to Regional Vice Presidents and work at all levels of accounts, from our strategic “POD” accounts to the enterprise and the mid-market. From the Engagement Manager role, there is an opportunity to become a Senior Engagement Manager and eventually a Principal Engagement Manager. We offer career paths for those who want to remain individual contributors and those who are interested in managerial roles leading a team. MongoDB is also very committed to internal mobility, and there is an opportunity to transfer to other roles such as Customer Success or Practice Leads, both of which are global teams. JD: What is the team culture like? LP: Our EMEA team currently consists of six Engagement Managers who report to the Director of Engagement Management, and we’re growing rapidly. We have regular team catch-ups where we discuss weekly forecasts, what’s working and what’s not within our accounts, and share best practices with one another. There is a true open door policy across the entire team -- everyone is just a ping away! We also have a very defined onboarding program for Engagement Managers. Onboarding is spread over five weeks, and new hires will participate in our Sales Bootcamp, new hire technical training, and a services-specific onboarding program where you’ll be assigned to a buddy who is responsible for helping you get settled in. JD: The Professional Services function at MongoDB is still taking shape. What has the Engagement Management team’s journey been like so far? LP: I joined MongoDB a year ago, and we’re always looking for Engagement Managers to change the way MongoDB sells professional services. When I started, we were doing volume-based selling with small deal sizes and packages or “off the shelf” offerings for customers. Now, it’s much more strategic and we’re selling bespoke offerings with project or program-based delivery. Instead of merely advising on how to set up our data platform, we now engage in developing the complete application and working with customer contacts such as C-levels and VPs instead of just architects. We are working on end-to-end projects that innovate on top of MongoDB, showing customers how to deliver faster and better thanks to our technology. All of this results in MongoDB’s reputation as a strategic partner. JD: Why did you join MongoDB, and what makes you stay? LP: What really got me excited initially was MongoDB’s well-structured hiring process that helped me understand the culture, people, and products. It was the culture at MongoDB that made the difference. The people here are truly fantastic, and the hiring process allowed me to interact with a lot of individuals. The second thing is the product. MongoDB’s products are amazing, and there’s nothing else like it on the market (at least nothing that’s competitive). You also receive a lot of autonomy here in general, but in the Engagement Manager role specifically, you’re given the freedom to reach out to customers directly, run your own pipeline generation plan for accounts in line with account strategy, and many times speak to customers one-on-one without an Account Executive present. Employee recognition is an important part of our culture as well. If you are good at what you do, MongoDB will applaud you at all levels. I saw that I could really contribute and add value here, and I still feel that to this day. Interested in pursuing a career in Professional Services at MongoDB? We have several open roles on our teams across the globe and would love for you to transform your career with us!
Joyce, a Decentralized Approach to Foster Business Agility
Despite all of the tools and methodologies that have arisen in the last few years, many companies, particularly those that have been in the market for decades, struggle when it comes to leveraging their operational data to build new digital products and services. According to research and surveys conducted by McKinsey over the last few years, the success rate of digital transformations is consistently low, with less than 30% succeeding at improving their company’s performance. There are a lot of reasons for this, but most of them can be summarized in a sentence: A digital transformation is primarily an organizational and cultural change and then a technological shift. The question is not if digital transformation is a good thing nor is it if moving to the cloud is a good choice. Companies need (badly, in some cases) a digital transformation and yes, the pros of moving to the cloud usually overcome the cons. So, let’s try to dig deeper and analyze three of the main problems companies face when they go on this journey Digital products development Products by nature are customer-driven but companies run their businesses on multiple back-end systems that are instead purpose-driven. Unless you run a very small business, different people with different objectives have ownership of such products and systems. Given this context, what happens when a company wants to launch a new digital product at speed? The back-end systems (CRMs, E-commerce, ERP, etc.) hold the data they need to bring to the customer. Some systems are SaaS, some are legacy, and perhaps others are custom applications created by the company that disrupted the market with innovative solutions back in the days, the perfect recipe for integration hell. The product manager needs to coordinate and negotiate multiple change requests with the system’s owners whilst trying to convince them to add their needs in the backlog to meet the deadline. And things get even worse, as the new product relies on the computational power of the source systems, and if those systems cannot handle the additional traffic, both the product and the core services will be affected. Third-party integration “Everybody wants the change, (almost) nobody wants to change.” In this ever-growing digital world, partnering with third parties (whether they are clients or service providers) is crucial, but everyone who has tried to do so knows how challenging this is: non-standard interfaces, CSV files over FTP with fancy update rules, security issues… The list of unwanted things can grow indefinitely. SaaS everywhere The Software-as-a-Service model is extremely popular and getting the service you want without worrying about the underlying infrastructure gives freedom and speed of adoption, but what happens when a big company relies on multiple SaaS products to run their business? Sooner or later, they experience loss of control and higher costs in keeping a consistent view of the big picture. They need to deal with SaaS internal representations of their own data, multiple views of the same domain concept, unplanned expenses to export, and interpret and integrate the data from different sources with different formats. Putting it all together All the issues above fall into a well-known category of information technology. They are integration problems, and over the years, a lot of vendors promised a definitive solution. Now, you can consider low-code/no-code platforms with hundreds of ready-made connectors and modern graphical interfaces. Problem solved, right? Well, not really. Low-code integration platforms simplify implementation. They are really good at it, but doing so oversimplifies the real challenge: creating and maintaining a consistent set of APIs shaped around the business value over time, and preventing the interfaces from leaking internal complexities to the rest of the company, something that has to be defined and maintained through architectural choices and proper skills (completely hidden behind the selling points of such platforms). There are two different ways to solve integration problems: Centralized using adapters. In this case, the logic is pushed to the central orchestration component, with integration managed through a set of adapters. This is the rather old school SOA approach, the one that the majority of market integration platforms are built on. Decentralized, pushing the logic to the edges, giving autonomous teams the freedom to define both the boundaries and the APIs that a domain must expose to deliver business value. This is a more modern approach that has arisen recently alongside the rise of microservices and, in the analytical world, with the concept of data mesh. The former gives speed at the starting point and the illusion of reducing the number of choices and skills to manage the problems, but in the long run, inevitably, this begins to accumulate technical debt. Due to the lack of necessary degrees of freedom, you lose the ability to evolve the integration points over time, the same thing that caused the transition from SOA to microservices architectures. The latter needs the relevant skills, vision, and ability to execute but gives immediate results and allows you to flexibly manage the evolution of the enterprise architecture over time. Old problems, new solutions At Sourcesense in the last 20 years, we have partnered on hundreds of projects to bring agility, speed, and new open-source technology to our customers. Many times through the years, we were faced with the integration challenges above, and yes, we tried to solve them with the technology available at the time, so we have built some integration solutions on SOA (when they were the best of breed) and interacted with many of the integration platforms on the market. Then, we struggled with the issues and limitations of the integration landscape and have listened to our customers’ needs and where expectations have fallen short. The rise of agile methodologies, cloud computing, new techniques, technologies, and architectural styles has given an unprecedented boost to software evolution and the ability to support business needs, so we embraced the new wave and now have growing experience in solving problems with these tools. Along the way, we’ve seen a recurring pattern when we encountered integration problems, the effectiveness of data hubs as components of the enterprise architectures to solve these challenges, so we built one of our own: Joyce. Data hubs This is a relatively new term and refers to software platforms that collect data from different sources with the main purpose of distribution and sharing. Since this definition is broad and vague, let’s add some other key elements that matter and help define the contours of our implementation. Collecting data from different sources can bring three major benefits: Computational decoupling from the sources. Pulling (or pushing) the data out of the originating systems means that client applications and services interact with the hub and not directly with the sources, preventing them from being slowed down by additional traffic. Catalog and discoverability. If data is collected correctly, this leads to the creation of a catalog, allowing people inside the organization to search, discover, and use the data inside the hub. Security. The main purpose of the hubs is distribution and sharing. This leads immediately to focus on access control and security hardening. A single access point simplifies the overall security around the data because it significantly reduces the number of systems the clients have to interact with to gather the data they need. Joyce, how it works The cornerstone concept of Joyce is the schema. It allows you to shape the ingested data and how this data will be made available to client services. Using the same declarative approach made popular by Kubernetes, the schemas describe the expected result and the platform performs the actions to make it happen. Schemas are standard JSON schema files stored and classified in a catalog. Their definition falls into three categories: Input – how to gather and shape the source data. We leverage the Kafka Connect framework to provide ready-made connectors for a wide variety of sources. The ingested data can be filtered, formatted, and enriched with transformation handlers (domain-specific extensions of JSON schema). Model – allows you to create new aggregates from the data stored in the platform. This feature gives the freedom to model the data the way needed by client services. Export – bulk data export capability. Exported data can be any query run against the existing data with an optional temporal filter. Input and model data is made available to all the client services with the proper authorization grants through auto-generated REST and GraphQL APIs. It is also possible to subscribe to a dedicated topic if an event-driven approach is more suitable for the use-case. MongoDB: the key for a flexible model and performance at scale We heavily rely on MongoDB. Thanks to its flexibility, we can easily map any data structure the user defines to collect the data. Half of the schema definition is basically the definition of a MongoDB schema. (We also auto-generate one schema per collection to guarantee data integrity.) Joyce runs in a Kubernetes cluster and all its services are inherently stateless to exploit the full potential of horizontal scaling. The architecture is based on the CQRS pattern. This means that writes and reads are completely decoupled and can scale independently to meet the unique needs of the production environment. MongoDB is also the backing database of the API layer so we can keep the promise of low latency, high throughput, and continuous availability along all the components of the stack. The platform is available as a fully managed PaaS on the three major cloud providers (AWS, Azure, GCP) but if needed, it can be installed on an existing infrastructure (in cloud and on prem). Final considerations There are many challenges leaders must face for a successful digital transformation. They need to guide their organizations along a process that involves changes on many levels. The exponential growth of technological solutions in the last few years adds more complexity and confusion. The evolution of organizational models and methodologies point in the direction of shared responsibility, people empowerment, and autonomous teams with a light and effective central governance. The same evolution also permeates the novel approaches to enterprise architectures like the data mesh. Unfortunately, there’s no silver bullet, just the right choices for the given context. Despite all the marketing and hype around this or that one solution to all of your digital transformation needs, a long term successful shift needs guidance, competence and empowerment. We’ve built Joyce with the aim of reducing the burden of repetitive tasks and boilerplate code to get the results faster and catch the low hanging fruits without trying to replace the necessary architectural thinking to properly define the current state and the evolution of the enterprise architectures of our customers. If you’re struggling with the problems enlisted at the beginning of this article you should give Joyce a try. Learn more about Joyce
FHIR Technology is Driving Healthcare's Digital Revolution
Technology supporting healthcare’s digital transformation is so pervasive that the question isn’t what technology to choose, but rather, what problems need to be solved. Advancing technology and access to secure and real-time data analytics will vastly improve patients’ health and happiness, and growing interoperability standards are pushing organizations forward in their digital transformations. Together with the Healthcare Information and Management Systems Society (HIMSS) and leading healthcare insurance provider Humana , MongoDB recently released a three-part podcast series chronicling the ways Fast Healthcare Interoperability Resources (FHIR), AI, and the cloud are reshaping healthcare for the better. Here’s a quick roundup of our discussions. Data is the future of healthcare . Whether providers are driving patient engagement through wearable devices, wellness programs or connected care, data will take healthcare to the next digital frontier. We’ll see these advancements through AI, FHIR, and the cloud. FHIR is revolutionizing healthcare technology . Not only is FHIR implementation a requirement, it’s also a crossroads for data architects. Choosing the right approach has deep implications for healthcare IT. The operational data layer (ODL) approach to interoperability makes the impossible possible . Through Humana’s digital transformation journey, it became clear that meaningful progress isn’t possible using core legacy database systems. AI, FHIR, and the cloud: Why data is the future of healthcare In this episode , we dive into what a digital transformation would look like for the healthcare industry, and what are some of the biggest technology challenges facing healthcare today. A digitally transformed healthcare industry will weave real-time data analytics with more personalized care. Patients today want a more modern healthcare experience that includes telemedicine, digital forms and touchless mobile check ins. The end goal is simple: maximize the human experience while advancing away from legacy technology systems that slow down both healthcare practitioners and patients. When it comes to today’s biggest healthcare challenges, the cloud stands out as a key driver of promise and peril. The promise is that we can build applications, go to market and reach patients through wellness programs more quickly. The peril lies in the infrastructure, which is unknown to many healthcare organizations. This presents a unique challenge for the architects and certainly the developers at organizations with older legacy systems. The challenge here is avoiding a simple left hand shift or cloud for the sake of cloud, and moving from simple modernization to actual transformation. Listen below to hear the entire conversation Your browser does not support the audio element. Bring the FHIR inside for digital transformation In episode 2 , HIMSS and MongoDB take a closer look at why FHIR is a change agent in healthcare technology, and how healthcare organizations globally are using the new data standard to jump start legacy modernization and digital transformation. What is FHIR? The FHIR standard is a common set of schema definitions and APIs that helps providers and patients manage and exchange healthcare data. Using FHIR, records provided by healthcare organizations are standardized into a common data model over rest-based APIs. It makes the data that healthcare providers and payers use easier to exchange. Growing regulatory pressure has accelerated U.S. FHIR adoption among healthcare organizations and technology vendors.The Centers for Medicare and Medicaid Services (CMS) started a rolling deadline for FHIR compliance in 2020, with fines for institutions that fall behind. As a result, for most U.S.-based healthcare providers, payers, and their technology vendors, the past few years were a headlong race to adopt FHIR. Here are three reasons why FHIR is hugely significant for healthcare technology leaders: It’s a federal mandate from the Centers for Medicare & Medicaid Services. It’s a complex data integration challenge. Legacy systems built before the mid 2010s are not interoperable with the FHIR mandate. FHIR implementation approaches For large organizations with huge data requirements, data architects can experience paralysis from the sheer volume of legacy systems to unwind. These groups have all of their patients’ electronic healthcare record information, payer information and more bound up in legacy systems, none of which is interoperable with FHIR. The second challenge is cloud migration, which can be skirted by organizations using a checkbox compliance approach. In those cases, API layers are used to ingest and serve data to legacy systems, but are not really integrated with the legacy system in real time. The most successful approach to tackling this challenge is not to rewrite, unwind or replace legacy systems completely, but keep them contained. We recommend bringing in an operational data layer that exposes the information in the legacy system and keeps it in sync with the legacy system, but then lands it in an ODL in the FHIR standard. With the FHIR API, patients and providers can interact with data in real time and access records in milliseconds after a diagnosis. Real-time records synced with legacy systems and patients’ private data is protected. Delve into the full conversation below Your browser does not support the audio element. FHIR and the future of healthcare at Humana You don't have to take the rip and replace approach when modernizing your legacy systems with an ODL method. This was a key to successful modernization for Humana, as discussed in the third and final episode in our series. For large enterprises that may have decades’ worth of acquired legacy systems, often pulling similar datasets from disparate databases, the pursuit of modernized interoperability begins to look like an impossible task. Listen to the final episode of our podcast series to here how Humana’s ODL approach met the company’s data velocity requirements, and next steps for personalized healthcare and interoperability at Humana. Listen to the entire conversation below Your browser does not support the audio element. More related FHIR and healthcare resources [ White paper ] Bring the FHIR Inside: Digital Transformation Without the Rip and Replace [ On-demand webinar ] Building FHIR Applications with MongoDB
Corporate Sales at MongoDB: Meet the Reps
MongoDB Corporate Account Executives sell into some of the world's highest growth and IT-focused companies, with a goal of securing net new logos in organizations of up to 1500 employees. They drive and build solutions that serve the best interest of our customers to help them innovate faster than ever before, often working directly with CTOs, Engineering/IT leaders, and technical end users. A majority of our Corporate Sales team sits in Austin, Texas, with other reps and leaders spread across the U.S. Meet three Corporate Account Executives to learn about their experience in the role and why our Corporate Sales org is a great place to grow your career. Sebastian Cañizares , Sr. Corporate Account Executive, Austin I joined MongoDB as a Cloud Account Executive back in 2019 to build a career. Not knowing it at the time, I felt I had reached a personal sales career plateau. I wanted a challenge in an industry that was vastly different from what I was accustomed to, with a sales process that could help me create a strong foundation. MongoDB sold me on three things: The “Sales MBA” : I didn't know of any other company investing as much time and resources on an individual as MongoDB was. A sales team with a formalized sales process and a full-fledged sales enablement team caught my eye. Leadership : The leaders at MongoDB come from diverse backgrounds. Going through the interview process I spoke with multiple leaders that challenged me intellectually and at the same time were so selfless. I was leaning in further. Market opportunity : At the time, MongoDB was a tiny piece of a growing database pie. Noticing the trends in the market, I wanted to be a part of a company that was positively influencing how technology was being made. Data was at the crux of it all, and MongoDB was challenging a legacy mindset while at the same time establishing incredible groundswell among its core community: developers. Now it was a matter of capitalizing on it and MongoDB was. I was fully bought in. I’m so glad I joined MongoDB back then, and truly believe it was a career altering decision. After nine months in the Cloud role, I transitioned to a Corporate Account Executive. If you haven’t read about our BDR to CRO program , the transition from Cloud to Corporate was one of the first internal sales promotion tracks that the Corporate Sales org built out. There was a promotion path in place with clear guidelines on what was needed to not only reach the next step but also excel in it. During the transition, I had the benefit of following reps that had gone through the process before me and were successful in that next role. They never hesitated in offering their time, helped whenever anyone asked, and created an environment that was both collaborative and positive. Additionally, the leadership team challenged me every step of the way. I was developed in the Cloud role by a former sales rep (who became my manager) who enabled me with the information and knowledge to foundationally succeed at MongoDB. He invested time and resources, and I’ll be forever grateful for the opportunity he prepared me for. Not only that, I had support from other leaders that wanted to see me succeed. They met with me on a regular basis, mentored me, and helped me gain a footing in the Corporate role. MongoDB’s leadership fosters a merit-based culture all while supporting you along the way. I experienced that in my transition from Cloud to Corporate and still see it in my current role today. It is rare that a company holds up to the things they say during the recruiting process, let alone over-deliver. MongoDB has done just that. I’ve been able to grow my sales career while also getting to talk to people daily that are creating things that are changing the way we interact with technology. It’s the perfect blend of career opportunity, intellectual curiosity, and enablement that I don’t believe I could get anywhere else. Now, why should someone join the Corporate Sales team? You get to witness a company that is fundamentally changing the status quo at the highest level You receive an enormous investment in sales enablement You collaborate with a team that is hungry, competitive, and best in class You work for an established company that is constantly innovating and growing You learn from some of the best sales leaders out there You grow your career at a company that values meritocracy and promotes from within You get to help build history Paige Springfield , Sr. Corporate Account Executive, Austin I took a leap and joined MongoDB in April 2020. When evaluating the opportunity, I had three top criteria. Market opportunity : MongoDB is a leader in the database industry and we’re just getting started. The product is best-in-class and mission critical to customers across all industries - this means uncapped opportunity and earning potential. The team : It was extremely important to me to be surrounded by colleagues who would uplevel and challenge me. Growth and development potential : MongoDB (especially the Corporate Sales org) is just getting started. We’re positioned to grow exponentially in the next two years and the number one focus across the leadership team is people development and promoting from within. At previous companies, I never felt invested in from a sales enablement perspective. Ramping typically meant a couple 1-hour training sessions and then it was off to the races. Here at MongoDB, I was blown away by the onboarding and training process from day one. I’d compare the experience to getting your MBA in sales. I think it speaks to leadership’s commitment to invest in people, their development, and ultimately their long term success. Our Sales Enablement team set me up with all the tools I needed to master the complex technology and a repeatable sales process. I’ve been on the team for a year and a half and seen a ton of success. Recently, I was promoted to a senior-level sales role and accepted into leadership upskill as part of our BDR to CRO program. Working at MongoDB has been the most transformative, rewarding time in my career. If you’re looking to uplevel yourself (both professionally and personally), the Corporate Account Executive role is an incredible opportunity. Drew Oros , Corporate Account Executive, New York City I joined MongoDB for three key reasons. Professional Development : My long-term goal is to become a professional executive for pre-IPO tech companies. I see a tremendous opportunity to build that expertise in the cloud infrastructure/services space. I know to get there, I need a great story selling technology that’s mission critical and best in class - that’s without a question MongoDB, and it has given me a great opportunity to start writing that story. Leadership and people : It was important to me to be around leaders and sellers I feel I could learn from, as I'm a firm believer that your network is equal to your net worth. At MongoDB, I feel like I’m surrounded by current and future household names in the software industry. Product and market opportunity : I only want to sell best in class, mission critical technology. It also has to be the right timing, and have a huge, total addressable market, and strong go-to-market motion. I knew if I found that, magic would happen. MongoDB is the most downloaded NoSQL database , and it fits a wide variety of use cases for mission critical applications. The TAM is estimated to be $82 billion by 2022 , and MongoDB’s sales org and process are key differentiators. Ramping into the Corporate Account Executive role can be challenging, however, you are amongst some of the best people in the software industry to learn from. I identified the skills that were key to becoming a great seller and met with three to five of the top reps to learn how they created a pattern of success in each of those areas. Ultimately, I identified pipeline generation best practices, meeting preparation, discovery calls, New Business Meeting excellence, champion building, and paper process as the key skills fundamental to creating, moving, and closing pipeline. “Build together” is one of MongoDB’s core values and a big reason why colleagues are so open to sharing what makes them successful. If you put in the time and effort, there’s no shortage of resources to learn from here. Overall, this year has been a great success story for me as I’m 200%+ of my yearly number and won the Most New Logos award in Q3. We believe in a culture of promotion - internal promotions are core to MongoDB’s culture and strategic to how the company scales. MongoDB does not get in the way of your personal growth, but rather accelerates it. The BDR to CRO program lays out what good versus great looks like and what you need to do in order to move farther down that path. Whatever your career goals are, MongoDB is a company that supports your interests and provides the investment to help get you there. Interested in pursuing a career in Corporate Sales at MongoDB? We have several open roles on our teams across the globe and would love for you to transform your career with us!
엔지니어링과 DIRT 비용 감소: 시대에 뒤처진 데이터 아키텍처가 혁신을 가로막는 걸림돌인 이유
저는 지난 2021년 3월, 혁신세 The Innovation Tax 에 관한 글을 썼습니다. '혁신세'는 번거로운 프로세스와 시대에 뒤처진 기술로 인해 엔지니어링 팀이 고객을 만족시킬 만한 우수한 기술을 개발하지 못하는 상황을 일컫는 말입니다. 이후로 몇 개월이 지나면서 저의 생각은 훨씬 더 발전했습니다. 앞으로 얼마나 많은 기술 임원이 자신의 회사에서 이러한 문제점을 빠르게 알아차리고 깊은 상실감을 저에게 털어놓을지 짐작조차 못할 정도입니다. 이번 포스팅에서는 수없이 많이 받은 피드백과 함께 제 생각이 어떻게 발전했는지 알려드리겠습니다. 또한 혁신세의 부담을 줄이기 위해 실천할 수 있는 방법도 전해드리겠습니다. 이를 마다할 분은 없으시겠죠? 혁신세는 소득세처럼 실제로 존재합니다. 물론 고객 이탈과 감소로 인해 사기가 떨어지기도 하지만 그뿐 아니라 금융 및 기회 비용도 발생하기 때문입니다. 혁신세 부담이 큰 기업들은 인력과 자원이 혁신이 아닌 유지보수에 집중되어 있어 혁신에 뒤처지는 경우가 많습니다. 우리는 이를 DIRT 비용이라고 합니다. 왜 DIRT일까요? 먼저 DIRT는 데이터(D)에서 발생합니다. 최신 애플리케이션은 실시간 데이터에 액세스하여 풍부한 사용자 경험을 창출해야 하지만 기존 데이터베이스로는 이를 지원하는 데 어려움이 따를 때가 많기 때문입니다. DIRT는 혁신(I)에 영향을 미칩니다. 개발 팀이 복잡하고 취약한 아키텍처를 지원할 방법을 찾기 위해 끊임없이 고심해야 한다면 혁신에 쏟을 시간이 거의 없기 때문입니다. DIRT는 비일회성이라서 반복적으로(R) 일어납니다. 마치 세금(T)처럼 한 번만 내면 해결할 수 있는 비용이 아니기 때문입니다. 오히려 그 반대입니다. 새로운 프로젝트가 있으면 여러 다른 팀이 관리해야 하는 구성요소, 프레임워크 및 프로토콜이 늘어나기 때문에 DIRT가 발생하여 새로운 프로젝트의 어려움이 더욱 커지기 마련입니다. 돌이켜 보면, 기술 임원들은 분명히 이러한 비용을 인지하고 데이터 아키텍처에서 얼마나 발생하는지, 혹은 얼마나 절감할 수 있는지 파악하려는 노력을 시작했을 것이 분명합니다. 데이터는 까다롭 전략적이며 대규모에 난해하지만 최신 디지털 기업에 없어서는 안 될 핵심 요소입니다. 최신 애플리케이션은 불과 10년 전에 개발했던 애플리케이션과 비교해 봐도 데이터 요건이 훨씬 더 정교해졌습니다. 데이터가 늘어난 것도 분명한 사실이지만 복잡성은 더욱 커졌습니다. 기업은 데이터에서 보내는 신호에 보다 빠르고 현명하게 대응해야 합니다. 하지만 경직되고 비효율적인 단일 모델이면서 프로그래밍이 어려운 관계형 데이터베이스를 포함하고 있는 기존 기술은 이러한 기대에 부응하지 못합니다. 제가 2020년 MongoDB에 입사한 이후 지금까지 300회 넘게 최고 임원들과 대화를 나누었지만 이 문제를 언급한 CTO는 손가락으로 꼽을 만큼도 안 됩니다. 엔지니어링 팀이 기술 스택에서 새로운 애플리케이션의 요건을 처리하지 못하면 필요한 작업(시계열, 텍스트, 그래프 등)에 따라 단일 목적 데이터베이스를 추가하는 경우가 많습니다. 그런 다음 연속되는 파이프라인을 구축하여 데이터를 이리저리 마이그레이션합니다. 그 결과, 모든 것이 느리고 복잡해질 뿐만 아니라 정치적이 되기도 합니다. 하지만 이제, 복잡한 LinkedIn 프로필을 다듬을 때가 되었습니다. 자주 눈에 띄지 않는다면 무시하고 넘어갈 수도 있습니다. 하지만 대기업들은 수백 개에서 수천 개에 이르는 애플리케이션을 사용할 뿐만 아니라 각 애플리케이션마다 데이터 소스나 파이프라인이 다를 수도 있습니다. 시간이 지나 데이터 스토어와 파이프라인이 곱절로 늘어나면 기업의 데이터 아키텍처는 마치 복잡하게 얽힌 스파게티 뭉치처럼 보이기 시작합니다. 결국 얼마 지나지 않아 ETL, ELT, 스트리밍 등 완전한 미들웨어 계층을 운영하면서 유지보수까지 해야 합니다. 프레임워크와 프로토콜, 그리고 간혹 언어까지 다른 기술의 다양성은 개발자 협업을 더욱 어렵게 만드는 원인입니다. 모든 아키텍처가 맞춤 설계로 인해 취약하고 불안정하기 때문에 확장은 더더욱 어렵습니다. 개발자는 기업과 고객이 원하는 새로운 애플리케이션과 기능을 개발하지 못하고 통합 작업에 매달리느라 소중한 '워크플로' 시간을 허비합니다. 기업 아키텍트는 결국 잘못된 일을 해결하는 데 시간을 보낼 때가 많아지는 것입니다. 저는 대부분의 고객은 새로운 데이터 아키텍처 접근 방식을 도입할 준비가 되어 있다고 생각합니다. 제 업무 중에서 가장 좋은 점은 다른 최고 임원들의 얘기를 들으면서 정보를 얻을 수 있다는 것입니다. 팬데믹으로 인해 직접 만나서 얘기를 들을 수 없게 된 후 MongoDB가 이러한 기회를 온라인으로 옮겨 기술 임원들을 초대한 덕분에 온라인에서 일대일로, 혹은 그룹으로 만나 가장 커다란 문제가 무엇인지 터놓고 대화를 나눌 수 있습니다. 이러한 온라인 세션에서 한 CTO는 이렇게 말했습니다. “CFO의 대차대조표에 기술 부채도 들어가야 합니다.” Zoom에서도 이러한 발언은 분명히 설득력이 있었습니다. 저희는 또한 잘 알려진 일부 벤처 캐피탈 회사가 데이터 아키텍처를 설명한 슬라이드 데크도 살펴보기 시작했습니다. 벤처 캐피탈 회사는 자사의 포트폴리오 회사들을 각각 미래의 데이터 아키텍처 분야에서 유력한 업체로 반드시 포지셔닝해야 합니다. 하지만 전반적인 비전은 강렬하지 못했습니다. 한 기술 임원은 “스무 가지 신기술을 보면서 더 배워야 한다고 느꼈습니다. 정말 엄청나더군요.”라고 말했습니다. 다른 임원들도 이런 아키텍처 다이어그램을 보는 것만으로도 약간 당황스럽다고 밝혔습니다. 자사의 데이터 아키텍처가 그 정도로 복잡하다는 사실을 이미 알고 있었기 때문입니다. 대부분 데이터 아키텍처의 간소화 필요성을 알고 있지만 너무 버거운 작업이다 보니 기약 없이 미루고 있었습니다. 저는 최근에 대형 헬스케어 회사를 만났습니다. 이 회사의 임원들은 데이터 아키텍처 간소화를 어렵게 생각했지만, 과감히 작업에 착수한 결과 이제는 간소화는 반드시 필요할 뿐만 아니라 복잡하게 얽힌 데이터 아키텍처를 풀어가는 과정에서 많은 정보를 습득할 수 있다는 사실을 알게 되었다고 했습니다. 대부분 경우 혁신세는 새로운 기술을 생각조차 못하는 무능력에서 발현됩니다. 이는 기본적인 아키텍처가 너무 복잡해서 유지보수에 어려움을 겪다 보니 설상가상으로 잘 알지도 못해 바꿀 생각도 못하기 때문입니다. 수많은 대기업 임원들이 혁신의 둑을 손가락으로 막은 채 앉아서 은퇴만 기다리고 있는 이유가 바로 이것입니다. 자신들은 현대화할 수 없다고 생각하는 것입니다. MongoDB가 어떻게 이러한 문제를 해결했는지 들어보면 놀랄 일도 아닙니다. 범용 데이터베이스도 모든 유형의 데이터를 빠르게 대규모로 처리할 수 있기 때문입니다. 지금부터 자세하게 알려드리겠습니다. 저는 35년 동안 데이터베이스를 전문적으로 다루는 일을 하다가 한 가지 이유로 MongoDB에 입사했습니다. 제가 최소 30년 동안 만들고 싶었던 데이터베이스 및 애플리케이션 개발 환경을 MongoDB에서 구축할 수 있다는 확신이 생긴 것입니다. 이제 MongoDB의 비전은 데이터베이스를 넘어 더욱 광범위한 다양한 목적으로 사용될 뿐만 아니라, 어떤 유형의 애플리케이션이든 개발 방식을 가속화하고 간소화할 수 있는 애플리케이션 데이터 플랫폼을 향해 나아가고 있습니다. 이러한 변화는 예나 지금이나 변함없이 데이터를 통한 작업 용이성이라는 원대한 목표를 향한 거침없는 열정을 잘 보여줍니다. 우리는 데이터가 걸림돌이 아닌 혁신의 원동력으로 사용되기를 바랍니다. 그리고 마침내 기술 팀이 무분별한 기술 투자로 복잡하게 얽힌 스택을 풀고 DIRT를 제거할 수 있게 되기를 바랍니다. 그럼, 어디서부터 시작해야 할까요? 먼저 DIRT가 어떻게 기술 팀의 발목을 붙잡는지 정확하게 이해해야 합니다. 개발자들이 개발 환경의 파편화로 인해 협업에 어려움을 겪고 있습니까? 지원하려는 애플리케이션 변경 사항과 비교했을 때 스키마 변경 사항을 배포하는 시간이 더 오래 걸립니까? 고객을 전방위적으로 파악할 수 있는 시야를 구축하는 데 어려움이 있습니까? 만약 그렇다면 이유는 무엇일까요? 이러한 질문은 DIRT 분석을 처음 시작할 때 유용한 출발점이 됩니다. 또한 애플리케이션과 데이터 소스뿐만 아니라 데이터를 애플리케이션 데이터 플랫폼으로 마이그레이션하는 데 필요한 부분까지 주의 깊게 살펴보는 것이 좋습니다. 예를 들어 애플리케이션 객체를 비롯해 이러한 객체와 상호작용하는 애플리케이션을 전부 살펴보세요. 그런 다음에는 속성, 메소드, 컬렉션 등에 따라 각각 복잡성 점수를 할당할 수 있습니다. 이제 다시 돌아가서 각 객체에 연결되는 애플리케이션을 일일이 확인한 후 미션 크리티컬 수준, 애플리케이션 사용자 수, 애플리케이션에서 실행해야 하는 작업 수, 그리고 각 작업의 복잡성을 기준으로 등급을 매기세요. 이를 통해 모든 복잡성을 완전히 이해했다면 더욱 유리한 위치, 즉 복잡성과 통합 필요성이 가장 적은 데이터 소스부터 시작해서 계획을 세워 기존 시스템에서 벗어날 수 있습니다. 물론 측정 지표나 이점은 상황에 따라 다르지만 출발점으로는 손색이 없습니다. 그렇다고 이런 과정이 쉽다는 뜻은 아닙니다. 많은 분이 그러하듯 저는 지금까지 직무 경험을 쌓으면서 이 문제를 해결하는 데 대부분 시간을 할애해 왔습니다. 이 말은 이 문제가 어떻게 진행되는지 뿐만 아니라 기업이 DIRT를 청산할 수 있는 방법의 시발점까지 제가 잘 알고 있다는 뜻이기도 합니다. 저는 앞으로도 계속해서 이러한 당면 과제에 대해 글을 쓸 것이며 여러분에게 혜안을 드릴 수 있기를 바랍니다. DIRT에 대해 자세히 알고 싶으시면 MongoDB 백서를 다운로드 하시기 바랍니다. 늘 그렇듯 저는 여러분의 찬반 의견이나 다른 견해를 두 팔 벌려 기다립니다. @MarkLovesTech 로 트윗을 남겨주세요. 또한 marklovestech.com 에서도 MongoDB를 비롯해 그와 관련된 저의 요즘 생각들을 확인하실 수 있습니다.
Introducing Pay as You Go MongoDB Atlas on AWS Marketplace
We’re excited to introduce a new way of paying for MongoDB Atlas . AWS customers can now pay Atlas charges via our new AWS Marketplace listing . Through this listing, individual developers can enjoy a simplified payment experience via their AWS accounts, while enterprises now have another way to procure MongoDB in addition to privately negotiated offers, already supported via AWS Marketplace. Previously, customers who wanted to pay via AWS Marketplace had to commit to a certain level of usage upfront. Pay as you go is available directly in Atlas via credit card, PayPal, and invoice — but not in AWS Marketplace, until today. With this new listing and integration, you can pay via AWS with no upfront commitments . Simply subscribe via AWS Marketplace and start using Atlas. You can get started for free with Atlas’s free-forever tier , then scale as needed. You’ll be charged in AWS only for the resources you use in Atlas, with no payment minimum. Deploy, scale, and tear down resources in Atlas as needed; you’ll pay just for the hours that you’re using them. Atlas comes with a Basic Support Plan via in-app chat. If you want to upgrade to another Atlas support plan , you can do so in Atlas. Usage and support costs will be billed together to your AWS account daily. If you’re connecting Atlas to applications running in AWS, or integrating with other AWS services , you’ll be able to see all your costs in one place in your AWS account. To get started with Atlas via AWS Marketplace, visit our Marketplace listing and subscribe using your account. You’ll then be prompted to either sign in to your existing Atlas account or sign up for a new Atlas account . Try MongoDB Atlas for Free Today!
10 Signs Your Data Architecture is Limiting Your Innovation: Part 2
With the massive amounts of data organizations now ingest, store, and analyze comes a massive responsibility to monitor, manage, and protect it. Unfortunately, many businesses are functioning with little insight into how their data is stored and who is accessing it — and their overly complex data architecture can turn those challenges into Frail security can lead to unnecessary risk, and if you are not in control of your data architecture, the next big compliance offender or data breach victim could be you. These risks — and the time and resources required to address them — make up part of a hidden tax on your innovation. We call it DIRT — the Data & Innovation Recurring Tax . Our experts have identified 10 symptoms that can indicate your business is paying DIRT — read about them all in our white paper 10 Signs Your Data Infrastructure is Holding You Back , and check out Part 1 of this blog series. Here, we highlight two signs of this innovation tax that are all about security. Symptom #3: That last big data breach — or the next one — is on you The more complex your data architecture, the more threat vectors you need to cover and the more complicated and time-consuming it becomes to maintain security. Each data store and application may have its own security framework and requirements — its own access controls, role definition, and login procedures. Each database may in turn be connected with multiple other technologies and vendors, further adding to the time and complexity needed to keep everything secure. That’s a drag on your team: Some 30% of IT managers spend more than 16 hours a month just on patching, and 14% spend more than 48 hours a month. Often, it’s impossible to keep up: 42% of breaches are the result of an attack for which a patch was available but not applied, according to a Ponemon Institute study of IT professionals. On average, 28% of vulnerabilities remain unaddressed. Our Solution: With an application data platform, you have one set of database and data service components that share the same developer experience and the same underlying operational and security characteristics, making it a lot easier to defend. Organizations can use a single overarching security policy and implementation without having to reinvent the wheel every time someone has a new use case for the data. Maintaining audit logs and access is dramatically streamlined. You get both security and speed. Symptom #4: Rampant data duplication makes compliance a nightmare In a modern organization, every part of the business should have access to the data and insights that help optimize performance and meet customer demand. But most data is trapped in silos, each with its own formats, access, and authorization controls. Attempts to address data silo issues often create their own web of separate niche data technologies, each trying to solve the problem. That can create a lot of data duplication — so even your IT leaders may not know who has copies of which data, or even how many copies there may be. That’s obviously a problem for security reasons. It also makes it extremely difficult to comply with regulations such as GDPR and the California Consumer Privacy Act, or to respond effectively to audits. How can you tell your regulators exactly where personally identifying information sits, or where it has been, when you don’t even know how many copies exist? Our Solution: Eliminate silos in the first place by using an application data platform, which addresses many of the use cases that would otherwise spur teams to duplicate data. And, with MongoDB, you can federate queries across multiple sources so you don’t have to move data into different formats. Our next installment will focus on your developers’ time, how it’s spent and the price you pay when they can’t find the time to develop and roll out best-in-class features. For a complete view of DIRT, read our white paper DIRT and the High Cost of Complexity .