Avoiding the One-Off: Building Holistically in the AWS Cloud
Oct 19, 2020
There are many cloud-migration scenarios where individual business units and departments are tempted to migrate to the AWS Cloud on their own or build their own solution. Perhaps it’s a university department that has received a large grant, or a business unit within a corporation that suddenly landed a large client. When faced with the sudden need for greater resources, departments and units frequently feel the urge to forge ahead and stand up their own ad hoc systems. Such windfalls, however, become squandered opportunities if the new solution is unable to work with existing systems or further the larger goals of the organization. the pitfalls of this kind of planning – and how to avoid it.
The Danger of One-Off Solutions
The “go it alone” mentality described above can be costly in many ways: whatever is built serves only that unit; the department itself suddenly becomes responsible for compliance, DR, and backups; and the system likely doesn’t talk to the rest of the organization, never mind lacking integration with established systems and the organization’s overall goals. From a staffing perspective, communication and lessons learned about migration are siloed, stymieing organizational improvement. The good intentions of spearhead problem-solving efforts can end up producing a patchwork quilt of various one-offs – not tied together, not aligned with planned organizational mission and, on top of that, now demanding their own maintenance and upkeep requirements.
No one sets out to create an inadequate or even duplicative ad hoc system within an organization. Though well-intentioned, this is all-too-often the result of trying to solve a single problem. How can you instead build holistic solutions that are agile and responsive to scale and shifting requirements? The answer lies in communication and getting stakeholder buy-in, across the organization.
Building Holistically
First, identify a champion within the leadership team – someone who is willing to take up the cause of AWS migration. Make sure that person clearly understands the problem your business unit is trying to solve and how AWS can solve it. Be sure they are willing to support you, and that they can communicate with anyone else who needs to be involved across the organization. This person should also make sure that your solution aligns with overarching business goals.
Second, be sure to include other IT departments in the planning session. Perhaps other units are facing similar problems and have similar needs? Your solution might work for all of them. Or maybe they can identify a problem that will save you time and headaches later on in the process, such as ensuring that your new solution integrates with the online payment system in their own department.
Pulling all of the stakeholders into the planning process will help pave the road for collaboration and satisfaction, moving your organization toward the proactive mind shift we talked about in our earlier blog post. Once everyone is on board, you can move forward with confidence that your solution will add value to the entire organization, and that your solution in the AWS Cloud will be adaptable and scalable as you move forward.
Pulling in shareholders from across the organization is an important step to cloud migration. The natural next step is to think about cost; here, too, there are some common pitfalls. Read our next blog post to learn about how to approach cost conversations: Starting Your AWS Cloud Migration: Moving from Reactive to Proactive
Asim Iqbal
Asim is Enquizit’s CTO and a member of the founding team. He has been an SME on security, storage, and resilience as well as Enquizit’s Lead Architect and VP of Solution Architecture. Among his professional endeavors is the implementation of a weather modeling HPC setup for Environment Canada, storage design and implementation for the Canadian National Institute for the Blind’s library, Media ingestion, encryption, and transcoding architecture for Bell Satellite TV, Cloud infrastructure, resilience, and security architecture and implementation for The Common Application and complete migration of Harvard Business Review’s Primary and DR data center to AWS. He maintains a strong personal interest in frictionless technical designs focused on end-user happiness and employee satisfaction, still thinks that ‘Data Availability Architect’ (from his early days working with HPE) is the coolest certification title ever and is an ex-CISSP. He neither confirms nor denies his purported afflictions with coffee, slow travel, and cats with unbridled spirits.
