In our new era of technology-driven disruptive innovation, success is increasingly predicated on an organization’s ability to not only leverage and deploy enabling technologies, but to do so more quickly than the competition. In fact, in many cases, deep technology prowess is required to just stay in the game.
DBAs Ideally Positioned to Boost Innovation
Arguably (and especially in our increasingly data-driven world where data is now deemed to be more valuable than oil), databases are one of the most important pieces of technology within an organization. Not only do they underpin almost every application in use, but they are jammed packed with all kinds of features that when leveraged properly can remarkably boost an organization’s technical capabilities. As database experts, DBAs are therefore ideally positioned to significantly boost innovation potential within an organization, which is exactly what the good ones do.
But it goes even deeper than that.
DBAs Control the Data and the Tools
As guardians of the corporate data and the systems in which it is stored, DBAs have tremendous power and influence when it comes to deciding who has what access to what data, and with what tools. Accordingly, DBAs often directly or indirectly control what IT tools and database features are used within an organization, and this is where they can perhaps have the biggest impact of all.
However, fortunately, and unfortunately, that “impact” can be either positive or negative.
How so? Simply put, when DBAs allow and promote the right high-productivity tools, including low-code tools like Oracle APEX that require their support and cooperation, innovation can flourish. However, disallow these same tools unnecessarily or over cautiously, and innovation suffers.
“But wait!”, I hear you say. “It’s not that simple. What if the “high productivity” tools people want to use create security issues or introduce some other risk? Aren’t DBAs doing their job by not allowing tools that may destabilize the environment?”
Of course. I’m not suggesting that DBAs recklessly allow every random tool that users find on the interwebs. As protectors of the database, the DBA’s primary responsibility is to keep the data safe and ensure the database is healthy. That’s the “table stakes” of what good DBAs do.
Good vs. Great DBAs
But great DBAs? Great DBAs go beyond that. Great DBAs proactively leverage the database to help the organization squeeze every ounce of value from its data assets and database investment. They enthusiastically promote the database features that streamline processes, boost productivity, and drive operational efficiencies.
But the truly distinguishing characteristic of great DBAs? 
Truly great DBAs focus more on enabling people to do smart things than they do on stopping them from doing stupid things. They prefer optimistically educating rather than pessimistically restricting.
Here’s the opposite of what that looks like.
Lunch with 3 DBAs
At the COLLABORATE16 conference in Las Vegas, I happened to have lunch with three DBAs from large organizations, who each had been in their roles for 25 to 30 years. Almost the entire conversation focused on horror stories about how some renegade developer did some stupid thing that caused some big problem. The quote that seemed to best sum up their mindset was, “I’ve never met a disciplined developer”. The rest of the conversation revolved around how they lock everything down as tightly as possible to ensure no developer could ever again do something stupid and ruin their day.
I left the table feeling very sad for their respective organizations; I couldn’t help but imagine the toll such a mindset was taking on innovation and technology-driven progress at their companies. No wonder some people joke that DBA stands for “Don’t Bother Asking”.
See, the best way for a fighter pilot to have a perfect safety record is to never leave the ground. But that’s not what great pilots do. Great pilots take the time to learn exactly what their aircraft are capable of, and can balance risks to safely push their jets to the limit to accomplish the mission. Great DBAs are no different. They recognize there are risks with pretty much all progress, from crossing the street to connecting to the internet, but they know how to safely manage risks to accomplish the corporate mission.
Mediocre DBAs? They default to “no”.
DBAs vs Developers
To be fair, many DBAs have good reason to be wary of developers. Either they’ve heard horror stories or have experienced first hand the damage that can be done when someone messes up the data, or brings the database to its knees with some gnarly SQL statement executed multiple times per second without a bind variable in sight.
In fact, the discord between DBAs and developers goes way back and is well known. Steven Feuerstein even has a great “Couples Therapy” video for DBAs and Developers, and has posted tips on how developers can work with DBAs more effectively. In many cases, developers really do need to “up their game” when it comes to effectively utilizing the database, and DBAs are completely within their right to impose restrictions or limit the use of certain features when they are deemed unsafe or are being used improperly.
But is it possible for the pendulum to swing too far?
Playing it Too Safe?
When mechanical transportation first emerged in Britain in the 1800s, the British parliament passed the Locomotive Act in 1865, which placed burdensome restrictions on motorized vehicles. They were restricted to traveling just two miles per hour in cities and towns, and four miles per hour elsewhere. Especially onerous was the requirement that vehicle operators have three people attend the vehicle at all times, one of whom had to run 60 yards in front and wave a red flag to warn horseback riders and carriages. Anyone ignoring the rules was subject to fines as high as the equivalent of $1,100 in 2015 dollars (source: Harvard Business Review).
Thankfully for the automobile industry, people started seeing the many benefits of automobiles and came to recognize the fears were overblown. In 1896, the restrictions were considerably relaxed, innovation flourished, and look where we are now.
As with many areas in life, finding the balance between latitude and control is important to get right, or you could end up with unintended and undesirable consequences. This is especially true in IT where we’d do well to recognize the wisdom of pioneering Unix programmer Doug Gwyn when he said:
“Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.” -Doug Gwyn
When Policy Becomes the “Thing”
Of course, the rules governing how a database is used within an organization are not always set by the DBAs. I’ve met more than one frustrated DBA held back by IT policies set by those many levels removed from the action.
Most often, this seems to occur in larger organizations with multiple levels of IT management. In his most recent letter to shareholders, Amazon CEO Jeff Bezos explained exactly why this happens:
“As companies get larger and more complex, there’s a tendency to manage to proxies.
A common example is process as proxy. Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. …The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right. Gulp. It’s not that rare to hear a junior leader defend a bad outcome with something like, “Well, we followed the process.” A more experienced leader will use it as an opportunity to investigate and improve the process. The process is not the thing. It’s always worth asking, do we own the process or does the process own us?” -Jeff Bezos
The United Airlines example
Thanks to United Airlines, we have a recent example of how “following the process” can go sideways when they infamously “re-accommodated” a passenger. After the now viral video surfaced of the incident that left the 69-year old passenger bruised and bloodied, the CEO of United initially responded with:
“We sought volunteers and then followed our involuntary denial of boarding process…”
To his credit, he seemed to recognize the ineptness of the “we followed the process” excuse in a full-page ad that came out a few days later in the Washington Post:
“That day, corporate policies were placed ahead of our shared values. And procedures got in the way of employees doing what they know is right.” -Oscar Munoz
Policy vs. Outcome in IT
How does “following policy regardless of outcome” type thinking manifest itself in IT? A perfect example showed up in the Official APEX Group on LinkedIn not too long ago:
All the examples that exist of how Oracle APEX can significantly boost productivity and drastically improve delivery times, and this company might not use it because APEX version control processes are different from what is dictated in the corporate IT policy manual? Incredible. In the meantime, while the IT Auditor gets hung up on what amounts to “problems in theory” versus “problems in practice”, someone else with a much more pragmatic approach will eat the company’s lunch.
But that was an IT Auditor. A DBA would never ban a high-productivity tool like Oracle APEX, right? After all, APEX lives in the database, and they can control exactly how it’s used.
Remember my experience at COLLABORATE16 I mentioned earlier?
It got worse
Later, I attended a session presented by Insum’s Sylvain Martel on using APEX to build Oracle E-Business Suite (EBS) Extensions. There are many areas where APEX shines, and one of them is to connect to EBS to build either real-time dashboards and reports or specialized data entry forms. Sessions demonstrating this functionality always generate a lot of excitement, and this one was no different.
Afterwards, I was speaking with an obviously impressed DBA from a large Fortune 500 company, and asked if his company used APEX. “Oh yeah”, he said. “It’s a great tool, but we only use it in the DBA group.” “Oh? Not elsewhere organization?” I asked. “No” he said. “We used to let the business use it, but they started using it so much and started asking too many questions, so we turned it off because it was taking up too much time”.
They turned it off. Maybe bring in some trainers? Have some lunch and learn sessions? Nope – just turn it off.
One can only imagine what initiatives were killed by that decision. What would a CEO looking to improve productivity would have to say about that? What if he found out what capabilities were summarily eliminated from the organization by that simple yet fateful decision? Talk about impacting innovation…
Giving Innovation a Boost
Thank goodness not all DBAs are like that. Contrast that decision with one made by Alfredo Abate, a DBA who now works as an Oracle Systems Architect at Brake Parts Inc. in Chicago.
Developers at his company were running into limitations extending Oracle EBS with the traditional tools (Forms and Reports). They couldn’t finish projects quickly enough. Seeing the problem, Alfredo did exactly what proactive DBAs do and pointed out an Oracle database feature he thought would help:
“I had used APEX in the past and knew how quickly you could create applications with it. Developers already know PL/SQL. Therefore, first-timers very quickly learn the basic navigation and functionality of APEX. After I created the initial proof of concept, our IT team realized its potential. The developers quickly adopted this as the go-to tool for EBS extensions. A year later we have generated 15 applications including over 60 reports in APEX!” –Alfredo Abate
Move Off a Mainframe
Or, take the work Robert Lockard is doing as another example. Rob is an Oracle ACE and a deeply experienced DBA who helps his clients fully leverage their Oracle database investment.
One client, in particular, had many applications in production that were first written in COBOL in the 1970’s. A key COBOL programmer who had been supporting the applications for the last 40 years retired. Shortly thereafter, the organization realized they needed to modernize their systems and move them off the mainframe. Rob introduced Oracle APEX to the client, and explained why the client loved the idea:
“[APEX] has the advantage of a short learning curve, and being bundled with the Oracle Database. The customer did not have to purchase additional infrastructure to start the migration of these applications. We have a group of Oracle programmers that already know PL/SQL. Getting them up and running on APEX was quite easy. We are now accessing other critical applications that can be migrated off of mainframe/COBOL to Oracle APEX.” –Rob Lockart
In both cases, they didn’t just keep their heads down and focus only on maintaining the database. Both DBAs introduced ways for the organization to move past a hurdle. The leveraged an asset they already owned, using resources they already had. Talk about impacting innovation…
Conclusion
Given my current area of focus, I’ve used Oracle and specifically Oracle APEX examples in this article. However, there are many other great database features which DBAs can promote to help boost innovation at their organizations. If you have any examples, please share them in the comments below.
Title Photo by Pedro Gabriel Miziara on Unsplash
