Positioning your company to leverage the new web
Now that some of the dust has settled on Microsoft's vision for the direction of the company and their role to enterprise, it's time to have a serious discussion about positioning your company to be ready for the future. This isn’t a blog on 'future-proofing' your infrastructure, but instead a 'peppers' guide to surviving the web's transition to the cloud.
Many studies have shown that companies will be moving to the cloud eventually. As cloud services like Azure and Amazon Web Services (AWS) become more prolific and competition drives down operating costs, the 'proper' cloud will become more and more dominant as companies try to compete for customers’ attention. This doesn't even begin to discuss the fine tuning of advertising afforded by better compute power on these offerings, which will allow you to pinpoint a person by mining data on the fly and catering an advertising campaign to that specific decision-maker. Services like Azure will inevitably become the standard, so what can you do now to prepare yourself for that future?
Federation & Security
With an increasing focus on security, identity verification and safeguards against felonious activity, it is becoming less likely that your company will operate a proprietary login system within the next 10 years. The National Institute of Standards and Technology (NIST) has been working with the National Security Administration (NSA) for a number of years to develop a federal identification system that works in-silico (in the virtual world) and in the real world in the form of a Personal Identity and Verification Card (PIV Card). There is no date yet as to when these will be adopted as identification cards for your email yet; however, it is good to be aware that this is happening.
Words of the Trade: Security
Authorization: Controls who is allowed to see a resource.
Authentication: A functional check to ensure that this person is who they claim to be.
Identity: The person trying to access resources
Federation (SSO, OAuth etc...): A group of companies that have agreed upon shared log in credentials ( The common login with Facebook or Twitter)
"Principle of Least Privilege:" Allowing a user to only have access to what is required for them.
To prepare your company for the transition, it is wise to start considering security (Authorization, Authentication and Identification) as one place that a little foresight in current development efforts could save massive time in the future. To achieve this you will need to analyze how your company currently handles security.
If you are like most companies, you have a database of usernames, passwords, names, addresses and some internal authorization info. Living in a federated world and having internal subsidiaries or external strategic partners, you have some very careful decisions that need to be planned out against long-term strategic goals.
As an example, let’s say that you work closely with a number of other companies – larger or smaller – that all have an application your organization interacts with, and perhaps vice versa. You most likely have three logins and three passwords or more: one for each company/application. With SSO, you would log onto your corporate network and have access to all three!
If this scares you – and I can hear your reply: "I have sensitive data that they should not be able to access!” – keep calm and continue reading. This is not a world of lessened security, it is actually a world of heightened security. By coming to an agreement on how you will exchange information, you can guarantee that you will immediately see updates from users at external partners (e.g. new address on a W-2 form). This disallows them from adding false (unverified or unreliable) information into their address field in your Database. It also offers a small bonus to the amount of data that you need to store on your database, freeing up your resources for your more business-crucial information. Additionally, if agreed upon, this creates the ability to communicate other information with your partners that speak to the abilities of that particular person.
For example, let’s say that you have a person who is trying to access your company’s newest online offering. With a conventional approach, this person might have to sign up or verify their information before using your application. This is time-consuming and therefore results in a loss of profit. Using a SSO approach, the person can access the application gain access to any application or site to which they are granted permission based on prearranged agreements on level of service. Better yet, it’s all seamless and essentially invisible to that user.
By planning ahead and incorporating your company’s registration system into a unified Identification system, you can start positioning yourself for future growth. It’s much easier to update one identity service than all of your company’s applications.
The new web has more connection, more flexibility and less direct correlation. This pattern has been evolving for roughly 15 years but is now recognized as a substantial player in presenting hurdles that companies face as they move to the cloud.
There may once have been a time when a server or two was enough to support infrastructure needs. However, in the near future you may decide that keeping an IT guy around to maintain your servers is not enough, and you will need two or more to step in and help out. Now you’re in the area where the cost-benefit of these decisions should also be including external hosting options.
It would be reasonable to think, "How does this apply to the 'cloud' discussion?” This, though, actually is the cloud discussion. As you think about the 'proper cloud,' what you're really considering is moving the software that you’re running physically outside of your premises and behind the firewall(s) to a cloud provider like Azure.
If this scares you – and again, I can hear your reply: "I have sensitive algorithms that they should not be able to access!” – keep calm and continue reading.
In reality, there’s no cause for concern; the transition actually adds a level of safety. By placing your production code in the cloud, it becomes a literal moving target. When it was on-premise, it has a fixed IP. If your facility is hit by a tornado, earthquake, hurricane, asteroid... (You get the idea) what will happen to your company’s profits as your servers float away (or melt depending on circumstance)?
The Azure cloud guarantees that natural disasters will not affect your company’s incoming traffic. Additionally, the underlying architecture of the Azure cloud makes it harder (if not nearly impossible) for cyber attackers to disrupt your business. Beyond that, the form of isolation used in an Azure cloud most likely gives your software a more deeply secured firewall(s) to live behind than your IT Guy is capable of. Lastly, WinRT uses a slightly different data paradigm than some are perhaps familiar with. As a result, restructuring the tiers of your application in a manner which is amenable to a Service Oriented Approach will save considerable rewrite time.
SQL on the cloud is basically the same, and a good portion of your existing data approach will migrate readily. However, it’s usually the most crucial parts of one’s approach that inevitably end up being the linchpin of failure when migrating technologies. In this spirit, it is wise to rein in your SQL approach and future development into an approach that’s more in line with SQL Database (the Cloud form of SQL). Things like replication, jobs, CLR-defined types, UDAs/UDTs, Mirroring and Table Partitioning (read more here) are areas in which additional consideration and planning are necessary.
I can see you cringe, thinking: "I have lots of tables and complex schemas that use replication! This could be cost prohibitive!” Keep calm and continue reading.
Microsoft offers SQL Server Data Tools (SSDT) as a free installation to aid you in your efforts. With only a small investment of a database administrator’s (DBA) time, you can get an idea or make a roadmap of what will be required to migrate your data to the cloud. Your DBA may be able to offer insight into how migrating to the cloud could affect your company and if there’s a need to separate your data to host some in the cloud and some locally. Ten minutes of planning saves a day of confusion (see note below).
To the clouds?
Once you have looked into the impacts of the cloud on your security, architecture and data, you will be more prepared for the future. The savings gathered from a simple exercise of road mapping – whether ultimately you decide to go to the cloud or not – will be well worth the time. They may even give you strategic insight to further press your competitive advantage.
Note: The original reference for this phrase could not be found, however it has been said by John Maxwell. Although no references agree as to just how beneficial this type of planning actually is, it is a commonly accepted truth. Here are some alternatives with the same ultimate meaning:
- A little bit of planning saves a whole lot of stress.
- This kind of planning saves a lot of headaches later on.
- Every month of planning saves a month in construction time.
- An ounce of planning saves a pound of cure.
- One minute in planning saves two in execution.
- Invest 15 minutes to save three hours each week!
- One minute can save you seven.
- One hour of planning saves 20 hours of chaotic running about.
- This kind of planning saves you money and helps you achieve your goals.
- Measure twice, cut once.