Search BMC.com
Search

Share: |


There’s a lot to cloud computing. There are designs and architectures and processes. There are organizational challenges. There are expectations and support and naysayers. But there are also stages of adoption. Day 1, your little cloud is in its infancy – it cannot be expected to master spelling and fractions out of the gate.

 

Initially, it is important to set expectations. You need an end goal – or set of goals – for which to strive. Then, with that goal in mind, it’s time to put together a roll out plan that starts small and grows.

 

The secret is not to get overwhelmed. With an end goal in mind – even an abstract set of goals – you can make the decisions today that will facilitate that growth. If your goal is to manage your entire IT portfolio from the same cloud interface, for example, you won’t implement a cloud management platform that constrains your rollout. Even if that rollout happens over 5 years, you’ll keep moving forward, building on prior decisions and success.

 

Build a plan. Set milestones with concrete, demonstrable business value. Continue to build and refine the vision, evangelizing along the way. Recruit a team of similarly motivated people. And just start clouding. When you feel the change happening, it will whet your company’s appetite for the fruits of your labor.


We’re  doing a series called “What to Expect When You’re Expecting… a  Cloud”  which focuses on the many elements of cloud planning, and the  questions  you should be asking yourself and your team as you make your  way towards  true cloud delivery. Start reading with Part 1!

Share: |


A lot of work goes into creating and raising a cloud environment. Time. Money. Effort. Tears. It’s not easy work. But, when you’re past the terrible twos and over the petulant teen years, how do you know if you’ve brought up a cloud you can be proud of?

 

There are many ways of evaluating the success of your cloud environment. ROI is always a favorite, though the math can be done in so many ways. Cost savings. Cost avoidance. Datacenters spared. Hardware un-purchased. There’s lower cost per service. There’s different amortization of resources. ROI people probably love cloud computing, since there are so many ways to skin the cat. And, it’s hard to argue with a good ROI calculation. Still, let me pose a few alternatives:

 

Value to the Business:  What did you enable the business to accomplish which couldn’t have been done before? More drugs may have gotten tested. More models run to lower risk. New products may have launched. Development times may have shrunk. Features may have been added. Whole opportunities may have been pursued which otherwise would have been too painful or costly to entertain.

 

Value of Flexibility: Were there times when something was possible that otherwise would have been impossible? Massive scale out in response to a successful ad campaign. Disaster recovery after a tornado. Continued quality service despite an emergency situation. Rapid response to an unanticipated market shift.  Think of all the times when unanticipated market shifts, both positive and negative, changed the landscape of a business overnight – and then think of the value of being agile.

 

Value to IT:  Has cloud changed the nature of the IT department? As IT, we want to put ourselves last, in deference to the business – but that’s not always right. IT departments need to attract and maintain a clever team of motivated, intelligent and creative people. Losing them to the frustrations of process overload and boredom doesn’t help IT and it doesn’t help the business. Cloud computing can change the culture of an IT department, positioning it to act as a key strategic component of the company and to only increase its opportunities for interesting, industry-leading work.

 

So, how do you make sure that your cloud is delivering on its campaign promises? Set the goals early, and measure what you’d like to see. Keep those report cards coming. And remember that math class isn’t the only one worth acing.


We’re  doing a series called “What to Expect When You’re Expecting… a  Cloud”  which focuses on the many elements of cloud planning, and the  questions  you should be asking yourself and your team as you make your  way towards  true cloud delivery.

 

Start reading with Part 1! Read the final installment, More Cloud than I can chew?

Share: |


Every month or so, we like to look at our infants and track their height and weight. We like to ensure they are sprouting enough teeth and making progress against all the key developmental markers like pulling on their own ears or chewing on their own toes. This sort of regular barometer of progress helps us feel confident that everything’s moving along swimmingly.

 

A cloud environment, not unlike a child, needs to measure progress. In a traditional computing environment, users have dedicated hardware and then track performance on that hardware/software stack. It’s not simple – but it definitely has a certain tangible end point rooted in physical machines. In a highly dynamic cloud environment, the game changes. In the cloud, the SLA is king.

 

Why? Because given a service level, the resources of the cloud should line up to meet that service level. There’s no situation in which the memory on the box was insufficient or the processor needs an upgrade. Those elements need not even be defined, really. All you should have to say is: “I need 5 9s of uptime and a certain transaction speed” and the environment should, theoretically, add or remove resources to meet that goal.

 

