At MongoDB World, the largest gathering of the MongoDB Community, you'll see how engineers and technical executives around the world have discovered the power of MongoDB to help them transform their businesses, using MongoDB to take innovative applications from pilot to production in weeks, not months, building high performance systems at scale.
Who's going to be at MongoDB World? Check out our fantastic speaker lineup and see how our speakers have taken their applications to scale at MongoDB World:
The DBA's future as the Database Adviser
With such a large shift towards NoSQL technologies like MongoDB, there is a lot of discussion about the changing role of the Database Administrator (DBA). Many go so far as to say DBAs are no longer needed , an idea driven by new database capabilities that focus on agility with a dynamic schema instead of a fixed schema and features that make operational management easier in areas like high availability and horizontal scaling. Based on my experience working with hundreds of customers to implement MongoDB in their organizations, there is still room for the DBA, even if their everyday tasks might take less time with MongoDB. First, let's talk about the parts of their role that stay the same. There still needs to be someone to set up back-up/recovery processes, handle capacity planning, run maintenance tasks (e.g. upgrades), diagnose issues, do configuration management, and set up replication and sharding. In enterprises, often separate operational teams handle security, monitoring, and diagnosing common issues but that could be part of the DBA's role in some firms as well. Notice I left out schema management; in MongoDB, the implementation of the schema is NOT predefined but is rather determined at the application level and the structure of the object is stored in the application team’s favorite programming language. This is incredibly valuable when business units request new features or data be added to the application. The application developer can simply add it in, and no change needs to be made in the database, enabling rapid agility. In this case, the DBA is no longer the middleman, and can focus on keeping the database up and running. But in some cases, application changes are more complex, and development teams need a database expert to consult about schema design and its impact on performance, maintainability, and other factors. In this case, the role of the DBA transforms into the DB Adviser. In this role, the DB Advisor would work closely with the application development team that implements the schema. The DBA provides the process and due diligence to manage the pace of change rather than enforce the limitations of the relational schema. Implementing the schema in the application might be disconcerting to some DBAs and others out there who rightfully worry about application developers making uninformed decisions and bringing down an application. Letting go of schema management might be a difficult step, but DBAs rely on application developers to make decisions in their application code on a regular basis. Creating a poorly constructed algorithm will bring the system to a crawl and querying fields in unexpected ways would cause performance problems as well. Is choosing schema design in the database so much more responsibility than any other development decision? The DBA should still guide developers, but without the enormous overhead of having to always update a relationship database schema to simply add a field! Your schema should be as dynamic as your business: agile with the optimal amount of control. The DBA has always been the person accountable to ensure the reliability and performance of the database alongside development teams. However, in today's market, the DBA will continue performing most of the activities they do in the former relational-only world, but will advise in other areas to allow their business groups to innovate and iterate faster than their competition. In this shift, the DBAs can take on new roles to help their businesses achieve more, faster. See how you can help your organizations get faster, better and leaner with MongoDB .
The Rise of the Strategic Developer
The work of developers is sometimes seen as tactical in nature. In other words, developers are not often asked to produce strategy. Rather, they are expected to execute against strategy, manifesting digital experiences that are defined by the “business.” But that is changing. With the automation of many time-consuming tasks -- from database administration to coding itself -- developers are now able to spend more time on higher value work, like understanding market needs or identifying strategic problems to solve. And just as the value of their work increases, so too does the value of their opinions. As a result, many developers are evolving, from coders with their heads-down in the corporate trenches to highly strategic visionaries of the digital experiences that define brands. “I think the very definition of ‘developer’ is expanding,” says Stephen “Stennie” Steneker, an engineering manager on the Developer Relations team at MongoDB. “It’s not just programmers anymore. It’s anyone who builds something.” Stennie notes that the learning curve needed to build something is flattening. Fast. He points to an emerging category of low code tools like Zapier, which allows people to stitch web apps together without having to write scripts or set up APIs. “People with no formal software engineering experience can build complex automated workflows to solve business problems. That’s a strategic developer.” Many other traditional developer tasks are being automated as well. At MongoDB, for example, we pride ourselves on removing the most time-consuming, low-value work of database administration. And of course, services like GitHub Copilot are automating the act of coding itself. So what does this all mean for developers? A few things: First, move to higher ground. In describing one of the potential outcomes of GitHub Copilot, Microsoft CTO Kevin Scott said, ““It may very well be one of those things that makes programming itself more approachable.” When the barriers to entry for a particular line of work start falling, standing still is not an option. It’s time to up your strategic game by offering insight and suggestions on new digital experiences that advance the objectives of the business. Second, accept more responsibility. A strategic developer is someone who can conceive, articulate, and execute an idea. That also means you are accountable for the success or failure of that idea. And as Stennie reminded me, “There are more ways than ever before to measure the success of a developer’s work.” And third, never stop skilling. Developers with narrow or limited skill sets will never add strategic value, and they will always be vulnerable to replacement. Like software itself, developers need to constantly evolve and improve, expanding both hard and soft skills. How do you see the role of the developer evolving? Any advice for those that aspire to more strategic roles within their organizations? Reach out and let me know what you think at @MarkLovesTech .