I originally wrote this article after five years of working at MongoDB. Seven years later, the post is still as accurate as the day it was published. This article highlights the broad range of technology and sales skills required to be successful as a Solutions Architect (SA) at MongoDB, skills which led me to claim (and still claim) that you have to be the best of the best to be an SA here. However, MongoDB has changed, the technology landscape has changed, the Solution Architect role has changed, and I have changed along with them. This change has been pioneered by the SA organization.
Before taking a look at how SAs pioneered some of MongoDB’s evolution, let’s take a look at some of the biggest changes at MongoDB since I wrote this article:
MongoDB Atlas: Atlas has become the platform by which most organizations use MongoDB for production workloads.
Unified database platform: MongoDB has transitioned from a database company to a full-featured unified database platform expanding to include full-text and vector search, stream processing, and time series data, thus enabling a single platform and query language to support all required data operations to build modern applications.
Generative AI: MongoDB has become the preferred way many organizations build AI applications and use AI to rapidly modernize legacy applications and eliminate technical debt.
In terms of technical knowledge, MongoDB SAs now need to have a detailed understanding of everything I listed in the original article, plus:
A technical understanding of all three cloud providers, cloud security, and how to securely deploy applications in Atlas. SAs are strongly encouraged to obtain or expand their cloud certifications during their MongoDB tenure.
An understanding of how to build applications using all the capabilities of the unified database platform beyond the core database.
An understanding of how to build AI applications using LLMs and surrounding GenAI technologies. The MAAP reference architectures provide as much guidance to our customers as to new MongoDB SAs.
It can be a lot, but it is also a great way to expand your technical expertise, grow your career, and ensure that your skills are current.
One perspective I failed to capture in the original article is how the Solutions Consulting organization has been a centerpiece in driving the evolution of MongoDB. This is probably due to the unique position SAs play at the intersection of customer sales and delivery conversations, product marketing feedback, and technology. Consider MongoDB’s support for Generative AI, exemplified by the Modernization Factory and MAAP programs.
The kernel of the idea that led to the Modernization Factory came from one of my colleagues. After some hard internal selling, the SA organization held a hackathon to brainstorm and conceptualize what type of application modernizations were possible with GenAI. (For those curious, the hackathon was set up as North America versus Europe with each region building 4 applications and was judged by a cross-functional team including many members of MongoDB’s executive staff, including our CEO, Dev Ittycheria. North America won) The power of the ideas generated by the hackathon led to the first Modernization Factory projects, and those successes led to the expansion of the Modernization Factory program.
The genesis of the MAAP program followed a similar trajectory: internal hackathons expanding our understanding of how MongoDB could be leveraged as the platform for GenAI applications. It also produced a set of compelling customer demos that have been leveraged to expand customer understanding of the value of using MongoDB as the data platform for AI applications. This set of initial ideas and proof of concepts was then formalized by MongoDB’s product and partner teams into MAAP.
The one thing that has always been constant at MongoDB is change—I’m certain that the Solutions Consulting organization will continue to play a role in pioneering it.
The best solutions architects work at MongoDB
Despite the bravado in the title, the purpose of this article is not to say that MongoDB Solutions Architects (SAs) are better than those working at other organizations. Rather, this article argues that the unique challenges encountered by SAs at MongoDB imply that successful MongoDB SAs are some of the best in the business. This assertion is derived from the unique challenges encountered by both supporting MongoDB customers and the MongoDB sales organization, and the breadth and depth of skills and knowledge required to be successful.
To see why this is the case, let’s explore the role of an SA at MongoDB and the wide range of skills a Solutions Architect must master. A MongoDB SA (sometimes called a Sales Engineer in other organizations) is an engineer who supports the sales organization. The role is multi-faceted. A solutions architect must have:
In-depth technical knowledge to both understand a customer’s technical challenges and to articulate how MongoDB addresses them
Communication skills to present technical concepts in a clear and concise manner while tactfully dealing with skeptics and those more familiar with other technologies
Sales skills to engage a prospect to learn their business challenges and the technical capabilities required to address those challenges
Design and troubleshooting skills to assist prospects with designing solutions to complex problems and getting them back on track when things go wrong.
The description above may make the MongoDB Solutions Architect role sound like other similar roles, but there are unique features of MongoDB (the product) and its competitive situation that make this role extremely challenging. We will explore this in the sections below.
Technology
While the strength of MongoDB and a major factor in its success has been the ease with which it can be adopted by developers, MongoDB is a complex product. Presenting MongoDB, answering questions, brainstorming designs, and helping resolve problems requires a wide range of knowledge, including:
The MongoDB query language
Application development with MongoDB’s drivers in 10+ different programming languages
Single and multi-data center architectures for high availability
Tuning MongoDB to achieve the required level of performance, read consistency, and write durability
Scaling MongoDB to manage TBs of data and thousands of queries per second
Estimating the size of a cluster (or the cloud deployment costs) required to meet application requirements
Best practices for MongoDB schema design and how to design the best MongoDB schema for a given application
MongoDB Enterprise operations tools: Ops Manager, Compass, etc.
Atlas: MongoDB’s Database as a Service Offering
MongoDB’s various connectors: BI/Atlas SQL, Spark, and Kafka.
Migration strategies from RDBMS (and other databases) to MongoDB and Relational Migrator.
This is a lot to know, and there is a lot of complexity. In addition to the core knowledge listed above, understanding the internal workings of MongoDB is essential when designing applications with high-performance and scalability requirements. Therefore, most Solutions Architects understand MongoDB’s internal architecture, such as how the WiredTiger storage engine works or how a MongoDB cluster manages connections.
This is a lot to know, and there is a lot of complexity. In addition to the core knowledge listed above, understanding the internal workings of MongoDB is essential when designing applications with high-performance and scalability requirements. Therefore, most Solutions Architects understand MongoDB’s internal architecture, such as how the WiredTiger storage engine works or how a MongoDB cluster manages connections.
To make the SA role even more challenging, organizations often choose MongoDB after failing with some other technology. (Maybe their RDBMS didn’t scale, or it was too difficult to expand to handle new sources of data, or Hadoop processing did not meet real-time requirements, or some other NoSQL solution did not provide the required query expressibility and secondary indexes.) This means that MongoDB is often used for bleeding-edge applications that have never been built before. One of the roles of an SA is to understand the application requirements and help the application team come up with an initial design that will ensure their success1.
It is probably obvious to experienced SAs, but SAs need to understand the capabilities, strengths, and weaknesses of all competing and tangential solutions as well. MongoDB’s biggest competitors are Oracle, Amazon, and Microsoft – all of whom are constantly evolving their product offerings and marketing strategies. An SA must always keep their knowledge up to date as the market evolves.
Communication
Being a great technologist is not enough. An SA spends at least as much time communicating with customers as they do working with technology. Communication is sometimes in the form of a standard presentation or demo, but it most often entails detailed technical conversations about how MongoDB works or how MongoDB can be used to address a particular problem. Concise technical explanations that address customer questions using language tailored to their particular situation and frame of reference are the hallmark of an SA.
MongoDB SAs have to be comfortable communicating with a wide range of people, not just development teams. They must engage operations, line of business stakeholders, architects, and technology executives in sales discovery conversations and present the technical aspects of MongoDB of most concern at the appropriate level of detail. For example, an SA must be able to provide technology executives with an intuitive feel for why their development teams will be significantly more productive with MongoDB or will be able to deploy a solution that can meet scalability and performance requirements unattainable with previous technology approaches.
Similarly, an SA must learn an operations team’s unique challenges related to managing MongoDB and describe how tools like Ops Manager and Atlas address these requirements.
Public speaking skills are also essential. Solutions Architects deliver webinars, speak at conferences, write blog posts, and lead discussions and MongoDB User Groups (MUGs).
Sales
An SA is a member of the Sales organization, and “selling” is a big part of the role. Selling involves many aspects. First, SAs assist the MongoDB Account Executives with discovery and qualification. They engage the customer in conversations to understand what their current problems are, their desired solution, the business benefits of the solution, the technical capabilities required to implement this solution, and how they’ll measure success. After every customer conversation, SAs work with their Account Executives to refine their understanding of the customer’s situation and identify information that they want to gather at future meetings.
Once the required technical capabilities are understood, it is the SA’s role to lead the sales activities that prove to the customer that (1) MongoDB meets all their required capabilities and (2) MongoDB meets these capabilities better than competing solutions. Most of the time, this is accomplished via customer conversations, presentations, demonstrations, and design brainstorming meetings.
Finally, customers sometimes want to test or validate that MongoDB will meet their technical required capabilities. This is often in the form of a proof of concept (POC) that might test MongoDB performance or scalability, the ease of managing MongoDB clusters with its operations tools, or that MongoDB’s BI Connector and Atlas SQL provide seamless connectivity with industry-standard BI Tools, such as Tableau. SAs lead these POC efforts. They work with prospects to define and document the scope and success criteria and work with the prospect during the course of a POC to ensure success.
Design and troubleshooting
I alluded to this in the “Technology” section: helping prospects with creative problem solving distinguishes SAs at MongoDB. Organizations will choose MongoDB if they believe they understand how it will help them succeed. Imparting this understanding (a big part of the Solutions Architect’s role) is typically done by helping an organization through some of the more thorny design challenges and implementation decisions. Organizations will choose MongoDB when they understand the framework of a good MongoDB design for their use case and believe all their design requirements will be met.
Designing a solution is not a yes-or-no question that can be researched in the documentation, but rather one that is found through deep technical knowledge, careful analysis, and trade-offs among many competing requirements. The best answer is often found through a collaborative process with the customer. SAs often lead these customer discussions, research solutions to the most challenging technical problems, and help craft the resulting design.
Solutions Architects are also a source of internal innovation at MongoDB. Since Solutions Architects spend a significant amount of time speaking with customers, they are the first to realize when marketing or technical material is not resonating with customers or is simply difficult to understand. The pressure of short timelines and the desire to be successful often results in innovative messaging and slides that MongoDB’s Product Marketing organization often adopts.
Similar innovation often occurs with respect to MongoDB feature requests and enhancements. SAs are continually working with customers to help them solve problems, and they quickly identify areas where MongoDB’s enhancements would provide significant value. The identification of these areas and specific recommendations from SAs on what product enhancements are required have played a big role in focusing the feature set of future MongoDB releases.
Project management
Lastly, SAs often support a number of Account Executives and work on several dozen sales opportunities per quarter. This means that SAs are working a large number of opportunities simultaneously and must be highly organized to ensure that they are prepared for each activity and complete every follow-up item in a timely manner. It is not possible for an SA manager to track or completely understand every sales opportunity, so SAs must be self-motivated and manage all their own activities.
Summary
Solutions Architecture at MongoDB is a challenging and rewarding role. The wide range of technical knowledge, plus sales and communication skills required to be successful, is common to SA roles. When you combine this with the need for SAs to design innovative solutions to complex (often previously unsolvable problems), the SAs have the set of skills and the track record of success that makes them the “best” in the business.
If you want to join the best, check out the open roles within Solutions Consulting at MongoDB.
About the author
Jay Runkel is a Distinguished Solutions Architect at MongoDB, where he has spent the past 12 years helping organizations harness the power of modern data solutions. For the past two years, he has served as the North American Technical Lead for MongoDB’s Modernization Factory program, an initiative that leverages generative AI to accelerate the transformation of legacy applications to MongoDB.
Prior to joining MongoDB, Jay was a Principal Technologist at MarkLogic, where he worked with financial services, healthcare, and media companies to build operational systems for analytics and custom publishing. His career spans a wide range of technology domains, including encryption asset management, automated underwriting, product information management, and CRM solutions.
Jay holds a B.S. in Applied Mathematics from Carnegie Mellon University and a Master’s in Computer Science from the University of Michigan.
1 My favorite part of the job is to get locked in a conference room and whiteboard for 4 hours with a development team to brainstorm the MongoDB solution/design for a particular use case. The most valuable end product of this session is not the design, but the development’s belief that they will be successful with MongoDB and that the development process will be easier than they expected.
Source: Read More