A few things to note, however, in that somewhat idealized scenario:
a)    Performance management and capacity management in a cloud environment get pretty intimately linked.
b)    There will be times when the right thing is to shrink resources – or “right-size” the service – rather than grow them. That’s a key benefit of the cloud to IT efficiency.
c)    The very definition of an SLA can change in your organization for cloud environments – there’s no reason to assume it remains identical

 

This level of automation is fairly futuristic. The algorithms involved are a bit dizzying to a layman like myself. Considering whether peak or mean requirements over what span of time constitutes a spike. Evaluating how much of which resource to add, and if this is just a runaway process that might require rebooting. Identifying if the right solution is to back up and restart the whole thing. There’s a reason performance and capacity management is a highly specialized function, with teams of people supporting that task.

 

However, the technology is getting there. Step by step, the more mechanical, rote automations are being developed, freeing up the people to provide higher level guidance and services.  As I told a customer just this week, perhaps the challenges of performance management didn’t get easier – but the tools at your disposal have grown tremendously!


We’re  doing a series called “What to Expect When You’re Expecting… a  Cloud”  which focuses on the many elements of cloud planning, and the  questions  you should be asking yourself and your team as you make your  way towards  true cloud delivery.

 

Start reading with Part 1! Read the next installment, An Upstanding Cloud

Share: |


Your internal cloud may start small. And it might not be growing exponentially over the first few months. Yet, the demands of your business might be much higher than anticipated. Or, even if you have a huge cloud – it might make sense not to keep growing it to fulfill all anticipated – if splotchy – demand. In other words, there are often times when leveraging public cloud resources can make good business sense.

 

Counter intuitively, perhaps, cloud computing actually should increase the consumption of IT in your company.  Until now, let’s face it - IT resources haven’t been growing on trees. Cloud basically creates a u-pick-it facility for IT resources, and that’s going to greatly increase demand. Whereas before, people picked a shiny apple for lunch every day, all of a sudden they’ll think of making pies and making applesauce. It will turn out, apples are a lot more useful than they thought – and consumption will go way up. This is, of course, a good thing.

 

When consumption goes up, IT no longer becomes the bottleneck to the business. It might be interesting to see, as a sidenote, where the new bottleneck emerges. But, IT will be lauded as highly supportive of whatever efforts the business needs to expedite. The only challenge is – IT has to have enough resources to continue to support thus buffet of computing indulgence. That’s where public cloud comes in.

 

There are probably workloads that you’d feel comfortable moving to the public cloud today. Actually, I’m willing to bet that you’re already using some shared services on the cloud. Maybe you’re using Salesforce.com. Maybe you’ve outsourced your benefits administration. Maybe travel is not done in-house. Stuff is out there. And you’re probably not too worried about it.

 

More and more services can go out there. There’s a remarkably amount of non-mission-critical non-high-risk computing that goes on. And public clouds are not only getting more secure (they must – their business depends on it) but they are also providing more and more guarantees of security, service levels and so on. Furthermore, software packages like BMC Cloud Lifecycle Management (forgive the shameless plug) enable you to manage those external resources in the same way that you manage internal resources, cutting back on overhead and ensuring consistency across the environments.

 

So think about it. What’s the role of the of external suppliers in your smorgasbord of services? Sometimes a little extra goes a long way.


We’re  doing a series called “What to Expect When You’re Expecting… a  Cloud”  which focuses on the many elements of cloud planning, and the  questions  you should be asking yourself and your team as you make your  way towards  true cloud delivery.

 

Start reading with Part 1! Read the next installment, How's my Cloud Doing?

Share: |


Somewhere in the cloud dream is that pervasive idea of chargeback. Chargeback is so compelling because it implies that IT will actually be able to collect compensation commiserate with the service it provides. While unlikely to ever account for the aggravation services, the late-night-blackberry-session services, or the weekend-trip-to-the-datacenter services, this seems like a small step forward in getting real acknowledgement for the efforts of IT, which, let’s face it, doesn’t get box-loads of gold stars shipped to their cubes every day.

 

The nice thing about cloud is that you can track consumption of resources. The challenging thing about that is, as we saw before, resources are sort of … variable.  Hardware resources are reasonably easy to track. Network is less easy to track. Software starts getting pretty tricky to track. Then there’s the overhead of management – both software that manages the cloud and people that manage the cloud. So, consumption is not quite as easy as weighing your box at the salad-bar line.

 

