Stitch

All of these things totally depend upon your business logic. If you want to remove duplicates or you want to implement some kind of format for postal addresses, like keeping pin codes in this format, you can customize your code accordingly and then you can get consistency in the data.

Since the way everyone is moving towards AI, my suggestion will be to lean more towards natural language processing. So rather than writing proper SQL, the way Snowflake  is processing or Cloudera is processing things, they should also have a chatbot or something similar where we can simply write things, it understands that particular thing and enhances that particular thing at the back end.

I do remember I used to work for geographical interfaces, where we needed most of the location information. It was a petroleum extraction client. So we needed the location and everything. For that, we used libraries that were more focused on getting the basic distance between two geographical locations and everything. Those kinds of functions, if we wanted to implement them, we used to extract that particular thing from the external libraries and use it.

Definitely. Even though you are paying a huge amount, the quality and the time it takes to process big data is definitely lesser. Things are more systematic. All transformations are connected to a pipeline. If you have implemented those things in production and there is any bug, people can easily debug things and identify where exactly the pipeline has an issue. You have easily accessible logs and notifications available. There are a variety of components which can be used to implement any of your logic.

With my current client, I am working for a client who has used Stitch . They have provided it in their environment only. I do not remember from where they have purchased it.

During the processing of transformation, sometimes we used to bring up our own logic, like removing duplicates from the data if I have checked two or three keys. Rather than picking up the one which was provided, there is not a process where, for example, if I have four duplicate keys in the record and I have checked two or three fields and ideally we want something which should also utilize the way the record came. The first record which came should not be deleted, and anything other than that should be deleted. Those kinds of functionalities are not provided. It randomly deletes whatever if it finds a duplicate. These kinds of small things, I remember when I worked, I faced challenges because I was doing a migration and my data was not matching. Then I realized these kinds of features are available in this. That is the reason, it is not the problem for Stitch , it is with other ETL tools also.

Seven to eight years.

It is very rare. I have seen and faced the issue, but it was very rare that there was a network issue, meaning some kind of thing which has broken down and we were stuck and were not able to work on that.

It depends upon if you are using the cloud version, then definitely it is scalable for sure. Or if you are using a normal legacy one, then you cannot scale it that much.

Definitely positive. The kind of support Stitch provides is good.

I used to work with Azure  back then.

Anything which reduces your effort of writing code is beneficial because it will reduce your time. Efficiency is important, and since it is pre-written or reusable code which we are writing, it is going to be more efficient, definitely. If they are providing automation, then definitely it will be beneficial for any of the business or any of the domains you are working on.

To be frank enough, I will say right now that since we are not using it, they are too expensive. I will be very frank to you. If you are using any ETL tool, they are too expensive. People, if they are working on any of the databases such as Snowflake  or Databricks , are trying to get involved in using their functionality even more rather than picking up this additional ETL tool and moving towards that.

Other

I have moved my role, actually. So basically right now I am into management mostly. But my projects which I am handling right now do have those things that have been handled. Greenplum  I have used long back in my previous organization.

If we talk about Greenplum , I worked on that around seven to eight years back. That was a long time ago. PostgreSQL  is used frequently by any project, whichever you pick up. PostgreSQL  is used very frequently. That is why I mention it.

I have worked with Stitch, Alteryx , Informatica, and DataStage. There are most of the ETL tools I have worked on. I worked on Stitch for five years, two years in DataStage, and I am also certified in Informatica, which is another ETL tool. I also worked for one or two years with Alteryx , which is another ETL tool.

My whole experience is on ETL only. Even though I am doing project management right now, all my products are related to migrations and everything. They involve those ETL things. Since everyone is moving towards Snowflake or Databricks , they are migrating, but the projects still use ETL tools.

I worked as a partner integrator, mostly for data transformations, extraction, and transformation. Transforming the business logics and everything.

Stitch is totally capable of doing those things. It is the way you implement it. It is totally the way you want to customize your code and you want to implement your business logic. If the developer is good enough, they can utilize that tool in a very good way.

Right now, since the way things are moving in the market, everything is on cloud right now. Mostly, even the current projects I am working on, everyone is migrating towards cloud.

The learning curve is moderate. It is not that complicated.

You need a skilled resource because what happens is the person who is a coder, such as I am a coder in Python and JavaScript, can easily go and start it. But when you are working with such kinds of tools, you need a person who is tool-specifically skilled. Have they worked on this particular tool? They need a person who has some knowledge about the tool. They should know where which functionality is available. Those kinds of details they should know.

I give this review an overall rating of eight.

I use Stitch  mainly for designing and building the UI of the application and products that I was working with. I used Stitch  to design and build the UI of a colony management mobile application, which stands out to me. I have used Stitch for building high-class web applications, which played a big role in my projects.

