SAP BW4HANA alternatives and competitors

For Snowflake, we had four main use cases. The first use case was related to a data warehouse, and my banking client wanted to move his SQL Server database to Snowflake. All the source systems were also on Oracle and file-based systems, and the target data warehouse was SQL Server. From SQL Server, the client wanted to move to Snowflake. 

The second use case was related to a chat or messaging client. They were using EMR Hadoop as their data warehouse, but it was not performing, so we had to move the EMR Hadoop to Snowflake. 

The third use case was related to a ServiceNow compliance system, where ServiceNow was using SAP HANA for its reporting data warehouse, but it was too slow. It was not performing, and it was causing a lot of problems. We moved that ServiceNow compliance system from SAP HANA to Snowflake.

The fourth use case was related to a huge SQL Server database for a banking client. We moved the entire SQL database to Snowflake. 

Data sharing is a good feature. It is a majorly used feature. The elastic compute is another big feature. Separating compute and storage gives you flexibility. 

It doesn't require much DBA involvement because it doesn't need any performance tuning. We are not really doing any performance tuning, and the entire burden of performance tuning and SQL tuning is on Snowflake.

Its usability is very good. I don't need to ramp up any user, and its onboarding is easier. You just onboard the user, and you are done with it. There are simple SQL and UI, and people are able to use this solution easily. Ease of use is a big thing in Snowflake.

Portability is a big hurdle right now for our clients. Porting all of your existing SQL ecosystem, such as stored procedures, to Snowflake is a major pain point. Currently, Snowflake stored procedures use JavaScript, but they should support SQL-based stored procedures. It would be a huge advantage if you can write your stored procedures using SQL. 

It seems that they are working on this feature, and they are yet to release it. I remember seeing some notes saying that they were going to do that in the future, but the sooner this feature comes out, it would be better for Snowflake because there are a lot of clients with whom I'm interacting, and their main hurdle is to take their existing Oracle or SQL Server stored procedures and move them into Snowflake. For this, you need to learn JavaScript and how it works, which is not easy and becomes a little tricky. If it supports SQL-based procedures, then you can just cut-paste the SQL code, run it, and easily fix small issues. 

I have been using this solution for three years.

So far, with all four clients who have this solution, I have not seen any problem that stands out and causes major headaches or something like that.

Its scalability is really good. You can scale in both ways. You can actually scale up and down or scale out. Scaling up and down is done where we have an extra small warehouse, and we are moving to small, medium, large, or something like that. If you have a query that is running slow or a lot of data you are dealing with is slow, you can scale up. If you want to scale down from large to small, you can do that. 

If you want to get concurrency, scale-out architecture is available. I can actually do a cluster-based architecture where I can have two clusters, three clusters, or something like that. This way the concurrency can be improved.

In terms of the number of users, we have around 200 users.

They have a website where you have to go and raise your tickets. They resolve the ticket, and they are working fine. 

They don't actually entertain emails nowadays because the company has become big. I remember initially interacting with them through email. Now they don't do that. They clearly say not to send emails and go through the ticketing process, which makes sense. For a big company, it is not possible to track emails.

It is not complex. It is straightforward. It is a very simple database anyway. It is just having a script and running them. 

The only thing is that you have to go through the whole nine yards of getting an account or getting your single sign-on enabled. That is a part of every process. For any single sign-on application, you will have to go through this process. 

You also need to involve the right people, such as the security team, infrastructure team, and networking team. When they are there, the setup becomes easier, and there are no problems.

For its maintenance, we have only two or three people. We have one DBA and one account admin. There is another DBA who will take a rotation. You don't really need a big team to manage this because it is all cloud. Management is not that heavy.

Snowflake goes by credits. For a financial institution where you have 5,000 employees, monthly costs may run up to maybe $5,000 to $6,000. This is actually based on the usage. It is mostly the compute cost. Your computing cost is the variable that is actually based on your usage. It is pay-per-use. In a pay-per-use case, you won't be spending more than $6,000 to $7,000 a month. It is not more than that for a small or medium enterprise, and it may come down to $100K per year.

Storage is very standard, which is $23 a terabyte. It is not much for any enterprise. If you have even 20 terabytes, you are not spending more than $400 per month, which may turn out to be $2,000 to $3,000 per annum. 

