Why Poor Data Classification in Government Will Impact BYOD
In recent discussions with IT leaders from both federal and Department of Defense sides of US government, representatives stated that they are having a heck of a time accommodating expansive growth in mobile computing. This is critical given that today, in most cases, agencies and departments still have control over which mobile devices can be used. In the future, these executives realize that the changing demographics of contractors and employees means they will not only need to support continually growing traffic, multiple presentations and increased asset management, but will also have to deal with a wide spectrum of mobile devices due to Bring Your Own Device (BYOD).
This idea that these executives will one day soon have to loosen their grip over endpoints is a major concern. Contrary to belief it is not about power and supremacy over their domain. Most users have no concept of the level of complexity for managing access and availability of data and applications when there is no control over the endpoint; nor should they. While network security solutions have improved dramatically over the past decade, improper use of the tools and ever increasing abilities of hackers means that “locking the front door” isn’t good enough to solve this problem by itself.
One of the keys to solving this issue in a way that doesn’t alienate users, but also ensures confidentiality and security of government data is going to be segmentation. Segmentation is the act of distributing the data across multiple tiers from unclassified to compartmentalized and providing greater levels of restrictions on access at each layer. For example, unclassified information should be hosted in the public cloud with no permanent connections back to any data center housing higher classified documents. For Official Use Only (FOUO), Confidential, and Secret data should require minimum Virtual Private Network (VPN) connections for access. This means that the mobile devices must support the VPN protocols in use in order to establish a connection. Finally, Top Secret and above information should require on-premise wireless or wired support only combined with two-factor authentication, VPN and the ability to remove any data downloaded to the mobile device when the VPN connection is broken.
However, the biggest issue for government is going to be segmenting data that is either improperly classified or comprised of various levels of classifications. I was once part of a project where the requirements documents were improperly labeled FOUO, which raised many problems sharing them with foreign counterparts even though the project was developing a collaboration portal to work with foreign government officials through what was going to be a publicly hosted application. This is just one small instance of tens of millions within the government. Moreover, it seems more recent projects have seen serious disagreement among government IT employees and contractors as to what are the appropriate classification levels for certain pieces of data. In one of these cases a very junior security professional within the government was demanding aggregated publicly available information could not exist in a publicly hosted cloud.
I don’t relish these government IT executives position with regard to the growing mobile demand. BYOD is going to amplify this problem exponentially.
Adventures in Cloudwashing: Are You the Cloud Or in the Cloud?
Anyone who is working intimately with cloud computing and having critical conversations regarding this medium will eventually be party to the “cloudwashing” conversation.
Cloudwashing: the activity of associating all your products with cloud computing even though it doesn’t meet core attributes that define cloud computing as created either by de jure or de facto processes.
Depending upon your role in information technology cloudwashing is either a major concern or a significant benefit. If you are a product vendor looking to gain attention for your product, then cloudwashing is very useful. It opens up interest in your product to an entirely new audience that may see benefit in your offering even if it really doesn’t align fully with cloud computing goals and values. If it attracts eyeballs without significant additional costs, then it’s positive.
If you are an IT manager, director, vice president, CIO or other, and your goal is to say that you’ve successfully delivered a cloud computing initiative, then cloudwashing is good. After all even if it’s traditional managed services, if you can label it cloud, the pure confusion and lack of agreement on what is cloud will work in your favor. That is, who can argue with you that your initiative isn’t cloud computing if they cannot define cloud computing in a concrete and definitive manner.
If you are a security officer concerned with privacy and security of your businesses’ data and access, then cloudwashing may work in your favor as well. Most cloudwashing is typically managed services repackaged, which means it doesn’t really incorporate key attributes of cloud computing that concern security professionals, such as multitenancy and shared hardware platforms. So, the security professional who cares less what the business wants to say they’ve accomplished as long as they’ve done their job securing information and access may be better served by a cloudwashed product or service than a real cloud computing product or service.
So, why should we care if a business wants to cloudwash their offering? For one, its disingenuous, and anyone that’s willing to sell you something in a disingenuous manner should trigger you to question that company’s values and ethics. Ultimately, it could mean the difference of them being their when you need them and you out on the street with your briefcase in hand looking for your next job.
Secondly, it damages the entire industry. While you can technically argue that there’s no one single globally-accepted definition of cloud computing, NIST and Cloud Security Alliance are two very credible organizations that have settled on a common definition. There may be others also promoting this definition as well. So, to imply that there’s no standard undermines the work of these organizations in attempting to help businesses and individuals understand cloud computing. Moreover, without a common agreement, there is no means to develop agreed upon metrics for comparing offerings from different vendors.
Finally, there should be delineation for vendors that are in the cloud and those that are the cloud. This differentiation is unclear when vendors cloudwash their offerings. Being ‘in the cloud’ means that you are selling a service that relies upon yet another provider’s cloud computing service. This is important for businesses to know that are signing up for a service. In the same way that you would want to know that FedEx or UPS uses a third party delivery agent in a foreign country and that they are not handling your package from start to finish, you should want to know who ultimately is touching your data and applications. Cloudwashing makes it difficult to distinguish those who are “in the cloud” from those that “are the cloud”.
Of note, I know there are those that will argue that you’re buying a service and you shouldn’t care, but that’s a naïve opinion that demonstrates a lack of understanding for the business requirements for audit and compliance. Maybe some startup in Bumpuck, Nowheresville that’s hosting a free service can get away with this approach, but real businesses that hire professional accounting and auditing services are responsible for understanding the implications for using that service; this often means knowing what software and services is being used to provide a service.
Start Building Your Next Generation IT Department Now
David Johnson’s Blog piece really got my goat. In this piece, “Meet Jamie - A HERO With The Power To Force Change,” Johnson paints a sales representative that has rejected his IT department’s choices for device support in favor of an unsanctioned Bring Your Own Device (BYOD) strategy as a hero. Frankly, I believe Johnson does a major disservice to the IT industry with this piece, once again painting them as inept and unable to keep pace with the speed of business.
As someone who has consistently been advocating for pushing the envelope within IT, my goal has been to help business establish a framework for operating in a rapidly changing industry and meeting the expectations of its users. And, like a good mentor, I can push my students to reach their potential, but don’t you come bash them for not being able to rise to the challenge.
How many of you out there believe your IT department is a hindrance or a hurdle to you getting your work done? Okay, let’s put that feeling to the side for one minute. It’s a valid concern, but let’s look across the table at the challenge from ITs perspective.
- Operational costs are continuing to rise and continually consuming a greater portion of the annual IT budget
- Technological shifts are coming faster and are more disruptive with each shift
- In many businesses, the same IT group is responsible for desktop support, mobile device support, application management, operations management and telecommunications
- The IT department is supporting many different businesses, not one. From the IT perspective, marketing, accounting, executive, sales, distribution, warehousing, supply-chain & logistics are all different businesses
- Enterprise class software and hardware generally sucks
Now, let look at prioritization of efforts in the environment I just described. Who should get the most attention? In the realm of this, does it seem reasonable that they may not be organized in a way to support your desire to bring in the latest mobile device or tablet?
All this aside, let’s turn back to the answer we put aside earlier regarding your concern that IT is a hurdle or hindrance to getting your job done. The reality is that you should expect that the business provide the appropriate levels of support to ensure you operate with maximum productivity. It’s in their best interest and yours. This is not a question of “should we”, but “how can we?”
Frankly, I believe IT departments have no choice but to innovate with regard to how they staff, organize and deliver service. The old world nature of silos of expertise are toast. Lack of cross-domain understanding of IT-related issues accounts for 90% of slowdowns, lack of response and service disruptions. This type of change cannot occur overnight. It must be an evolution unless the business is also willing to accept service disruption as a possibility in order to speed the change within their own organization. I am not stating this facetiously either; it is a risk management decision that may be viable and worthwhile if it will enable the organization to triple their efforts and operate more effectively.
It’s time to put away the pitchforks and torches with regard to the IT department. The best thing you can do to help yourself is not become a rogue BYOD agent, but convince your management to contribute to innovation investment within IT to support your needs for greater productivity.
Become the Platform
Steve Yegge, a Google engineer, recently posted a long rant on Google+ about how Amazon does everything wrong and Google does everything right. Probably the most traffic generated for Google+ since they launched, which is why he most likely still has a job. While it was painfully excruciating to get through, I wanted to make sure I read the entire entry because the focus wasn’t really on Google at all, but on a transformative idea of Jeff Bezos, founder and CEO of Amazon.
As Steve points out at some point Bezos got “it” and he realized the power and the value in his company wasn’t just to be an online retailer, but to the be THE platform for online retailing. Now, to fully understand this, Bezos didn’t say to his team build me a platform that handles every aspect of online retailing including managing the supply-chain and facilitating third-party suppliers to sell directly through Amazon. What he said was simpler than that, but significantly more powerful; he said, every team in the business will expose their data via a service interface.
Now, I’ve written about Enteprise SOA till I’m blue in the face and still had to deal with arrogant dweebs argue about REST vs. SOAP or top-down vs. bottom-up just more people who didn’t get that SOA is an architecture that should be applied to the business, not to just the software. Now, I have the greatest proof point imaginable for my argument, Amazon is the embodiment of Enterprise SOA; no two teams can communicate data without going through their own public interfaces or face termination. I guarantee that format, protocol, size, shape, smell, whatever attribute you want to convey about SOA all became irrelevant after a few months of your fellow workers kicking the crap out of you for having a broken or dysfunctional interface.
This isn’t even the best part of the story; it’s just the beginning. What Bezos effectively created by this one mandate was to turn Amazon into a platform. Amazon today is probably the most powerful retail platform in the world. The underlying software helps that platform to run smoothly, but the platform is more than the software. It’s the people, the processes and the technologies working together in harmony to move products from buyer to seller in both physical and digital forms.
Additionally, what Amazon realized in due course of this act is that the computing platform developed to drive their retail platform can also play a significant role in helping other businesses become a platform as well. Hence, Amazon Web Services is the embodiment of that effort providing the same methodology as Amazon the retail platform uses to the world-at-large.
On the other side of the jungle sits a million pound behemoth attempting to stay valid in this fast moving cloud market, where lots of small and mid-sized competitors, as well as some large competitors, are all already vying for leadership positions. Companies, such as Dell, Google, HP, Oracle, Cisco, Microsoft, Unisys, and Harris are established firms with solid client bases that are all looking to deliver cloud services to the enterprise. So, what can IBM do as a Johnny-come-lately to the cloud game to compete in this arena?
Obviously, IBM believes it’s been playing in this cloud game for some time, but perception is reality and when people talk cloud, IBM is typically not part of the conversation. And, that’s when it hits me, IBM needs a BHAG (Big Hairy Audacious Goal) to turn this perception around. They’re not going to win this game by throwing money and people at the problem, it’s a different world led by a different mindset and Grandpa’s enterprise computing approaches aren’t going to cut it. IBM needs to become the platform! They need to embody everything they know and have been delivering for the past 100 years, package it and deliver it through service interfaces. They need to make every team work with every other team only through service interfaces. And, most importantly, they need to change the conversation from “what is cloud computing” to “what is cloud computing about”.
Now, I suppose this same approach could work for HP and Microsoft as well since they too both struggle to stand out against in the field of cloud computing. However, at least HP and Microsoft are part of the conversation. Maybe I’m just rooting for the underdog like I always do, which is why I still haven’t given up on the Washington Redskins … yet! It would be fun to watch a behemoth like IBM come stomping from the backfield, crushing those with existing market penetration and moving to the front of the pack to compete against the leaders in cloud computing.
Cloud Conundrum: Private Cloud Computing With A Pay-for-Use Model
One of the touted benefits of cloud computing is supposed to be that it is a metered service. Much like your water and electric, the cloud is supposed to allow users to access compute resources as needed and be charged only for what is used. This is a great model for users of cloud computing since the risk is nominal. However, it’s a very costly investment on the part of cloud service providers since they need to create, market, manage and support the service without any guarantees that the service will be used. Moreover, pricing this usage so as to be profitable can be a complex initiative since users expect to pay less than it would cost for them to acquire and manage the resources themselves.
Now, some pundits and vendors can talk all they want about what they believe cloud is and isn’t, but the truth of the matter is that customers are speaking up, especially in the federal government, and they want usage-based charge models. Here’s the rub; many of these users also only want to be the only tenant. Hence, we have customers that want a low-risk, private cloud solutions on one hand and cloud service providers that offer either public usage-based charge models or private temporal-based charge models on the other hand.
The answer to this problem is not a simple one. The reason why these two options exist is to balance the risk. If you want to be the only tenant, then many cloud service providers are willing to share the risk, but want commitments for usage based on time. These contracts are analogous to your mobile phone contracts, where there are fees for early termination. Meanwhile, the cloud service provider can significantly reduce the costs and offer a usage-based charge model if they can share the resources among a wide enough audience such that they are likely to have a very high utilization rate.
However, recently I have learned that there are some companies, such as ESCgov, that are offering up alternative means of acquiring private cloud computing services based on usage. Due to the complexity these alternatives are not one-size-fits-all, but instead, are highly-dependent upon the individual business opportunity. Each opportunity needs to undergo an underwriting process that examines multiple variables, such as expected usage, other existing options for acquisition, and the private cloud architecture. Given that these businesses can qualify that the consumption patterns exist, they will develop custom private cloud services for customers that charge based on usage-based models.
I recently watched a video from Stanford University’s Entrepreneurship program in which the speaker made a very interesting statement, “big problems = big opportunities.” While challenging, answering the call from customers for private cloud pay-for-usage models could lead to the creation of the next Amazon Web Services.
Cloud and Tablets Favor the Content Publisher, LANs and PCs Favor the Content Creator
I recently added a Vizio tablet to my list of technological acquisitions. It’s a relatively good Android-based tablet that is very reasonably priced compared to equivalent functional models. However, I realized today a pattern emerging regarding my usage of the device--I’m more willing to pay for content when using my tablet than I was on when using my PC.
The primary reason for the tablet investment was to gain a hands-on experience with what the future is shaping up to look like. I would not be the first to state that tablets are consumption devices, but what I haven’t seen clearly stated is that the future is rosy for content publishers, such as the music industry, book publishers, magazine publishers and websites. While these devices are nothing more than scaled down operating systems, they are clearly not designed to offer a multi-windowed multi-tasking experience. This means that it’s highly unlikely you will find a burgeoning market for the creation of content, such as movies, music, art, books, and even blogs that run on these devices.
I am not saying some application developers won’t develop tools to support creation in this manner, but I am saying I don’t believe there will be a large audience of users who will be creating content on tablet and mobile platforms. Additionally, as cloud-based services continue to emerge for the storage of tablet and mobile content, such as Amazon’s Cloud Player and Google Music, the barrier for acquiring and loading the content on alternative devices through alternative means increases when compared to the ability to click a button and have it show up on your cloud storage system.
The thought of acquiring a CD, ripping it and then copying the songs onto my phone or ipod is already too burdensome a task compared to clicking one button, running the Amazon MP3 application on my tablet or phone and voila -- my music. Plus, these devices don’t come with typical peripherals needed to perform these operations. The tablets and phones that do have USB ports are for tethering to PCs for maintenance and loading, not extension.
That said, I will never consider writing even a blog entry on that device because I would most likely want to slit my wrists before finishing the first paragraph. Heck, I can’t even stand IM’ing on that device because of the pain of typing on it. Which means that while the future is less rosy for the PC market, there is still going to be a need for power machines to help develop the content that is being consumed by our phones and tablets. It also means that I’m going to want responsive access to the files that I’m working on and most likely will not desire to wait for this data to be transferred over the Internet. So, this data will continue to be stored locally either on the PC or on a local area network, which may or may not be backed up to the cloud.
All-in-all, the tablet and mobile computing market has dramatically shifted the balance of power in favor of the cloud. Indeed, it might be fair to say that it’s these devices that have really breathed life into the need for cloud computing since most users are consumers, not producers, of content. The one gray area of course is social media, which turns all users into content producers, but typically at a level or volume that is achievable on the mobile device specifications and uses alternative input effectively, such as camera and audio. This begs the question, if the PC/LAN era is shrinking due to this fact, can it still be considered commodity or will it become specialized and will equipment for publishers cost more in the future due to less volume?
There Is No ROI in Cloud Computing
Return-on-Investment (ROI), perhaps the biggest crock-of-$%@& metric ever applied to the information technology industry. How does one measure return? If we use monetary return, then the question, “how much money did I make on my investment in a $10K server,” is relatively impossible to answer. One must consider the software run on that server, what role it’s playing in servicing customer value, etc. The answer is arbitrary; it’s a minute subcomponent of a complete capital expenditure plan directed at delivering a business service. Using an intangible metric is even more obtuse. “Gee, after we made that additional $10K investment in that server hardware the number of calls into the help desk seemingly decreased,” is bad Freakonomics at best.
ROI was created by management consultants to illustrate the relationship between investments and expenses on revenue. Then one of these quacks decided, “hey, vendors will love this tool as a means of explaining why IT management has to use their latest doohickey.” ROI is now a plague on the IT industry being used to show how spending more money now will save you money in the long run. To me this is akin to the US government paying citizens to shuck perfectly good working cars that were paid off for new working cars and additional consumer debt.
Okay, I’ll get to the point. Cloud computing is about an effective use of compute resources that provides agility and flexibility to my business in a cost-effective manner. I’m not investing in cloud computing, I’m consuming a service. Do you discuss the ROI on eating at McDonalds or having your car washed? Of course not, because there’s no ROI in using a service since using a service is not an investment. Using services is about effective use of cash flow relative as an alternative to using your own resources and assets.
You may ask, “but I’m investing in acquiring my own cloud computing infrastructure, and I’m expecting an ROI on that.” My answer, if you’re not a cloud service provider, good luck with that. Call the sales representative that sold that bill of goods to you and tell him Christmas gift will be paid for with the ROI on your new cloud infrastructure. I imagine you’ll break even on that investment just in time to need a technology refresh on those blades. If you’re investing in your own cloud infrastructure, I hope it’s because it will effectively allow you to scale certain processes that are not scaling well today and would be cost-ineffective to acquire dedicated hardware to support. Moreover, I would hope this investment is because you have some very rigid requirement that would not allow you to burst to an existing cloud service provider for that additional compute power when required.
Sorry Virginia, there is no ROI in cloud computing. If you want to compute the value of using cash to acquire a service versus doing it in-house, that would be a risk/reward or opportunity cost analysis, not an ROI. The only thing you are investing in with cloud computing is lining your cloud computing service provider’s pockets, which is okay as long as you applied the same resources and assets to an endeavor that will generate more revenue than you are spending on the service.
Defining DevOps
Recently a member of the LinkedIn DevOps group started a discussion entitled, “Concise description of DevOps?” This member’s post focused on clarifying DevOps as a role mainly for the purposes of simplifying his recruiting efforts. The member pointed out that recruiters and vendors are starting to overload the term in an attempt to attract a wider pool of applicants even if the jobs they are recruiting for are primarily operations focused.
Overloading of technical terms in the information technology industry is quite the norm, but it does sometimes play an integral role in confusing technology consumers and delaying progress through failure or mismatches. The more popular a term, the greater it will be co-opted by various factions for their own purposes. DevOps is certainly not escaping this trend.
Another member in the forum responded to the discussion by stating their regret for introducing the concept of DevOps as a role since management immediately saw the role as a consolidation of multiple roles, thus leading to higher productivity for lower costs. After all, if we can get one person to do the work of three that would certainly be a great advantage. Unfortunately, if management really believes this they should be shot for not recognizing the old adage, “if it seems too good to be true, it probably is!” This member is now attempting to undo the damage by redefining DevOps in his organization as a movement.
I’ve provided my own beliefs on what DevOps is here. I would say based on this I am more closely aligned with concept of DevOps as a movement than a role, but then again I am only one opinion amidst thousands. I would say there’s broad agreement that DevOps incorporates collaboration across the various phases of software development lifecycle, which, oddly enough, is not a widely-followed practice in many organizations. The primary cause as I can discern for the lack of collaboration is a belief that the infrastructure should be organized to support the needs of the application. However, with the movement to cloud computing, the need to reduce disparate hardware stacks and lower overhead of managing the data center, all of a sudden, business is starting to see the impact of that decision on the bottom line and reversing this trend. This requires that the application developers and testers understand the limits of the environment in which they will be deploying.
A subset of DevOps professionals also believe that DevOps is the combination of development and operations in a single role. Here, however, the development effort is required for automation of the deployment and management of an operational environment. System administrators have been developing scripts for years to simplify the task of managing and operating an environment and now that effort is being recognized as an important skill. That is, those administrators that can also code scripts are more valuable than those that simply administer through human intervention alone.
In light of this skill, these developers are also now being grouped into the DevOps movement. The only issue with this is that there is no clear delineation between application developers and the operational developers. Perhaps differentiation is unnecessary, except in the case of recruiting since an agile Java developer does not want to waste time interviewing for a position that ends up being Python scripts for deploying machine instances.
One thing is for sure, the DevOps movement is very important to improving the quality and support of applications and infrastructure services. As I stated in my blog entry, “Thar Be Danger in That PaaS” “PaaS, is fraught with pitfalls and dangers that could cause your application to stop running at any point. Moreover, should this occur, the ability to identify and correct the problem may be so far out of your hands that only by spending an inordinate amount of time with your PaaS provider's support personnel could the problem be corrected.” PaaS is one area where support requires the collaborative efforts of a group that has both application and operational experience and can work with each other to uncover problems for their customers.
That said, should you be hiring DevOps? Or should you be seeking System administrators with ability to program automation scripts and software engineers and architects with an understanding of infrastructure architecture?
Thar Be Danger in That PaaS
There's a lot of momentum behind moving to Platform-as-a-Service (PaaS) for delivery of applications on the cloud, but is there enough maturity in PaaS to deploy a mission-critical application? Here's a story regarding one loyalty program provider that offers his customers SaaS solutions. This SaaS provider deployed his platform on a PaaS that offered SQL Server and ASP.NET services. The SaaS has been operating perfectly for months handling the needs of his clientele, but unexplainably stopped working midday on a Saturday—a busy retail time period.
While the PaaS provider supposedly offered 24x7 support, they responded only to the first support ticket with a single response, “we really can't identify problems within your application.” The developers did what they could to discern the problem, but all their research pointed to something changing on the server. Upon hearing this, I had a bevy of thoughts regarding the maturity of PaaS:
1. With IaaS, the customer takes responsibility for maintenance and updates to the server OS, so, hopefully, they test changes before rolling out into production. SaaS providers also could implement changes that could impact their customers, but, again, I would expect that these would be tested before rolling out into production with the ability to rollback should some unforeseen problem arise. However, PaaS providers can make changes to the platform that are all but impossible to test against every customer's application, meaning that changes the PaaS provider rolls out could shut your application down. Moreover, they may not even be aware of all the nuances of a vendor-supplied patch making it very difficult to recover and correct.
2. Out of IaaS, PaaS, & SaaS, the PaaS provider has the greatest likelihood of pointing their finger back at you before pointing at themselves. After all, other customer's applications are up and running, so it must be your application. Hence, a PaaS provider needs to provide much more expensive help desk support than the other two service models in order to be able to ascertain the severity of a problem and get it corrected. Additionally, PaaS providers need to provide more 1-on-1 phone support as these issues are too complex to handle by email and trouble tickets alone.
3. IaaS, PaaS and SaaS each offer less visibility into the internals of the service respectively. However, lack of control over the PaaS means that key settings that may affect the performance of your application may be outside the ability for you to affect. Case in point, the specific problem this loyalty SaaS provider had was that the PaaS was reporting a general error and telling him to make certain changes to his application configuration environment. However, the recommended changes were already implemented and it was seemingly ignored by the platform. At this point, the lack of visibility meant that the PaaS service provider was the only one capable of debugging the problem, even it was the fault of the application, which in this case it was not.
4. Which brings us to the next point, the problem according to the PaaS provider was that an update forced the application to run under an incorrect version of .NET. Even though the developers forced the appropriate version through their control panel once problems started occurring, it seems that the control panel changes didn't actually have any affect. Hence, the customer must have a lot of faith that the tools the PaaS provider offers actually do what they state they are doing and if they don't then the visibility issue in point #3 will once again limit any ability to return to full operating status.
All this leads me to question if PaaS is actually a viable model for businesses to rely on. IaaS gives them complete control, but they will need to learn how to architect for scale. SaaS removes all concern for having to manage the underlying architecture and the SaaS provider will live or die based on their ability to manage the user experience. PaaS, is fraught with pitfalls and dangers that could cause your application to stop running at any point. Moreover, should this occur, the ability to identify and correct the problem may be so far out of your hands that only by spending an inordinate amount of time with your PaaS provider's support personnel could the problem be corrected.
I welcome input from PaaS providers to explain how they overcome these issues and guarantee service levels to their customers, when they cannot guarantee that customer's applications are properly written, that the libraries they use will run as expected in a multi-tenant environment or that a change they make to the platform won't stop already applications from running. Additionally, I'd be interested in hearing answers that equate to PaaS solutions that are more than pre-defined IaaS images, such as CloudFoundry or Azure.
Cloud Enables Big Business to Play Like SMBs
I can store pedabytes of data in the cloud. I can run my E-mail, communications, CRM, HR and Accounting in the cloud. My employees can live and work anywhere in the world thanks to the cloud.
The Internet was the great equalizer. On the Web small businesses and large enterprises were virtually indistinguishable from each other. Businesses with percent of revenue per employee of eighty percent, or greater, emerged overnight. The threat to large enterprises is real as demonstrated by Amazon and EBay, both small Web businesses that emerged to challenge the stronghold in their markets by dominant brick and mortar companies. But in a twist of fate, it is possible that cloud computing could provide the same advantage that Internet once provided Small- and Mid-sized Businesses (SMB) to large enterprises. The only thing standing in the way of large enterprises taking advantage of this opportunity will be the cultural constraints that limit their ability to change and adapt.
When one thinks of big enterprise today, one typically envisions big corporate headquarter buildings, maybe even campuses, thousands of employees, and lots of moving parts. Monolith is the word that I often associate with this image. One thing we’ve learned about monoliths is that they are typically not agile and respond adversely to change. However, just as the Internet emerged as an equalizing force that empowered small businesses to compete head-to-head with these monoliths, and in some cases become one, for big enterprises that can recognize the opportunity, the cloud can become the force that allows them to play at the same high revenue per employee model that is empowering small businesses.
Realize that cloud computing is in its infancy today. The discussions regarding cloud computing revolve around security and availability with large businesses holding fast and tight to the notion that cloud concepts are great, but we need to build and own our cloud computing infrastructure. While true in the near term, this will not be the case three to five years out and the short term thinking leads to continued investment in centralized systems that will continue to need to be refreshed and expanded in an attempt to remain relevant and competitive.
Here’s an example I use in my cloud adoption presentations. Through 2002, most employees accessed their email through a single client application, typically only using the work LAN, and typically during prime working hours, such as 8am to 6pm. With the emergence of the RIM Blackberry, email traffic was doubled as a copy was stored in the email server and sent to the device. In 2011, the same email accounts are now simultaneously accessed over both the corporate WAN and LAN, using multiple devices directly accessing the mail server. The net result is an explosion in network traffic, data duplication, and increased surface area for cyber attack. Moreover, corporate users are now expecting this same level of accessibility for the rest of the applications they use to complete their work. Furthermore, as the generation raised on iPhones, iPads, & iPods enter the workforce, their expectations for speed, accessibility and resource consumption is going to weigh exponentially on the already stressed corporate computing environment.
Technically, these issues can be overcome, but solving the problem technically is not the same thing as embracing the opportunity to change a way of doing business. Realize that SMBs are already embracing cloud out of necessity. They do not have the capital to develop large, centralized data centers and are forced to take advantage of lower cost, more agile solutions. Once again, their limitations may end up being their primary advantage. However, if large enterprises can recognize that cloud computing affords them the same advantages that are afforded to SMBs they will have a significant competitive advantage in the market. This will require that big business loosen the reigns of control over applications and data and allows their users to choose the best tools for delivering the best products and services. Most likely, those choices will lead to cloud-based solutions.
Needless to say, cloud sprawl that might ensue based on this approach is real and needs to be managed. Without going into detail with regard to handling this situation, suffice to say that the big business must implement appropriate governance to manage this situation and to ensure that the data is safe, available and can be shared among various parties within the business. This scenario is manageable and the freedom afforded your staff will mean that they can do more, which should, hopefully, result in greater profit for the same levels of expenditure. Thus, big business will be able to compete on value with SMB while offering greater stability and more service.
Disclaimer
My Most Recent Books
:Other Links
Web Profiles
Recent Posts
- Why Poor Data Classification in Government Will Impact BYOD
- Adventures in Cloudwashing: Are You the Cloud Or in the Cloud?
- Start Building Your Next Generation IT Department Now
- Become the Platform
- Cloud Conundrum: Private Cloud Computing With A Pay-for-Use Model
Tags
Recent Comments
- JP Morgenthal on Adventures in Cloudwashing: Are You the Cloud Or in the Cloud?
- Andi Mann, CA Technologies on Adventures in Cloudwashing: Are You the Cloud Or in the Cloud?
- Cloud, has it arrived? And what does it mean to the physical infrastructure? - Quora on Become the Platform
- Cloud Storage: Where’s the ROI? « Cloud Computing on There Is No ROI in Cloud Computing
- » Cloud Storage: Where’s the ROI? on There Is No ROI in Cloud Computing
Blogroll
Other Links
Archives
- January 2012
- December 2011
- November 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- November 2010
- October 2010
- September 2010
- July 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- March 2009
- February 2009
- January 2009
- September 2008
- August 2008
- May 2008
- December 2007
- November 2006
- April 2005
