MANTA Cases

MANTA Cases #3: (Not Always) Agile Development

Many companies seek to achieve an agile development strategy. Sometimes it is not exactly needed and might bring some difficulties (as our CEO Tomas Kratky already mentioned in one of his older articles here).  But sometimes an agile-type strategy naturally evolves in the development department. In the third part of our MANTA Cases series, we will take a look at how one of our customers uses MANTA in a (not agile) development team. 

Many companies seek to achieve an agile development strategy. Sometimes it is not exactly needed and might bring some difficulties (as our CEO Tomas Kratky already mentioned in one of his older articles here).  But sometimes an agile-type strategy naturally evolves in the development department. In the third part of our MANTA Cases series, we will take a look at how one of our customers uses MANTA in a (not agile) development team. 

One Too Many Patches

One of our customers, an international bank, was using a workshop-type software to release internal production software. Because this internal database software is so complex, they have 10 to 15 patches of code each day between releases. To make sure that the environment doesn’t crash, they have to deploy these patches of code all at once. Each patch of code is created by a different development team, and the individual teams are not aware of the dependencies between their parts of the code. Because of this, the patches were often deployed in the wrong order causing the entire environment to crash.

These crashes often made the deployment process last more than one day, with numerous other patches needing to be developed to fix the problems created while deploying the previous patches.

Understanding the Environment

The patches of code the development team wrote were all improvements to their internal database system (e.g., changing database logic, repairing certain objects, even adding new columns or creating more tables and views). Such patches resulted in changes in paths or even in values within the environment. And given the size of our customer’s database – which contained multiple banking systems, each having an average of 180 thousand scripts – and the amount of data being added to the database each day, it was necessary to perform the 10-15 patches daily.

The only way the customer could keep up with the (not) agile development pace and effectively find the dependencies between the patches was to apply automated software like MANTA.

Post-MANTA

Now that the customer has MANTA on their development team, they take all the patches that need to be deployed that day and let MANTA run them. MANTA draws out all the dependencies between the individual objects that the patches are related to. Then the customer exports them using MANTA’s API and has an automatically sorted order that it needs to deploy the patches in so that the environment will survive. This has cut the entire deployment down to a couple of minutes and has also made it a one-person job.

This one person now only needs to:

  • Gather the patches
  • Upload them into MANTA
  • Use MANTA to determine the order of deployment
  • Order the scripts accordingly
  • Release them in that order
  • Done!

Conclusion

Now, the customer can be sure that the patches will be deployed correctly and that it will be done in just a couple of minutes, making the daily-release strategy actually work out every day.

MANTA has been an enormous help to their situation. And well, what can we say: this case is proof that not every development team chooses to be agile. Some just have to adjust their development pace to the complexity of their environment.

Be sure to read more of our MANTA Cases! Any requests? Any questions? Send your comments to manta@getmanta.com.

MANTA Cases #2: Pure Development Efficiency

In the second part of the “MANTA Cases” series, we will take a look at a US investment management company that deployed MANTA, primarily for their development team to perform impact analyses and to boost the overall efficiency and agile development processes of their internal software. 

In the second part of the “MANTA Cases” series, we will take a look at a US investment management company that deployed MANTA, primarily for their development team to perform impact analyses and to boost the overall efficiency and agile development processes of their internal software. 

The Customer had a fairly small yet, for its size, very complex data environment. The environment consisted of three databases:

  1. One was used as the main data warehouse that collected data for the core business
  2. The second database was a special investment data mart database (this database had specific requirements, making it even more challenging for it to co-op with new releases)
  3. The third database contained resources for the sales team

The entire environment contained about 15 hundred scripts, of which 20 to 30 percent were legacy code. The other 70 to 80 percent were newer code that was evolving at a fast pace due to the customer’s agile development standards. The customer used Microsoft SQL, most of the ETL code was in T-SQL, and some scripts were in SSAS.

Given the user requirements for each of the separate databases, the environment was growing and its expansion was necessary – otherwise, it would have become a burden. And, as is always the case in development teams, that familiar question was floating around in everyone’s heads: What’s gonna break if we make changes? The customer had developed an automated testing process for new code involving Unitask software, but for the legacy code, there was nothing like that. This made it necessary to deploy a tool that would define the dependencies between various parts of the code.

Now that MANTA has become part of the customer’s development process, MANTA can show the development team the impact a new release will have on existing code, making it easier to catch most of the larger issues during the testing phase. The issues the customer faces after a release have been, in their words, reduced by half and are in general much smaller.

Another benefit of MANTA for the development team is that the overall testing time before a new software release has been cut by 10 to 20 percent, and the number of developers needed to perform a release is now 2 people!

In this case, MANTA helped the customer maintain an agile development strategy for their internal software and improve the overall performance of impact analyses. However, due to the benefits that came with it, such as the reduction in overall testing time and the number of people needed to perform a release, MANTA could easily be beneficial for companies having trouble with staffing as well as for other small development and business analytics teams.

Do you have any questions about this specific case, or would you like to learn more about how to deploy MANTA in your company? Write us at manta@getmanta.com.

MANTA Cases #1 (Pilot): Market Data Tracking

We have created a new series for you on our blog: MANTA Cases. Real-life examples of how to use MANTA are what interests our readers and prospective customers the most, therefore we have decided to periodically publish some of the most interesting and creative cases on our blog. You will be able to find the entire series in the category called “Use Cases & Case Studies” on the right side of the page. Enjoy!

We have created a new series for you on our blog: MANTA Cases. Real-life examples of how to use MANTA are what interests our readers and prospective customers the most, therefore we have decided to periodically publish some of the most interesting and creative cases on our blog. You will be able to find the entire series in the category called “Use Cases & Case Studies” on the right side of the page. Enjoy!

The first part of our series is dedicated to using MANTA for market data tracking. This interesting way of using MANTA was thought up by a company that provides analysis and reporting services to their customers. Such companies handle large amounts of data. They themselves also need to buy enough data for their analyses and reports from other companies, e.g. market data from Bloomberg and others.

The problem, in this case, was not a matter of personal data, therefore they did not need to comply with GDPR. (Compliance projects are, by the way, one of the most common uses of MANTA.) This was data such as past and current prices of shares, market research data, and other data that has a different kind of “sensitivity”.

Here, there were two main problems with the sensitivity of the data:

  1. When the company buys market data from third parties, they often need to assure the seller that the data is being handled in a safe way, with minimum risk of leaking, and it usually must be used according to the terms of a license agreement for data use.
  2. The second thing to look out for in relation to this data is that such data is usually priced according to the number of users who have access to it.

Based on these two points, MANTA had to help the customer with the need to comply with the licensing agreements, to be able to prove how and where the data is being stored; and to be able to prove the number of users, to monitor the profiles of the users working with the data.

How does MANTA solve these problems?

MANTA documents what market data sets are used in which individual reports. When combined with access privileges to the individual reports, the company has a clear and documented understanding of which data set is used by how many end-users, and they pay for the particular data set accordingly. Moreover, with people coming and leaving and any changes happening in the actual data use, the always up-to-date lineage gives them exact numbers at any point in time.

Do you have any questions about how MANTA can solve a problem at your company? Contact us at manta@getmanta.com or use the cute little bot on the right. 

We cherish your privacy.

And we need to tell you that this site uses cookies. Learn more in our Privacy Policy.