Found on the Interweb and too good not to cross-post (Original creator unknown)
Waterfall into sprints
Category: Work
Real-Life tips for Moving Tech from On-Premise to Cloud: Part 2
Welcome back to part two of our real-life series on moving technology from on-premise systems to the cloud. This post follows up on my previous entry, highlighting additional hidden challenges often encountered during cloud migrations. Many of these issues can in recent years, stem from the maturity of cloud infrastructure, which is now complete with its own established processes and methodologies. Let’s get started:
1. Outdated Methods May No Longer Be Supported
One common challenge arises from previously acceptable practices or technologies becoming obsolete, especially concerning security protocols. Methods that evolved naturally over the years in an on-premise environment may now be explicitly disallowed in the cloud. Whether it’s due to new compliance regulations or discovered security vulnerabilities, practices you’ve relied on for decades might no longer be viable.
It’s essential to collaborate proactively with your security team. Security departments often focus strictly on what is disallowed rather than proposing alternative solutions. Engaging them early in the migration process ensures practical and secure solutions are developed, especially when dealing with existing system integrations and established support procedures.
2. Loss of Assumed Features
When operating on-premise servers, many built-in features are taken for granted, such as logging, connectivity, remote access tools, and even physical infrastructure integrations. Virtual servers, Docker instances, or cloud-based platforms often lack these default features, requiring additional setup or third-party solutions.
A notable real-life example includes systems that rely on physical hardware integrations, like emergency pagers plugged directly into servers. Transitioning such setups to the cloud can become complicated and costly, potentially requiring extensive system rewrites or redesigns.
3. Hidden Re-coding Costs
Migrating legacy systems often involves substantial rewriting. In some cases, the original platform or coding language is unsupported in modern cloud environments, necessitating a full rebuild of the application. These hidden recoding costs can escalate quickly, making a simple “lift-and-shift” virtual machine approach sometimes the only feasible short-term option.
4. Bandwidth and Communication Chatter
On-premise systems often generate substantial communication noise, particularly regarding data storage and retrieval. Because bandwidth was essentially free and readily available locally, efficiency wasn’t a priority. However, in cloud environments, such frequent communication can incur significant costs and performance issues.
Evaluate how your existing systems communicate and store data. Modern cloud solutions may require optimised, efficient communication patterns to avoid inflated expenses and ensure long-term sustainability.
5. Day-to-Day Maintenance Costs
On-premise systems often conceal maintenance costs within periodic capital expenditures, typically every three to four years, covering licenses, hardware, and infrastructure. Conversely, cloud environments shift to recurring monthly costs, which can accumulate unexpectedly if not accounted for upfront.
To avoid financial surprises, thoroughly analyse the ongoing costs of cloud infrastructure, licensing, and resources before migrating. Accurate budgeting helps mitigate unexpected expenses and ensures smoother operational planning post-migration.
Summing Up
Sorry to add more items to the problem of moving to the cloud, but these are worth considering when you work out how you will move an older application to an existing and established cloud platform.
Corporate term: “Evergreen Deck”
Definition:
A continually updated presentation slide deck that serves as a single, evolving reference. New slides are added at the beginning, and older slides are progressively moved to an appendix at the end of the presentation.
Explanation:
Unlike traditional slide decks, which are typically versioned, published, and then archived, an evergreen deck is continuously maintained and adjusted. This practice is common in Agile projects or rapidly changing environments, providing an ongoing historical record and enabling easy access to past decisions or discussions.
Disclaimer: As always these posts are not aimed at anyone client or employer and are just my personal observations over a lifetime of dealing with both management and frontline associates.
How to Sort Out and Assign Owners in Large-Scale IT Organizations
Ownership and responsibility can be a never-ending challenge in large IT organisations. In fact, it’s rare to find a corporation that doesn’t struggle with these issues. Many people want the authority and control that come with ownership, but they’re wary of the overhead involved, especially in complex cloud environments. This post explores why ownership can be so complicated and offers strategies for clarifying and streamlining it.
Why Ownership Gets Complicated
The Cloud Factor
When dealing with traditional on-premises systems, like physical servers, switches, and firewalls, it’s relatively straightforward to identify who “owns” each piece of infrastructure. But cloud systems often lack the same physical presence and involve more abstract services. For instance, setting up networks across multiple cloud environments or even inside a single cloud environment can involve numerous layers of security and function-specific configurations. Because these configurations are invisible and frequently shared across teams, pinpointing a single owner can be tricky.
Support Costs and Billing
Support in the cloud world is more expensive and convoluted. If something breaks, it could be failing in one of many places, a network misconfiguration, a permissions issue, an application bug, or a problem with the underlying cloud service. Finding who is accountable can feel like detective work:
- Identify which piece is failing.
- Prove that this failure lies in a particular team’s domain.
- Negotiate any associated costs (e.g., cross-charging or project billing).
Because support often entails additional expenses, teams may not want ownership if it means they’ll be on the hook for increased costs. This can lead to a cycle where no one steps forward to take responsibility, and “the last person who touched it” becomes the de facto owner.
Three Layers of Ownership
In many large organisations, ownership tends to break down into three informal layers:
Official (Paper) Owner
The person who appears on the org chart as the owner. They often have sign-off authority and budget oversight. However, this owner might not be the one who reacts quickly when things go wrong.
Escalation or “Real” Owner
Often a senior architect or hands-on manager who steps in during a crisis. This person makes quick decisions, coordinates teams, and resolves technical or logistical bottlenecks.
Issue Owner or Specialist
The subject matter experts who actually fix problems. They hold deep knowledge of a specific system or process. Everyone goes directly to them for specialised help, sometimes bypassing formal channels to avoid paperwork and costs.
This layering can create confusion. The “paper” owner might not actively manage the system, while the “real” owner and specialists handle the day-to-day issues without official recognition or the resources to do so.
The Impact of Fuzzy Ownership
When ownership is unclear, or people avoid it, multiple problems arise:
- Overburdened Specialists: The same experts get called on repeatedly, leading to burnout and capacity issues.
- Budget Battles: Cost centres fight over who pays for support, making cross-charging and billing an administrative nightmare.
- Slowed Innovation: If key people are always dealing with “firefighting,” they have less time for new projects or strategic initiatives.
- Blame Culture: Support rarely gets recognition for maintaining the status quo, but mistakes draw immediate criticism.
How to Fix Ownership Challenges
Define Clear Boundaries
Document who owns what, especially for cloud services. Even if a service is abstract, outline the specific responsibilities of each team or role. Invite technical architects to clarify details for senior management, ensuring everyone understands the scope of each service.
Establish Transparent Budgets
Make sure that ongoing costs (beyond initial project budgets) are well-defined. If a new service or feature will increase the support burden, communicate this early. Agree on how expenses will be allocated so that nobody is surprised.
Prevent “Sneak-Ins”
Some projects quietly introduce new dependencies, only to leave the supporting team footing the bill. Insist on a formal review whenever something new enters production. Ensure that the project’s budget covers the required support or that the correct owner is identified from the start.
Track and Justify Costs
As environments grow more complex, support will inevitably cost more. Keep detailed records of what each service or system requires to run smoothly. This way, you can demonstrate the value provided and justify budget increases when necessary.
Reward Ownership
People often avoid ownership because support work is undervalued. Leadership should incentivise and recognise the teams or individuals who keep critical services running. Providing career growth opportunities, bonuses, or public praise for effective ownership can shift the culture from blame to appreciation.
Final Thoughts
Ownership in large-scale IT isn’t just about assigning a name on an org chart; it’s about ensuring that the right people have both the responsibility and the resources to manage complex infrastructures. By clarifying boundaries, aligning budgets, and recognising the contributions of those who take on support roles, organisations can foster a culture where ownership is genuinely shared and valued, rather than avoided.
The Hidden Cost of Corporate Silos
Corporate silos 1 can create subtle yet far-reaching problems within large organisations. Often, these departments act with the best intentions, addressing internal problems swiftly and decisively.
However, the insular nature of their approach can inadvertently harm the broader organisation.
Typically, influential departments like Finance, Procurement, or HR may identify an issue they consider critical. Driven by urgency, they set out to resolve it promptly. While they might make a cursory effort to seek feedback from other departments, this feedback is often viewed through a narrow, departmental lens. Because the feedback deals with external concerns, it is frequently misunderstood, undervalued, or dismissed outright.
As a result, these departments implement changes to processes, policies, or procedures, believing they have effectively addressed their issues. Unfortunately, they rarely realise the negative ripple effects their actions can have elsewhere. The cumulative consequences can be severe, ranging from decreased productivity and widespread frustration to a noticeable slowdown in overall business operations.
Ultimately, siloed thinking undermines the very corporation these departments aim to serve. Yet, because their perspective remains internal and insular, they seldom recognise the broader impact of their decisions. It’s the rest of the organisation that bears the brunt of these unintended consequences.
If you find yourself leading a powerful, influential department, take the time to fully consider the broader implications of your actions. Addressing your internal challenges should not come at the expense of organisational health. Remember, the decisions you make today can either uplift or inadvertently burden hundreds of your colleagues tomorrow.
- which are departments or areas operating in isolated, self-contained mental bubbles [↩]