Key Considerations for Disaster Recovery
•Download as PPTX, PDF•
2 likes•212 views
Your IBM i platform is essential to the growth and continuity of your business, and even a short-term hiccup can lead to a long-term business disruption. Will you be ready when disaster strikes? Download full webinar here: http://www.precisionsg.com/disaster-recovery-plan
Recommended
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Key Considerations for Disaster Recovery
- 1. A P R E C I S I O N S O L U T I O N S G R O U P W E B I N A R Key Considerations for Disaster Recovery Finding the Right Solution For Your Enterprise
- 2. Key Considerations for Disaster Recovery Presenters • Larry Dube – President – PSGi – One of 3 founders of PSGi which has been providing software and managed services for Manufacturers and distributors for 13 years. – 28 years of experience with the Poweri platform and its predecessors – 29 years of overall experience helping manufacturers and distributors receive the highest ROI with their ERP solutions
- 3. Key Considerations for Disaster Recovery Presenters • John Hamel – Principal – TurningPoint Systems – A seasoned technology executive with 25 years of experience – As the Principal of the Infrastructure division, John oversees and manages all aspects of the infrastructure division including sales services, and product solutions for Turning Point Systems. – Prior to joining Turning Point Systems John has a long history of sales success including sales and sales management positions with IBM and Technology Solution Providers.
- 4. Key Considerations for Disaster Recovery Agenda • DR overview • Assessing your business requirements • DR testing • DR Solution Strategies • Q+A
- 5. Key Considerations for Disaster Recovery Disaster Recovery Preparedness Council 2014 Survey • 73 percent of the respondents are failing to take adequate steps to protect their assets. • 63 percent of the respondents said their disaster recovery budgets are not enough, or worse, underfunded • Those with adequate funding, the disaster recovery plans that have been established remain untested. • Of those that do test their plans, it's an annual test, and they'll often fail their own tests. – CSO Online, May 5, 2014
- 6. Key Considerations for Disaster Recovery DR Challenges • blog.net-essence.co.uk
- 7. Key Considerations for Disaster Recovery Examples • NHS: a computer meltdown at Scotland’s biggest health board caused this autumn led to 500 operations and appointments being postponed. A major IT glitch with NHS Greater Glasgow and Clyde’s servers meant doctors and nurses were unable to access vital patient information. Luckily no patient lives were endangered during the system failure.
- 8. Key Considerations for Disaster Recovery DR Overview
- 9. Key Considerations for Disaster Recovery DR Overview
- 10. Key Considerations for Disaster Recovery DR Overview • Disaster Recovery – A set of policies and procedures that will enable your company to continually do business in the face of a disruption in your IT infrastructure that supports your primary business systems.
- 11. Key Considerations for Disaster Recovery DR Overview • Business disruptions often are not the result of disasters – Air conditioner leaks – Mold – Anything that prevents access to your business system • True Disasters – Fire – Power outage – Natural disaster
- 12. Key Considerations for Disaster Recovery DR Overview • DR Policies – …. Allow your company to continually do business • This could mean policies and processes that are manual • This could mean technical solutions • This definitely means a coordinated effort between the business and IT • This definitely means a complete plan that is tested across affected organizations
- 13. Key Considerations for Disaster Recovery DR Overview • Downstream Affect – Have you considered the downstream affect of an outage. • You may have decided that you can work around a 24 to 48 hour outage but if data is not being delivered to your supply chain what happens at those other locations • We are so interconnected now, we need to consider DR in a wider playing field – Perhaps there are questions you should be asking of your key suppliers
- 14. Key Considerations for Disaster Recovery Business Requirements
- 15. Key Considerations for Disaster Recovery Top Down Design • Determining those tier one business processes – Essential processes that allow you to do business – Interdependencies for those processes (people and functions) – What applications support those functions – Can any of the work be done manually – How long can it be done manually • Build your recovery time definition
- 16. Key Considerations for Disaster Recovery Assessing Your Business Requirements • Tolerance for downtime – Companies often believe they’ll be able to last a day, two days, three days… but rarely have they tested those assumptions. In almost every case, their true tolerance for downtime is very little. • Have your assumptions been tested • Have business stake holders agreed to the down time • Have you looked at downtime by application
- 17. Key Considerations for Disaster Recovery Assessing Your Business Requirements • The cost of downtime – A less efficient workforce – Can you truly accomplish time sensitive tasks necessary to do business – Do you have a method of accounting for all transactions • After operating for years without testing your manual processes you may be surprised at what you cannot do
- 18. Key Considerations for Disaster Recovery Assessing Your Business Requirements • Email – 2 hours – You must be able to communicate – Tier 1 • Customer delivery facing apps – 2 hours – You must not lose revenue – Tier 1 • Master Data Maintenance – 24 hours – No real impact to customers unless a new product is introduced – Tier 2 – may not need to have immediate access and the business will continue • HR – 48 hours – important to employees but the business will continue – Tier 3 •
- 19. Key Considerations for Disaster Recovery DR Testing
- 20. Key Considerations for Disaster Recovery DR Testing • Is your test plan sufficient – Business processes are increasingly relying on connectivity to outside systems, and there is more dependency on interfaces and integrations. • Windows servers in data centers, cloud-based systems, banking systems, freight company systems, etc. – DR Testing Playbook • Do you have a documented playbook to execute the DR plan • Does it cover the IT infrastructure and business processes • When was it validated
- 21. Key Considerations for Disaster Recovery DR Testing • Test Tier 1 – Too often only the core systems are tested – Too often only a cursory test is done to ensure the system is simply up and running – Questions to ask: • Simulate a day’s activity • Do the applications interfaced and integrated to your core applications function properly
- 22. Key Considerations for Disaster Recovery DR Testing • Most tests focus on the systems and if they will operate when they are back up and running • Test the processes that are needed while the systems are down – “Test” people and processes, too • What processes will you use to get back up to speed? • How will affected employees manage their workflows during and after downtime? • Where will they get their information – Is it stored on a server that may be down.
- 23. Key Considerations for Disaster Recovery DR Strategies
- 24. Key Considerations for Disaster Recovery DR Strategies • Let business requirements drive the solution • There are many solutions for you to choose from – Only your business tolerances can guide what will work for you. – Tape – Evault – Replication – …. • Any solution can work as long as it matches your business expectations – But does your current plan match your business expectations
- 25. Key Considerations for Disaster Recovery Top Down Design • Determining those tier one business processes – Essential processes that allow you to do business – Interdependencies for those processes (people and functions) – What applications support those functions – Can any of the work be done manually – How long can it be done manually • Build your recovery time definition
- 26. Key Considerations for Disaster Recovery DR Strategies • DIY – Where is your DR location • What systems are included • What communication capabilities are included • How fast can that location be made available to you • Can you get people there quickly – What media are you using • What is the process to get full backups to your location and reloaded – What processes do you have to make up the gap during down time
- 27. Key Considerations for Disaster Recovery DR Strategies • Hybrid – DIY with help – If a 3rd party datacenter is used to your DR location • What processes are necessary for your DR location to communicate with your ancillary systems • How long will it take to get those communications up and running – Do you use full replication to your own datacenter • What is the cost of maintaining those environments – Have you consider application license issues
- 28. Key Considerations for Disaster Recovery DR Strategies • DIY – Pros • Total control – Cons • Internal staff time and cost • Overall cost of hosting your own solution now is more in most cases
- 29. Key Considerations for Disaster Recovery DR Strategies • What about the cloud – No need for large cash outlays for equipment – You do not need to worry about the IT infrastructure • Only your business requirements – Available servers to recover to – to – fully replicated environments – Ready-to-go communication to your locations – Faster testing times – Fewer personnel requirements
- 30. Key Considerations for Disaster Recovery DR Strategies • Outsourced DR – Range of possibilities • Backing up your data to the cloud • Off-site as needed • Fully replicated image of your operating environment – Some similar concerns • Can you access your ancillary systems • How long will it take to make that happen • If you are not replicated – how long will it take to get the system up and running – Typically your personnel are not needed. • Verify your application licensing
- 31. Key Considerations for Disaster Recovery DR Solutions • Backing up your data to the cloud – Be aware of back up recovery sets – Does the solution provide technology that can truly provide fast restores – What is the solutions own back up processes – What guarantees can you get on our restore times – Are there people available to help design our back up process for the fastest saves and fastest restores.
- 32. Key Considerations for Disaster Recovery DR Strategies • With a reputable DRaaS provider you get: – A proven solution for DR • You can rely on the systems being available • You can rely on processes that are tested • You know that other companies are successful using the same methods – Your personnel are not tied up doing DR work and can focus on strategic business items – Reduced concern over any level of disaster – Working with a team that has done it before – Overall cost can be less than a DIY solution
- 33. Key Considerations for Disaster Recovery DR Strategies • Ask some questions – its not all sunshine and roses: – Is your data securely transferred to the cloud – Are users authenticated and does your provider offer two level authentication if needed – Does your provider meet regulatory requirements – Do you have the bandwidth to transfer data appropriately to the cloud – Do you have the bandwidth to handle your user base if they need to access systems in the cloud.
- 34. Key Considerations for Disaster Recovery DR Strategies • We find few people truly understand the business tolerance for downtime • We find very few companies fully test their DR solution • We find business processed during down time have not been considered or not tested • We find businesses overcomplicate their DR plan by trying to do too much with too little.
- 35. Key Considerations for Disaster Recovery DR Strategies • Overall, most companies don’t have the human resources, time or capital to manage a truly viable DR plan
- 36. Key Considerations for Disaster Recovery Business Continuity Services Cloud-Based Disaster Recovery Solutions for IBM Power I Environments TurningPoint Systems offers a customized, complete, best-of- class, turn-key, cloud-based business continuity solution that will meet your Recovery Time (RTO) and Recovery Point Objectives (RPO), and your budget. Economical, Turn-key IT Recovery Solution— No hardware to buy, no software to install, no new systems to learn. Your staff works on your business’ core needs, while our specialized staff assures the continuity of your critical business functions.
- 37. Key Considerations for Disaster Recovery Questions
- 38. Key Considerations for Disaster Recovery Contacts Larry Dube President Precision Solutions Group, Inc. (877) 677-5776 Ext 910 Larry.Dube@PrecisionSG.com John Hamel Principal TurningPoint Systems (978) 373-8773 JHamel@TurningPointSystems.com
Editor's Notes
- Hello and welcome to our Disaster recovery webinar for the power i. It is our pleasure to be spending about 40 to 45 minutes talking with you about our experiences with DR and some thoughts that surrounding that topic.
- Joining me is John Hamel. A seasoned technology executive with 25 years of experience As the Principal of the Infrastructure division, John oversees and manages all aspects of the infrastructure division including sales services, and product solutions for Turning Point Systems. Prior to joining Turning Point Systems John has a long history of sales success including sales and sales management positions with IBM and Technology Solution Providers. Together we hope to share our experiences and give you some insight into disaster recovery concerns.
- Joining me is John Hamel. A seasoned technology executive with 25 years of experience As the Principal of the Infrastructure division, John oversees and manages all aspects of the infrastructure division including sales services, and product solutions for Turning Point Systems. Prior to joining Turning Point Systems John has a long history of sales success including sales and sales management positions with IBM and Technology Solution Providers. Together we hope to share our experiences and give you some insight into disaster recovery concerns.
- Lest start with a quick run through of our agenda. We will be covering an overview of disaster recovery. We think that there is quite a bit more to DR than just getting your it infrastructure up and running again. You should be looking at a holistic approach to DR taking into account your business operations. And DR testing is certainly part of the whole approach. We often see holes in the DR test plans so we will discuss approaches for testing. Then finally we will look a few different DR solution strategies that you need to consider and what would drive you to chose a certain direction.
- First lest look at the general state of DR in our industry, Almost everyone we work with thinks about DR and has some level of plan in place. But we wonder if these plans will cover their business needs should a disaster really strike. And looking at survey data it seems many companies agree.. 73 % of survey respondents from a DRP council survey as published by CSO online indicated they were not prepared. And 63% of the respondents did not have the budgets they needed. When the real disaster is not front and center, that money gets a little harder and harder to justify. And the scenario is not much better for those who did have adequate plans because they were untested. Oh and by the way, if you fail your test, make sure there is an action/review process and the appropriate steps are taken to make sure you are adequately covered. The cost of not doing proper testing, can be company ending in some cases.
- IN another published survey by net-essence you can see the DR challenges that many companies face. I think it is very interesting that the biggest challenges have nothing to do with business buy in or management support. It’s having the resources to execute (or thinking you may not have the resources to execute) and “hey this has never happened before” so it is just lower on the list for now. I’m guessing that these survey results may ring true with you too.
- The problem is – disasters really do happen from time to time. I like to tell people that we don’t do brain surgery so our risks are more than likely not life threatening but this is not always the case. IN this example it could have been. Some server issues prevented doctors from having access to vital records and in turn prevented them from performing operations. A simple need with a not so simple result. Their DR plan failed them for sure.
- Maybe it’s a good idea to go over what we think is included in a DR plan
- we find that a wide range of plans in the companies that we have worked with and in some cases those plans are truly not focused properly. They all have more than a “Help! Help!“ plan but there are quite a few holes in many of them
- DR is A set of policies and procedures that will enable your company to continually do business in the face of a disruption in your IT infrastructure that supports your primary business systems. The key words in this statement “enable your company to continually do business”. That is the goal of your DR plan. Its not to make IT infrastructure available, although that is almost always the core of the plan. Don’t lose focus on the business being the number 1 priority in any of the plans you make. That’s the top of your decision cycle as you work your way down to what is required in your DR plan.
- As we have started to talk about in the examples earlier, there can be a number of reasons why you need to execute on your DR plan and they’re not always catastrophic events like a natural disaster. A simple air conditioner leak could cause issues. What about something as simple as a major traffic accident that closes down a major highway that many of your employees use, and they will not be able to get to the office for the day. Do you have a solution? In this case, many of you probably do have a technical solution with how common remote access is these days but, do you have the processes to support the actual work that needs to take place. We want you to think about DR as more than a technical solution. The disaster is just the event. That could be anything. The DR plan focuses on “continually doing business”
- Continually doing business could mean manual processes that are executed along with technology solutions. It most definitely means that the IT group and the business need to work together to finalize a plan and create a DR play book. And everyone is involved in testing that plan to make sure the business requirements are met.
- Another item to consider in your DR plan is how the world keeps getting smaller and smaller everyday. Through technology we can do business with almost anyone in almost any place in the world. We are so interconnected! Now anything that happens within our walls is more than likely going to affect companies out side of our walls. Our disasters are shared. Or in some cases our partner disasters are shared with us. Are you asking the right questions to your partners. Do they have plans in place that will enable you to “continually do business” If they are key suppliers for you make sure you ask the right questions because that could be a very big part of your disaster recovery plan. Does your plan take into consideration what might happen if one of your key suppliers goes off line for 48 hours. Are you prepared if you are the one in the supply chain to suffer a disaster. Do your plans take your partners into consideration.
- I wanted to mention the supply chain to open up the thought processes about how wide your DR plan should reach in some cases. The only way to really define that reach though is to focus on your business requirements. So lets take a look at considerations for that.
- What allows you to continually do business. Those are the tier one processes that just cannot go down for any length of time. It is important to understand we’re not talking about applications but business processes. Orders getting into the business. The warehouse able to ship product. Your ability to communicate, focus on those processes and the interdependencies of those processes with other functions and people. Document them. Now look at the applications and information that support those functions. Can any of the at be done manually. For how long? Is there a part of it that just cannot be done manually. Answering these questions will help you arrive at your recovery time definition and be a start to creating a tier one application map.
- Working through that top down design will really give you a process to define your tolerance for down time. I find that in many cases no specific process was used or the process started with the applications vs the business processes. I was working with a company recently in a non-DR capacity and through that relationship came to learn about an issue they were having with a small application. This application pushed orders to a 3rd party warehouse for shipment. There was a failure, in this case that was software related and it was corrected in several hours, but during that several hours there were no orders being shipped, and because of the volume of orders that are received electronically there was no way to keep up manually. I also know that this company has a 48 hour up time goal in their DR plan. Truthfully that plan has not considered all of the business scenarios that could occur and the cost of those scenarios. What if you could only delver a fraction of your orders over a 2 day period. Would your customers wait for you. A better question might be Could they wait for you? Its so important for you to test assumptions and then really make sure your stake holders in the business agree with your assessment. When you have looked at your requirements are you using a top down design starting with business processes.
- Will you be able to continually do business. Delayed business is usually lost business.. In the very best scenario when disaster strikes, your customers are patient and there are no repercussions to your inability to temporarily deliver product to them. But even in that best case scenario it is still lost business for you. If you do not deliver product to your customers and in turn they cannot use it or sell it to their customers. In your case you have lost revenue in that time period that is never recovered. All of you future revenue simply slides out. The cost of down time can be high. It can be high in terms of actual revenue lost and also softer costs like the efficiency of your workforce and whether or not they are even able to do their jobs. And then when you do get your systems back on line did you have the correct “play book” in place to be able to recover any work that was done manually. Are your manual processes in synch with your technology plan. Only you can really define the cost of your down time. But if you do follow the methods we are talking about that cost will start to be apparent by business function. How much revenue is a half days worth of orders.
- After going through your top down design your DR plan should document down time tolerances or uptime requirements by business function. Take the time to assess each area appropriately and identify the true down time tolerance and why the time is either short or longer. Identify those areas as Tier 1, 2, or 3. Once that is fully defined your DR plan is starting to take shape and its based on business requirements which will make sure you can continually do business.
- Now you have your business requirements lined up with your downtime tolerance and as I said your DR plan is taking shape. Now its time to test it. Lets go through important topics in regarding DR testing
- I know that its a little backward to talk about DR testing before we even talk about DR strategies but thinking through testing can make your strategy that much stronger. And the point is not really to go over how you test your DR solution but to go over how you approach DR testing in general. How many of you have executed on your DR test plan by getting the back up of your systems, and simply making sure that you can get major applications up and running. And thats it. Maybe someone executes some menu options. Maybe some main transactions are processed. And the check box is checked off and you walk away from the test for another year. Remember your DR plan needs to allow your company to continually do business. Lets keep that in mind as we walk through the next few slides. We already mentioned the interconnectivity of our world today and the down or up stream effect on the supply chain, if one of the links is broken. Those links come in the form of integrations and/or interfaces to other systems. Have you ever tested those links in your test plan. Have you asked someone from the business team to process even a couple hours of workload manually. Do they have the documentation they need to do that,. do they have the capability to document the work they do, so when it is time to synch up the system you have all of the information you need. Can they just take the DR play book and start marching down through it. Listen, what we are trying to get across is simply try to consider those scenarios where you cannot get electronic orders or where you cannot get information easily to a warehouse. Or if you cannot get information electronically to a 3PL, can they deal with paper. Or are you able to communicate properly All of these thoughts in your test plan may make you rethink the over all plan and the cost of that plan.
- You don’t have to test everything but you do have to test all of your tier one business processes. You definitely cannot just stick with the core systems. Many companies look what systems most people use and start from there. They think if they get their Erp system up and running then 95% of their staff can get their work done. But if the business processes were not focused on you may allow 95 % of your staff to do their jobs but if the orders you are entering all day cannot get to your 3rd party warehouse, then your customers are just as angry as if your entire system went down. Think about what it takes to get product to your customers, That is what needs to be tested. Then simulate that activity. Be honest with the results
- Now beyond testing your failover IT solutions spend a little time testing those processes during the down time. Can your employees really do what they need to do? do they even know what they need to do? Its important to test the people and the processes. The goal is not to judge whether people are capable of doing the job during a disaster but to make sure they have the tools they need. As we walk people through some testing scenarios it may become clear that the DR strategy may need to change rather than to try to build more processes. After creating your business requirements through the top down design process and reviewing how you test your DR plan you will be more prepared to execute on a DR strategy.
- Lets take a look at some DR strategies
- Certainly your solution to DR will be unique to you. We are working with smaller business right now that is not affected by many supply chain connections and the tier one business processes are limited. And they happen to have manual processes defined for some business functions. A simple solution will work for them. While a larger global organization with 24X7 requirements and a significantly automated process is in a different situation. They really do need a more sophisticated solution. Your business requirements drive your solution.
- I am bringing this slide back from earlier because this is the process that you need to follow to build your plan. This is the first step in building your DR strategy
- Once you have that map of information defined you will be able to choose a plan that fits your needs. Maybe you can take care of it all on your own. Maybe you have access to a separate datacenter and additional equipment. Maybe your downtime tolerance is reasonable. And maybe you have the staff to manage the plan over time. I know a number of companies that are doing just this and it is working for them now. If you are taking complete responsibility there are a number of tasks that you need to be concerned with though. From the failover systems, backup storage and recovery, communications to those failover sites, are they in one of your data centers or elsewhere. How fast can that location be made available and how fast can you restore your data. More than likely in a DIY situation, you are going to need people there to help get things up and running. Are they available to you. Your good test plan should shake out if this will work for you. It can, just go into it with your eyes wide open
- The DIY solution could take on a number of forms. one of those is to use cloud services just as your failover location while you manage your own back up and recovery to that location. You can use the cloud as your DR site only, or you can replicate to it, or you can even just use space when you need it. The benefits of taking advantage of the cloud include but are not limited to no capital outlay for hardware and lower personnel impact because others are taking care of your failover site. So running your own DR process but taking advantage of the cloud can really be beneficial But don’t forget about licensing issues for software that will run in the cloud. You will need to negotiate those licenses with your software vendors in advance.
- If you do it yourself, you certainly have complete control. With that control comes all of the responsibility to keep the systems running. You have all the visibility that you need at every step of the way. But you have the cost associated with that control and you have the personnel requirements too. Just go into the process with your eyes opened and consider alternatives as you build your plan
- So lets talk more about the cloud. There are certainly plenty of reasons to look at a DR solution in the cloud. The cloud has really opened up accessibility to full DR solutions to SMB’s. Where in the past a company had to absorb full cost of alternate hardware and data center space, now you can take advantage of usage based plans that are affordable for SMB’s. If properly implemented your DR plan can be available very quickly. Even accessing your environments for testing is simplified. Most businesses operate at 100 miles an hour. People moving in different directions very quickly. The IT staff really doesn’t have time in many cases to spend on the DR solution and the cloud based strategies can help alleviate that problem
- And its not one size fits all. You can still design your own solution. From just backing up your data to the cloud, to having system space off-site as needed, to having dedicated space whenever you needed it, to restoring your own data, to a fully replicated environment. Now at quick glance it does sound easy especially when we are talking about your power I. But your business doesn’t run only on your power i. All of the planning we talked about early in the presentation still needs to be considered. How far you go with your DR solution depends heavily on the importance of those tier one systems. The idea of your Power I as the centerpiece with some virtual machines to take care of ancillary systems should provide you with an image of a robust failover solution. And it can all be in the cloud As with any solution, you should have concerns on executing the plan. Can you access the necessary systems, how long will it take to get up and running. And do you have the proper licensing. Think and plan about the big picture.
- One cloud based service is just backing up to the cloud. You may see quite a bit about E-vault solutions. Lets talk about that for a minute. If you are looking for a provider that you can use to back up your data electronically to, please take a little time to get to know their solution. It sounds so easy to back up to the cloud but make sure you have someone that can help you design your solution for the fastest possible recovery and least impact to your day to day business. How you define your recovery sets and the method of backing up your data can make a big difference on your recovery time. Be aware of the differences in solutions and make sure they have people that can help you along the way.
- Ok back to the bigger picture. One of the biggest benefits of using a cloud solution is that you’re working with a company that has done it before and will continue to do it for other companies. They have the processes in place to make sure you have a stable environment to fail over to. They have the communication capabilities to handle your employee base. You can rely system availability as they have the same concerns as you do and want to make sure they have contingencies covered. Your concern over disaster recovery should be reduced and your personnel are freed from work that is not so strategic for your company. And finally overall cost is competitive. SMB’s can now truly take advantage of services that only larger companies could do in the past.
- The cloud solution is not a perfect one. You still need to dot the I’s and cross the t’s. Although most established DRaaS providers will be able to handle your requirements, do not assume that they have the user authentication, or they meet regulatory requirements that you need. Can you reach any other cloud based solutions you need in your tier one map. And for yourself, Make sure you have the capabilities to handle new bandwidth requirements. It is important to understand exactly what you are getting and if matches what you need. Ask questions.
- Ok if there are a couple of things that I hope you take away from this presentation - it is that there are alternatives out there that can make implementing a DR solution much easier than in the past and that you take an honest look at the DR plan you have in place today and think about the areas that you may not have considered. Did you do a top down design to create a tier one business process map Do you do adequate testing and do you have a good action plan if a test fails. Do you have the manual processes covered while systems are down Do not be afraid to ask for help because we find that ….
- in most cases companies don’t have the human resources, time or capital to manage a truly viable DR plan but that is because of how they try to implement it.