Category Archives: Art of BI
Data Lifecycle Management for Oracle EBS
Oracle Enterprise Business Suite (EBS) is used by thousands of enterprise customers around the world, with applications ranging from enterprise resource planning (ERP) to customer relationship management (CRM). While this rich array of software is tremendously useful, the complexity of your Oracle EBS environment can quickly become overwhelming if you don’t actively work to manage it.
Below, we’ll discuss one of the most pressing concerns for Oracle EBS: data lifecycle management (DLM). If you’re not careful, the size of your Oracle EBS environment can quickly swell, increasing your IT expenses and slowing down the system’s performance. Data lifecycle management for Oracle EBS is an essential practice that can slim down the size of your EBS footprint while preserving access to data for the users who need it.
The 4 Stages of Data Lifecycle Management
Every piece of data that your organization handles is located at a particular stage in the enterprise data lifecycle. The 4 basic stages of data lifecycle management are:
- Creation: First, data is created and/or collected. For example, you might acquire data from a third party, manually create it with data entry, or observe it with a given tool, process, or sensor.
- Storage: Data that is useful long-term needs to be securely stored and backed up on a regular basis. However, this need for secure storage also must be balanced with the ability to easily view, modify, and analyze the data.
- Archival: Information that is no longer used, or used only infrequently, should be archived in a separate location. Archiving files helps limit the data bloat of your Oracle EBS footprint, while also ensuring compliance with the necessary standards and regulations, such as GDPR and CCPA.
- Deletion: Once data is no longer useful, and no longer subject to regulatory compliance, it can be safely deleted. In particular, sensitive and confidential information must be handled with care and properly wiped so that it’s not exposed to a third party.
How to Practice Data Lifecycle Management for Oracle EBS
The data lifecycle management stages listed above are ideal for any organization that relies heavily on its enterprise data (and these days, that’s pretty much all of them). Unfortunately, far too many businesses aren’t able to achieve a fluid, efficient DLM process for their enterprise data—whether that’s due to organizational inertia or lack of in-house technical expertise.
However, practicing good data lifecycle management for Oracle EBS is a must. By archiving and deleting the data you use infrequently or not at all, you’ll have less information in your EBS deployment to manage. This has several advantages: you’ll no longer be replicating unused data when cloning a new EBS environment, and your reports and analyses will speed up significantly.
A few data lifecycle management best practices for Oracle EBS include:
- Understand the data you collect: Oracle EBS databases are capable of storing a wide variety of information, from customer records to accounting spreadsheets. Each type of data, and the database in which it’s stored, may also have separate concerns regarding regulatory compliance and data privacy. The first step in data lifecycle management for Oracle EBS is understanding exactly what type of information you have on hand and how it needs to be managed.
- Have a backup and business continuity plan: While archiving data is a best practice for the information you rarely use anymore, the data you use on a daily basis should be backed up on a regular basis to help preserve business continuity. On-premises backups are perhaps easiest, but they’re also at risk in the event of an on-site natural disaster. Cloud backups securely replicate your files on multiple servers and can easily scale up as the amount of your enterprise data increases.
Working with a third-party managed services provider can help with DLM—but you’ll need to choose the right one. Your choice of Oracle EBS MSP should be familiar with your business goals and requirements so that they can help advise you about which data to preserve and how to preserve it.
Conclusion
By applying data lifecycle management best practices for Oracle EBS, you can make your enterprise IT significantly less complicated, while also improving performance and slashing costs. However, DLM is just one of the many IT challenges that Oracle EBS users need to address.
As an Oracle Platinum Partner, Datavail has many years of experience helping our clients manage and maintain their Oracle EBS deployments. To learn more about the complexities of using Oracle EBS, and how you can take steps to resolve them, check out our white paper The Top 6 Challenges of Managing Oracle EBS Environments.
The post Data Lifecycle Management for Oracle EBS appeared first on Datavail.
Does Agile Testing Improve Application Development?
Application development is a complex process. Developers work very hard to produce products that are error-free, but without a formal testing process, the final product can be flawed. That’s why testing is so important. It’s necessary to ensure the delivery of a viable application that works in practice. There’s no controversy over the need for testing. The question is, “Which type of testing is the most effective?”
Waterfall vs Agile Testing Philosophies
The two most common types of application development methodologies are Waterfall and Agile. The Waterfall methodology calls for planning out a complete project to produce a final product. The Waterfall project team works in phases, and the output from one phase flows to the next until the product is complete.
The Agile methodology breaks a project down into small segments that are completed in “Sprints” of two to four weeks. The process focuses on collaboration among the team, the customer, and the users, and working iteratively to refine the team’s output.
Waterfall Testing
The Waterfall testing model breaks-down activities into linear sequential phases. Each phase is dependent on the successful completion of the previous phase. This approach is less iterative and flexible as progress flows usually in one direction… downward.
Testers that are part of a Waterfall process validate the features as defined in the project documentation. If problems arise during testing, it is difficult to make any significant revisions or changes in how the product works. Again, individuals working with a Waterfall methodology are caught in a downward, one-way, delivery method. It is not designed to stop (mid-stream) the team’s delivery tasks, to go-back to fix the problem, and then paddle-on to the next task. Waterfall testing should not be considered for large complex projects – but for small, short-duration projects, there is certainly a place for this delivery model.
Agile Testing
When the Agile methodology was developed, testing was one of the motivators. Experienced developers using the Waterfall methodology believed that leaving the testing until the project was almost complete left too many opportunities for problems to hide in the code. By the time testing was initiated, fixing problems typically required changes that were costly and time consuming.
Agile development involves members of a cross-functional Agile team, with a focus on the expertise of the testers. The testers are continuously testing (in cycles call “Sprints”) the features being developed as they are being developed, thereby supporting DevOps. This approach improves product quality, and consistency of meeting delivery dates.
The Agile Testing Philosophy
Agile testing can be done differently in different organizations. But, the authors of the book “Ten Principles for Agile Testers” outline a number of principles that Agile teams can incorporate into their Agile methodology.
- Make feedback continuous.The testers, development team, analysts, and the product owner should exchange feedback throughout the Agile process.
- Focus on the customer. Everyone’s goal should be to develop a product that works best for the customer. Even an elegant product isn’t useful if the customer isn’t delighted.
- Make communication face to face. Testers and developers should communicate in person to eliminate misunderstandings and to make clarifying feedback easy.
- Support courageous testers. Testers need to feel comfortable fighting for things they believe are in the best interest of the customer.
- Avoid too much testing.Testers should focus on only the most necessary tests to keep the product simple but valuable.
- Make continuous improvement critical.Testers need to have the mindset that continuous improvement is important to improve their skills and to stay open to new ideas.
- Don’t fight change. Testers need to adapt to the changing needs of the customer and the marketplace easily.
- Encourage self-guidance.Morale is higher when testers and the other members of the team can work together to guide their own activities.
- Stay centered on people.Testers should have excellent communication skills and care about the other team members. Working as a dynamic team will result in the best outcome.
- Have fun. When testers are a respected part of the team, and when testers respect the skills of their team members, you end up with a motivated team that has fun working together to create an outstanding product.
The whole point of the Agile testing mentality is to avoid this type of exchange between a tester and a developer.
- Tester: Hi Joe, I wanted you to know that when you press this button, the application crashes.
- Developer: Well, sure, you’re not supposed to hit that button on that screen.
- Tester: So, I made a mistake, and if I did it, the users will probably do it, too.
- Developer: OK, I’ll tell the trainers to be sure and teach the users not to hit that button.
The Quadrants of Agile Testing
The Agile testing process is often presented in four quadrants that give an overview of how agile testing works.
- Quadrant 1: Testing focuses on the quality of the code. It is technology driven and supports the team.
- Quadrant 2: These are business driven tests that support the team to test topics such as workflows and the user experience.
- Quadrant 3: This quadrant often consists of automated tests that are designed to build confidence in the product.
- Quadrant 4: These tests focus on non-functional requirements to ensure the product delivers what the customer expects. These elements include tests such as stress tests, infrastructure testing, security tests, and more.
Benefits of Agile Testing
Application testing is critical to allow an Agile team to produce excellent products. The process produces a number of benefits.
Facilitates documentation
In most instances, using the Agile methodology results in less documentation, but documentation is still important. Involving technical writers during development allows them to talk to the developers while they are immersed in the project rather than waiting until the end of the project when people on the team are moving on to other assignments.
In addition, since testing is completed during development, the documentation that is produced doesn’t need to be revised after a separate testing process.
Adapts to changes
Agile testers aren’t working in a structured environment where they’re comparing the final product to the original requirements. Since testers are part of the team during the development process, they can easily restructure their testing to conform to the requirements as they are refined.
Fixes happen during development
Incorporating testing during development lets the development team fix bugs or gaps during the development process. It is much less costly and time consuming to make changes as the code is written rather than addressing fixes just before the product is released.
Increases collaboration
In Agile testing, the developers get regular feedback from users and testers. This type of interaction increases the developers’ understanding of the user and how they will interact with the product. It makes it easier to fix problems and gives a new insight to the developers that often avoids problems as the development moves forward.
Delivers a high-quality product
In traditional Waterfall projects testing is completed at the end of development. In many cases, there is extreme pressure to complete testing rather than extend the release date. That approach leads to oversights and mistakes.
With the Agile approach, testing is incorporated into the development. It’s not perceived as a separate step toward product release that often gets in the way of meeting timelines. The only pressure comes from the team members who have satisfying the customer as their goal. Agile testing usually results in producing a high-quality product.
Faster delivery
Using the Agile methodology, with its integrated testing, often results in a faster delivery of a final product. It doesn’t matter if the application is for internal use or it’s a step toward increasing a company’s competitive edge in the market—fast delivery is always good news for everyone involved in an application development project.
Testing is a critical part of application development, and Agile testing has a lot to offer. But, inadequate testing is only part of what can make an application development project fail. Learn about other reasons why projects break down, and seven solutions you can use to meet the challenges of today’s application development environment by reading our white paper, “4 Reasons Why Application Development Projects Fail.”
The post Does Agile Testing Improve Application Development? appeared first on Datavail.
The Importance of Database Modernization for Cloud Adoption
Getting the most out of cloud technology involves far more than simply adopting cloud-based infrastructure. Older databases shifted into the cloud may not serve the needs of modern applications. As your users have more complex use cases, with a growing amount of data and data sources, real-time feature requests, and rapid scaling requirements, your database technology needs to change too.
Database modernization is spread throughout multiple stages, as your organization goes through testing, evaluation, and pilot projects to determine which areas benefit the most from upgrading the database.
In our recent cloud adoption survey, 46 percent of respondents planned on using or are considering modern data platforms, 34 percent are remaining on their current solution, 22 percent are considering a move in the future, 19 percent are evaluating and planning their migration, 15 percent are in the process of migration, and 10 percent are building new applications on new platforms and keeping legacy applications on old platforms.
As you can see, the way that organizations go about database modernization comes in many forms.
Benefits of Database Modernization
Gaining Purpose-built Databases
Databases are not a one-size-fits-all technology, but some organizations opt for the same technology no matter what application it’s for. By matching purpose-built databases to specific use cases, you can improve performance, expand functionality, and get the data structures that make sense for the project.
Reducing Costs
Modernizing your databases can also lead to lower expenses. Since they’re fine-tuned for a specific purpose, you get access to the features you need without paying for those that are not useful. These database platforms often require less time spent on maintenance, security, and optimization, so your database administrators and system administrators have more time in their workdays.
Better Reliability
Modern database platforms are filled with features that help your systems stay online and meet SLAs, including high availability, distributed processing, and robust disaster recovery options. If you’re using cloud-native database solutions, you also have the advantage of using technology specifically designed to get the most out of the cloud.
Fast Provisioning
You drastically reduce the amount of time it takes to spin up a new database instance and often enjoy a streamlined process. For some database platforms, all you need to do is click a button. Scaling is also simple, with many solutions offering automated control over the resources you’re using.
Signs That You Should Modernize Your Databases
- Difficulty in keeping up with growing usage: Your users and workloads are rapidly increasing, and the system is starting to strain under the pressure. Performance issues abound and make it difficult to achieve peak productivity.
- Inability to work with new data sources and structures: As new data sources and structures develop, older databases may not support these formats. You could lose out on valuable insights or end up with a major opportunity cost in the long run.
- Increased demands on the IT team to keep the system running: Frequent downtime, crashes, errors, and other issues add up fast with older databases. You also have to worry about security exploits and other vulnerabilities occurring with databases that are past their prime or end of life.
- Struggles meeting SLAs: You fail to meet your SLAs due to issues with the system, whether it becomes inaccessible or has extremely slow performance.
- Database costs rising uncontrollably: Propping up older technology can become expensive in many ways, from the resources required to keep it operational to sourcing specialists of less popular databases.
Moving to Modern Databases in the Cloud with Datavail
As a leading cloud partner with AWS, Microsoft, Oracle and MongoDB we can help with your database modernization and cloud migration. We have more than 15 years of experience and over 800 data architects and database administrators ready to move your applications to cutting-edge databases. Learn more about the cloud adoption journey and see the results from the rest of the survey in our latest paper. Contact us to get started.
Read This Next
Modernize Legacy Tech with MongoDB
Your organization is probably running technology that is past its prime, and you probably know you need to update and upgrade it all to maintain your corporate competitiveness. In short, you need to ‘modernize,’ and MongoDB provides you with the tools you’ll need to bring all your tech – software, apps, and systems – up to speed.
The post The Importance of Database Modernization for Cloud Adoption appeared first on Datavail.
The Benefits of Moving On-Premises MongoDB Applications to Amazon EC2
Deployment of MongoDB databases and analytic applications happens through public cloud infrastructure, hybrid environments, and DBaaS providers such as MongoDB Atlas. In this article, we’ll discuss the advantages of shifting your on-premises MongoDB applications to the Amazon Web Services (AWS) public cloud solution, Amazon EC2.
Lower Your Total Cost of Ownership
Expenses often drive up the price of an on-premises deployment for your MongoDB applications. From the need for data center hardware to enough personnel to keep everything running, you’re responsible for large upfront payments and all costs associated with this application.
An AWS migration takes away many of those upfront costs, making ownership more manageable for many companies. The expenses you remain responsible for change to monthly and usage-based pricing, and they are easy to predict based on your current and estimated requirements.
Leverage AWS Cybersecurity Resources
How strong are your IT security measures for your MongoDB application? Unexpected downtime, data breaches, and data loss can have a devastating impact on your application. If the application works for internal use, your organization may suffer from productivity loss and other back-office issues. If it’s a client-facing application, your business could lose revenue and customer trust.
AWS cybersecurity resources help you create better security for your application to avoid these negative consequences. The technology used on this platform may be significantly more effective than the solutions you use for your on-premises systems.
Easily Achieve High Availability
Configuring high availability is a simple process on AWS through the use of availability zones and regions. You can distribute your MongoDB replica set members across geographically diverse locations and let the systems undergo automatic failover in the event of a disaster. You won’t be left without your application if a region-wide disruption occurs, which is particularly important for mission-critical solutions.
Reduce Ongoing MongoDB Application Maintenance Requirements
The underlying hardware and software that powers your MongoDB application databases are no longer your responsibility. AWS takes over that part of the process in the cloud. You can focus entirely on optimizing your MongoDB instances rather than maintaining the server hardware or patching the server OS.
By giving your in-house IT department more time, you can empower them to work on more strategic projects and improve their job satisfaction. You also reduce the need to recruit additional database experts for day-to-day tasks.
Maintain More Control in the Cloud Compared to a DBaaS Deployment
MongoDB offers a powerful first-party DBaaS solution called MongoDB Atlas, but the lack of control of many underlying functions may make it ill-suited for your application. Since AWS is self-managed, you can set its maintenance windows to the best times of the day or week and optimize configurations based on your unique needs.
Automate Your MongoDB Disaster Recovery
AWS has several ways for automating your backup and recovery processes to mitigate failures and other problems you may encounter. Reducing unexpected downtime has many benefits for your organization, such as improving productivity and establishing a reputation for a reliable solution.
Gain Flexibility Capacity for Changes in Your Application’s Requirements
AWS delivers flexibility on a level that on-premises data centers can’t match. Migrating to a public cloud provider makes scaling up and down a painless process, even when working with MongoDB applications with major demand fluctuations.
Streamline Remote Access to Your MongoDB Applications
Remote workforces are rapidly becoming the norm in many industries, and to do their jobs, these workers need access to the same resources they use on site. It may be a challenge to support work-at-home employees with an on-premises deployment.
AWS is set up for anytime, anywhere access, so you face fewer barriers to achieving your remote access goal. You avoid trying to retrofit this support into infrastructure that was never intended for this use case.
Are you ready to migrate your on-premises MongoDB application to AWS? Learn more about planning and executing a successful migration in our white paper “Everything You Need to Know to Move Your On-Premises MongoDB Data Center to AWS.”
The post The Benefits of Moving On-Premises MongoDB Applications to Amazon EC2 appeared first on Datavail.
PostgreSQL vs. Oracle: Let’s Compare
Companies are faced with many options when deciding on a database management system. Discover the key differences between PostgreSQL vs. Oracle that will help you make an informed decision.
Types of Database Management Systems
Database management systems can be categorized as open-sourced or closed-source systems. Open-source means that anyone can download and modify the source code of the database technology for free. Closed-source means that the source code is private and inaccessible to everyone except the developers and authorized parties. You often need to pay a license fee to use closed-source software.
Open-sourced software has an active community of users and developers who can check the code for bugs, extend the software’s functionality, and often provide support for the solution. You have greater flexibility with open-sourced software, as you can customize it based on your company’s needs and have access to a large community for development resources.
Closed-source software offers less flexibility compared to open-source solutions, but it can make up for that through premium support options on-hand for emergencies, extensive training, and documentation resources, enterprise-grade security and stability, and less decision-making on the software versions to implement.
You can also find overlap between closed-source and open-source capabilities. For example, closed-source software may provide an add-on framework that allows third-party developers to extend functionality, while some open-source software can provide access to paid support solutions.
Key Differences Between PostgreSQL and Oracle
When you look at PostgreSQL vs. Oracle database management systems, the main difference between these two databases is that PostgreSQL is an open-source database, while Oracle is a closed database system. PostgreSQL is a free relational object-oriented database management system that is developed by volunteer developers worldwide. Oracle is a licensed commercial relational database management system.
Both database systems use similar concepts such as schemas, tablespaces and indices, but they diverge in areas such as replication and support. Let’s explore the ways that these two database systems handle vital operations.
Functionality
PostgreSQL
- High availability
- Four levels of transactions: Read Uncommitted, Read Committed, Repeatable Read, Serializable
- ACID-compliant
Oracle
- High availability
- Higher transactions per second
- More functional than PostgreSQL, but these functions come at a price premium
- ACID-compliant
Scalability
PostgreSQL
- More scalable due to its open-source characteristics
- Databases accommodate any volume of data
- Cluster-based storage solutions allow for free expansion
- Foster integrity during scalability operations with WAL files, although these files are limited to 16 MB
Oracle
- Have to spend more on infrastructure to carry out scalability operations, as the Standard edition only has four sockets, while the Enterprise edition offers more
- Maintain data integrity with redo logs
Security
PostgreSQL
- Offers roles and inherited roles that allow developers to set permissions
- Supports native SSL that assists in encrypting server communications
- Provides extra access controls through SE-PostgreSQL that rely on SELinux’s security policy
Oracle
- More robust security features than PostgreSQL
- Higher cost editions are required to access advanced security options
- Resilient through security assessments, data protection, auditing, and monitoring
- Provides excellent isolation solutions between pluggable databases and independent key encryption management
Support
PostgreSQL
- Active community that offers free online support via blogs, emails, code, and other channels
- No phone number to call for emergencies
- The cost to hire PostgreSQL community developers for premium support is less than a comparable Oracle specialist
- Third-party support providers are also available, such as EnterpriseDB and 2nd Quadrant, that also offer their own PostgreSQL distribution
Oracle
- Expensive support
- Large corporations have to hire Oracle consultants or depend on Oracle’s support, with a cost of up to 25 percent of the license fees
- Emergency support is available by phone
Compatibility & Replication
PostgreSQL
- High availability through Streaming Replication
- Master-slave replication provides developers with flawless performance during backup, task allocation, and clustering
- ORM framework support
- Support for a larger group of APIs than Oracle, making it more compatible with many applications, add-ons, and SQL environments
- JDBC, ODBC, OLEDB and .Net library support
Oracle
- High availability through DataGuard
- Master-slave replication provides developers with flawless performance during backup, task allocation, and clustering
- Master-master replication
- ORM framework support
- JDBC, ODBC, OLEDB and .Net library support
- Less API support than PostgreSQL
SQL Compliance
PostgreSQL
- Less complex SQL Syntax, as PostgreSQL follows standard SQL
- Non-standard built-in procedural extensions are available through pg/SQL
- Pg/SQL is a less mature technology than Oracle’s, and is slower
- Developers can use query handlers such as R and Python to write directly into the database
Oracle
- More complex SQL Syntax compared to PostgreSQL, as this database follows Oraclism
- Non-standard built-in procedural extensions are available through PL/SQL
- PL/SQL is a faster technology than pg/SQL
High Availability
PostgreSQL
- PgPool in PostgreSQL Enterprise edition provides similar functionality to Oracle Real Application Clusters
- Add nodes dynamically through horizontal scalability options
- PgPool is not a built-in feature to PostgreSQL and requires many Clusterware tools to achieve similar functionality to Real Application Clusters
Oracle
- Databases can be shared across a pool of servers through Oracle Real Application Clusters
- When one instance of failure occurs, the database can run on the remaining databases to offer continuous workflow management
- Real Application Cluster is a built-in feature
Migration Tools
PostgreSQL
- Offers many tools that support migration from Oracle
- Ora2PG migrates large projects
- Oracle_FDW moves schemas and data
- Orafce ensures function compatibility
- PGREPLAY is a stress testing tool that can be hacked to stress test large databases
- For migrating code, third-party tools such as the AWS Schema Conversion Tool work well
- Moving huge Oracle databases to PostgreSQL can consume significant resources and time
Oracle
- Database Replay and SQL Performance Analyzer in Real Application Testing allow you to analyze and test migration requirements before the move
- The migration process is easier to plan through these preparation tools, reducing the time and resources required compared to PostgreSQL
Backup and Recovery
PostgreSQL
- The data recovery process is straightforward, as it simply replaces directories and sub-directories plus the associated WAL files
- PGdump and pgbasebackup are simple and straightforward database backup solutions
Oracle
- The data recovery processes can be overly complex
- RMAN provides an efficient and straightforward database backup
Choosing a Database Management System
Overall, PostgreSQL and Oracle are evenly matched in their capabilities, performance, and compatibility. Oracle takes the lead on security, replication, and availability, while PostgreSQL has stronger API compatibility, cheaper support and more robust scalability. As database administrators, we think your choice of databases depends on your company’s priorities.
If you want an easy-to-use database you can customize for your operations, with a low Total Cost of Ownership, then PostgreSQL is a good choice. If high availability and flawless replication during voluminous transactions are the most important things for your business, then Oracle provides robust functionality.
Datavail offers many resources to help you decide between PostgreSQL and Oracle, from choosing the right database technology for your company to executing a migration. We deliver the DBA expertise, services and strategies to help you get the most out of your data and database technology.
Your database administration team manages and optimizes your databases through monitoring, maintenance, disaster recovery, user support, training, migration planning, and more. We offer flexible DBA capacity, so you get the right level of support throughout your technology journey, from one-time projects to 24/7 assistance.
See how Datavail can help you manage all your complex database needs and maximize your investment in PostgreSQL, Oracle and other database technologies.
The post PostgreSQL vs. Oracle: Let’s Compare appeared first on Datavail.
