 experience report of our journey on applying extreme programming practices on ETL projects. How many people here have worked on ETL projects just so we get a sense of who's here? The rest of you, are you aware of ETL? What are the challenges in ETL? And we're going to talk about some of the challenges that we face in ETL and how we apply extreme programming practices to those things. Those are some gifts for people who are going to hang around till the end. I have stayed in a hotel, right? It's a safe assumption to make. So when you walk into a hotel, they give you a price. This is the price of this room. They might have different categories of room and they might say, these are the different prices for you. Do you ever wonder how do they code these prices? From where do they get these prices? Is the person at the counter just out there looking at you and saying, looks like handsome guy, should be 7000 rupees. Or do they have some standard rates defined and they just apply the standard rate across? Well, it actually turns out that Ideas is a company which basically builds these analytic systems which basically take a lot of data from different systems and then does a bunch of analytics on top of it and then determines for different kinds of people who get into the hotel what the price should be for them. So in short, what we do at Ideas is we do revenue optimization for the hotel industry. We also do revenue optimization for car parks, big large airports. We have big car parks and we do revenue optimization for car parks. And so that's kind of a quick list about ideas. And the reason I talk about that is because it's important as we get into the nature of the problems we are solving to understand and appreciate what are the challenges we face. So if you look at a typical ETL process for us, there is a bunch of input data that is coming from different systems. You have various different hotels that are sending you data. You have third party systems from where you're getting competitors data. What are other hotels or what are other people selling their hotels at? You have a bunch of other third party systems that you have. Social media, we want to know what is the reputation of the hotel. Based on the reputation we want to determine certain pricing and decisions. So we have a bunch of downstream systems or input systems sending as data which comes in different formats, some send it as files, some send it as messages, some send it in different formats. And that basically goes into our ETL stage which will basically normalize the data, we'll do aggregation, we'll do various other kinds of data cleanup and then we'll take a copy and keep that because you need to have data over a period of time to be able to apply our next stage which is the IP or the analytics stage where we would apply analytics on top of the data that we have got to be able to come up with these pricing decisions and what price you should sell, how much overbooking can you take, what would be the cost of walking someone to a different hotel if everyone shows up and you have overbooking and things like that. So some very complicated decisions are made and those decisions need to be sent back to these systems because they need to know what the decision was and at what price they should sell or how much overbooking or things like that. Again, if you look at here at the bottom there are different configurations or different parameters based on what you decide how much data to send you need to send the entire decision you need to only send the data you need to send it for the entire year because someone's not just going to book the hotel for today they might be booking for a hotel in the future date. So those kind of decisions whether you need to send a file, whether you need to send a message whether you need to send some other format so there's a lot of configurations and based on that you would send data back to these downstream systems or outbound systems. So that's in a nutshell as simple as I can make it what goes on in this system. So there is an analytics piece and there is ETL piece which is basically going to trans all the data that comes in. So that's a quick context. Profil, we were talking about from a development point of view, right? How does it work? Yeah, sure. If you can't hear me ETL, ETL, ETL, that's the word we hear in our organization many times. ETL process, we, in the ETL process we talk with unknown and unknown vendors sometimes known vendors they are difficult to deal with and unknown vendors they are very easy to deal with. Our ETL process starts with discovery because we don't know what data we are going to get. The discovery phase is a very important phase in our life because we need to know what we are going to deal with. The concept is formed. What is the concept? I want to use my social media data to make or refine my output or my decisions to the product. That's the thing like, how does it come to us? There is an innovation concept that gets said and there is hope you should be doing this. There is a market research that tells us we should be doing this. There are vendors who come to us and say please can we do business together? There is our own team, they tell like we need to go and look for this data that will improve our ETL. So that concept after a long wait we decide that we need to do such and such ETL process. The next thing happens we start with the data exploration. Who are the players in the market who could provide us data? First of all we have just the higher information about our own social media data. Apart from that I don't know what exactly I am going to be getting. Then we find out those players can help us in finding out that data. And we start interacting with them and we come up with a set of data. We tell them please don't bother yourself when it comes to sending data to us. Just we want to know how to pass it. We will take care of it. So what we get here is the unstructured data. At the same moment we get our research team together and keep this data to them. Research teams analyze the data and they come up with some idea as to how this data could be used in practice. And once that is parallel, that decision is arrived then there are certain teams, special teams they come to be and they start structuring the data. I mean thousands of fields or hundreds of fields are not really useful. Analytics says we need just between 20, 30, 40, 50 colors. We don't need more. So we just constrain that data, unstructured data and we come up with something what ideas needs. And this is then put into an informed form. A specification document for outward vendors and they go through all these documents that we are working on. So this is the phase where we just transform our unstructured data into structured data with the help of those analytics team members. The general process would look like this. The flow would look like this. Concept, form concept, get the data, explore it, structure it. Then give it to your requirements to detail the work. And we also formalize our communication interface. We got this stuff. Then the two teams we are with weekly handshake or a four-night handshake. And then ideas team starts looking at internet customers, their way of communication, the requirement for each of them. And the software is formed and then it is delivered as a specification document. So generally it's a way of communication. So let's talk about some of the typical challenges that we face when we try to accomplish this. So we've kind of given you very brief about the context in which we operate. What is the general workflow or lifecycle of how products get built. So when you take something like this, what are the typical challenges that you would see? The first and the foremost challenge that you would see very clearly is that a lot of teams are involved in this. A lot of handovers, a lot of handshakes. And that leads to a lot of people working in silos. The next thing you will see is people start focusing on what they need to do and the awareness of the big picture about how, let's say you're getting some reputation data over here and how that's going to influence some of the decisions. That entire big picture might be lost. People work in silos and people focus on their piece of stuff. That obviously leads to last minute surprises. People end up with having some kind of surprises. We have external parties. We have internal teams. We have a lot of moving parts into the system. That obviously causes late delivery. No surprise over there because you end up doing rework. You end up doing a lot of rounds of negotiation. And if you look at overall time to market, these days time to market is extremely critical. Time wants to squeeze the time to market as little as possible. But the nature of the beast that we are dealing with is where you end up basically spending a large amount of time in the discovery because you don't know how this data can be used. This is not building a website. You're trying to figure out there is some complex data simplifying that down, then taking it into your system. So a lot of time spent in the discovery and by the time you say that data actually can be transformed and can be used this way you have very little time left for actually doing the development. Does that sound familiar? Yeah. So when you say there's very little time for doing development, what development? What development? So what we have done in the discovery process is we've basically taken the data. We've run through various different algorithms in the analytics side and we figured out that yes, this will influence. But we need to work at a much larger scale now because that data will come consistently. You need to automate a whole bunch of things because it was all done manually to start with. So automating that and so forth. Automating a lot of different things, building more resilient code because you just took data, you got it to see work. Okay, this is useful. Now you need to automate the entire process. You need to make this scalable, consistent, all of that stuff. So that's where a lot of time goes in development and development gets squeezed as usual. What would that lead to? Everyone's happy? No, of course, because everyone's squeezed for time so there's a lot of things to point out. Only if you guys could have discussed that and formalized that in the case earlier, we wouldn't have to deal with all of this stuff. And a lot of that unfortunately scaling becomes a bottleneck because we are so focused on getting this to work but we don't think that what scale will be operating, how many integrations we will be doing, what is the amount of data that will be coming in and the system that will be building, can they actually scale seamlessly? So some of those challenges you will see and I think, Prof, why don't you talk about some of the vendor related challenges because that's a big part of how we operate. So far we've seen how the idea itself affecting the development or the delivery. But there's another play that we have seen the small little box with state vendor. And vendor is really important because if vendor doesn't send data to us, we are not going to be trying or refining our values or decisions to our customers. So we also take care of our vendor. We also work with vendor very closely. The most important problem that we face with the vendor is the requirement conformity. When the says, when the A says, oh, I can make your requirement very easily, vendor B says, oh, we don't maintain this data. Vendor C says, we can't give this data because there are some legal findings of us. We cannot do this. And then you start generating. That adds to a lot of discussion, signing contracts, so many things. And then you get first glimpse of that data. And what the third vendor C has the largest client list. Then our time to market is still like, next thing is requirement misunderstanding. We always make all the phone, we don't know who the vendor is in Singapore, Tokyo, LA. Or they have a person working from LA, they have a person sitting in Chicago and few members, developing members in Singapore. Lot of different combinations we see. So for them also, what ideas one, they don't know at times. And first thing, when we have first meeting this year's specification, they all say, yeah, I've been understood everything. Yeah, it's well and good. When they start working actually on it, they come back. What did we say then? Oh, we wanna do this. Oh, that's not possible. So that sort of discussions happen a lot. And we take care of it now by our experience. Then everything, they give it to us. They say, hey, ideas, take this, make this call to API and we'll get everything. And now they don't know that for a good focus system, you need data from past. And now they say, we need data from past for two years and then if we are starts misbehaving and we are again in problem. We take care of those problems always very well. Let's change our data. But all these bottom three, they want to make changes in data. They're neither mining, they also, all the things that matter to us. Delays are part of our system because we work with different vendors. So just to give you an example, for parents, when we import the data, we have 45 vendors. For social media, we have four vendors. And all of them, and competitors, we have 15 vendors. So they all have their own way of working. They have their own lingos, their terms about the business, they are different from ideas. And it takes a lot of time for us to match the expectation itself. And priorities, of course, if ideas business is not priority, who will you work with at least? Now, very priority, that's all that comes there. And we undertake queries of experience, we manage them where? So that's about the better. But we take a break here. Let me do this nourish. I think there's no one here who doesn't know nourish, nourish, because they are affecting you. He's a great coach, and he's a great nourisher. That's interesting. So I started working with ideas about a year ago and Profil leads one of the, Profil leads the integration development teams at Ideas. How many years have we been there? I think much older than how I am now. 15 years. Ideas have been there doing ETL, doing integration. So he's obviously the subsequent expert. And we thought it would be good to share our experience of how we're going through this journey. So that's where we are kind of working together on this presentation. So this is not a technical story. This is a story of efforts made by those small little teams coming together to get ideas to a level where we don't have to face some of the problems that we've discussed. Everyone has contributed this success to the success. And we're going to walk you through how we are going to tell this story. We started on that when we were practicing Agile in 2008. And that's the time we got integrated with many systems or the aspects of XP or Agile there. So we started our projects from 2008. And in the last four years we completed some of these integrations. The scale of these integrations I want to first mention, this one is almost 6,000 photos. This is nearly 3,000 photos. And this is around 700 photos. So that's the scale that we are working on. And we are also learning many things or we have learned many things for these four years through these projects. So we are going to walk you through all these stages in the next 20 minutes. I'm sure everyone is familiar with this. This is what we were doing considering the nature of the beast. And we wanted to move to something that's more I'd like to talk about ETL projects, integration projects can also benefit from some of these. But not many people actually talk about this. This is not very common. I mean, a lot of people that we know still continue to operate in the previous time. So we were not even sure if some of these practices can actually be very successfully used. So we said, well, let's give it a try. And we started with the first project that came along. We said, can we use some of the XP practices here? Let's see if this can help. So I'm going to quickly run through a couple of practices, right? The whole team approach, breaking the entire iteration into the entire release into smaller iterations so we can have something early, demoable, and we can try to see how we are progressing. We found CI was a very important integral part of making this journey. So we said, let's get this integration going. And let's set it up. We didn't even have the right tools when we started, but we said, well, let's give it a shot. We'll talk later about some of the tools that we had to deal with. And we said, let's start with some user stories. Let's not write these big environment documents that no one really needs. So let's start with breaking that down into user stories. And it's not more of an environment document, but let's try and put it in terms of what is the problem that we are trying to solve using this perspective. These were, I think, the four key practices that we started with. We didn't want to be too ambitious. We didn't want to say, oh, let's put everything and let's see how it goes. We started with these four practices and we said, let's see how that shapes up. And the entire project was actually delivered. We had some challenges, but I think these practices help. And because these practices help, when we got the next integration project, we said, well, we learned some things from that. Can we build on top of that? Can we evolve those things? And can we add a few more practices? So when we got the next integration project, we basically started with pair programming because we felt that was one of the key things that was missing in our previous project. So we started with pair programming. We'll talk a little later about some of the challenges we got into. We wanted people to do a little bit better homework compared to the planning meetings, to the grooming meetings and stuff, just showing up and wasting every month's time. So there was a little bit of more focus on basically being more prepared towards the planning. We introduced testament development. We felt that this is important and this needs to go in for our CI to be actually successful. By this time, we noticed that a lot of code that was written felt like that specific code. So we said, refactoring is an integral part and we need to introduce these practices. We have architects in the U.S. who had set some coding standards that we talked about and the team got together and they looked at those coding standards. We still debate about them, but it was a good starting point. We said, at least let's start thinking about coding standards so that it looks like it's one team producing it on a hot spot of stuff. There was a lot of focus on teamwork, team ownership. We used to work very individualistic, especially when it comes to some of the challenges we talked earlier, silos and all of that stuff. There was a lack of collective ownership. So we said collective ownership is important. One of the classic things you will see with ETL or integration projects is that people go big bang and try and look at every possible thing that could go wrong. If you're getting 500 fields in a field, how can we score all these 500 fields? Even if you're only going to be using four fields. So we go overboard. We kind of complicate things. So we said, well, let's simplify things. Let's focus on simple design. Very common in the ETL spaces to worry about optimization even before you've written a single line of code. We don't even have a system working when you start talking about what happens if you get a million records and how would you scale this, how would you optimize this? So we said, well, let's get it to work first and then we will optimize. So that was, again, easier said than done, frankly. Whenever we got a bug, we said let's do test-driven development on it. So we will write a test and prove that the bug exists and then we will do the development. So these were a few practices that we put in place for this project. Was this easy? Yeah, now is it? This is the software team here. It's the practices that everyone knows exactly what you mean by any one of those, right? It was hard. What we're trying to talk here is that these are not easy. This is a journey over four years. We're trying to squeeze it into a 45-minute presentation. Over four years, there's been blood and sweat spilled over some of these things and tears too. Okay, we got here some of these practices. Are we doing it as per the industry standard? Are we, like, perfect? No, far away from that. But we got started, right? That's the important thing. We got started. Some of the teams started accepting it. There's still a bunch of skeptics and that's always going to be there. But at least a few people bought into the idea. A few people said, yes, this makes sense and this is actually applicable to ETL projects because the first thing you talk about is, ah, that applies for website development. We are different. There's enough life for us, right? So even to get people to accept some of these is good. Let's talk about how we evolved from here for the last integration that we did. Let's talk about some of those things because we are going to be very interesting in some of those. Right, so far we have seen two integrations that we did. He'll start purely written in SAS. SAS is our current component and we selected their programming language for our media process. The second component was written in a pretty good job. So, SAS when we accepted it as a programming language we were quite new to it. I would say none of us felt even knowing what SAS was going to do. Everyone was skeptical but we were kind of a business decision that we got into and we had to do it in SAS. We started working in SAS and you see the strategy and we wrote it all exactly like that. We didn't know how SAS is. What are the do's and don'ts of SAS programming we never do that and we started just marching towards the goal. Right? That's why we got into a space I will show you a little later and when opera came by we said oh, let's do it in Java. It's far better. Java is very agile, friendly language and we got all those items covered in our operative update. There is a side to this crisis. When this came all of us we rose and said we want to do this in Java. Business guy came back and said do you know one thing? If you do this project in SAS you are going to reuse 50% of the code from Insta. I don't want to get into that angle I want delivery to be done. We said no, no, no Java is the most friendly language we want to do everything more there and we will do it. He said yes, fine. Next meeting he came back and said okay, you guys say it's Java I want everything done in two months. The development that took years was passed to be done in months and we were surprised. So we had such talks and such different pressures were there and we had three options. First thing, reward and say Java. Second thing, when you have me and go and do get your score score wherever it is possible insert your plugs out there and make it happen. And third thing, who says in SAS is not a self-friendly language everyone is too young. We want to make it a self-friendly language and let's try it. And in that way, we took that challenge and business was also happy because we are now going to do or going to reuse the code that they were asking for. So we started there but before that why SAS is so? Why people are afraid of SAS? Because SAS is not generally available outside. First thing was I introduced SAS here a little bit. SAS is a very powerful data management for Java. It contains macros, functions and procedures that help you manage your data very effectively. I have written some tests and it shows that in few milliseconds it doesn't take time and it's very data friendly language. When I was working with Narayesh we have discussed it before that some of the features are very close to functional programming. Functional programming is a buzzword nowadays. So everyone is trying to learn some functional programming language. So SAS is very close to it. And now SAS, today we invited me with this SAS, you can learn SAS on the web now. This is the link that he gave to me I just included in this session. So SAS is not really a big problem here. The code that we don't get it was a spaghetti code. Long functions, finite lines, thousand lines you don't know what is there. Another thing in SAS that was another problem to us. So we started looking at the problems that SAS posters we couldn't get unit tests in. We couldn't fail or fail that SAS could fail. We couldn't understand what SAS was doing as a programming language and we started working on these problems. It's also a platform in the language. This is a lot more to learn about the entire platform than just the language. There were a lot of things that people were afraid of. They didn't want to go. This is an unknown territory. But SAS is a very good technology engineer. It has a very good BDIG for visual analytics. And there are various other products like SAS comes up with. A lot of friends from SAS always they got us. Very good things. They gave us a presentation about SAS programming. And because of some of the suggestions they started to announce for unit testing, for estimating. And by doing so we do that. It's a journey with we could integrate in functions. They become like this. Very small, manageable, testable, measurable. Everything was there. So we adopted the first thing we made is we made part of our local bin and we made it very fast. Second thing we did is we took it to the gentils. And in gentils we also made it very fast. We published all the failure reports to the outside world. So the crisis like when there are engineering practices they are always at the core. You pick any language they have to bear at the core. The tools may not be there but when you have a commitment you can always bring it back up. So there are some benefits that we got. I think that we should have decided. I think we have 10 minutes so we will have a place to rest. So we will talk about challenges. I think that's what is more interesting is one of the challenges we ran and how we look in the world. So quickly kind of running through internal code quality because as you could see smaller functions more unit testing external quality went up. So perceived number of reports from the clients we are passing their expectation. You could see a noticeable difference in that. That went down. Refactoring was always looked as you did a shabby job and you have to now spend additional time refactoring stuff. But now it has changed the attitude. They said you know what? Refactoring is a very integral part of how we do development. It's not something that it's a mistake and now I am rectifying it. This is part of that. There was a lot of focus on keeping code clean. I mean now we would, in the planning meeting people would be talking about why this is important and there would be descriptions around clean code. Earlier we had to push for that. We had to ask you know whether are you duplicating the code how are you going to do this and now people are like I don't know I need some time to basically do that in the clean thing. So I think we saw that. This is the time to market. The time to market if you look at these three products that we evolved we could see clearly noticeable difference in the amount of time to market. Why does that happen? Why did the time to market reduce? If you look at some of the challenges that we talked about earlier late discovery and problems like that we could find some of those things we were able to integrate with the vendors much more often. We were able to work with them much more closely because of some of these things. So I think that really helped us people who were training about unit tests became such an integral part about how you do things. When you ask someone for this is the feature they will be thinking about what are the unit tests I think. And I think that's a very important shift with that person. The team felt now earlier it was like all the silos everyone working in the silos don't bother me and give me the spec I will work with that. Now this is how the team felt. So I think there was some really good stuff but nothing comes for free all of these things don't just happen. Prof, can you talk about some of the change management challenges that we faced? Yeah, so I think it comes free there are a lot of privileges and everyone had this feeling about agile practices. They had their own definitions they were looking for some prescribed steps every time because we are quite used to now what a form. I heard through lightning discussions they were all around this but it's not really the prescribed steps that you look for. But that's something which both of these we learned is the incremental design or incremental and ideal design. Yeah I mean what we were doing earlier was more of just incremental design it had to be perfect the first time and you're done with it. With the notion now you can do just enough and do a simple thing or what people call about as mile wide inch deep go mile wide inch deep earlier it was like let's get this one fully flushed out before we look for something else and this change of this attitude was very important and I think the practice of story mapping really helped us over there where we get everyone together and say okay if we want to if we're talking about reputation data and how that's going to influence your decision let's talk about the entire thing what is the outcome. Most people are surprised I mean I don't know I'm just going to take this data and give it I don't know what happens next why do I care about it. I assume the data for you to be able to you know as simple as for you to be able to do effective design of your databases right because is it going to be deep is it going to be read more often is it going to be written more often how do you optimize things so a lot of those discussions happen because of that the whole concept of creating spikes right the field in which we are there's a lot of ambiguity like it's not like a website where you know this is 10 steps and you just need to repeat that over and over again you're integrating with a new vendor you know they have some technology that you're not aware of they expose certain ways of how people consume the data and a lot of times this is ambiguity so what would we typically do we would sit and analyze and analyze and analyze and say oh I don't know that data I don't know what to do so let's do some more analysis and try to change that but yes we don't know but can we take a fixed time box and maybe two days why don't you try and just write some basic stuff to see how you can consume that data how you can get the data how you can send it downstream so the whole practice of basically doing your spikes was very important helping people change that was very hard CI taking the ownership so even though we put CI we would see that there were failed builds a lot of times don't care let's fill whatever we'll fix it later somebody else's problem not my problem so getting people to take the ownership that you can't leave the build it's collective ownership that took a lot of time to go through still working on it pairing itself I think why do I need to pair I can just do it myself why do I need to pair pairing was a hard practice to get people to understand and it was not just about developers pairing with developers it was about cross-functional pairing it's about pairing with other people because we have a very short time to market a lot of a good activity so how do you get people to work closely together so that in the given time we can deliver stuff I mean team ownership this is the classic story with team ownership I think we still have some challenges with team ownership I think it's way better than what was before if you look at testers not being part of design decisions a lot of times testers are not involved as part of the design decisions what value do they have to design so you know actually what depending on how you're designing things they would be able to tell you they would be able to mistake-proof your design but that was very hard to convince people that actually testers can add value and a lot of times bringing them in to see if they can actually add value was very important a lot of testers were also not used to doing automated testing and things like that so that was another thing we'll talk about 5 minutes to go yes how do testers get measured in most of my versions based on the number of bugs they use and the general notion is a tester is performing well so we're going to get more bugs so we want to change the attitude we want to change the attitude saying your job is not to find bugs your job is to stop the bugs from getting in the first place mistake-proofing is important rather than finding defects and inspection and again a lot of automation practices put in place things like that so again each of these things that I'm talking about like some are very easy to understand this push back helping people understand why these are important and we still by no means done we still have a lot of things to go every time a new member comes in we have to go through the same cycle again with a new member so we have some of those challenges we have last 5 minutes left so you can talk about road ahead for us I'll quickly go through what we still want to continue like we want to make more headway right now being a starting place thinking about it now it should be now integral part of like it should be integral part of the story itself story development itself simple design, thinking don't think complex take a step-by-step approach design and evolve your design try sandbox don't solve all the problems in your context solve it and bring that solution back to the context and by doing this you are going to try the evolution design how to try the programming skills and polyglot our developers should know different languages so that they understand the features in those languages and try to limit it then in some way how we use right now all the businessmen we want to go ahead with real-time integration and our teams are working on it at this point real-time was a schedule or back that is the pattern that we are now solving we are going real with the real-time there are many vendors which will be supporting this we are going with the real-time for others who may stay schedule developers the other thing that we must say is the joint application developer with vendors we see that when we have a lot of conflicts or issues there we can solve those issues when we sit together not over the phone but sit together and talk about the repair the way to take away from this for us digital practices are universal with determination and perseverance you can always pay there everything they get from standard so we have to be very determined the XP practices delayed us to create a T-Shift individuals or generalize developers many of us are now thinking in that way they are not there but now they are opening up to this idea and product history and story mapping they are quite important for our alignment with vendors' alignment they are teams so that's what we think and so our session ends here but are it yours as an audience to continue any questions? we have one or two minutes so we can certainly take a couple of questions yes can we go up to the next can we consider code refactoring should it always be considered as a technical spike or can we consider it as one of the users story in a current spring because it may not be any of the actual feature or user story that I am working on could be something else so what is the best way of considering the refactoring? okay so I'll just rephrase your questions I'll just repeat so I have at least understood it correctly I think your question is that when you have refactoring can you consider it as a technical spike or should you take it as a user story I would kind of step back and say why are you refactoring the code I am assuming you are refactoring the code because you see that you are going to be adding some new functionality or you are fixing a bug and this unfactored code is getting in your way so I would try and see that could be made part of that sometimes it could be so widely spread that putting it as part of some other story might be difficult and in those cases at least I would make that one fix for the time being and maybe add it as a technical debt story later to be dealt with so it doesn't matter so much in my honest opinion whether you take it as a technical spike or you treat it as another story the point is you need to do one in the context of what you are working at least get one thing fixed and then maybe you understand what effort it would take to do the rest of them and that could be a separate task or a separate story go ahead second one is easy we are doing a talk tomorrow where we are going to talk about that very thing so if you are interested we are going to do Sachin and I are going to do another talk tomorrow where we are going to talk about the QA transformation right correct that's the focus of our talk tomorrow so that one we will handle tomorrow let's come to the first one which is the tools we have explored which in our case is pretty standard code we have very standard pretty much open source there isn't any like paid upper form SQL server so we are playing around with storm right now and we are basically doing some experiments on it but other ways traditionally a lot of stuff was written in Java J2E and SAS was a big component as well so there was a lot of ETL work that was done in SAS between Java J2E and SAS was predominantly the tech stack but one of the things we see is that we kind of for every integration repeating the same plumbing work over and over again so we are exploring frameworks like storm and others to see if we can basically offload all the plumbing work to the framework and we can focus on the business logic and in another product a team of architects they are exploring various combinations at this moment because there is no strict answer in the market available for our problems and at times you need to just you get into a lot of pain when you absorb that basically code from the market so they are exploring newer ways to do this real-time integration and other aspects of our ETL alright last question do we need to run for the keynote? I would like to share a question I found the good point that where to introduce at what stage we should introduce those testers in the project that is a good thing actually the idea they are involving testers in a designing place really it is a good thing I just wanted to share that actually we are ignoring testers right from the analysis of the requirements it is a joint venture for us absolutely yeah so if you see where we talk about the story I think so as the testers are an integral part of the story and then we get into design description for that then we also want to involve the testers so a lot of places testers are involved in the requirements and things like that but they stop there and then go in a different direction and you are saying no let's keep them as integral parts throughout actually we are doing a real test that will be shared along with the testers and the additional testers that will lead the unit testing for them we actually are doing a lot of planning so developers and testers are sitting together and actually working so that is again speeding up things for us cool thank you alright thank you guys I know there are more questions but we do need to open the rooms for the keynote so we will come back thank you