by Robert Buda | Jan 22, 2021 | Best Practices, Oracle DBA, Uncategorized
We all know that database projects and other technical/IT projects often fail. They are never completed, the results fall far short of expectations, nobody uses the new application, and so on.
Why? At the end of the day, if we look beneath the surface-level issues, the main reason for database project failure — by far — is poor communication.
Case in point: If a project fails because of technical errors or deficiency, It’s either because the technical resources did not have the right skill set, or the requirements that they were working from were incorrect or incomplete.
If it’s the former, then there was a breakdown in communication between the resources and the project manager regarding the set of abilities that the resources have, or there was a breakdown between the project manager and the business analyst regarding what skill sets were needed for the project. If it’s the latter then there was a breakdown in communication between the business analyst and the project manager regarding what the overall system requirements were.
Another typical project failure involves missing deadlines. Typical causes of missing deadlines include resources not being available when needed, or the infrastructure not being ready when it was needed, or the business users not being ready when needed for testing or migration activities.
Again, in all of these cases the root cause is communication. If one of the parties is not ready when they need to be, it is either because they didn’t know when they would be needed, or they incorrectly stated their availability. If the infrastructure is not available when it is needed, then either the requirements or the deadline for the infrastructure were not properly communicated to the infrastructure team, or the infrastructure team miscommunicated their ability to get the work done in time.
If you look deeper and break down the presenting problems, in almost all cases the root cause of project failures is communication. Often the communication failures occur in the very beginning of the project, during the scoping and estimate or quotation process.
Here are 4 key approaches that I use to mitigate the significant risks to project success caused by poor communication:
- When asking someone for a decision on an important point, I always ask twice. If the two answers differ, I ask a third time. And I continue that process until the answers become consistent. If I receive the two different answers from two different critical stakeholders, I will find a reason to send a joint email or have a conversation with both present, and I will re-ask the question in hopes of gaining consensus. (Political sensitivity and tact is critical here… Perhaps that’s the subject of another blog post…)
- When nailing down an important decision, I follow up in writing to validate and underscore everyone’s understanding, especially for something for which I have received two different answers over time.
- I treat decisions differently than statements of fact. If I ask a client, “Do your customers connect directly to your database?”, this is a statement of fact. There is a right and wrong answer to this question, and it can be validated independently. However, if I ask the customer, “How many customers do you want the database to support in five years?”, this is a decision or a target. There is no right or wrong answer. This cannot be validated except by the same individual (assuming they are the decision-maker).
I treat statements of fact very differently from decisions/targets:
- I validate a statement of fact in a variety of ways. I might look at the user accounts on the existing system, or I might ask someone else in the organization, or I might look at the application for clues.
- For decisions or targets, validation can be more difficult. As mentioned above, I ask at least twice for any decision that can impact the scope of the project. If the answers differ, or if I feel like the answer is not solid and may change (based on my client’s tone of voice, hesitation, inconsistencies with other statements or requests, or other factors), I will ask again until I am satisfied that the answer is solid.
- For all important points that can impact the project time or cost estimate, or the database design or implementation, I always validate them in one fashion or another before we act on them. And if I can’t validate them for some reason, I call them out separately as an assumption in the estimate or quote in order to bring it to the client’s attention and to the team’s attention, and then I mention it directly when reviewing the document with them.
To sum up: as you might expect, the antidote to poor communication is good communication. Especially going into a project, keep the above in mind. Get clarity and validate what you’re hearing. This will make you look good, your customers and technical team members will appreciate it, and your projects are much more likely to succeed.
To get optimum value and results from your database project investments, contact Buda Consulting.
by Robert Buda | Jan 31, 2020 | Best Practices, Cloud, Database Security, Uncategorized
In response to the recent Capital One data breach, where a hacker exploited a misconfigured open-source Web Application Firewall hosted within Amazon Web Services (AWS), the Amazon CTO reminded customers that they must secure their own data when housed on AWS infrastructure.
This seems obvious, but it is a very important point.
When you move your data into AWS or any cloud provider, because it is not in our your data centers, and because you often no longer employ full-time people to manage the server hardware and software that house that data, you might get the feeling that someone else is managing our data just as carefully as our own staff once did.
That may be true for some dimensions of data management. For example, the cloud provider is responsible for making sure that the hardware stays up and running. Likewise, when you use software as a service (SaaS) or platform as a service (PaaS), the service provider is responsible for making sure that the application software and/or operating system stays up and running. In the case of infrastructure as a service (IaaS) offerings, the customer is still responsible for the latter two functions.
But in all the above cases, the customer is ultimately responsible for the security of their own data. The AWS security documentation describes it this way:
-
- Security of the cloud – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the AWS Compliance Programs. To learn about the compliance programs that apply to Amazon EC2, see AWS Services in Scope by Compliance Program.
- Security in the cloud – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations.
The key takeaway is that if you have your data in any cloud service, you must be as rigorous in securing that data as if it were in your own data center—and in some cases even more so.
Following are some key things to think about when moving your data into the cloud. These are the same considerations you need to focus on when keeping your data in-house. Some of these concerns only apply to IaaS in the cloud, while others are relevant to all cloud service scenarios.
-
- Is the underlying storage configured properly so that only the database software, application software and authorized users can access it?
- Is the data encrypted both at rest and in transit?
- Is proper authentication in place for the application or database, to ensure that only proper users can gain access to the system?
- Is proper authorization in place for the application or database, such that data is exposed only to the proper users?
- Is the network configured properly to reduce the surface area vulnerable to attack?
These considerations are not new. In fact, our Database Security Roadmap, initially created primarily with on-premises systems in mind, is still completely relevant with cloud technology.
Download the roadmap to make sure you have all the bases covered.
by Robert Buda | Aug 18, 2014 | Oracle DBA
Upgrades and patches are a primary cause of planned downtime for Oracle databases and the applications that rely on them. Therefore, you need to have a strategy and process for your Oracle database upgrades that minimizes business disruption but does not postpone these essential tasks.
Waiting to perform upgrades is likely to increase costs and downtime. Failure to apply patches in a timely manner not only can take longer and make things more complicated when you finally do it, but also can leave your databases open to instability and security risks.
Keeping your Oracle environment up-to-date with minimal impact on the business depends on timely periodic maintenance that includes incremental updates and critical patch upgrades. The cadence of these activities should be tailored to your specific business needs.
But with more and more data to manage and skilled Oracle DBAs in short supply, many organizations are hard-pressed to keep up with these kinds of day-to-day database maintenance tasks. It can likewise be a challenge for DBAs to keep their knowledge up-to-date so they’re aware of best practices and “gotchas” associated with patches and upgrades.
If your team struggles to keep up with patches and upgrades, or the business is experiencing excessive planned downtime, you should consider outsourcing these “non-core” processes. Here are three reasons why:
- Lower database administration costs
Hiring the expertise you need, when you need it, often costs less than hiring, paying and training full-time Oracle DBAs.
- Improved business agility
Offloading “non-core” processes like database patching and upgrades can help supplement the efforts of in-house Oracle DBAs, enabling them to focus on data modeling, database design and other strategic objectives that drive innovation and get new applications to market.
- Reduced planned downtime and improved SLAs
Outsourcing Oracle DB patching and upgrades to experts who do them every day of the week will result in more process automation, more proactive problem-solving, and more best practices to ensure quality and minimize downtime. That means improved SLAs around uptime, performance and reliability. It can also mean reduced negative impact on business revenue and customer satisfaction.
Oracle patching and upgrades can be performed onsite or remotely with equal speed and efficiency. Activities can take place at off-peak times, in sync with other planned downtime activities, or whenever it best suits your operations.
In addition, outsourced Oracle DBA experts will have solid experience with “tips and tricks” like using Oracle Data Guard and Oracle GoldenGate to minimize downtime and optimize results. Expertise like this can be critical for organizations that need to upgrade mission-critical database environments that are currently running older Oracle versions.
If you have a one-time, periodic or ongoing need for additional support to patch and/or upgrade your Oracle environment, contact Buda Consulting for a free consultation to discuss your options.
by Robert Buda | Jun 12, 2014 | Oracle DBA
Even in this “age of outsourcing,” Oracle database administration (DBA) outsourcing is still often overlooked. Despite some predictions to the contrary the overall percentage of organizations outsourcing their DBA has remained relatively small and stable in recent years.
Perhaps this is because Oracle DBA outsourcing is most often treated as a cost-based, tactical decision rather than a strategic move. But with the right partner, the benefits of outsourcing your Oracle DBA can extend well beyond bottom-line cost savings on database management and support. These include:
- Improved database performance and availability
- Enhanced data security
- Continuous support for 24×7 web environments
- Increased developer productivity and efficiency
- Reduced attrition and loss of organizational knowledge
“But wait!” I hear you saying. “Aren’t those the very reasons why I have a full-time Oracle DBA on staff?” “And don’t I need this expertise more than ever to keep up with disruptive trends like mobility, cloud and big data that are turning my data stores inside out?”
I’m not talking about eliminating your Oracle DBA expertise—I’m talking about enhancing and stabilizing it, by partnering with a certified DBA expert that offers unbeatably broad and deep expertise and won’t leave for a better paying job. I’m also talking about leveraging expertise not only in the realm of process-related, everyday database services; but also project-oriented, cutting-edge architecture, intelligence and security/compliance work.
One: Improved database availability
According to Oracle, human error is the second leading cause of unplanned downtime after network outages. By hiring the services of bona fide experts you can improve database availability and reduce the cost of downtime associated with hiring junior Oracle DBAs because they’re all you can afford.
Two: Enhanced data security
Like uptime, data security and risk reduction are a function of expertise, not just policies. An outsourced Oracle DBA expert can probably assess your environment and identify vulnerabilities better than an in-house DBA who 1) may not have focused on building security expertise, and 2) is actually hampered by familiarity with your environment. To achieve optimum security and ensure compliance it’s advisable to outsource to an “onshore” partner that you know will comply with strict US privacy laws.
Three: Continuous support for 24×7 environments
If you’re offering your clients a global service that’s up-and-running 24×7, the cost of keeping in-house DBAs online could be overwhelming. Using outsourced Oracle DBAs to keep your core Oracle databases purring along will be cheaper and more predictable.
Four: Increased developer productivity
When you strategically outsource Oracle architecture, design and performance tuning expertise you not only end up with more robust and scalable applications, you also optimize developer time by streamlining the development process with everything from better decisions to better documentation, at least where the database is concerned.
Five: More stable organizational knowledge
With Oracle DBAs in such high demand, the attrition rate is high. By using remote Oracle DBA support on a consistent basis, enterprises actually reduce the risk of losing expertise and confidential information. Likewise, there’s no “ramp-up time” while a new employee comes up to speed.
In short, Oracle DBA outsourcing can deliver the expertise required to enable organizations of all sizes to handle growing database responsibilities—and yes, cut costs as well. Contact Buda Consulting to start a conversation on how we can help.