The second challenge is one of investment. The cloud resources must be ready and waiting for new requests to come in. That means hardware (and some software) has to be paid for in advance of the user “buying” it. So, the flow of payments to IT has shifted. Historically, IT bought hardware to support funded projects. Now, IT buys hardware before they even know what projects are coming. IT has rarely kept a stocked pantry – but this is basically the model. When someone wants pasta, it better be available.

 

Finally, let’s touch on the challenge of actually getting the money. Sure, you can do showback pretty easily, sending each business unit a report of their monthly consumption. Then, you can even go through an exercise to extract some budget from each of those groups in line with their usage. I like to call that “guilt-back.” 

 

True chargeback involves inputting consumption and cost calculations into your organization’s financial systems – the ones that track the flow of money around the company. That typically changes the budgeting process, and probably involves a few long conversations with the CFO’s team. It might even impact financial statements, if the change in model is a substantial enough part of the business’s expenses. This is nontrivial stuff.

 

Of course, there will come a time when all this is much more straightforward and this path to chargeback is well worn. But for now – bring your hiking boots.

 

We’re  doing a series called “What to Expect When You’re Expecting… a  Cloud”  which focuses on the many elements of cloud planning, and the  questions  you should be asking yourself and your team as you make your  way towards  true cloud delivery.

 

Start reading with Part 1! Read the next installment, Running Out of Cloud?

Share: |


Earlier this week, Novell announced their new Cloud Manager product (link here), which they state “enables customers to create and securely manage a cloud computing environment as a seamless extension of existing data center resources”. As a resource for prospective customers, they provide a comparison chart, showing the Novell solution ranked against selected competitors, which I’ve reproduced below (original is here )

 

novell-comparison.JPG

 

 

I appreciate the competitive reference, and would like to briefly comment on the criteria.

(On a side note, I must say that I was shocked, shocked to see Novell awarding themselves full credit for each listed feature ).

 

Frankly, I’m not interested in writing an “our product is great!” posting (which I don’t think would be particularly enlightening or valuable), nor in criticizing Novell’s product.  What I do think will be interesting will be to talk about the criteria that a prospect should consider when evaluating cloud management solutions.  Novell lists the following features in their chart ; my brief comments follow each.

 

 

  • Role-based self-service workflow
  • Business service template catalog

 

Absolutely! A self-service portal, driven by a service catalog has consistently been a primary requirement from the numerous prospects I’ve met with. To achieve the responsiveness and reliability required in a cloud solution, IT needs to provide this kind of role-based interface to its internal customers – giving them the ability to request and perform ad-hoc actions, yet remaining within constraints dictated by IT.  Also, it’s valuable to be able to expose business services in the catalog, not just technical services. This enables numerous benefits – for example, allowing IT to assign resources or set SLAs based on the business value of a service. This context is key to achieving IT-business alignment.

 

  • Customizable service levels

Yes, these should be customizable both by IT (which defines the service levels, and *how* they get rendered when they’re deployed into a cloud environment), and selectable by the requester from within the self-service portal (to better match up the business value of a service with its required SLA).  This in turn needs to be connected with …

 

  • Flexible costing models

From my perspective, this should be more about service pricing – transparently exposing to the internal customers the different prices for different levels of service, backed up by the ability to provision based on service profiles (more on this momentarily).  Pricing, in turn, should be based on a real service costing analysis – effectively achieving IT cost transparency.  What this means is that IT should be operating from a model of what it costs them to deliver a given level of service, and to price things accordingly.  (Service Costing, Chargeback, and Showback is a rich subject in its own right, which I will discuss in a future posting).

 

  • Heterogeneous virtualization platform support

Certainly – many customers that I’ve spoken with require management of both existing virtualization platforms (such as AIX LPARs), as well newer ones.  Analyst surveys underscore this, indicating that many enterprises anticipate having multiple hypervisors in place – and system management companies need to respond to this customer demand.

 

  • Automated workload provisioning

This is a key aspect of any cloud lifecycle management solution – the ability to actually provision (and later, deprovision) workloads.  However, there are some subtleties around this that are important to understand – specifically the ability to dynamically assemble the desired environment, based on the (potentially custom) requirements from the requester, while still remaining within configuration and compliance constraints defined by IT.  This is really important – even while enabling a dynamic, on-demand Cloud environment, IT must remain in control of the environment.  The requirements for security, operational, and regulatory compliance are even more important in the larger and more complex Cloud world than they were in the purely physical data center.

 

  • LDAP & ActiveDirectory Integration
  • Support for multiple virtual datacenters

