Spectrum Technology Platform

 View Only

  • 1.  Experience in Sagent => Spectrum migration

    Employee
    Posted 02-26-2019 04:56
    The first customers from Germany have embarked on the journey to move from Sagent to Spectrum. So I wondered what experiences others have made. Anything to watch out for?

    I have been a long time user of Sagent and found it hard to get going with Spectrum. Later I realized the main difference: with Sagent, I always started with data: I pulled them in and then started to transform them. With Spectrum, it is much better to start with a function - that being Address Validation, Geocoding or something like that. Then you seek to get the data required for it. Once I understood this, it became much easier ...

    What is your experience? What helped you to get going?

    ------------------------------
    Marcus
    ------------------------------


  • 2.  RE: Experience in Sagent => Spectrum migration

    Employee
    Posted 02-27-2019 03:02
    You are probably the first user (amongst the ones I've spoken to) who has compared Sagent & Spectrum, and rated Spectrum better! All I've heard till now is that Sagent is far better in terms of functionality & performance w.r.t. 'ETL' capabilities. The comparison is fair & it is bound to happen when you try to replace an existing product with another one. It is good that you started this thread & with this we should try to gather all the features/aspects of Sagent that makes it better than Spectrum (if that's the case actually!). This will help the Product Management team to prioritize the features, if we get solid facts about these missing features in Spectrum.

    Waiting to hear from folks on this...  

    Thanks!

    ------------------------------
    Himanshu Verma
    CIM - Technical Product Manager
    Noida, India
    ------------------------------

    Original Message


  • 3.  RE: Experience in Sagent => Spectrum migration

    Employee
    Posted 02-27-2019 06:45
    I am a big fan of "external" information. Let's have a look here: https://www.alooma.com/blog/etl-tools-comparison
    There it says : Limitations of incumbent ETL tools
    The biggest limitation of incumbent tools is that they were designed to work in batch: gather some data, upload it, gather more data, upload it, etc. Batch loading of data works in some situations; however, there are issues with a batch-only approach.
    Batch data transformation tools can be hard to implement for cross platform data sources, especially where Change Data Capture (CDC) is involved. When something goes wrong with your batch data upload, you need to track down the problem, troubleshoot, and re-submit the job, quickly. This kind of error handling is crucial as lost data can be a huge issue in cases where you have, for example, surpassed your 24-hour allotment of API calls in the data warehouse, or where the incoming data gets backed up and CDC information is lost or overwritten.
    And what about the ever-growing number of streaming and other types of data sources? They are not a good fit for toolsets designed and built around batch processing, especially with today's demands that the freshest data be available as quickly as possible.
    and it is hard to argue with that ...



    ------------------------------
    Marcus
    ------------------------------

    Original Message