When comparing it with SAP HANA, there is no one solution that fits all. Snowflake is useful if you have a SaaS-based product such as Salesforce, Workday, Anaplan, and Greenhouse. You can get the data from this type of SaaS-based system and ingest data.

SAP is born out of the entire ERP ecosystem. You have enterprise resource planning, and you have manufacturing, finance, and other systems. Big manufacturing industries usually implement ERPs because they want to do reporting, etc. SAP has this custom box stuff, and it is very difficult to get the data out of your SAP systems. So, you have to use SAP HANA. If you're not using the SAP systems, you don't really need SAP HANA. You are free to go for Snowflake. If you have an ERP system and you need to get the data out and move into an SAP or ERP system, and you want to have a data warehouse actually of ERP system, then SAP HANA makes more sense because it can natively talk to SAP. In such a case, you don't want to go for Snowflake. 

I would advise looking at your environment. Look at the workload and what you are trying to migrate. There is no one size fits all model. If you are a transaction system and you want to go with Snowflake, I would not advise this solution. If you are a reporting system and you want to migrate, Snowflake is the best choice. 

You also need to look at what kind of queries people are running. Don't assume that just because you are moving to Snowflake, you are going to cut down the cost by some factor. That is not going to happen. You need to really do a lot of homework and groundwork to know what kind of queries you're running and how can you avoid the compute costs. There is a lot of metadata available in Snowflake. You have to look at all that and then consciously try to improve the numbers. 

It is definitely a good tool and a good database without any adoption problems. Users who are SQL savvy can immediately adopt this solution. User onboarding is not really a huge exercise. It is a very simple exercise.

I would rate Snowflake an eight out of ten.

We are a telecommunications company. The information that we have there, it's Oracle Suite including a CRM, help service integration, and more. That's the core of the system. All the information is available to users using Oracle BI, and some other tools. We're very Oracle-based in our product choice.

In the past, all the reports that the organization needed would have to pass through a new requirement. And in order to create it, a person needed IT, and the developers. They would have to then test it and release it. Now, since we have this information available, access depends on the role, and the security filters and the user can access information and can make their own dashboards and reports and take decisions. They no longer need to go through IT and developers.

We're working on making our usage to be part of a service in a manner that the client can use the information and create their own dashboards, and reports. The client can access the information they need based on the role they have. It prevents them from being dependant on an IT department for access.

The data replication is very good.

The solution offers a good data warehouse.

The solution allows us to avoid conflict with the transactional databases. 

The replication of the database needs to avoid collision with the transactional databases. That's a very, very important aspect that needs to be looked at. 

It would be nice if we had access via mobile devices. To be able to have this information and the dashboards on cellphones or tablets or something like that would be great. It would make the solution similar to Tableau, for example, and other kinds of solutions. 

The initial setup process is very difficult and extremely complex.

I've used the solution since about 2017. It's been a few years at this point.

It's a pretty good solution, however, there may be more opportunity for more stability within the product. That said, the hardware and the database are some of the best Oracle has. It's pretty stable.

The on-premises versions of the solution are very difficult to work with, however, the next-generation cloud-based options are likely easier to expand as necessary.

We have about 800 concurrent users on the solution at any given time. It's a mid-sized company.

I'm not sure if we have plans to expand out own usage. It's a difficult time in Mexico, politically and also with COVID. We had plans to change some things last year, and they have since been pushed out. We're looking at different aspects of our entire system and we're reconsidering how it operates and if we should add partners or not.

While we used Oracle consultants for the implementation of the product, and that did not go very well at all, now that it is set up, I can say that we do find their general technical support quite good. We're on good terms with support in general, which comes from America, and I would say we are satisfied with the level of service Oracle provides.

We used a different solution a long, long time ago. It may have been something like InfoWorks. However, as I said, it was quite some time in the past.

The initial setup is not straightforward at all. It's very complex and extremely difficult.

It's not easy to explain the entire process overall as there's a lot of criteria. We start working on the requirements, and the first implementation was not exactly what we spec'd it for. We had to start over, and we were complimenting these requirements. However, the functionality and scope ended up not being agreed upon by two partners. The users also did not take into account that they needed to be a part of the process. There were just so many moving parts that never lined up properly.

We've realized that a good solution must also be easy to use as the users will end up being the ones accessing the information, and, if they are confused, they'll never use the technology. On top of that, the requirements and scope need to be clear upfront.