No arguments here!

 

These are all good, relevant, and sound requirements for a cloud management solution….they’re just incomplete. I submit that, in addition to those listed above, that prospects (both on the Enterprise and Service Provider side) should also consider the following:
•     Full-stack provisioning
Provisioning needs to be much more than just cloning a VM image –in order to keep the service catalog down to a manageable size, while still enabling the flexibility that line-of-business customers demand from IT, any cloud solution must be able to layer additional elements on top of (and outside of ) a base OS during the automated provisioning process.  That is, the solution must be able to place middleware, security, backup, and monitoring components into a service, as it is being provisioned. It must be able to deploy application software as well.  And, it must have the ability to correctly place this service into the right network container, to ensure that this service can only see (and be seen) by its related business services. This is exceptionally important in any multi-tenant environment.
•     Integration with IT change management
•     Integration with CMDB
•     Integration with IT governance & compliance
Any Cloud management solution must be part of an enterprise’s overall IT management solution – and it must be able to be incrementally introduced.  The organizations I’ve spoken with have made tremendous investments in their people, processes, tools, and policies – and are unwilling to introduce new silos into their organizations.  They find Cloud very appealing, but only when it’s executed in the right way.
In conclusion, I recommend that any prospects interested in a cloud management solution use the list of criteria above as a starting point – but to carefully and thoughtfully plan use your cloud roadmap to adjust and weight your decision factors to best match your specific needs.

These are all good, relevant, and sound requirements for a cloud management solution….they’re just incomplete. I submit that, in addition to those listed above, that prospects (both on the Enterprise and Service Provider side) should also consider the following:

 

  • Full-stack provisioning

Provisioning needs to be much more than just cloning a VM image –in order to keep the service catalog down to a manageable size, while still enabling the flexibility that line-of-business customers demand from IT, any cloud solution must be able to layer additional elements on top of (and outside of ) a base OS during the automated provisioning process.  That is, the solution must be able to place middleware, security, backup, and monitoring components into a service, as it is being provisioned. It must be able to deploy application software as well.  And, it must have the ability to correctly place this service into the right network container, to ensure that this service can only see (and be seen) by its related business services. This is exceptionally important in any multi-tenant environment.

 

  • Integration with IT change management
  • Integration with CMDB
  • Integration with IT governance & compliance

Any Cloud management solution must be part of an enterprise’s overall IT management solution – and it must be able to be incrementally introduced.  The organizations I’ve spoken with have made tremendous investments in their people, processes, tools, and policies – and are unwilling to introduce new silos into their organizations.  They find Cloud very appealing, but only when it’s executed in the right way.

 

In conclusion, I recommend that any prospects interested in a cloud management solution use the list of criteria above as a starting point – but to carefully and thoughtfully plan use your cloud roadmap to adjust and weight your decision factors to best match your specific needs.

 

One final comment…I must say that I was puzzled to see VMware’s Lifecycle Manager product listed in the comparison chart, since it’s no longer available as of Sept 1 (see here ), and has been supplanted by the (new) VMware vCloud Director product.

 

To wrap up, I do wish to acknowledge that I have several friends and former colleagues at Novell, and wish them the best of success in their endeavors. I’m in no way disparaging Novell or their solution; I’m just using their comparison chart as a catalyst for this conversation about decision criteria.

 

 

What do you think?

Share: |


When you introduce a cloud into your IT environment, it’s a little like bringing a new baby home. While that cutie pie seems pretty self-contained, a lot of other parts of the household actually impact her, and she probably impacts them as well. Sure, Mom and Dad are up until all hours making sure she’s happy – but Older Bro has also been reading books on his new role for weeks. And the dog has been listening to audio tapes of babies crying to acclimatize her little schnauzer self to the noise levels. Her crib might be an idyllic land of sugar and spice, but this little one is part of a family.

 

The cloud is part of a family too. Contrary to some architectures that imagine the cloud as that oasis of greenspace where IT can finally wipe the slate clean and start over ‘right this time,’ those of us up to our ears in IT process know better. You still need to manage configuration and change. You probably still want the same CMDB tracking cloud services like any other CI. You already have some functional ITSM processes and workflows – which will continue to live on. Let’s not bring up security and compliance, since there’s no way you’re getting away without that for long in your cloud.

 

