Migrating to a new cloud service not only requires evaluating and finding the right cloud partner that meets your requirements, but also ensuring that your infrastructure and processes are ready to integrate with the new service.
A hasty or ill-prepared launch into a new cloud service could negatively impact your existing processes never mind absorb a lot of time, effort and cost to remediate if things don’t go well first time.
As with all IT implementations a cloud migration needs to meet the business goals and the best way to measure whether the business goals have been satisfied is to have a clear quality assurance delivery programme.
At ChallengeCurve we have compiled the 5 key areas for which a cloud migration programme team should consider to ensure a smooth transition to a cloud service:
Delivering high-quality code into production faster, cheaper and more efficiently has always been a primary objective of the software delivery process. Recent initiatives such as Shift Left, where the focus of testing effort is moved upstream closer to business design, has gained widespread popularity and adoption. However, for some organisations there has actually been a reverse trend where the User Acceptance Testing phase has increased in scope and size. How can this be? What are the circumstances behind this trend?
In this whitepaper we discuss the real situation in which many organisations find themselves and some techniques on how they can start to Shift Left.
Please contact email@example.com if you would like a copy.
As featured on LinkedIn.
The recent Volkswagen’s emissions scandal when a “Code Cheat” was placed in the software of diesel cars has resulted in the departure of former CEO Martin Winterkorn, a 30% fall in VW’s share price and a criminal investigation. But it has also created an important precedent:
CEOs are ultimately accountable for the source code of their products.
The boards of major corporates are handsomely paid; they enjoy the perks and trappings of high office and are trusted by employees, shareholders and customers alike to create sustainable returns by providing products and services that meet consumer needs.
Corporate boards deal with strategic issues, shareholder meetings and 3 year plans so the world of bits and bytes in computer code is a long way from the boardroom. Computer code is “deep techie stuff” and has no place on the agenda of corporate board meetings – until now.
Martin Winterkorn denies any knowledge of wrongdoing on his part but ignorance is no excuse as he has found out to his cost. The incident at Volkswagen may have left other CEOs worrying if something similar could happen to them. If not, then they should be.
What could Martin Winterkorn have done differently to have quickly determined who was responsible for the “Code Cheat” within the fleet of diesel cars rolling off the production line? What would he now give to have had complete traceability of the source code – who specified the designs, who wrote the code, who tested it, who implemented it? If the proper processes were in place then this information should have been available to him within minutes so that he could have quickly found those responsible and taken the appropriate action. It is because he didn’t have this information that he had to assume the responsibility for this scandal and resign.
Perhaps if the lines of computer code were given the same scrutiny as the figures on the company ledger then this episode may not have happened? Every financial transaction that organisations conduct can be traced and tracked. Independent auditors scrutinise the books before signing off on company accounts so perhaps we need the same independent diligence for scrutinising a company’s software code?
Organisations often feel that investing in independent Quality Assurance and Testing is a costly overhead or a commodity service for which the lowest tender wins the contract. Given the VW incident many companies may now take a greater interest in the hygiene of their computer code – after all, a 30% fall in the share price and a class action lawsuit due to some errant computer code is going to make the agenda in most boardrooms.
“Delivering value to the business” is not just the mantra of every IT Department – it is their raison d’etre. Yet often the Business may feel that their internal IT Department is too slow, often late or too expensive in delivering new systems and maintaining existing ones. Recent survey statistics on the amount of projects that end in failure confirm this 
Clearly, the Business feels that it is not getting value for money. There is a growing trend, known as Shadow IT, where the Business deliberately bypasses their internal IT department to engage directly with service suppliers in an effort to gain benefits more quickly. The provisioning of Cloud-based and “Software as a Service” models makes it very tempting for the Business to procure new applications. Yet often the IT department will end up having to manage the new service in terms of maintaining user access controls, backups of data, etc. It is too early for the demise of the IT department but there has been a loss of confidence and trust in the IT department’s ability to deliver business value.
What can the Business and IT do to address this perception? How can IT not only deliver more value to the business but also be seen to deliver more value?
This whitepaper examines why the quality of an end product or service often falls short of expectation and how the definition of business value changes currency at each delivery stage. This “value currency exchange” leaves the delivery open for loss of value to occur. The paper concludes with recommendations on how organisations can maximise the efficiency of their value currency exchange.
 Raconteur. http://raconteur.net/business/how-to-spot-the-signs-of-a-failing-project
Please email info@ChallengeCurve.com for a copy of the white paper.
Too often Quality Assurance has been seen as a drag to organisations – at best it’s a box ticking process that is a burden to complete and in the worse case scenario it stifles innovation and gets in the way of the real work. Time for QA to change?
We think so. We set up ChallengeCurve to enable organisations to embrace change and to be innovative by providing them with the right QA harness to confidently experiment and to try out new ideas.