Stitch gives really better high-class mobile application UI designs that helped me with those high-class applications. Stitch gave me the option to export the HTML and CSS code for the pages it provided, which was a really good feature, even during the free trial.

For building a basic UI application structure, Stitch has been really good, and that positively impacted my organization. Stitch saved a lot of time, gave more options, and made it very quick and easy to build a UI.

Stitch only gives a few UI design pages, and not much more than that, which is an aspect that can be improved. I wish Stitch would add more screens at the same time, not a limited number, to make it even better for me. Stitch gives a very limited number of UI designs, which is what comes to mind for needed improvements.

Stitch was changing the UI design at each screen, so every screen had a different UI design that was not according to the theme of the application.

I started using Stitch when it was very new and just launched, so I have been using it from the very beginning.

I didn't notice any explicit crashes or bugs with Stitch, as it is actually stable, but still, it needs to be improved.

I think Stitch can actually handle more complex and more number of projects and complex designs because it was at a very early stage that I used it; however, I don't think that Stitch itself is scalable. I would advise that you should not use Stitch if you are going to build a big number of screens or a heavy UI application with complex designs because it is not ready for that kind of work.

Stitch's UI is actually really good, beneficial, and very beginner-friendly; however, for heavy building and highly scalable applications and a big number of screens, Stitch is not a very viable option according to me.

I never needed to contact any customer support for Stitch, and my experience with it was fine.

I haven't seen a return on investment with Stitch as it did not save me time or money.

I used Dora, which is also a very good 3D design UI artificial intelligence, before trying Stitch because it gave some free credits, although it didn't allow me to export the code. I haven't known about other options besides Dora before choosing Stitch.

I don't have any knowledge about Stitch training, but I have basically used Stitch for its free trial. I used it just two or three times for building high-end designs. The first stage with Stitch was bad due to its features.

I used the free version of Stitch, and that was all regarding its deployment in my organization. Stitch's pricing, even though I just used the free version, was not really that good because there were many options. I think it's not that impressive because there were many options, other AIs like Dora, which give free 3D design files. I would rate this review a 7 out of 10.

Stitch  is primarily used for integration between multiple systems in our environment. On top of that, we have data integration and data analysis. We draw information from multiple systems, both systems that we manage ourselves, and we have a number of data partners that manage their data. We hook into their environments, use their information and our information, mix it all up, and then develop new products. Primarily, we're using it for analysis around the data that's captured around the environment. Our council is responsible for looking after a large chunk of New Zealand and monitoring air and water and sea, and managing the quality of a large number of different environmental factors. We need to keep reporting that in real-time aggregation on a monthly and yearly basis. We're looking at how climate change is affecting our environment and reporting on anything about the environment.

The benefits of Stitch  that we see are the ease of being able to integrate and visualize data that's in other systems. We're dealing with APIs, both XML and JSON, and pretty much every integration format that you can imagine. The platform itself is really easy to hook into all of those different outside sources and bring it in and transform it into a format that meets all of our internal systems. It's just the ease of use really.

We're connecting to everything with the extensive connector library in Stitch. There are pre-built connectors already in there, but one of the big powerful things about Stitch is that a lot of these specialized systems aren't standard connectors, like SAP or any of those big systems. Because the components themselves are very configurable, we can actually connect to systems that don't have a standard interface connection or have an API but the XML format isn't quite normal or the JSON format isn't quite normal or whatever format they're in. Stitch allows us to connect to those specialized data sources and transform them into a format that's easy for us to deal with internally.

The transformation language feature helps with data consistency in our case, as we convert everything into JSON. JSON is our internal standard for data formats. Stitch makes that whole data transformation part really easy. That was the biggest selling point for us.

The schema evolution capability helps to maintain data integrity because a lot of these systems don't change, but when they do change, we need to be able to manage that change in a controlled manner. The ability to transform based on different versions is where Stitch is really powerful. We can set up version one using a transformation standard, but when we upgrade to version two, it transforms the whole mapping capability. It makes it really easy to go from version one to version two in real-time. We don't have to convert the whole database; we can transform it as we need it, which means that we don't have to go through a big migration anytime there's an upgrade or change from the source system.

One of the key things is that we need benefits from real-time insights and monitoring tools in the product because we need to know when something goes wrong or something isn't part of the standard pattern. The jobs themselves alert us when something goes a little bit differently or doesn't fit the existing pattern. It doesn't stop the whole job, but it gives us an alert and makes us aware of what's actually going on so that we can intervene if we actually need to. But a lot of the time it's more of an information notification about what has changed rather than a critical alert. However, over time, those little variations do grow and grow, and the platform allows us to actually keep track of how far things are actually growing or changing so that we can then interpret whether it's the best time to actually make a change to the whole program of work, or whether we can just live with it for a bit longer.