The cloud has to work together with these other pieces. Now, you always have the option to rip and replace. You always have the option to start a fresh parallel path of compliance monitoring efforts and a second CMDB and maybe a whole new set of service management tools and workflows. You can recreate how you release application packages. Redoing work is always an option.

 

It’s just usually not the best option.

 

It took years of blood, sweat and tears to get all that stuff worked out in your existing IT environment. And let’s face it – precious few people are chomping at the bit to recreate SOX compliance rules for a new environment.  Why not leverage all that existing investment in the cloud? Sure, some things will change. Workflows will get more automated. Performance management will get more dynamic. But, so much is staying the same.

 

To flip the analogy – let’s not toss out the baby with the bathwater.


We’re  doing a series called “What to Expect When You’re Expecting… a  Cloud”  which focuses on the many elements of cloud planning, and the  questions  you should be asking yourself and your team as you make your  way towards  true cloud delivery.

 

Start reading with Part 1Read the next installment, Who's Gonna Pay for All this Cloud?

Share: |


We just talked about how BIG the cloud team can be. Now, let’s talk about how small that cloud team can be.

 

Sure, you need some great cross-functional collaboration – but that doesn’t mean the entire capacity management team needs to clear their schedule for an offsite. Why not take a page from the business side of the house and create a small, agile little “startup” team. Like a startup inside IT. It’s been done often in innovation and product development efforts – and this is very much one of those. It just happens to be sitting in your IT shop, rather than over the wall in R&D or the Innovative Cereal Creation Team.  (Wouldn’t that be a fun division? Designing new breakfast cereal… could be amazing)

 

As luck would have it, I’ve spent some time in the world of innovation management, and so I’ll share a couple guidelines:

 

a) The team has to be pretty representative, but still pretty small. Think about 5-10 people, not 30.
b) The folks on the team should be selected for their domain expertise as well as their attitude. Nervous nellies and naysayers need not apply.
c) The team should be funded – but not overly funded. Resource constraints drive creativity. Think about the last home repair you did – you ran out of something, or didn’t have the right tool, right? And somehow, you got it done anyways. That’s the spirit.
d) They should have clear goals and milestones.
e) They need strong, consistent, unwavering executive support.  There must be a champion – to help cut through the red tape, smooth out the politics and ensure the funding isn’t cut off next quarter.

 

There’s tons of research on how to build these teams, but we all know how strong well-motivated technologists can be. This is the fun stuff, folks – so, anticipate having far more applications than open positions on this cloud initiation team!


We’re  doing a series called “What to Expect When You’re Expecting… a  Cloud”  which focuses on the many elements of cloud planning, and the  questions  you should be asking yourself and your team as you make your  way towards  true cloud delivery.

 

Start reading with Part 1Read the next installment, No Cloud is an Island

Share: |


It takes a village to raise a cloud. It’s true.


Let’s inventory, shall we?


  • We need the infrastructure folks. Multiple folks. Server people, Network people, Storage people. That’s all just the hardware.
  • We need virtualization folks – if they are separate. The hypervisor team or the vCenter team.
  • We need the OS team – again, if they are separate. Otherwise, there are some really busy infrastructure people out there.
  • We need the team responsible for performance monitoring.
  • We need their cousins, the capacity management people.
  • We could use some security people – they’ll get on board one way or another.
  • There are probably some change management and compliance people with a real stake in this.
  • Of course, if you’re serving up applications, each one of those teams should probably be involved.


Someone better order pizza. This is getting to be a crowd.


But seriously – this isn’t a bad thing, is it? The whole point of cloud is IT transformation – not IT business-as-usual, right? This is going to change the game for everyone. If it’s everyone’s goal – it should be everyone’s dream as well, so let’s get the team together from the start and ensure they’re engaged and energized.


What? You’ve never MET some of these people? Well, get out your business cards – it’s time to throw a party.


We’re  doing a series called “What to Expect When You’re Expecting… a  Cloud”  which focuses on the many elements of cloud planning, and the  questions  you should be asking yourself and your team as you make your  way towards  true cloud delivery.

 

Start reading with Part 1! Keep reading the next installment, How Large is this Cloud Team?

Share: |


Is it a boy? Is it a girl? Is it an operating system?

 

