CompTIA Cloud+ CV0-003 – Domain 1.0 Configuration and Deployment
Here’s a tool that I’d like to share with you that I think is a really nice tool to help you, whether you’re an architect or presales perhaps could be a useful tool. Or, for example, you’re working at a company that’s just getting started in the cloud and trying to understand some of the differences between the major cloud providers. This resource is by a company called Right Scale, and Write scale is one of the leaders when it comes to cloud platforms and research around the cloud as well. They also have an annual report called “The State of the Cloud” that is well received by the industry. So if you’re interested, go over to the link Writescale.com Cloud Comparison Tool, and you’ll see that it brings you to this page, where it says, “If you’re interested, there’s documentation here.” It’s a free tool, and the goal is to help you determine what might be the best cloud fit. So you continue here. Now this is a very simple interface, and essentially, you can select each of these and then go review each of them as well. And it appears that, please wait a moment while I reload that. Okay, so it looks like you had a little browser issue, but you should see some check boxes here, and I do now. So as far as the comparison, for example, a very common question I get is usually around who supports what compliance or who supports different versions of SQL. For example, if you go down and scroll down and look at everything, like certifications, this would be the compliance. As an example, you can see that this certification—MPAA—is not supported on IBM Cloud. However, it is supported to some degree or another on each of the others common in the US.
For example, it’s very common for government agencies to need to be compliant with FedRAMP. As you can see, Google Cloud does not support FedRAMP at this time. You can go ahead and validate that. And regulations such as FISMA and HIPAA are very common. So they put in the most common certifications on their operating systems as well. Now, I just want to point out that this is more at a high level. For example, if you’re going to use Amazon Web Services or Google, not every one of their data centers is going to support each of these or even each of these operating systems for example. So you need to get more specific. So even though AWS will likely support all of these, not all the images are fully supported in each of the AWS data centers. This is perhaps not so true in the US. However, if you travel internationally, this could be a problem. Different countries have different network services, such as content delivery. And even though they all support it, what’s also pretty useful is that it tells you the name of the service. So it sort of saves you a few minutes from having to, oh, I forgot the name of the CDN.
Well, it tells you right there, so you don’t have to go and try to determine what the name is or the DNS service. So this gives you some immediate value, especially if you know AWS but are not familiar with Google or Reserve. You can see that they have quite a few relational databases and nonrelational databases, and it appears that they’ve updated this, because I don’t recall that being broken out about a month ago, actually a few months ago when they released it. So that’s cool. Caching additional services so that search capabilities can be seen Elasticsearch is becoming increasingly popular. Elasticsearch is a very popular service that I’m seeing a lot of customers inquire about or use. Again, it’s not fully supported on Google, so you need to be aware of that. Dr. again, there are a lot of things to look at. Now, in terms of security, for example, do they have security assessments? So when it comes to security, you have what’s called the Amazon Inspector. This is a good tool. This is sort of a way for you to scan your services to determine any kind of vulnerability, essentially. Now with Google Cloud, it’s only supported on AppEngine, and that is still true only because I’m actually working on a project right now where we need to look at third-party solutions. But with that said, you could see, for example, certificate management. Another weakness of Google Cloud is certificate management, as well as HSM.
Now, this is true to the extent that if you don’t connect your Gmail because Google Cloud does a good job with security if you want to connect your organization, However, not every organization, especially if they’re an enterprise organization, wants to use Gmail, okay? They want nothing to do with Gmail. So Google, again, has some weaknesses around the enterprise. They’ve done exceptionally well with developers and small and medium-sized businesses, but they’re woefully lacking in the enterprise. I just think they really need to invest in that area. So anyways, you can see that AWS, even Azure, and IBM are much stronger in those areas when it comes to threat detection. Again, you need to really look at this. So, for example, if I want to do something, I have a few options. Let’s say, for example, that I’m a presales engineer and I want to go ahead and get this put together as an RFP. I could go over here to either export selectedor export all whatever I want to do.and I go over here. You can see I can go ahead and email this. And it’ll also let me opt out if I want to. For example, when things are updated in this, it’ll actually email you and basically allow you to get updates, so it’ll send you that CSV file. And then I could also go over here to share and copy the link directly. That way, it will have that saved information for them to view forever. And I go over here and copy it, and I just paste it in, and you can see that it will bring me directly to that saved worksheet. Like over here, you can see that I selected this. So this is a nice little simple tool that you could use, especially if you’re just starting out. So go on over to write scale. Amazing platform, amazing company that adds so much value in so many other ways. So just don’t check them out for this; check them out for other reasons.
Let’s talk about deploying cloud systems. Migrating services to the cloud is probably one of the more enjoyable aspects of the cloud. So whatever that application is that you’re migrating to the cloud, that is now a cloud service. And at least for me, I find that to be pretty rewarding. So let’s talk about some areas around deploying cloud assets. First, let’s just clarify what a resource is. So, in terms of assets, an asset is essentially a resource. A resource could be an asset, but let’s just clarify. An asset is typically something that you own. And typically, the provider owns the hardware resources. You essentially own the application in most cases. So just be aware that when you’re deploying cloud resources, you really need to understand many different areas.
Some of these are listed here. I won’t read them all to you, but just be aware that security, costing, and performance are going to be big deals. Before you deploy any assets, though, you really need to understand the characteristics, deployment models, and service models. So let’s go ahead and talk about those so that you have a good idea of why they are f why they areHopefully, you are familiar with NIST cloud computing. NIST is the National Institute of Science and Technology. Essentially, they’re based out of Maryland, off the 270 Beltway. NIST is an interesting organization. They typically like to take technologies, get input from the government, and try to translate those requirements into best practices or reference architectures to help solve problems, for example. Now, NIST is under the Department of Commerce. But here is really what I want you to know for the exam: And before you take this exam, I’m going to highly recommend that you know this from memory. And here’s why: This is very simple to memorize, but if you don’t memorise it, give me questions. This is an exam that doesn’t have a lot of “give me questions,” as I like to say. So any questions you can get for me are usually a good thing, especially given how CompTIA grades the exam. It’ll definitely be critical to you, and I’ll talk more about the exam at the end. Now you have what’s called the essential characteristics. So this is broad network access, rapid elasticity, measured service, on-demand cell service, and resource pooling. Now, with cloud essentials, you probably already know what these are, but at a high level, these are essentially the characteristics of a cloud service. So, for example, if you’re going to use Amazon Web Services, you’re going to typically expect to have these characteristics as part of that service, right? You’re going to be able to access that resource from anywhere. That’s broad network access. Now let me just clarify one thing. Broad network access does not mean that you open up that cloud service to anyone to get to it. You don’t want to have VPNs. I always recommend that you have mobile device management, DLP solutions, firewalls—you name it. Everything is set up to secure your cloud resources.
You could also do anything ranging from “country blocking” to “blacklisting.” So, for example, if you’re a US-based company and you don’t have employees in Germany or Russia or China or Argentina, wherever, and you see no need to allow someone to log in from that domain, then block it. You have to take security pretty seriously, right? Rapid elasticity. This is where I could take a VM and either scale them up or scale them down. I could either make the VM bigger or add more VMs. For example, measured service I don’t want to pay for more than what I need, right? Essentially, that’s chargeback billing, right? On-demand self-service I want to log in. I’m going to spin up that virtual machine in EC and call it a day, right? I’m going to also look at resource pooling. Now, when it comes to resource pooling, remember that this is a cloud. You’re sharing these resources with other customers. Now, you may have a virtual private cloud that is still on shared infrastructure. Just be aware of that. You have the three service models and the four deployment models. Make sure you know these. For example, for the test, I’m going to say this numerous times during the course. This is what you gave me. There’s no way you should get these questions wrong. Okay, let’s talk about the characteristics. As a result, we have on-demand service.
So, remember, you log in, spin up that VM, and in about a minute or less, that VM is typically fully operational for you to use broad network access. This is where you’re going to go ahead and access that resource from wherever you want, but also on whatever device you need to. Typically, that’s going to be mobile access over the Internet. Resource pooling is essentially where you share resources to mitigate costs, right? If the provider gave you private resources for everycustomer, the cost of that would be substantial, right? That’s one of the benefits of resource pooling—it enables those economic efficiencies. Rapid elasticity. Can I scale up or down? Measurable service pays for what you get, right? Cloud deployment models Now, like I said, you’re expected to already know these, but I’m just going through this as a quick refresher. For elasticity, the public cloud, for example, is commonly used. It has utility pricing, and you could also leverage expertise. So, for example, with Amazon Web Services, you can contact support if you have issues. doesn’t mean support is going to be great or very responsive, but at least there’s expertise to reach out to. You may have a TME available; I don’t know. Utility pricing is private cloud, right? This is where you’re going to want to have total control. So you’re going to go out and get that VMware hybrid cloud, right? You’re going to want to keep that in house. Now, VMware, of course, has changed the name several times—Service Provider Edition, et cetera—whatever it is this year.
So just be aware that whatever that private cloud is intended to do, it’s probably going to be more secure. You may need to go with the private cloud for regulatory purposes or for more more flexibility. Community cloud, this is going to be your nonprofits, typically, but it could also be. Now I’ve seen a lot of vendors, for example, that have a community cloud. These vendors, for example, may have a partnerecosystem, and those partners are able to collaborate together with, let’s say VMware with Cisco, right? And then a hybrid cloud is essentially two or more of these. And then we have the deployment models, right? Again, we know what they are; we just talked about them. Again, the list is there. I want to make sure you get it. And then we have the service models, right? Infrastructure as a service, platform as a service, and software as a service And what are they? Right. Software as a service This is your business application. Now, just be aware that SAS may also have components such as business processes as a service. could be, like, expensed, right? It could be QuickBooks; it could be a real niche use case. Platform as a service This is generally going to be used for development testing or for rolling out new services. Again, your developers will typically use pass and then infrastructure.
This is going to be your typical administrator managing VDI. It could be for managing big data services. Now, again, some of the services could be a mixture of platform and infrastructure in some cases. SharePoint is a good example of that. So SharePoint could be utilised in the past, but also as an IAS as well. So there could be many different use cases. So just know that NIST has three service models, right? Four deployment models and five essential characteristics Let’s talk about cloud responsibility. Now, I would recommend that you look at this chart for a few minutes and compare left to right. For example, we have one on premise. In most cases, if you have an application, you’ll be managing everything on premises yourself, right? at a high level. You may have contractors; you may have consultants; I don’t know. So you’re going to manage your VMs, your servers, your storage, and your on-premises applications. So you’re going to do it all. Infrastructure as a service Going to the cloud is a different take. So you’re not going to be concerned with installing hypervisors. You’re not going to typically be concerned with going out and purchasing blade servers or data storage. So this is where you need to realise that your responsibility changes. One of the common concerns I typically get is: “What are we going to do when we move all these services to the cloud and they get rid of the infrastructure?” I don’t know.
I mean, what else can I tell someone other than you may want to get a resume ready? So this is what happens in the industry, unfortunately. I was working at a company literally two years ago as a presales engineer for another company actually. So this company, a large equipment manufacturer, had 170 people on it, a worldwide organization, and tens of billions of dollars. And they decided to go to the cloud and shut down some data centers. So they did this over a period of time. They went from 170 employees down to essentially 30 or 40. This is part of the financial scheme. Companies aren’t making money, and this is just part of the cloud business. So what I want you to realise is that you may still have a job, but your job may not be the same when you go to the cloud. And this is just common sense, but for many people, I can appreciate that you used to have infrastructure, and now that infrastructure is no longer yours, and you can’t even touch it. So it’s like you can’t go to the datacenter, and that blade server isn’t there anymore. That network switch isn’t there anymore because, you know what, it’s somewhere else and you don’t have it anymore. You don’t own it, so you don’t control it.
So your provider is going to manage pretty much the grey areas, and the blue areas would be typical of the areas you’re going to manage. So looking at this chart, I just want to make sure you understand that typically, when you spin up the VM and Amazon Web Services, they’re going to handle this for you. You’re going to specify that machine image. So that’s going to be the AMI. And I’ll walk you through the ECT demo so you can get an idea and spin it up. And guess what? This is what you’re going to manage. This is typically what you’ll manage if you migrate to Microsoft Azure or Google Cloud, specifically the Google App Engine. You’re not going to be concerned with VMs OS. The provider is going to do all that. And then with software as a service, you’re really going to do nothing except maybe import and export data. You may also need to add accounts, of course, but from an administration standpoint, there isn’t going to be much you’re going to do. So again, in the content, I would highly recommend you go through this and make sure you understand what a service level agreement is. So an SLA is a contract between you and the provider. It’s going to define the level of service that you should expect from the provider. So an SLA is different than a contract. And, once again, it says it’s a contract, but that’s not the best way to define one. But here is sort of what I want you to know. An SLA is typically referenced in the contract. And here’s sort of the way cloud contracts typically work. You’ll have an end-user licence agreement, contract, and so on that will typically refer to the SLA. So Amazon, for example, reserves the right to change the SLA parameters at any time. So it could be four nines today and three nines tomorrow.
It is what it is. It’s up to you to accept that when it comes to an SLA, it’s going to define the level of service that the provider is providing. So typically as well, the provider as well as the customer is going to have responsibility. It will define support levels, as well as speed and feeds. Typically, the SLA will determine, for example, that the provider will resolve this for you, but you will be responsible for managing your im. In other words, they’re not going to set up identity management for you. It’s up to you to set up identity management. They’re going to allow you to use the LDAP services and show you how to tie it into their services. But they’re not going to do it for you. They’re going to support you. There’s plenty of documentation, support, whatever. Again, for example, in an SLA, you’re going to see uptime, and that’s pretty much a bare-bones SLA. It will state, for example, that the service is 99.5% available or that it is 49.99% available. Right. This is where you need to understand exactly what they’re going to guarantee. Now one of the areas you want to look at, especially with a cloud SLA, is that the provider typically reserves the right to change it at any time, but it’s also up to you to call the provider.
For example, if Amazon or Google are unavailable. So for example, Amazon’s Three was down a few months ago in the Northern Virginia region, and even though it affected all the customers in that region, they were down for 4 hours and exceeded their SLA threshold. It’s up to the customer to contact Amazon and get a credit back for that subscription that they’re paying for. Typically, it depends on the service. Two and three EC. They’re all different. So I would go to the website and take a look at the ake a look This is the easiest way to go to Google, Yahoo, or Bing, whatever your service is and whatever your favourite search engine is, and type in EC 2 SLA or Amazon 3 SLA. And that will bring you to the typical SLA page because it’s not all in one area. You’ve got to find the stuff again; that’s why cloud consultants get paid by the hour. There’s a lot of work to this, but for the exam, I need you to know what an SLA is and that it defines support levels. It is an agreement between you and the provider. This will help you greatly on the exam. Here’s an exam tip: the consumer manages the virtualization layer in infrastructure as a service, and the provider manages everything below that. Another exam tip is that the hybrid cloud has two or more deployment models that utilise orchestration for services.
Cloud components. Let’s proceed and talk about what a component is and why that is important to correlate to your cloud design. So a component, simply put, is essentially anything that you’re utilising in the cloud. As a result, your compute, storage, network, and appliances could all be affected. You may be utilising ASA. For example, a Cisco ASA You may be using Palo Alto, as well as other appliances, VMware software, hypervisor APIs, APIs, and, excuse me, client devices. Let’s talk about what an asset is. Now, an asset could be anything that you own as a company.
And that is typically your data; it is your knowledge. It will also be determined by your employees’ skill sets. Now, generally, in the cloud, you’re not going to have assets in Amazon that you’re going to own. Now there could be some exceptions, maybe in licensing, for example. But generally, most customers using AWS, for example, don’t own the equipment; they don’t even own the licenses. It’s pretty much the data, and that’s about it. So with that said, just be aware that an asset is typically going to be more around data, knowledge, skill sets, and then, of course, the people. Cloud assets can be both physical or virtual assets. To an organization, data is usually considered the most important asset. So as far as your company is concerned, it’s generally going to be your data that is most important. Your production data would probably be number one on the list, hopefully. What’s? An API. So cloud API is an area that I have typically discovered a lot of but that I believe architects do not fully comprehend. So an API is an application programming interface. It’s a type of API that enables the development of applications and services used for the provisioning of cloud hardware, software, and platforms.
So simply put, the API is essentially your connector for how you’re going to access that cloud service. So if you’re on an iPad, chances are you’re reconnecting to that cloud service using an API. So this API is going to have the protocols for how you’re going to connect to AWS or to Salesforce. Whatever the cloud services, an API is essentially going to be used to connect the front end to the back end. Typically, in most cloud deployments, you’re going to have numerous APIs, and generally, a lot of customers will not only have different types of APIs. So, for example, you have more security-focused APIs, social media APIs, services APIs, and so on and so forth. Again, it’s critical to understand that there is a front end and a back end. In the cloud world, we consider the front end to be how the user connects to the cloud service. So that is going to be the device—the PC, the mobile device, whatever it is. So just be aware of that, and then the backend is going to be the services of the provider. So think of the API as essentially the connector. APIs need to be understood. They’re a core component of cloud solutions. Rest and soap are typically the most commonly used. The majority of cloud services support Rest and Soap. In a lot of cases, rest is the main focus. So you need to check with your provider. Now, for this exam, you don’t need to know all the details about APIs. You don’t really need to know what the calls are.
For example, a list, a put, a get, or whatever. You don’t need to worry about that. But first, I want to make sure you understand what an API is, why it’s used, and some other points to think about. But basically, this is how you’re going to interact with the infrastructure. APIs are either front-end or back-end. And lastly, they are going to vary on cloud solutions. So, for example, if you’re going to connect to AWS and also connect to Google, you’ll of course need to have different APIs. Google is going to have a different API than Amazon, so just be aware of that. APIs are generally not portable. However, the application could certainly be portable depending on how the developer chooses to go about that process. So again, take a look at these reasons around APIs and understand why they are important some factoids. There are over 50,000 APIs out there for cloud services in 2016. Now this is an excellent website. It’s called the programmable web. If you don’t know anything about APIs, I highly recommend you take a few minutes and go to their tutorials and take a look at what information they have around APIs. There’s mobile, social media, fintech, and IoT. Again, there are many different APIs available. Let’s talk about an exam tip. APIs are used to connect the client to the cloud service. You want to know what an API is now that you’re back on the exam. If you see a question asking you about how you’re going to connect the cloud service, you know that an API is probably going to be the better choice. So, for example, don’t get confused around connectors, scripts, or anything like that. Just try to focus on APIs. Another exam tip is that the front-end devices are typically the client, and the backend is going to be the provider.
We’re going to talk about baselines and proof concepts in this specific module. Now, these are pretty important to understand not only for the exam but also for your cloud projects as well. When we talk about a baseline, we’re essentially talking about the starting point for comparisons. So, for example, if you set up this application service, you want to basically understand how it performs. So this will be a way for you to document and understand how it’s actually performing so that if things change down the road, you’ll have something to essentially analyse against a baseline. Drift, which is generally also known as noise, can definitely occur when the original purpose changes over time. For example, this is very common where you’re rolling out a new application.
In that application, all of a sudden, it needs to have this bell and this whistle. So, for example, you might not want the search box there, but they might. Instead of just conducting a basic search, you want to use the Google search API instead. So all of these things can definitely affect the baseline. So that’s called drift or noise. On the exam, you’re likely going to get a question on what a baseline is. So do you make sure you understand? And the goal of the baseline is, of course, to compare and understand where you were and where you are. Now, one of my favourite things to do, especially when it comes to baseline and cloud services, is to typically do three things, or at least two if not three things. The first thing is that I always like to get buy-in from the stakeholders on what they want to baseline and document. In other words, if the application should have a latency of no more than 30 milliseconds or 120 milliseconds if it’s in the cloud, let’s say, then you want to document it and determine how you’re going to document that latency. For example, you could document latency in a couple of different ways, just like you could document performance in a couple of different ways. Another thing that, in my experience, can give you a headache is the user experience. So you want to determine with the stakeholders how you’re going to document the user experience, because what will generally happen over time as that application matures and you have turnover is that the expectations of the application or the service will likely change. And so what was fast two years ago may not be fast enough now. My whole thought on this is that you get a document; that’s the first thing you’ve got to do. The second thing, along with the documentation, is to get buy-in from the stakeholders; make sure you understand what really needs to be documented and how. And then the third thing is to make sure you understand why you’re baselining where you are. And this will help you down the road to mitigate any issues as well. What are some best practices? You want to identify what the applications are. You’re going to the starting point. The second thing you want to do is determine what the measurements are, what the performance is, and what the usability is. Like I was mentioning, with end-user experience, this could vary widely.
You could talk to stakeholders literally in the same department, but they may be in a different location, and they may have a totally different idea of what should be measured. You want to document your process. You also want to understand the differences. This is also critical as well. So, for example, that application is going to perform differently in house than in the cloud. Of course, as you are aware, you will most likely have a network that has no or very little latency in-house. Hopefully, if you have too much latency, something’s not right. But again, you have to determine what is acceptable for that application. And then, when you go to the cloud, you have a lot of other issues that could induce latency or jitter. For example, it’s very common for service providers to change roads. How do you know that they changed roads? Well, maybe you want to determine what the road is beforehand, right? If you know that the latency is, say, 50 ms, that’s the average latency, or the median, or whatever measurements you want to use.
So you go to, for example, a Cloud Harmony application. For example, go to Cloud Harmony and do some baseline estimates before you even do a POC or anything, just to get an idea of what that service provider’s geo or zone may actually perform at. Now you want to document how it works in-house versus how it works in the cloud. That’s really the important thing to understand. Again, latency is going to typically be your number one challenge in the cloud. Baseline should be a snapshot, and a snapshot is more of a picture of however everything is set up and how it’s performing. Let’s go ahead and talk about the proof of concepts, but before that, I’m getting ahead of myself. Let’s talk about baseline and service models. So infrastructure as a service, platform as a service, SAS, and then BPAS So each of these will likely require a different approach to determine how things are performing and how the baseline has been documented. For example, with infrastructure as a service, you’re going to have some sort of liberty on how you want to set up your virtual machines. For example, your host operating system is So, for example, if you want to deploy Linux or Windows, great. Just realise that both of those may actually perform very differently platform as a service. So again, developers are very good at documenting and validating performance and testing.
They’re probably going to be your greatest assets, especially when it comes to APIs. APIs can definitely affect the performance of your application SAS. So you’ll be a SAS member as well as a BPIs member. SAS is really the same thing. I just broke it out because, depending on the camp you go to, sometimes you see it this way, but it’s really only three, with what is called business process as a fourth right now. So the service model can definitely be something you want to look at. And then, of course, you want to look at the deployment models. Now, generally, you would think that if you have a private cloud and that private cloud is hosted in your organization, in your own real estate, in your own data center, under your control, that you should probably have better security measures, better performance, probably a much more robust user experience, and some sort of documentation around I would think. But again, this is not always the case. You need to determine how you’re going to baseline that hybrid cloud deployment, right? So, for example, storage in the cloud should probably be slower than storage in your house. Again, it’s all part of that.
Another thing to think about is that we don’t talk too much about content. So content delivery is an area that is a whole niche in itself. When it comes to content delivery, you definitely want to look at where your applications are serving. In other words, where are your customers? Are your users in Europe? Are they in the US? South America, so on and so forth. And you want to know if that application performs as well in this geography as it does in another. However, when it comes to content, one of the most important aspects to consider is the user experience. Does it take too long to download? Does it take too long to upload? These are going to be common issues. So baselining your systems is critical to establishing where you are and where you need to go. Proof of Concept: We’ve done a lot of POCs in the past as a pre-sales engineer and a PS engineer. And one of the things I can tell you, as a customer, is that if you don’t do a POC, in my opinion, it’s probably a mistake. But again, that is up to you to decide. So with the POC, I’m going to talk about this from the customer perspective, and then we’re going to talk about it from the provider perspective. You want to set the goals and requirements. You want to set a timeline. So, for example, POC when we’re talking about cloud services really shouldn’t be too difficult. It shouldn’t be more than a few weeks; it shouldn’t be that long. It could even be a day or two in some cases. You’re simply attempting to load some data, test it, validate requirements, and run some tests against it. It could be a couple of days or a week or two. Usually you don’t see them for much longer than that.
Set a timeline, right? Determine which apps and services are low risk and high value. Okay, now I want you to highlight this or pay attention. Generally, you want to do a proof of concept on an application that is low risk to your organization but could provide high value. So what exactly would that application be? That’s a really good question, and that’s something you’re going to have to really look at in your organization. So, for example, if you’re a development shop and you’re developing your applications in-house, every time you have to deploy one, you have to reconfigure equipment. For example, that can slow down your process and add additional costs. Whereas if you go to a cloud situation, for example, you go look at Pivotal, you look at Google AppEngine, whatever, you reduce a lot of the risk, but you also reduce a lot of the cost. You streamline the process.
And if you’re able to induce efficiencies into something in your organization, that’s of high value, and if you could do this with no downtime or bad attention, that’s low risk. So it’s really up to you to determine what that application is. It could be email, it could be CRM, it could be accounting, or it could be going to service. Now, whatever it is, try to figure it out. So every industry will have these applications that could provide some kind of value. Hopefully, you want to make sure the stakeholders are involved. Talk to the application developers, the application owners, and the users. You want to do a test drive. You want to keep this short and sweet. In other words, the provider of the course has limited time, just like you probably have limited time, so don’t take advantage of it. But on the other hand, you have to make sure that you meet your goals. You have to make sure that you answer your questions and that you go out of the PO with a good decision. Hopefully, the findings will be confirmed.
Check everything, from latency to round trip time. For example, if it’s an ops project, whatever it is, you need to validate it, take a look at it, get feedback, and then finally confirm if there are any next steps. For example, the vendor sends you a quote, or you go to support with the question, and then you determine what the next steps are, whatever they are. And then, from the provider or vendor perspective, generally, if you’re in sales, one of the first things you want to do is identify the right customer sponsor. So you don’t want to go out there and spin your wheels with some administrator who might not even have any influence whatsoever, at least initially. So you have to determine who the right stakeholders are.
So it might be the IT director; it might be the CIO; I don’t know. Depends on—I’ve seen it all over the map, to be honest. Okay, identify a budget, right? Make sure that the customer has the funds to go to the next level if that’s something that they want to do. Identify the app and service; identify stakeholders. Generally, you want this to be in a sales cycle. What I mean by that is to make sure that this is part of selling a new service or a new solution, and that this is typically going to fall in a calendar cycle. Generally, you don’t want to do a proof of concept and find out the customer won’t have money for two years. You probably want to wait on that. Set goals, create a timeline, and schedule technical sports. So one of the things you should definitely do before doing a POC is deal with any technical chills that may arise. Make sure you have the right people ready to go to solve problems, validate results, and then confirm the next steps. Let’s talk about an exam tip here. Baselines are used to create a point of comparison.
Popular posts
Recent Posts