The automation features in the product have a significant impact on our data management process because we would not be able to do what we currently do if we didn't automate. The number of data sources that we're dealing with is growing, and every year there's probably twice as many as there were the previous year. We've only got a small team, so by automating, we don't have to spend a lot of time building new internal resources to manage it. We've pretty much got the same size team as we did four years ago. The automation just makes our lives really easy.

The best thing that we've seen coming out of Stitch is the Talend and Qlik relationship becoming more of a single entity rather than two entities. A couple of years ago there was a distinction between Stitch and Qlik. The biggest challenge when we were dealing with both was that we felt like we were dealing with two different companies. They are quickly merging the two different entities into a single one, and by around the end of this year, they're planning to basically consolidate everything. Until then, it does get a little bit complicated when we have Qlik and Stitch components together. It's not quite exactly one solution. That's probably the biggest negative at the moment. Each month we're seeing improvements in the cloud platform, and they're coming out with capabilities that we haven't even thought about that are going to make our lives easier. Probably the biggest negative they have is they're doing so much good stuff, but we don't know about it. It just appears and then we figure it out ourselves, but the communication of changes could be improved. However, the positives are that they're changing so much at the moment.

We've been using Stitch for about three or four years now.

The only real glitches we've experienced with Stitch are when we have uncontrolled change in our environment. All environments are reliant on their firewalls and networks. If we don't change anything to do with the firewall settings, then the last time we had a server issue was probably around seven or eight months ago. It's all running in a cluster, and we can auto-restart servers whenever we feel appropriate for load balancing or the distribution of job resources. Stitch is really stable.

We've found that the scalability of Stitch is really easy. The easiest part is that we just spin up a new server and add it into a cluster, and then it pretty much manages the load balancing across all the servers in the cluster. We keep track of how much CPU is being used at different peak times and all of that. Because we manage most of the load ourselves internally and it's based on internal systems, we're actually pulling more data into our environment and feeding it out to external customers. We can control that load quite well. When it does hit the limits, we just add a new server into the mix and let Stitch manage itself. It seems to work really effectively.

The initial support people from Qlik are really good. The best skill set they've got is that they know when the issue is outside of their knowledge, and they escalate really quickly so that we get to the right people when we need them. We've got a couple of solutions internally that seem a little bit unnecessary, where we ask a question of the support desk and they'll spend a week or two trying to resolve the issue when they really don't have the technical know-how. That's one of the really good things with Stitch support. If they don't know it, they escalate it and we get somebody who can resolve the issue really quickly. The support people are excellent.

The deploying and initial setup of the product is straightforward, but there's a little bit of configuration involved with the remote engines and the runtime environment. The documentation is really good. You quite literally just follow the steps that they say and then double-click an executable and you're away. We have had a couple of issues and they've primarily been our problem rather than the Stitch environment. When we've done upgrades and haven't kept up with the regular monthly updates, we've had things get out of sync. We've had to reinstall the Studio type environment, and it was a complete mess. However, twenty minutes later, we reinstalled it and everything was completely up and running with no problems at all.

We've got a project at the moment that we estimated the integration was going to be around $200,000 to $300,000, and we've been able to achieve the integration for less than a tenth of that, doing it in-house using Stitch. Additionally, long-term, the support and maintenance are better because we don't have to manage bespoke code and we don't have to manage the life cycle around that code. It's all built inside of Stitch and managed for us. It's quite literally a configuration rather than a writing code scenario. We've done a huge saving and that's only one of a number of projects that we've got on where the same sort of things are happening.

The worst thing about the price and licensing model of the product is that it sounds really expensive when you start to go into it because a lot of systems require ten or twelve seats. The challenge with Stitch and the whole Qlik environment is that you don't need ten seats, you just need three or four. The three or four seats will actually do the same as what you would have ten or twelve people in another system. People look at the price of the seats and think it's really expensive and that they're going to have to put ten or twelve people onto it. Actually, if you put ten or twelve people onto it, they'll be running out of work pretty quick because you'll be able to achieve so much more faster and don't need quite as big a team. The cost of the seats is actually cheaper by the amount of value that you're adding to the business. The seats sound expensive, but long-term, they're probably a lot more cost-effective for the amount of volume of work that you're getting through and the value you're adding to the business.

Stitch is definitely worth going for. A little bit hard to provide some metrics or examples of the impact on the data management process, but we have seen the number of transactions per minute increase by about 400 to 500 percent in the last two years. The number of meters that we have out in the real world actually measuring things like air quality and water flow has increased by about 300 percent. The number of databases that we've connected to has probably increased about four times from what we had about three years ago. Everything is pretty much three times as much now as what it was a couple of years ago. Our overall rating for Stitch is nine out of ten.