The industry likes to put a variety of letters before “aaS” and make distinctions about types of clouds. People like letters. I can’t blame them. But the cloud spectrum is really analog – not digital. There aren’t only 3 settings – Infrastructure as a Service, Platform as a Service and Software as a service. Let’s refresh our thinking on all the components of a software stack:

 

  • The Operating System (let’s skip over the BIOS – it’s too painful)
  • The Middleware
  • The Databases (sometimes in a different place, but still highly relevant)
  • The Applications (usually with their own tiers)
  • The Performance Monitoring Tools
  • The Compliance Monitoring Tools
  • The Security Tools
  • And the list goes on.

 

Most modern production applications have a smattering – if not all – of these pieces. You, as the deliverer of cloud, can provide any or all of these pieces to your different customer groups. You can go barebones and standard and give them a choice of OS #1 and OS #2, and leave it at that. Or, you can add in some monitoring capabilities. Or some middleware. Maybe offer a couple “standard applications” like Sharepoint. It can get complicated.

 

Since we all passed high school statistics – this begins to look like a ga-billion permutations of potential offerings. That’s true. Remember – you’re a service provider – so first, let’s think of what your customer needs and wants from you - and then let’s solve the “How.”  They probably need a range of options. You probably want to deliver that – since that’s your value. They probably don’t need unlimited options – and you probably don’t want to give them the chance to input the name of their favorite software package in a text box for provisioning.  They need some level of customization. You need some level of control.

 

<Shameless Plug> That’s why BMC’s Cloud Lifecycle Management software leverages full stack provisioning to build out cloud services. You can give users various pick lists of options and quickly build the environment they want while still controlling the content of those pick lists. And the best part is – since it isn’t image-based, there’s no associated image management of 800 combinations of cloud services. </Shameless Plug>

 

As always, where there’s a will, there’s a way. And this can be an evolutionary step in your deployment of cloud. But, it’s worth thinking – what AM I delivering – And is it what they want?

 

We’re  doing a series called “What to Expect When You’re Expecting… a Cloud”  which focuses on the many elements of cloud planning, and the questions  you should be asking yourself and your team as you make your way towards  true cloud delivery.


Start reading with Part 1And read the next installment, Who is on the Cloud Team?

Share: |



We talk glibly about cloud users. The users of the cloud are some implied group of people who are given access to a self-service portal and are then enabled to provision resources. With Amazon EC2 in the back of our minds, we can imagine that anyone is a potential cloud user, since you can order cloud alongside your copy of Wine for Dummies in that world. But, the question really isn’t that straightforward – and it will drive everything else you do.

 

Look around you. Are you going to be requesting servers from the cloud? Is your development team the target audience, at least initially? What about R&D – are they dying for additional resources to run their research processes? These are common candidates – folks with, shall we say, a somewhat high comfort level with technology.

 

Then, we think about the business. The business – presumably trying to host production applications in a cloudy environment – is definitely the paying customer when web sites are put up and Supply Chain software is installed. Trading applications, Sharepoint servers – all those are business workloads, in various levels of “production criticality.” But, it’s pretty unlikely that the head of trading is going to come to your site and provision himself some more trading application in the cloud.

 

That guy  will probably call on their applications team, and the applications team will probably determine the game plan, and sort out what needs to be installed and how much and how critical and how secure it all has to be – and THEN, they probably would want to provision some resources. That application team is probably the direct customer of the cloud. Sure, Mr. Trading writes the check – but he’s not the direct user.

 

Identifying your customer is always a key step in developing a business. Cloud infrastructures, however, take the form of a B2B product, in most cases. You’re providing your tires to the car manufacturer, for ultimate payment by the car buyer. They better be easy to install for the car company – but they better be pretty cost-effective for the end customer. Thinking of the value chain of your cloud offering will help frame every subsequent step of designing and delivering that product.


We’re doing a series called “What to Expect When You’re Expecting… a Cloud” which focuses on the many elements of cloud planning, and the questions you should be asking yourself and your team as you make your way towards true cloud delivery.

 

Read the next installment on What Are You Delivering?

Share: |


We are occasionally inspired to write a series of posts based on conversations we've had with customers and partners. Today, we are launching a series entitled What to Expect When You're Expecting Cloud. 


Borrowing from its namesake, this series is meant to open up areas of discussion, highlight certain aspects of cloud building that may be unexpected, and provide guidance to get you started.


This 10 part series begins today, and one item will be posted every day for the next 2 weeks. Read the first installment today!

Filter Blog

By date:
By tag:
It's amazing what I.T. was meant to be.