Information-OverloadThere is a wealth of information available regarding how to design and build technical architectures but there isn’t a clear view of your organizations infrastructure, risks and operational details and politics. We can talk about the number of servers, network connection to Microsoft if your deploying O365 but at the end of the day the design will depend greatly on your environment from a technical, operating and financial perspective. For a summary of my approach read my Migrating to Office 365 – 12 steps that will help you get there blog which is a summary of my migration framework scars and all.

Let’s dive into these topics further and I’ll recommend some reading for those wanting more information.

  • Financial – First off, what is the operating budget for your environment (e.g. funding for staff, infrastructure and contingency)? Do you own the infrastructure or is it leased (e.g. is it new? Fully depreciated? Lease ending soon)? What funding do you have remaining currently? What have you budgeted for next year? If you can answer the questions, then great and if not I suggest you seek out someone with financial management insight and experience. With financial insight, you can  assemble a meaningful business case for your new environment based current state as a baseline. When selling to the business you can speak to new services, agility, consistency, simplification and mobility (Speaking to enablement, alignment with business roadmaps and ease of use are best). When selling to IT management its generally about cost optimization and risk mitigation (Value add will create road blocks as IT people especially Operations hate change and are usually oblivious to business roadmaps and risk).
  • Operating – What staff and skills do you have? Current workload? Full time vs contractors? Service agreements with venders and service providers? For example, depending on skills and workload you might have to lean on service providers more than usual. If you have outsourcing agreements in place, contractual changes might be required for new infrastructure and staffing for the proposed environment. Another example focuses on your organizations support model and the alignment between the groups such as SharePoint, SQL, Windows, Network and Storage. As organizations grow larger, outsource and pepper in company culture you quickly end up in a politically charged environment full of poorly designed handoff points, nebulous process and policy, finger pointing and management that doesn’t know how to execute or has lost control. For example, in 2010 I managed a large SharePoint environment and most the issues were organizational – people did not work together due to trust issues, IT did not have a solid grasp of their infrastructure – IT was powerless as they didn’t have executive support. Add poorly documented and negotiated outsourcing agreements which ended up paralyzing execution.
  • Technical – There are many variables that will steer your technical architecture such as funding, functional requirements, compliance and audit obligations to name a few. To simplify the discussion let’s assume you have decided on a Hybrid model with SharePoint 201x and O365 (50/50 workload distribution. There are a few key areas I’d suggest focusing on:
    • Data management – using you control plan as a reference, what tools and settings are required to ensure your data will reside in the correct environment and be enforced ongoing. For example, how will O365 Compliance Center be configured, reports required and staffing to operate? How will classification be optimized for user experience? What have past audits recommended? Yes, this is a huge topic, search my blogs for more information as this blog is merely a summary. Read more here
    • Network – what changes are required if any to support the network bandwidth required between your network and the Microsoft O365 data center(s)? Has your network team conducted an analysis? Your network team can run reports on your current SharePoint workloads from a network perspective. If additional bandwidth is required, how will it be funding? Key message, involve your network team and vender in the study and be aware of global implications as some regions have limited bandwidth and latency capabilities. Read more here
    • O365 tenancy – what applications do you require? Features and functionality? Capacity? Microsoft has some excellent documentation on the topics that will help you through the process of answering the questions. Read more here
    • On premise – what do you require on premise? Virtualization options? Server standards? How flexible is the virtualization team? How stable is their environment? How quickly can they respond to capacity and feature add requests? For example, I’ve worked with organizations where the SharePoint team owned the virtualized environment and optimized it for SharePoint and SQL Servers – ran smooth and was optimized. I’ve also worked with organizations where the Virtualized environment was not optimized for SharePoint and SQL workloads, it took 3-4 months to adjust for capacity and feature requirements and the team track record was not so good. Key message, as you look at options know who you are working with, their ability to deliver and reputation for team work. Read more here
    • Tools – You’ll require tools for migration, moving content, enforcing security and data compliance. For example, how will you migrate content to O365? How will you copy content from your on premise 201x environment to O365. How will you meet data backup and restore requirements? Assuming your migrating from 2007 or 2010 you will require a migration tool that that will migrate you to O365 and or 2016. Or maybe you have 2013 and can use DB Attach and then copy to O365 using tools. This all assumes your source environment can be migrated as is and doesn’t require significant remediation due to data policy violation and or technical issues such as exceeding software boundaries (e.g. large lists, site collection size, custom code or third party add-ons). Read more here

Many topics covered in a summary manner, yes it would be nice to have an end to end checklist or best practices but nothing replaces experience. The worst scenarios I’ve witnessed are oblivious management, an inexperienced technical team and project management. It’s not their fault, the executive team has not supported them sufficiently – SharePoint is generally a nice to have and not mission critical so doesn’t get much of their attention until an “Incident occurs”.

In summary, your end state architecture will depend on your information architecture, security and data policy, service levels, services available to you such as virtualization, capacity plan, operational model and deployment scenario. Specifically, whether you plan deploy hybrid or Office 365 only – Read my how to choose blog and SharePoint pro articles on Architecture. Microsoft has much information on this topic so I won’t go into much detail but will say that if you plan to go hybrid, consider SharePoint 2016 as hybrid is greatly improved and user experience more consistent with O365.

Found this blog helpful or have suggestions? Contact me