technology. Tea in hand, I browsed through some literature on conventional design versus cloud technologies. As you will see, the conventional design required companies to invest heavily in physical assets such as servers and other related hardware components. Now, businesses are getting rid of the hassles of buying and maintaining physical assets or software solution with Cloud technologies.
When it comes to the Cloud, the third-party provider owns the IT systems, and the services are normally shared by multiple clients. The system users are charged on a periodic (monthly or so) basis. One example of such a public cloud is Google for Business. Here are a few important aspects of Cloud design that need to be kept in mind while opting for the Cloud technology.
Identifying the quick wins
Your team needs to carefully scan all applications used in the organization’s landscape to identify the initial targets for Cloud transformation. These are typically applications that can be converted using SAAS (Software as a Service) platform in a short time span without much complexity, for e.g. converting your mailing application to Google email (becoming a SaaS tenant).
Some common candidates for such transformation include mail, CRM, employee databases, time entry systems, and so on. These normally require very little turnaround time and – in most cases – do not even require historical data migration. Typically in giant organizations, introducing Cloud technology through such smaller samples helps curb the negative propaganda against Cloud (pertaining to the possibility of data theft or possible leakage of sensitive information outside the organization).
Possibility of Cloud Governance Issues
Cloud applications are normally available ready-to-use with minimal configuration options. They also require a relatively modest budgetary spend as the usage is commonly charged on a per-user basis, and no fixed costs related to hardware setup are to be borne. But this could potentially lead to risk of local departments in a company implementing cloud technologies using local, discretionary budgets. Organizations need to have effective cloud computing policies to mitigate the effects of ungoverned enterprise cloud applications.
Being in Charge of Your Cloud Project Borders
There is an overabundance in the market of various Cloud applications written by third-party sources, and there is also a huge variance in product quality in these satellite apps. Some of these applications are so easy to use that they can be easily implemented by end users extending the project boundary in an uncontrolled manner. This can also lead to severe data theft-related risks for the customer.
Selecting Project Execution Methodology
Project management methodologies such as Prince2 are more suitable for traditional projects that follow the typical waterfall or SDLC models. In such traditional projects, requirement gathering is followed by design, build, test iterations, and so on. However in Cloud, the approach is: First implement and then fine tune it further as you continue using it. This makes traditional methodologies unsuitable for Cloud projects; rather, they are not useful in the current form to effectively track the real progress of Cloud projects and might need lots of fine tuning considering the process flow pattern applicable in the Cloud.
New Quality Issues – As the Cloud application is hosted on external servers that are not in the customer’s network and the application is built and maintained by the service provider, new quality issues can arise, such as those related to network response time quality, provider support service quality, and the overall technical quality of the Cloud Solution (i.e. defect fullproofness of the solution).
Service Level Agreements
In Cloud computing, as the software vendor plays a crucial role in terms of solution and service provider, a division of responsibilities between users and service providers should be done based on well-defined agreements, usually called Service Level Agreements (SLAs).
Every Cloud vendor has an SLA that specifies what the supported functionalities are, the granularities of those functions, the workarounds/fixes available if any functions fail to perform as planned, and how much it all costs. For example, Microsoft has its Azure SLA(s) and Amazon has its EC2 SLA.
Project Managers may not have had much prior experience with this type of agreement. But when they are working in the Cloud space, they need to make themselves completely familiar with the concept of SLA.
All of the above factors are extremely important and should be kept in mind while managing any Cloud project.
What did I miss or didn’t get quite right? Let me know by writing to me at firstname.lastname@example.org.