I'm not sure how much staff has been needed for deployment and maintenance.

We used Oracle consultants and our experience with them was very, very bad.

I don't handle the licensing or billing, therefore, I'm not familiar with the direct costs of using this solution.

We did look at SAP before ultimately choosing Oracle. We may have looked at others, however, it was a long time ago. I'm not even sure if the same companies exist.

Ultimately, we chose Oracle as it was more suited for telecommunications whereas SAP was more into manufacturing.

We don't have a business relationship with the company. We are just users.

I'm not sure which version of the solution we're currently using.

While telecommunications is an area that always does pretty well - as people need internet and other related services, even in these strange times, it's a strange time in Mexico for a variety of reasons and therefore we are rethinking how we are approaching entire systems and maybe holding off on some decisions until the landscape clears a bit.

While I like Oracle as a solution, and its hardware and database are quite good, when we're talking about implementation, scalability, and integration, I would not recommend this solution. The best option today for a telecom company is likely Salesforce Vlocity.

I would rate the solution six out of ten.

I am a freelancer in this area. Microsoft Analytics Platform System is a suite of many different products. I have been busy using Microsoft Analytics Platform for the last 10 years and it is not really one single product. There are many different tools and many different technologies used both on cloud and on-premise. It is maybe a hundred products. There is not one single component that I would call Microsoft Analytics Platform System because it is just that: a system.  

Because that is the case, it is very difficult to pick one thing as most important or that we use it for most because it is so versatile and serves very different needs for different users. Sometimes a part of the suite is used by just a couple of people and sometimes by a complete team or even groups of teams. It really depends on the situation and the solution the product provides for a given project. No part is the primary part. I could only say that the use case is to work with a unified system to enhance collaboration, analysis, and productivity, and only that.  

Personally, I get assignments from companies and I then implement those assignments for those companies. I, myself, do not use those products at all. So I am not going to use more or less of a particular part or service. I go to the assignment and I implement the solution in Microsoft Analytics Platform System for them. I do all kinds of different projects, from small to medium to very big. My personal use case is to do the implementations for projects for those companies.  

The most valuable part of the product is that it is a system. It has different tools for different services for different kinds of scenarios. It is a very rich tool and an integrated technology-rich platform. The total integration with the rest of Microsoft products is probably the most valuable piece that creates flexibility and compatibility and makes the tool a very useful one.  

In general, I am not really very satisfied with the tutorials that are out there. When Microsoft releases a new tool, technology — whatever it is — oftentimes it is not really very easy to get your hands on the insightful information and documentation, training courses, and other training materials. If you can find them, they may not explain what you need to know in a nice way. Often times they are a little bit fragmented. These user-oriented guides are something that should be better and released along with the products they are supposed to support.  

For example, we have servers in Azure called Azure Data Factory which I work with quite a lot. When a new feature or new release happens, finding the right documentation or resources that explain these features and how do you work with them is a little bit more difficult than it should be, in my opinion.  

There are probably a lot of extra features that might be considered to add to the scope of this solution. However, adding ports for different types of users may be one of the best. Certain users are advanced users and they can find their way around. But sometimes non-technical users or those that do not have a lot of technical background can find the complexity a little bit difficult to work with. Better handling of user gateways and privileges would be a benefit.  

We have been using this solution for the last three or four years.  

I do not personally see many issues with the stability as long as everything is configured correctly.  

Essentially the scalability sometimes is a little bit difficult depending on how it needs to be applied in some scenarios. I have been working for very different companies from medium-sized to quite large — a few thousand users. Oftentimes only for groups of 50 plus users. Scalability is inherent in that scope and it can be done. The specific reasons and application of scaling may make it more or less challenging, but it can be done.  

I would say that the technical support is satisfactory. It is neither really good nor really bad.  

I have used other products like SAP or other third-party tools here and there. Most of my experience is with Microsoft Azure and I have not really considered working with other tools, platforms and solutions too much simply because Microsoft is best at integrating with their own products.  

For me, the setup is quite straightforward.  

The deployment can take just a few weeks in some cases. In some cases, it is a month and even years because of the scope of the rollout. So it really depends on the project.  

As I do the installations, I do not need to use outside services.  

I would recommend and do recommend using this product for others who need it.  

On a scale from one to ten where one is the worst and ten is the best, I would rate this product as an eight-out-of-ten.