Much of the conversation in the AI and agentic workflow rollout space is focused on quick enablement and adoption. The principles used for analysis here are fundamentally flawed when applied to regulated industries, government, and high risk spaces.

So today I want to start a series focusing on secure AI rollouts. The goal of this series is to provide you the reader with the necessary information to make the appropriate decisions whether you come from a technical background or not.

A caveat I will state as I start the series, I come from a technical background and much of the content will explore technical themes. I will try to relay the information so that anyone in the space can apply it in their decision making.

Topics

These topics come from conversations with CIOs, clients, friends and a common theme emerged: these are people who tend to have great long term insight but the AI cycle had caught them off guard and concerned.

Some of the topics I’ve wanted to explore in this series include:

• AI Operating models and architecture risks

• Building guardrails in your agentic rollouts

• Managing software supply chain risks in the agentic era

• Re-evaluating cloud architecture for disruptive tech

• Secure edge agents and managing orchestration

• AI Alignment with ESG reporting requirements

• Evaluating AI architecture based on workload risk

The goal of this series is to focus on the alignment between security and engineering needs beyond the traditional GRC focus from cyber experts.

I thought about writing one long piece that would cover all these topics but that could become a book so I decided to do it piecemeal.

Preface to the series

Before diving into the series I think it’s important that we establish a baseline of understanding. Below are some facts from my world view.

1. We’re no where near AGI. The current transformer architecture LLMs are based on aren’t capable of AGI. Agentic workflows are still very useful, but we need to understand their limitations.

2. Nobody knows everything about AI agentic workflows. It’s bleeding edge tech, we all are learning around the same time. Granted there are experts in respective fields, obviously PhDs focusing in this field. From a career of guiding rollouts of emerging tech, it never goes to plan. The point being if I write an article where you may have different insights than those that I considered, let me know - it’s best we all learn together.

It’s time we had a discussion on the risks of software supply chains related to AI adoption. Over the past few weeks there have been several scenarios that should give any Canadian leader in a regulated environment pause and thought on re-evaluating processes.

In February 2026, Anthropic refused the Pentagon’s demand for unrestricted military use of Claude, citing risks around mass surveillance and autonomous weapons. Defense Secretary Pete Hegseth gave CEO Dario Amodei until February 27 to comply. Anthropic held its position. The Trump administration responded by designating Anthropic a supply chain risk and ordering federal agencies to phase out its products within six months. Days later, OpenAI announced its own Pentagon deal.

Proponents of self-governance would rejoice that leaders at Anthropic made the right decision, but for the fact that they went back to negotiations earlier this month. Self governance and values always give way to shareholder, board, and business demands.

Meanwhile, TD Bank rolled out its AI strategy built on Microsoft’s stack. GitHub Copilot for engineering, generative AI assistants across contact centres and branches, and a proprietary model called AI Prism trained on bank datasets. TD’s stated goal is $1 billion in AI-generated value by 2026. The risk with technical supply chains to AI services and offerings is significantly higher than past systems.

These are systems people believe outputs even with hallucinations. And Microsoft itself disclosed that 31 companies across 14 industries had already been targeted through AI recommendation poisoning -- hidden instructions embedded in “Summarize with AI” features that manipulate chatbot memory and bias future outputs. Microsoft identified over 50 unique poisoning prompts over a 60-day window, with off-the-shelf tools making the technique trivially reproducible.

I’ve seen firsthand how these decisions are made in executive meetings, pick the approved vendor and lowest friction path; take their products because adoption will be easier. There’s little chance that TD looked at a product like Cohere that is targeted towards enterprise AI and would reduce the risk of any data sovereignty issues that might arise from Microsoft sending data to US servers.

Finally, Roey Eliyahu, CEO and co-founder of Salt Security, has come out stating the increased risk from orchestration for multi-agent architectures. This includes over-privileged access, integrations to sensitive data, and the increased auditing necessary.

Why It Matters

While these might look like separate incidents from AI governance to procurement, and cybersecurity risks, they share a root cause: AI systems increase technical supply chain risks and businesses need to plan for these.

Anthropic’s refusal looked principled, until you remember it had already signed a $200 million Pentagon contract in July 2025 with only two self-imposed restrictions. The company drew its own red lines, and the moment a government pushed back, the entire relationship collapsed. Self-governance gave Anthropic the right to say no. It also gave the US government the right to blacklist them. Neither outcome produced a stable, trustworthy framework for critical infrastructure.

For Canadian financial institutions, the lesson is direct. TD built its AI ambitions on Microsoft’s platform. OSFI’s Guideline B-13 requires federally regulated institutions to manage technology and cyber risk across their third-party relationships including data residency, supply chain integrity, and operational resilience. Yet the question of where AI-processed data resides, who controls the model logic, and what happens when a US vendor’s political environment shifts remains unanswered in most FI vendor contracts.

The AI recommendation poisoning findings make this worse. If an FI deploys AI summarization tools across wealth management portals or internal knowledge bases, the content those tools ingest at runtime can be weaponized by external actors. OSFI B-13’s third-party risk management requirements should cover this exposure, but most institutions have not yet mapped AI summarization features against their risk frameworks.

In Energy and Transportation sectors where edge IoT devices are common, and AI built products will continue to rollout your operational technology needs to reduce blast radius should a device be compromised.

Additionally, Canadian regulated industries such as banking, transportation, and energy need to view agent orchestration security as a first-order procurement criterion, not an afterthought. The attack surface transferred to the institution through vendor-hosted agent networks is real and often unquantified in contracts.

Canada’s AI governance gap is well documented. AIDA failed to advance. OSFI and the Global Risk Institute formed the Financial Industry Forum on AI, which produced the voluntary EDGE Principles. Voluntary principles without enforcement mechanisms repeat the same pattern the Partnership on AI demonstrated - high-level commitments with no monitoring, no accountability, and members that act against the stated principles when commercial incentives demand it.

What to Do

Start with the EU AI Act risk levels. Canada stalled on AIDA. The EU didn’t. Their risk categorization — from minimal to unacceptable — gives you a working model today. Map your AI supply chain against it honestly. Some vendors you’re currently using for high-risk applications won’t survive that review. That’s the point. Not every AI company is built for the regulatory and accountability demands of critical infrastructure, and finding that out at procurement is far better than finding it out after a breach or a regulatory finding.

Zero Trust is no longer a roadmap item. I’ve watched too many organizations treat Zero Trust as a future-state aspiration while AI deployments are already live in production. That sequencing is backwards and dangerous. Agentic architectures, multi-model systems, and vendor-hosted AI all assume implicit trust that doesn’t exist. Every day you delay is another day your AI stack is running on security assumptions designed for a threat model that no longer applies.

Procurement is your most underused risk lever. The geopolitical environment has changed. What a vendor commits to today can collapse under political or commercial pressure tomorrow — Anthropic proved that in a single news cycle. Your contracts need to reflect that reality: data residency, model governance rights, exit provisions, and explicit clauses covering what happens when a vendor’s operating environment shifts. Business as usual in procurement is not a neutral choice right now. It’s a decision to absorb risk you haven’t priced.

If this raised questions you’re sitting with that’s exactly what we’re here for. Subscribe for analysis every 10 days. No noise, just discernment.

• Connect on LinkedIn: https://www.linkedin.com/in/gurindersmann/

• Work with us: hello@blubyte.io

Every time a Canadian organization uses Microsoft, AWS, or Google turnkey AI services in the cloud for items such as fraud detection, that transaction data could be subpoenaed by US authorities under the Patriot Act. While most CIOs assume that their cloud contract protects them, it simply isn’t the case. In regulated industries such as banking, these aren’t risks that can be ignored.

The unpredictable nature of the US tariffs means Canada has been looking to diversify trade partners. Many of our systems are controlled by the same country economically pressuring us, we can’t continue the pattern with AI rollouts. Now that we’re diversifying our trade partnerships, Canada needs to realize that our tech infrastructure is a national security concern. Media coverage on these risks has been sparse, but these are discussions that need to be happening in board rooms now.

I’ve spent the last 15 years helping organizations adopt US cloud technologies. My experience is exactly why I’m saying it’s time we explored a different path.

How we got here

Planning and maintain your own servers has an overhead, with cloud service providers it became cheaper and easier than building your own data centers. With serverless and similar functionality, time to market for product development reduced significantly.

This can be deceiving. At first it’s cheaper to run serverless when you don’t have many users on the platform, over time the cost of every call adds up. Usage-based billing can bring some unexpected surprises.

The more businesses migrated from Infrastructure-as-a-service to Platform and Software as a service models, those conveniences came with additional risks. Services such as M365 and Google Workspaces have been adopted used almost universally in Canada.

While these services make it easier to adopting services and publish your workloads, there aren’t guarantees for those concerned with data sovereignty. US servers are subject to US law enforcement requests.

AI systems introduce another level of issues.

Concerns with AI adoption

With AI systems specifically the popular LLMs out right now, there’s several concerns:

1. Internal teams adopting 3rd party systems and sharing too much information. In regulated industry such as financial services it’s a nightmare as restricted and confidential data might be accidentally shared. Data lineage also becomes difficult when systems aren’t transparent.

2. The AI systems storing shared information for future training. OpenAI did accidentally leak past queries on google, they were searchable by anyone.

3. Lack of trust from a consumer side as these systems lack transparency and obviously aren’t deterministic in their output.

The difference with AI systems (specifically LLMs) is how people seem to adopt them and what they share. Traditional line of business applications have limited scope. With AI applications, team members can share PII and restricted data.

We should acknowledge that AI systems also have significant influence over shaping individual’s world views. Often time these systems initially replace traditional search, people only understand what the system portrays. It’s not surprising that 53% of consumers distrust AI-powered search results and 70% are concerned AI generated content will be used to deceive them.

These systems will share insights based on the biases introduced in training and we need to acknowledge that. It’s imperative that we understand the geopolitical goals across the globe, what’s working and what isn’t.

Current AI Geopolitics

US is pursuing the LLM rollout as the race to the moon, the goal is for the winner to take all the users, their data and becomes the defacto AGI solution. OpenAI, Google, and Anthropic are in a $100B capital race. The business model is to get users dependent on their system, then increase prices once switching costs are high. It’s the cloud & streaming playbook repeated.

Concerning is the fact that the US has laissez-faire attitude towards regulation. There’s little incentive to change as AI stocks dominate the US stock markets. In fact the Magnificent 7 stocks which are all related to AI, represented 84% and 73% of S&P 500s total return in 2023 and 2024 respectively. Keep in mind, these companies AI products have yet to make a sustainable operating cash flow.

These solutions are decidedly not open-sourced, because the goal is control and power over users. Side note: it’s funny how US LLM leaders are asking for regulation, so that when the crash happens they can blame someone else.

China has taken a very different approach, they are approaching LLMs with a manufacturing lens. It means a lot of models of different sizes, price points, and prepared for specific use cases. These models are often a better value than what the US has to offer. It’s also why they seem to be far more aggressive with open-source, granted they aren’t not fully open weights but tend to be in the right direction.

While China’s approach is strategically smarter than the US winner-take-all race, it does need to be addressed these models are subject to CCP content restrictions. If we are looking towards a world where middle powers work together, having a single entity whether American or Chinese determining the reasonable responses doesn’t work.

The EU focus has been on ethical adoption and introducing regulations that minimize risk while enabling innovation. EU’s AI Act classifies systems into 4 categories of risk: minimal, limited, high risk, and unacceptable. Examples of unacceptable risks would include predictive policing, social scoring, and realtime facial recognition in public spaces as these systems might have undue biases. High Risk applications include but aren’t limited to autonomous vehicles, law enforcement, etc.

High Risk systems require auditability, conformity, accountability, pre-market and post-market or once deployed monitoring. These rules apply to developers or providers, deployers of the system, and distributors. In order not to stifle innovation, EU has adopted a sandboxed approach to rollouts where both regulators and providers/deployers can work together to move projects forward.

It should be noted while the AIDA act in Canada did not get passed last year, it is expected to return and will likely align with EU AI Act risk profiles and some form of sandboxing.

Canada has two primary approaches to AI adoption: CIFAR focusing on policy and strategy, and a supercluster ScaleAI with a focus on adoption and commercialization of AI across Canadian supply chains and value chains. So what have we Canadians got for our approximately $340 million investment? It’s really the last 2 years where vast majority projects have been greenlit.

The criticism remains with superclusters is the focus isn’t to own data and IP, rather those get farmed out to large tech businesses with the goal increasing adoption. Strategic IP exits the country because ecosystem of opportunities is better in the south. On top of that these clusters are regionally focus, which means regional politics plays a bigger part than the importance of a national rollout.

We need to focus on developing strategic IP within Canada, and ensuring that the right data means it stays here. The dependency on US AI systems by Canadian enterprises is significant, we’re not adopting homegrown options. Let’s explore why we should be concerned about US dependency.

Canadian dependence on US AI

In terms of AI, it isn’t just shadow IT that you need to be concerned about. Even security solutions such as Microsoft Sentinel have AI services that can’t guarantee that your data wouldn’t be housed in US, in which case US Cloud and Patriot Act apply. For Canadian critical infrastructure such as finance and energy, this is a non-starter. OSFI B-10 cyber risks for federally regulated financial institutions has guidelines on tech and cyber risks which these solutions don’t meet.

US trained systems won’t align with Canadian values, in fact they will be projecting American priorities globally. It starts to make sense why China has built an ecosystem that can compete and offer services to their citizens.

Additionally, when US companies control the AI models your team uses, they control what answers get prioritized, what data gets collected, and who can access it. We have a competitive intelligence problem.

The fact that we have an ongoing trade war, and are now competing in several industries with the Americans globally means we need to have ownership on our systems. ScaleAI was supposed to help us here, but there mandate is incomplete.

How Canada’s approach needs to change

There’s also a gap in the market with current AI solutions being rolled out - security and privacy are byproducts not designed, local values and voices are subdued for those with global footprint.

I believe there’s an opportunity to create something unique that embodies the best of China’s and EU’s AI approaches. Canada should borrow China’s model diversity strategy (many specialized models vs. one AGI) and EU’s risk-based regulation (strict rules for high-stakes, freedom for experimentation). We should double on our Canadian advantage, abundant clean energy for training. The pitch is simple Sustainable AI with lower carbon footprint and democratic governance.

ScaleAI’s focus on commercialization more than driving innovation needs to change. The focus needs to change to meet Canada changing status in the global economy. Innovation doesn’t come for large scale businesses looking to just introduce operational efficiencies.

As training data is the lifeline of any of these systems. I propose we adopt a regional Canadian data center approach, where local values are built from ground up. Scale AI should pivot from helping big companies optimize to building shared infrastructure such as compute clusters, labeled datasets, evaluation frameworks. These would let Canadian startups compete without Silicon Valley funding. Anyone looking to represent Canadian values, would need to adopt our model and input any refinements here. Give access to startups to build tools and services for Canadians on top of this shared data system.

If Canada builds sovereign AI infrastructure that works, we create an export: a playbook for middle powers who want AI independence without choosing between US and Chinese tech. Australia, EU members, and Nordic countries all face the same dilemma.

Canada has a 24 month window before AI infrastructure consolidates around US and Chinese standards.

Here’s what needs to happen now:

1. Mandate data sovereignty for critical infrastructure

2. Redirect supercluster funding to shared compute

3. Fast-track regulatory sandbox for AI testing

The choice isn’t whether to compete - it’s whether to compete on our terms.

What can you do today

I’ve given a lot of food for thought in this article, what can leaders do today?

First of all, petition the government to support development of local infrastructure and data. We have the land, some of the cheapest and green sources of electricity. It is entirely possible to build here and meet the necessary regulations.

For financial services and other heavily regulated industries, adopt the EU AI Act risk identification mechanism internally. Use this when evaluating your AI strategy. It’s worth noting as Canadian businesses if any of your AI system is used in the EU, the AI Act does apply.

Identify which of your applications and workloads are on external systems and what data is being shared. Finally, speed up your internal adoption of Zero Trust Architecture. If your system is built around minimizing your risk footprint, it means when others are stressing about fines and not meeting requirements your systems will already have these features baked in.

We help Canadian organizations build AI strategies that are sovereign, compliant, and future-proof, hello@blubyte.io

Open Banking is accelerating innovation, and three regulatory frameworks that will have significant impacts for Canadian Leaders are EU’s open finance rules, stalled Canadian AI legislation, and US banking AI guidance. Today, let’s explore the implications of these, and how savvy leaders can adapt.

The Details

The EU’s Financial Data Access (FIDA) regulation is moving toward final approval after Council and Parliament reached their positions in late 2024. While negotiations continue and implementation won’t start until 2027-2030, Canadian financial institutions with European exposure need to start planning now. FIDA expands open banking principles beyond payments to cover investments, insurance, pensions, and crypto-assets - creating data-sharing obligations that will affect any Canadian FI with EU customers, partnerships, or cross-border data flows.

Unlike PSD2, which gave non-European institutions time to adapt, FIDA’s requirements around data access, Financial Information Service Providers (FISPs), and machine-readable permissions dashboards are more technically prescriptive. The framework also includes specific provisions restricting “gatekeeper” companies (under the Digital Markets Act) from combining financial data with other data sources - a complexity that affects how Canadian institutions structure their European operations.

Meanwhile, Canada’s Artificial Intelligence and Data Act (AIDA) collapsed when Parliament was prorogued in January 2025, leaving Canadian FIs without federal AI governance requirements. Bill C-27 died before final passage, and while the federal government has signaled intent to revisit AI regulation with a “light, tight, right” approach, there’s no timeline. This creates uncertainty: do Canadian institutions build AI governance frameworks now in anticipation of eventual legislation, or wait?

The key data point for Canadian FI’s is: OSFI hasn’t waited. The regulator’s Guideline E-23 on Model Risk Management (finalized September 2025, effective May 1, 2027) explicitly covers AI/ML models and requires comprehensive governance. Separately, US federal banking regulators - the Fed, OCC, FDIC, CFPB- Issued a joint Request for Information on AI use in financial services back in 2022 and continue to apply existing Model Risk Management (SR 11-7) and Third-Party Risk Management guidance to AI systems. Canadian banks with US operations face these overlapping requirements despite no harmonization between jurisdictions.

The Implications

• Compliance: You’re managing regulatory frameworks that don’t align. FIDA’s data-sharing requirements, OSFI’s E-23 model governance expectations, and US MRM/TPRM guidance all define “adequate AI documentation” differently. A compliant system in one jurisdiction may not satisfy another.

• Engineering: European operations need FIDA-ready data infrastructure (permissions dashboards, access interfaces, Financial Data Sharing Schemes) starting 2027. AI/ML systems need governance documentation that satisfies OSFI’s E-23 by May 2027. US subsidiaries need model validation under SR 11-7. These aren’t the same requirements - you’re building three parallel frameworks.

• Risk Management: The regulatory vacuum in Canada (no AIDA) doesn’t mean no regulation. OSFI’s E-23, international frameworks, and cross-border exposure create obligations anyway. Board-level AI governance committees are becoming standard even without legislative mandate. Executives NEED to get ahead of the curve now before its too late.

• Executives: Canadian open banking and AI targets are insufficient to be leaders on a global scale. We simply cannot lead while being a decade or more behind with regulations such as FIDA leading the way. While Canada is still debating the future of AI legislation, organizations should be looking at self-governance, and if you’re working with EU partners, co-governance with EU applicable rules. It’s time for execs to demand the system modernize and help us innovate.

How to prepare

• Map your cross-border regulatory exposure now. Which jurisdictions do you operate in? Which frameworks apply? FIDA affects you if you have EU customers or partnerships. E-23 affects you if OSFI regulates you. US MRM affects you if you have US operations. Document the overlaps.

• Inventory AI/ML systems against multiple frameworks simultaneously. A model needs to satisfy OSFI’s E-23 validation requirements AND meet US third-party risk management standards if it’s used across borders. Build one documentation that works for all jurisdictions. Don’t build multiple for each

• Monitor EU FIDA negotiations closely. When trilogue concludes (expected late early 2026), implementation timelines will become clear. Canadian FIs with European exposure should have data architecture plans ready before final text publishes.

• Build AI governance assuming eventual Canadian regulation. While AIDA is dead, an adapted version will appear. Institutions that built frameworks anticipating AIDA’s principles (accountability, transparency, bias mitigation) will adapt faster when new legislation arrives.

• Coordinate across compliance, legal, engineering, and risk. Cross-border regulatory complexity breaks siloed approaches. The team managing FIDA compliance needs to talk to the team implementing E-23 - these frameworks intersect at your AI-powered customer data systems.

Who’s already moving

Canada’s Big Six banks treat cross-border AI governance as a unified challenge. RBC and TD built AI governance frameworks that align with OSFI’s E-23, anticipate Canadian AI legislation principles, and satisfy US regulatory expectations simultaneously. Scotiabank’s 2025 AI governance report explicitly maps their controls to multiple jurisdictions.
Mid-tier institutions with primarily Canadian operations are focused on E-23 compliance only. Credit unions assume they’re exempt from international frameworks - many aren’t, particularly those with correspondent banking relationships or third-party service providers that operate cross-border.
European digital banks (N26, Revolut, Wise) expanding into Canada have FIDA readiness built into their architecture already. They’re positioning this as competitive advantage: “Our data infrastructure already meets Europe’s 2027 standards.” and they will surely steal some of the market from Canadian institutions - especially the ones who are unprepared

How you need to adapt

Many of these frameworks were written in isolation and won’t be enforced in coordination. FIDA focuses on consumer data access and portability. OSFI’s E-23 focuses on model risk management and validation. They all touch AI/ML systems that handle financial data, but from completely different angles.

A Canadian bank with European customers could build an AI credit decisioning model that:

• Satisfies OSFI’s E-23 validation and monitoring requirements

• Fails FIDA’s data access and permissions dashboard requirements

• Still faces uncertainty about future Canadian AI legislation

Building the right enterprise architecture will allow Canadian businesses to adapt and compete. If I were an executive today navigating digital transformation, I would seriously be considering the requirements coming from FIDA. If not your competitors from EU will adapt faster to changing market needs.

EU’s FIDA is building an Apple Store in the financial space, and Canadian leaders need to plan for it now. The app store monopolized the mobile market for decades and made it hard to compete, and those that do not adopt FIDA principles will not be able to compete in this new market.

What we’re watching

• FIDA trilogue conclusion: EU Council and Parliament negotiations expected to finalize in late 2025 or early 2026. When final text publishes, implementation timelines for different data types (24-48 months) will trigger. Canadian FIs need plans ready.

• Canadian AI legislation reboot: Minister Evan Solomon confirmed in June 2025 that AIDA won’t return in its original form. What replaces it matters. Watch for federal signals on “light, tight, right” AI regulation - this will set the framework Canadian institutions build toward.

• OSFI’s E-23 supplementary guidance: The regulator may issue additional material clarifying AI/ML model governance expectations before the May 2027 deadline. If it comes, it’s critical. If it doesn’t, institutions are interpreting complex requirements without official guidance.

• US regulatory coordination: Fed, OCC, FDIC, and CFPB have been studying AI in financial services since their 2021 RFI. Watch for updated joint guidance that harmonizes model risk and third-party risk expectations for AI systems. Canadian banks with US operations need alignment.

• Cross-border data transfer frameworks: How FIDA interacts with GDPR, and how both interact with Canadian privacy law (PIPEDA, Quebec’s Law 25) will determine data architecture requirements for cross-border operations. EU-Canada adequacy decisions matter.

BluByte Technology
Discerned Intelligence you can act on
Comment with your biggest AIDA concerns, we’re interested to hear from leaders

About Intercepts: Fast intelligence for practitioners who can’t afford to be six months behind. Published monthly. Zero marketing, pure signal.

Additional Reading

• EU FIDA Regulation Update – Taylor Wessing - July 2025 analysis of trilogue progress and implementation timelines

• EUR-Lex Official FIDA Proposal - Official EU legislative text and documentation

• Guideline E-23 – Model Risk Management (2027) - Office of the Superintendent of Financial Institutions) - Canadian AI/ML governance requirements, effective May 2027

• Bill C-27: The Future of Canadian Privacy Law – CookieScript - September 2025 analysis of AIDA collapse and what comes next

• Federal Register: RFI on AI in Financial Services - US Treasury June 2024 request for information on AI use

• Navigating Artificial Intelligence in Banking – Bank Policy Institute - April 2024 analysis of US regulatory framework for AI in banking

EDITOR’S NOTE
This is our first Intercept.
The goal: give you intelligence you can act on this week, not file away for later. If something here changed your plans or made you flag something internally, we’d like to hear about it.
If it didn’t - tell us what would have.

Real-time Rail (RTR) is about to transform the Canadian payments system by 2026, transforming the way we bank. It will facilitate instant money transfers enabling real-time payment processing making transactions faster, and more efficient.

For innovators it will open new opportunities, allowing fintech companies to develop cutting-edge solutions and services that leverage real-time payments. Incumbents, such as traditional banks and credit unions, will need to modernize their digital footprint to meet customer expectations in this era.

If we look across the Atlantic in Europe where real-time systems are present, younger & tech-savvy customers are gravitating towards digital banking and fintechs, where 35% of primary clients for digital banks are under 35, and over half (55%) are under 45 according to Kearney consultancy. We also see a trend with those that are on these platforms keep 80% to 100% of their finances at these institutions.

If we look at day-to-day banking needs where neobanks and fintechs seem to focus heavily, it accounts for up to 49% of a Bank's revenue (source: McKinsey). Tie that to the fact that the price-to-book ratio for banks globally is 0.9, meaning that markets don't believe banks are generating enough value.

What is RTR and why you should care

RTR is an effort to modernize the national Canadian payment system and is governed under the Canadian Payments Act. Imagine not having to wait several days for payments to go through, for small businesses this could reduce significant overhead for payroll. Perhaps a startup has just secured funds, well those funds would get to them faster than previously. Cash flow management can be just-in-time (borrowing from lean here) improving liquidity.

It's none too soon either, other countries such as UK, Australia, US, and broadly EU countries have similar systems implemented. For Canadian businesses to remain competitive in a global market it becomes a necessity to modernize.

As part of the modernization the underlying infrastructure that powers payments must be upgraded, as it's decades old banking systems. RTR includes components for

• real-time exchange, clearing and settlement including for 3rd party exchanges

• centralized fraud system

• Comprehensive by-laws, rules and standards

RTR is adopting the ISO 20022 messaging standard and that improves the data richness allowing for automated reconciliation. One could, for instance, include pay stub information within the payments now.

Opportunities for Fintechs

Why have I stated this as a benefit for fintech organizations? First, Payments Canada has opened the network for direct participation from Fintechs and Payment Service Providers (PSPs). Many may no longer need to coordinate with a partner bank for the payment component, arguably a prerequisite for open banking.

Fintechs don't have the technical debt that traditional banks have and have lower operating costs as physical presence is less of a concern. The core heart of these systems tends to be the underlying technology that enables these systems. It means these systems are built around integration from the start, they're using modern technology and processes.

Risks for traditional FIs

Banks and credit unions have issues related to long-term technical debt, meaning any realistic transition requires significant effort. There are opportunities to capitalize but given the mid-market is busy with M&A and consolidation of tech stacks, room for innovation is limited.

It's time the investment in architecture, infrastructure, and security matching current requirements or these businesses risk losing to nimbler organizations. A significant portion of the risk lies building capability and resourcing in house, often employees aren't trained on modern tooling and processes which can impede any initiatives in these areas. Even trying to capitalize on partnerships will require modern infrastructure and cybersecurity practices.

While they are still full-service institutions, losing a large chunk of day-to-day banking will mean customers will look for alternative means to their needs.

Planning your rollout

Far too often organizations misalign when planning rollouts. The vision needs to unite business units and emphasize the importance of the new digital model, capabilities means including time for upskilling and supporting teams during the transition phases, and finally systems/tools to adapt to these new workflows.

Cybersecurity becomes a bigger concern

In 2008, when UK launched its real-time payments systems, online banking fraud rose by 132% (source: EY), the landscape has since changed considerably. It's one of the reasons we see an emphasis on central fraud system from Payments Canada.

From an organizational perspective, these kinds of requirements highlight why it's important to move towards automation and industry best practices such as shifting left or simply put catching problems earlier in the development lifecycle. It can be up to 100x cheaper to find these issues earlier, where something that could have been $100 to fix during development can cost $10,000 in production.

Another recommendation for focusing maturity would be looking across 5 pillars for security: identity, devices, network segmentation, applications and workloads, and data. Integrating these into your workflow you will want to:

• Verify explicitly using identity, device, location, behavioural analytics

• Provide least privilege access so that user's only have what's necessary to do their job

• Assume breach and minimize the footprint within your network

• Continuous monitoring and analytics to be able to respond to any threats quickly.

Planning Ahead

Real-time Rail (RTR) represents a significant advancement in the Canadian payments system, bringing about faster and more efficient transactions. It offers numerous opportunities for fintech companies to innovate and thrive, while posing considerable challenges for traditional banks and credit unions to modernize their infrastructure and security measures.

As the rollout of RTR progresses, it is essential for organizations to align their vision, upskill their teams, and adopt modern tools and workflows to remain competitive. Cybersecurity will play a critical role in this transformation, highlighting the importance of robust practices and continuous monitoring. Embracing these changes will be key to future-proofing the Canadian financial landscape and meeting evolving customer expectations.

Below is the commitment made by BC on sectors that need to be established for our 2030 goals. Notice how Personal Travel is second to green electricity.

The issue is Personal Travel seems to focus on primarily electrification and Zero Emission Vehicles (ZEV). We have a unique opportunity to become a leader in MaaS, reinventing the traditional travel model to meet modern needs. Imagine a future where reaching your destination is seamless, sustainable, and smart, regardless of the mode of transportation.

It's time we created a homegrown industry to reimagine Uber model. Uber sparked a transportation revolution but didn't fully realize its potential, stopping at car rides. Now, it's time to move beyond and imagine a comprehensive MaaS system that prioritizes sustainability and efficiency. Let's explore this exciting vision for the future of green transportation in BC and beyond.

How BC is positioned to dominate MaaS

Canadian government has made large green energy commitments, and BC has close to 100% of our energy from hydro power. I think there's an opportunity to invest in alternative green energy sources; arguably we could sell a green energy blueprint to other provinces that are heavily traditional energy and resource dependent (looking at you Alberta) - but that's a topic for another discussion.

Personal Travel is an issue that needs to be resolved within BC, as housing prices in core urban areas are some of the most expensive in North America. It translates to population needing to move to peri-urban areas, where they are further away yet close enough to be in the city.

We can see this in the numbers, the population in BC is about 60/40% for urban vs rural respectively, and since 2010s rural growth has started to increase. Tied to that we have several benefits in this province that make rural growth necessary - access to ports (Asia Pacific Trade), access to lots of land, some of the cheapest electricity it means we would be great for data centers. But none of this is possible without easy access to more urban areas.

Source: https://www150.statcan.gc.ca/n1/pub/71-607-x/71-607-x2021030-eng.htm

While BC’s landscape is stunning, it's complex to serve with traditional transit. Outside the dense Metro Vancouver and Victoria areas, communities are often separated by mountains or water. Coastal communities like the Sunshine Coast or Gulf Islands rely on ferries as lifelines – there are no road or rail links. Interior towns can be hours apart along winding highways. This geography leads to heavy personal vehicle use; rural and remote residents often have no alternative but to drive long distances. Even within urban regions, natural barriers (like Vancouver’s surrounding ocean and inlet) concentrate traffic onto a few bridges and create congestion.

Green transportation is a problem we need to solve. It's not a problem that's unique to BC, and by solving the problem we can export the solution globally. Our ZEV targets align with California but imagine selling our homegrown solution there to the 5th largest economy in the world. They have many of the same problems and our geography means we need to solve those problems anyways which would translate to an easier adoption.

BC also happens to be a leader in the cleantech industry. According to Cleantech Group, we have 7 of the top 100 global cleantech companies here in BC, so going green is in our backyard. Our hardware and engineering R&D has always been strong, but BC has not leveraged the raw software engineering talent here that could be put to focus on a software solution tying many of these solutions together.

Why MaaS is the solution

If you're living within a peri-urban region, the primary option for transportation is vehicle based. I would know - over covid I moved out of the city and was forced to purchase an additional vehicle as it was the most reasonable option.

So, what would it take for someone like me to adopt a MaaS solution?

1. A single cohesive app - while TransLink has begun work in this space, it has a limited radius and doesn't service peri-urban areas well. For instance, I need to take a ferry but that's not included within the current app. Car-sharing & bike sharing services are similarly limited.

2. First/Last-mile solutions - The trickiest part for me is getting to and from ferries, any solution needs to address this. Partnering with private micro-mobility services such as e-bikes and e-scooters along with public transportation services would provide excellent coverage. Additionally, the service should cater to ride pooling to calculate and make the process similar. If many people are travelling to a common destination such as downtown Vancouver, they should be able to coordinate via the app.

3. Unified payment and green incentives - Having a single point for payment & rewards could align all transportation mechanisms to reward sustainable choices.

I love to drive as a hobby, but for a commute to work it becomes a chore. When travelling for work, I prefer modes of transportation that allow me to focus with peace of mind and no added stress. It's often why I use train transportation in Europe, it's wonderful I can work and not have to worry about traffic.

The vision of a MaaS service is to unite remote communities with urban centers allowing for the greenest possible modes of transportation. We need to provide people with multiple options for transportation, uniting public and private services, and rewarding people for selecting sustainable options. These are problems that need to be solved globally and we could be the test bed to validate it. A key benefit of this would be to allow private corporations to sell such services globally thus creating a model that would help BC tackle it's deficit issues.

Where Government support is needed

Policies and regulations could support establishing this industry by providing a framework that encourages innovation and integration. We need policies to align consumer behavior with sustainability goals, incentivizing greener choices and supporting the growth of the green transportation industry. A few areas to consider

• Integration and Data-Sharing: We need to mandate open data standards focusing on interoperability providing real-time information for decision making and encourage integration of these into all services. For instance, transit, ferry, and private mobility services each have separate payment systems and data silos.

• Focus on established cybersecurity standards for critical infrastructure: With nation state actors trying to disrupt other Canadian critical infrastructure services, it's not a far throw to imagine what open data opportunities would enable for hackers. Any services adopting these standards need to have sufficient cybersecurity.

• Rural and Inter-city Service: Current regulations and funding do little to ensure connectivity for rural areas. When Greyhound and other private coaches pulled out, no strong policy response filled the void, leaving fragmented regional services. A regulatory strategy (and funding) to support inter-city bus or rail as an essential service is lacking. The forthcoming federal Rural Transit Solutions Fund is a start, but without sustained support or coordination, rural Canadians remain car dependent.

• Implement Smart Pricing Mechanisms: To align behavior with sustainability, introduce pricing reforms. For instance, allowing municipalities to implement congestion charges or tolls in downtowns (with revenue recycled into transit improvements); encourage usage-based car insurance and parking pricing. What would help even more would be standardizing mechanisms to how pricing between public & private services be aligned, as a user you only must worry about a single price in the app, and it would divvy out payments.

Innovation and Technology

Technology is the glue that will enable these services and arguably spawn a new industry. Vancouver's TransLink RideLink is a great start but doesn't get us far enough. Let's explore a few technologies that could support this vision, where it's already adopted, and how they might transform the transportation experience.

• Artificial Intelligence: These days everybody seems to be mistaking LLMs for AI, there are lot more interesting use cases. We could apply dynamic decision making in traffic optimization moving towards smart traffic management and connected vehicles. Montreal is rolling out such a system to adjust traffic lights based on incidents, feeds, and sensor data. The goal here being to optimize traffic flow. These should be integrated with other core services; imagine reducing the risk for ambulances in emergency situations by adjusting traffic patterns. We could also use AI chatbots to plan routes based on commuter preferences.

• Digital Twins: using IoT sensors to monitor conditions in real time and simulate potential scenarios optimizing for sustainability targets. This could help with congestion management and providing alternative plans. It could even help build the case for additional infrastructure. YVR has adopted this type of system precisely for these use cases.

• Design for integration: The last piece is less of a technology but a design element, this type of system needs to be designed to allow 3rd party private transportation providers to coordinate and that's a big lift. The benefit would be integration with smart traffic management with public services such as buses, trains, ferries to micro mobility solutions to private services including Uber drivers, taxis, etc.

BC has an opportunity to build the Uber of tomorrow, that combines commuter's needs, municipal requirements, and builds towards a greener future. Now is the time to capitalize on it.

Why This Matters

• Canadian banks, insurance firms, and fintech companies routinely reference the CVE database to identify and patch vulnerabilities, guiding security investments and assessments.

• OSFI's cybersecurity regulations expect proactive vulnerability management aligned with recognized standards—often implicitly relying on stable CVE frameworks.

• The lapse in funding means delays in vulnerability disclosure, slower patches, and increased cybersecurity blind spots in Canada.

• CVE underpins many security programs and tools including MITRE, NIST, and is a dependency for Japanese and European Vulnerabilities Databases.

• Canadian cybersecurity programs (Western world for the most part) are heavily interlinked with US systems and that creates a strategic risk.

When your risk database is someone else’s budget item

The Bank of Canada has listed cyber risks as the number 2 risk for Canadian financial institutions, ironically right behind trade war. Traditionally, the US has been the leader for cyber programs, and we adopt many of their recommendations. From vulnerability databases to frameworks for implementations such as Zero Trust to security tooling. With the current US government's erratic approach to cutting funding for programs, it does raise a risk to any entities that are adopting these going forward.

The immediate impact felt through Canadian financial institutions would include:

• Financial Standards (OSFI, PCI DSS) - OSFI's B-13 guideline requires financial institutions to regularly scan, identify, and rank vulnerabilities. A standard such as CVE/NVD both of which are American are used as reputable sources. These assume that up-to-date information is available, which could have been risked in this case.

• Critical Infrastructure - The financial sector is considered one of the critical infrastructure sectors within Canada. But even national databases and advisories are based on CVE. Protecting our critical infrastructure means we need alternative plans.

• International Standard - many of other international vulnerability standards including European and Japanese are also impacted by CVEs.

This all equates to potentially slower patch updates, less reliable vulnerability intelligence, and increased cybersecurity uncertainty. This is precisely why Canadian Financial Institutions cannot rely on funding from US entities and need to explore alternatives.

Increased exposure during geopolitical tensions

In times of geopolitical tension, the cybersecurity landscape becomes even more precarious. The lapse in funding for critical databases like the CVE program coincides with an era of heightened cyber threats from nation-state actors such as China, Russia, and Iran. These actors are known for their sophisticated cyber tactics and persistent targeting of critical infrastructure, including financial institutions.

Canadian financial institutions would be vulnerable without timely updates and disclosures from the CVE program which could lead to increased susceptibility to exploitation. With delayed patches and less reliable vulnerability intelligence, these institutions face a higher risk of cyber attacks that could disrupt operations and compromise sensitive data.

During geopolitical tensions, the risk of cyber espionage and attacks escalates. Nation-state actors often exploit vulnerabilities to gain strategic advantages and disrupt critical infrastructure. For Canadian banks and financial institutions, this means a potential increase in cyber incidents that could have far-reaching consequences for the economy and national security.

Exploring alternatives to CVE

I've mentioned throughout the article that CVEs are linchpin to cyber initiatives across Western countries. So, what alternatives do we have today? In the short term, funding issues were resolved, that means access to timely cyber information still is available.

For the long run, the best option would be to look at alternative funding models for the program which benefits multiple countries, critical infrastructure sectors, security tool vendors, in fact the entire industry. In fact, the CVE foundation has begun to explore alternatives such as diversified funding and endowment funds. I would argue all member states of five eyes should be contributing to the foundation, and arguably it doesn't need to reside within a single country. That way should the focus of a single country shift towards domestic focus, it doesn't affect all other countries. Canada's policy should focus on increasing our resiliency and building a stronger say in the global economy.

Canadian financial institutions must develop fallback plans that ensure continuity and resilience in the face of cybersecurity challenges. This includes exploring alternative sources of vulnerability intelligence, investing in independent cybersecurity frameworks, and strengthening partnerships with international allies to share insights and resources. It's time to leverage our partners to increase visibility into potential cyber risks.

As the Canadian election draws near, I wanted to dive into what Mark Carney's promise of a Canadian trade corridor would mean for digital innovation and financial services. Countries with similarly remote communities, such as Australia, India, and Kenya, have modernized their digital infrastructures, leading to significant adoption of digital banking—89% and 78% of users respectively by 2021, and in Kenya's case, an 83% increase in digital financial services by 2019.

These advancements translate to real economic value. McKinsey Digital estimated that the core digital sectors in India could double their GDP this year, reaching between $355 to $435 billion. However, such impressive numbers don't come about by chance; they require cooperation between the public and private sectors to develop innovative platforms that benefit citizens.

Today, I want to explore digital innovation opportunities specifically for Credit Unions.

Rural Opportunities

According to Stats Canada (2021), approximately 30% of Canada's GDP comes from rural communities, there is commitment & focus to grow the GDP in these areas. The country's investment through the Universal Broadband Fund aims to enhance high-speed internet access and cellular signals, which will make access to digital systems easier. The corridor will focus on these areas, and they will benefit unequivocally.

Looking at the countries I mentioned above, simply providing access to high-speed internet and cell services is insufficient. There's an opportunity to partner with public sector to push innovative collaboration.

Credit unions have been pursuing mergers to hedge growth and reduce risk; the focus needs to shift to providing modern digital infrastructure which would allow key industries to collaborate on a trade corridor. Canadians as a whole have strong trust in digital services, Credit unions services are significantly behind their counterparts; even with mergers, consolidation of IT isn't enough to provide modern services.

Fintech Collaboration

While it will allow other financial institutions, particularly fintech easier access to these communities, looking at the data credit unions are still imperative. Seniors still have a strong need for physical presence of branches as there is more trust but make no mistake, the trend is toward digital services, and physical footprint alone isn't enough.

Banks are limiting risk by collaborating with fintech businesses, and once they prove their value they are acquired. While credit unions have regulatory requirements for limiting risk and cannot make the same types of plays as banks - there is opportunity for collaboration between credit unions and fintechs that adhere to regulatory requirements. For fintechs that adhere to regulatory requirements, many of them are dependent on other financial institutions for those services which provides a mechanism to integrate as they will have similar underlying tech.

This would require having an architecture that is able to integrate new services quickly. Cloud providers such as Azure can speed time to market with PaaS offerings and building internal architecture to focus on API based services.

As part of this modernization the capability of internal teams needs to be augmented. Fintech tends to hire industry veterans, developers that are the best in their field. While credit unions don't have the same IT budgets, technology is a team support - you can choose to play "Moneyball" (it's a movie worth watching) to build a team that is greater than the sum of its parts and can support modernization efforts.

Opening up collaboration between credit unions

In terms of collaboration between credit unions, most have their tech outsourced heavily. So much so that there are guidelines on risk management associated with outsourcing from OSFI. It means most credit unions are using a handful of systems such as veripark, ebankit, etc. This is an opportunity to build synergies that haven't previously existed.

With inter-provincial mergers going forward, it's easy to see that the financial space is changing. Credit unions looking to support a trade corridor need to be able to support businesses that will be working along these. That means having systems that can communicate across provincial boundaries.

Let's explore some of the benefits of collaborations beyond mergers.

• Reduce the cost & risk of innovation - We didn't land on the moon in the first go; there were several failed attempts. Fundamental shifts mean big impacts and these have risks. Collaborating to provide services that are traditionally strengths for credit unions such as local community presence while building a digital footprint

• Competing in a changing market - let's face it, a strong digital footprint is necessary for continued growth of credit unions. Rather than compete internally, they should collaborate to compete with larger market forces. The Big Banks have massive budgets and still control roughly 80% of the market, on the other side of the spectrum you have fintech businesses that often go around regulatory requirements - both groups are squeezing in on territory that would traditionally be credit unions. Combining forces to provide a unified digital experience would create a more equal playing field.

Green Investments

Canada has room to improve in green investments specifically for e-waste. Credit Unions are about local investments, e-waste becomes imperative to manage. Additionally, in our back yard Canada has some of the largest Cleantech innovations happening and the room for investments is massive.

Investing in local e-waste removal systems would be unique to credit unions and an area (particularly sustainability related initiatives) where traditional banks have minimal footprint. In fact, banks such as RBC focus on oil & gas energy businesses.

Tying the need for green investments into the local economy and showing the value added via digital means would increase consumer confidence in the unique value of credit unions. A few projects that come to mind:

• We have some of the cheapest & green electricity in the world, large rural areas for data center investments.

• Investing in green transportation such as ferries and tying those to smart cities are necessary investments and areas where credit unions could differentiate themselves while sticking to community benefit leaders.

Need for tech

All of these solutions require strong digital systems. I, as someone working with credit unions, wasn't aware of their unique value until I got involved and I suspect most people are in that category. It means being able to show members your value in a real-time digital format. If you can prove to consumers where your investments are going, trust will grow and it will fuel membership growth.

Investing in technology to keep the lights on will no longer be sufficient, and those that do will not succeed in the long run.

The technology world doesn't just evolve—it gets violently reshaped by forces most leaders never see coming. Right now, a seismic disruption is happening through US tariffs that's sending shockwaves through Canada's tech ecosystem. While markets fluctuate and analysts' debate, it's imperative we recognize the difference between temporary noise and fundamental shifts.

This isn't just another trade spat—it's a radical redistribution of the playing field that will separate visionary Canadian tech leaders from those who'll be telling stories about what could have been. The question isn't whether to wait it out or shift course—it's whether you're brave enough to see the landscape for what it truly is.

Key Stats

Canada and US have traditionally enjoyed a strong trading relationship, our economies are intertwined in many ways. To understand the amount of trade below are statistics on trading Canadian government.

• Daily US-Canada goods & services trade US$2.5 billion (two-way)

• US trade surplus with Canada (manufacturing) = US$33 billion

• Canada’s rank as #1 US export market (larger than China, Japan, UK, France combined)

• 46 US states where Canada is a top-3 export market, 36 states rank Canada #1

We heavily rely on US tech services for all kinds of enterprise needs from cloud services to cybersecurity vendors. A seismic shift in the relationship between US and Canada means we need to understand the implications to businesses, our economy, long-term effects should this escalate, and de-risk our position - which as we've seen is leading to new partnerships with other countries.

Implications of Tariffs

The US has shifted towards a protectionist economy, and we aren't seeing a coherent trading policy. The uncertainty surrounding these tariffs is detrimental to business, and the rapid introduction of these tariffs poses significant risks. From a tech perspective, US tech companies dominate the global market, and I want to review what that means for Canadian businesses whether you produce software systems/services or are consuming services from US tech giants.

For businesses producing software services -

1. Increased operating expenses - Modern businesses heavily rely on cloud computing, which has democratized innovation by making it cheaper and quicker to produce new solutions. However, with the increase in data center costs due to tariffs, the software bill of materials will inevitably rise.

2. Shift in focus towards data centers in US - Even if you're in the Canadian region for cloud services, the investments made by cloud providers, predominantly US-based, will shift due to the tariffs. It's estimated investments into data centers in the U.S. is expected to surpass $1 trillion in the next five years. I suspect these data centers will run service workloads such as AI services and share the cost to services globally not just people using the data centers. There's also the risk they focus fewer services in Canadian and other global regions.

3. Planning for the next 2 years - Tariff costs will take time to trickle down, unlikely in the short term. Also, as the goal post for the tariffs continues to shift it's harder to plan. Now would be a good time to lock in reserve pricing for cloud services for the next few years if you can, shift the budget towards long term investments.

For hardware manufacturers -

Tariffs may even apply to Canadian produced hardware - Hardware tech supply chains are complex, components come from across the globe. For hardware manufacturers, it means selling to the US may still have tariff implications. For instance, if a Toronto-based electronics company imports circuit boards or telecom parts from China to integrate into a product sold in the U.S., those parts may incur U.S. tariffs unless the final product qualifies as “Made in Canada” under USMCA rules.

For businesses with IT as a cost center -

1. Plan for added procurement costs for data centers - There will be impacts for IT infrastructure procurement for Canadian data centers. In the past, Canada has mirrored some tariffs from the US, there's no indication of that this time around. Supply chains will retract and as they sell less, manufacturing new components will become pricier as economies of scale won't apply. The knock-on effect of this is it will cost more to support the same IT capabilities as the previous year.

2. Resourcing constraints - As data center investment continues in the US, it will also strain access to technical resources with knowledge as many will get pulled into that market.

3. Planning for the next 2 years - For cloud resources, I would plan to get reserve pricing where possible, it provides the business a stable cost anywhere between a 1-3 year window.

Traditionally this would translate to delayed investments, expansions, and increased production costs in an uncertain environment. It's likely to lead to a slowdown of new tech-dependent services and limit resources for innovation. I would argue there's opportunities for Canadian leaders to reposition and come out stronger. Before going into that, let's also discuss other risks with data in the US market.

Additional risks of the US market

A significant concern I often see many forget is the issue of data sovereignty. Using SaaS products like Google Workspace or M365, where data resides in the US, means that the US Cloud Act allows their government access to this data. Determine if you have protected data that should not be transferred to the US. An example would be if you're doing business with EU as a Canadian entity, you need to have transfer mechanisms to move data outside of EU due to GDPR, the US Cloud Act may conflict with your requirements.

Additionally, US AI companies are also levying the US government that copyright laws should not apply to them. Some of these businesses are blatantly scraping the internet without any permission. As these become more prominent, there's risk to Canadian entities as any data provided to these tools can be used for future training. Combined with US Cloud Act these are major risks for Canadian public entities.

Local provincial requirements need to be considered as well. British Columbia’s Freedom of Information and Protection of Privacy Act (FIPPA), applies both to personal information and data under control for public bodies. It requires that

• ensure that “personal information is only stored in and accessed from inside Canada”

• “protect personal information by making reasonable security arrangements against such risks as unauthorized access, collection, use, disclosure or disposal”

This is becoming a bigger concern with the popularity of SaaS products particularly in the LLM space. As part of your vendor onboarding requirements, it's important to assess where data resides, the security of it, and sovereignty requirements.

Broadly, Canadian government requirements focus on data sovereignty, residency, and security based on a rating of protected B category are allowed within cloud vendors.

Opportunities Amidst Challenges

Despite these challenges, there are opportunities for Canadian businesses to excel. Companies focused on logistics or data analytics services will likely see increased demand as businesses struggle to understand the impacts of these tariffs. Canada has a strong presence in these areas, and these products could thrive under these new circumstances.

Additionally, we've got other trade agreements where new avenues will open as those businesses look to procure services outside of the US. I'm referring to the CPTPP (Comprehensive and Progressive Agreement for Trans-Pacific Partnership) and CETA (Canada-EU Trade Agreement). I believe it's an opportunity for Canadians to re-evaluate our focus and double down on strategic innovation.

Our largest AI product is Cohere, and while the Canadian government just invested over $200 million there's room to build an eco-system for key investments. We have an opportunity to apply strategic tariffs to build our home-grown AI ecosystem - this would mean Canadian data remains local and helps us compete globally. France and China have been investing in these spaces and we should learn from them. A Harvard case study titled "The Structure of Tariffs and Long-Term Growth" highlights how strategic tariffs can be beneficial to build industry, we should use this model.

There's a significant opportunity to invest in local data centers. Canada has some of the lowest costing and cleanest energy on the planet, making it an ideal location for such investments. Building an ecosystem behind data centers, similar to the approaches taken by the EU and China, could be beneficial. I will cover this in detail in a future article.

Canadian organizations should use tariffs as a wakeup call to boost self-sufficiency in critical areas. For businesses providing tech software, it's crucial to understand that cloud compute costs will rise, and SaaS products based in the US tech giants will pass on these costs. Strategic investments in computer equipment and hardware will become more expensive.

Supply chain-based companies, particularly in manufacturing, retail, energy, and mining, will be hit hardest. Investing in logistics and data analytics to understand the cost impacts and manage cloud costs effectively will be essential. Diversification is another key opportunity. On-premises and hybrid environments have been increasing, and reevaluating which workloads need to be in the cloud versus on-premises can help manage costs.

As leaders, we have an opportunity to redefine the future and how we might come out stronger. Now is the time to innovate, diversify, and invest strategically to mitigate these impacts and thrive in the new landscape.

DeepSeek has been all over the news with reactions ranging from excitement to fear (they were discussing banning it in the US). There's good reasons why US tech giants like Meta and OpenAI are shaken, and why it deserves your attention.

That said, there’s significant noise on this topic. From my experience during research, it was exhaustive differentiating fact from fiction.

My goal in this article is to provide you with insights to make your own informed decision. I'm going to discuss 3 aspects below of why you should consider DeepSeek.

Open-Source

DeepSeek is open-source - you can download the model, install it on your own machine, and run it privately. While Llama labels itself open-source AI model (Open Source Initiative doesn’t recognize them for good reason link here - https://opensource.org/ai/faq#which-ai-systems-comply-with-the-open-source-ai-definition), it’s reasoning isn’t at the same level. This is an open-source solution that can rival the best, competing with OpenAI’s o1.

It’s a significant shift in the GenAI landscape, which is dominated by proprietary solutions like OpenAI.

The AI industry has largely operated contrary to tech best practices—despite open-source being the foundation of modern technology. In fact, over 90% of applications today incorporate some form of open-source code, powering everything from enterprise software to the SaaS products we use daily.

The open-source community is essential to the sustainability and advancement of our systems. It fosters best practices through peer reviews and contributions from passionate developers with no direct financial gain resulting in collective innovation that benefits everyone. When it comes to AI—especially for enterprise adoption—open-source offers clear advantages over proprietary models, including:

• Transparency & Validation – Code can be peer reviewed and verified before adoption.

• Customization & Bias Reduction – You can train the model on your own data, mitigating previous biases.

• Data Ownership & Security – Your analysis and data remain within your environment, ensuring key intellectual property isn’t shared with third parties.

• Governance & Compliance – Full control over how the AI is developed, deployed, and maintained.

• Enhanced Security – Tighter control over sensitive data.

With DeepSeek, you have the flexibility to deploy AI on-premises or in your preferred cloud environment—and even retrain the model entirely, as you have full access to the code.

In contrast, proprietary AI solutions come with vendor risks. OpenAI, for example, has shifted its business model multiple times, transitioning from a nonprofit to a for-profit structure. These uncertainties make open-source alternatives like DeepSeek all the more valuable, ensuring organizations retain control, security, and adaptability in an evolving AI landscape.

It’s not all good news, as promised above I wanted to give you full insights. While the model is open-source, it doesn’t fully comply with OSI’s definition. We don’t know the training data and other vital training information.

But there is hope, the HuggingFace community seems to be working tirelessly to make this fully open-source, aptly named Open-R1.

Lower Cost and Carbon Footprint

One of the most striking findings about DeepSeek is that it was able to outperform other AI models at a fraction of the cost. While OpenAI reportedly spends over $10 million on a single training run, DeepSeek was built with just $6 million. This number may not seems significant at first, but as models grow and require more training, this cost efficiency is a game-changer, particularly in an industry where compute resources are one of the biggest barriers to entry.

Beyond savings, the lower cost of training has massive implications for energy consumption. AI development is notoriously energy-intensive, with companies like OpenAI calling for dedicated data centers and potentially consuming a significant percentage of total available electrical power. As the world becomes more reliant on AI, the industry is at risk of driving up energy demands at an unsustainable rate.

DeepSeek’s approach challenges this norm. By running on less powerful hardware, it significantly reduces energy usage, leading to a smaller carbon footprint and lower operational costs.

This efficiency not only makes AI more accessible to smaller organizations but also aligns with broader sustainability goals.

As this space continues to evolve, the conversation around energy efficiency will only become more critical. DeepSeek’s success demonstrates that powerful AI doesn’t have to come at an exorbitant financial or environmental cost.

It raises an important question: should AI development prioritize sustainability and accessibility over sheer computational scale? If so, DeepSeek could be a model for a more responsible AI future—one that balances innovation with efficiency.

Macro Global Risks

AI models will always reflect the biases of their training data, which are often shaped by the regional politics of their home countries which in DeepSeek's case is China. As AI becomes a key strategic investment for governments, we can expect increased competition between models from different nations.

DeepSeek, like all AI models has inherent biases, the same is true for U.S.-based AI companies. Allegations of data theft and misuse have surfaced on both sides, affecting companies like OpenAI and DeepSeek alike. Testing the boundaries within the systems, it’s easy to validate biases on all AI systems.

However, the trajectory of AI development in China appears to be leaning toward greater openness, whereas the U.S. AI ecosystem is increasingly dominated by a handful of private, closed-source entities. This centralization of knowledge and decision-making is concerning, as it places control of AI’s future in the hands of a select few.

For years, I've been consuming blockchain research from there because it's great quality and they're sharing critical findings. Going open-source is about sharing knowledge and learning collectively. As a species we proliferate when knowledge is shared. History shows that civilizations reach renaissance by sharing knowledge, and regress when internalizing

Looking ahead, DeepSeek and similar models may gain an edge unless the U.S. commits to substantial government-backed AI investments. It’s why we see the massive investment of $500 Billion in the StarGate initiative.

As AI continues to shape the future, more nations will likely recognize its strategic importance and ramp up their own investments. The question is not just who will lead AI development, but how the world will choose to balance openness, innovation, and control.

I truly believe that DeepSeek represents a pivotal shift in the AI landscape, in that it has popularized a open-source model and is challenging the status quo of costly, bloated, proprietary models. Its open approach offers greater transparency, flexibility, and efficiency, but the larger question remains: How should AI evolve moving forward?

Now is the time to engage in the conversation. Explore DeepSeek for yourself, test its capabilities, and consider what an open-source AI future could mean for you or your organization.

💡 What are your thoughts on DeepSeek? Do you see open-source AI as the future, or do you have concerns about its implications? Join the discussion in the comments, share your insights, and let’s talk about where AI should go next.

Leave a comment

I've been supporting organizations with digital transformations for over a decade and projects at scale over $1 Billion. In this next phase of autonomous transformations, the realm of possibilities is significant. I want to start a series that explores from an enterprise architecture perspective

• What is security, privacy, and regulatory concerns for such a rollout?

• What's possible with agentic models? How to setup checks and balances?

• Biases that you need to be aware of in models, and how to work with them

• Managing infrastructure & cost for such a deployment

• Can this be done in a sustainable manner (ie. minimize carbon footprint)?

I've decided the best way to do this is start my own project and share the findings as I build out agents and understand the implications of orchestration for these agents. As it's bleeding edge technology, I don't have all the answers today but I'm excited to explore these avenues.

Why you should care about AI

Before we dive deeper into the project I'm looking to build, let's touch base on why you should care about what's happening in AI. Periods such as the Industrial Revolution, and the Digital Age have had significant impacts economic, social, global, political, and environmental impacts.

We're now about to enter the era of AI (or at least that's the vision that's being sold to us) - does that mean Artificial General Intelligence (AGI) is around the corner (ie. AI that can reason like humans and consider multiple diverse domains in it's reasoning)? I suspect not. I think there's lots of interesting use cases prior to AGI that are worth exploring.

Exploring new use cases

I've decided to start a moonshot project that will help me distinguish reality from fiction, and I will share my lessons with you.

I read a significant amount of content from case studies to rss feeds from various sources. It's a common underlying need to all my work - from consultancy to even writing on here. The problem I face is there is a lot of noise - simply put poor quality content with little substance.

How do I determine if it's something worth reading? In my case, I'm looking for data analysis, sources, relevancy, timeliness, etc.

At one point I was considering hiring a researcher who could help me decipher what's worth my attention. For the purposes of this experiment, I'm going to try using an AI agent and see if it can support my needs.

Setting Project Parameters

I know OpenAI has DeepResearch as an offering, but it's entirely private. The issue here is we don't know if our data is safe, given the fact that their mission has changed, and the organization has made many questionable choices (remember they stole Scarlett Johansson's voice without her approval), I would like to avoid them.

The parameters & needs for this project then are:

• the LLM is open sourced

• Running on my infrastructure (this will be cloud)

• Cost-effective, secure, and minimal carbon footprint

Evaluating output

I will be judging the success of this project against the 5 questions asked above. Additionally, I will be reviewing the following items:

• Scalability to meet demanding workloads

• Performance metrics to determine latency in real-world scenarios

• Opportunities for integrations

• Continuous learning mechanisms for the agent - how will it adopt new patterns over time?

• Upgradability of selected solution

• Compliance and Ethics - all models are biased by those who train them, we will need to understand that

• Cybersecurity analysis against zero trust principles

Let me know if have any suggestions for additional parameters, I would be interested to hear from you.

In this week's Pulse we gathered observations and key takeaways that, while they may not fit the main article's scope, could provide valuable context for understanding the broader implications of these developments.

DeepSeek performance against o1

The open-source model from China is handled beating o1 with faster processing, using fewer tokens and being cheaper, running on more energy efficient hardware.

It's a great thing to get some more competition in this space. OpenAI has been data hoarding and not contributing back to the open-source community, which is a fundamental pillar to the tech space.

It's estimated 97% of applications use some form of open-source software, and we need to ensure it's available in the future. The other great outcome here is LLMs do not need to have such a significant carbon and energy footprint, it's possible to be efficient.

Link: https://venturebeat.com/ai/open-source-revolution-how-deepseek-r1-challenges-openais-o1-with-superior-processing-cost-efficiency/

MS Copilot oversharing information

Imagine a GenAI assistant sharing confidential information with the wrong employees or contractors, that would be a nightmare. It's not as simple as just turning on the tool, paying a license and forgetting about it. The article below covers your options from Microsoft.

Data security & sensitivity can easily be taken for granted. GenAI tools typically have a lot more access, and we need to ensure the agents use security best practices such as principle of least privilege to do their job functions.

It's also worth reviewing sensitivity periodically as organization shifts frequently & it needs to be a part of your data governance process.

Link: https://www.computerworld.com/article/3616459/microsoft-moves-to-stop-m365-copilot-from-oversharing-data.html

LLM on Kubernetes

If you've decided you want to setup your own LLM, the infrastructure management can be significant. Microsoft introduced the Kubernetes AI Toolchain Operator (KAITO) that automates tasks like provisioning GPU nodes, configuring resources, and setting up inference endpoints

I've seen a lot of organizations use APIs from OpenAI, Claude, etc. Several issues come with this - at scale these can be expensive; more importantly data security becomes an issue as it's hosted by a 3rd party.

You can choose to use a managed service such as AWS Bedrock, however, you're forced to deal with vendor lock-in, limited customizability, and data portability issues. It's a great project to familiarize yourself with as other AI use cases beyond LLMs increases, these tools will be necessary for scaling.

Link: https://github.com/kaito-project/kaito/tree/main

We are now fully in the world of GenAI. Every product we now touch has some AI component or a plan to have one. Whether you or your organization plan to join in or not, there still needs to be a strategy around it. AI was originally touted to increase productivity, efficiency, and for some organizations even replace hiring needs, it has also caused significant damage.

GenAI has shifted the landscape for organizations in 2025, whether you're planning on rolling out or not there still needs to be a strategy around it. While it was touted to increase productivity, efficiency, and for some organizations even replace hiring needs, it has also caused significant unintended damage to companies, their intellectual property or even their software code.

As GenAI has become multi-modal, it translates to the fact we can no longer simply trust what we see, hear, or read anywhere including social media as content can be produced by anyone with malintent. From a hacker perspective, it's has now become infinitely easier to generate phishing emails, social engineering attacks. For software development, since AIs are trained against open-source libraries, those vulnerabilities will get copied into many private code repos!

Should your decision be to not adopt GenAI tooling due to these fears, a strategy is still needed as many of the vendors in your software supply chain will be using such tools. Yes, they are supposed to get consent before collecting and using data, but it's always good to have a plan otherwise.

Concerns About The Current Landscape

Whether you're prepared or not, someone in your business will be adopting such tools and you will undo all the work you put in to eliminate shadow IT. In my experience, I have seen countless times departments like marketing have gone out procured a tool without IT team knowledge especially when "denied" the use of a particular type of application. The other part about this is if not don't address it actively, you're not sure how your team or organization are adopting these tools. Low hanging fruits such as code development and emails are easy to guess, but without using responsible AI tools (which usually cost money), it could also mean proprietary knowledge being shared with 3rd party entity without the organization's knowledge.

The truth is though, while the knowledge leakage is real, it is mostly not intentional. Case in point, I was chatting with an acquaintance regarding their ChatGPT usage, they mentioned:

Them: "I just throw in all documents and have it reviewed."

Me: "What about proprietary knowledge and business information? You could be sharing sensitive materials without realizing it, in fact you might be breaking half a dozen compliance standards without realizing it"

Them: "I never thought about it"

The kicker was - this person was in IT!

The landscape is becoming easily accessible to end users in both their home, and work lives with technologies like Apple Intelligence on phones to OpenAI agent models & Claude on the computer, all of which have the ability to control computers and mine personal data. Now imagine someone providing access to those on their own systems with Bring-Your-Own-Device policies (and it having access to your corporate data). Circumnavigating IT guardrails has never been easier.

Even if you decide to block via firewall, it's not entirely possible as MS Copilot, Google Gemini and similar products are integrated within the corporate products we use.

You Can't Beat It or Hide Your Head In The Sand, You Need a Strategy

While its daunting to not wanting to deal with AI, especially given so many other responsibilities we all have, it has to be done collectively in the entire organization for the organization's survival may depend on it. The following 7 Questions will help you uncover the guardrails needed to responsibly rollout AI in the organization:

1. What are your organization's mission critical workflows and proprietary data? This data must be protected and not fall into the wrong hands. Step 1 is to go and ask the business (or if your scope is department and/team, ask them) to review their mission critical workflows and determine whether they should be accessible via GenAI or not. Review implications if the data is leaked.

2. Look at your software supply chain, and how they are delivering using GenAI and its impacts to your tool usage. Do you want those capabiliteis and is there a way to turn them off if not? I can't count the number of times I've seen an AI product that was just a wrapper to OpenAI, Claude, etc. There are very real implications for your business should your vendors be sharing proprietary information.

3. Access to information? Oversharing is a huge issue in most organizations. There was a scenario where someone using CoPilot was able to see CEOs emails, that should never be the case. Access Control is imperative and determining how to clean those/put it in is key.

4. Differentiation of data sources and who (from an AI tool perspective) should have access? There is a common false notion that having access to all data means the best results, I think LLMs have proved that's not true. The quality of the data is imperative, and too much data can lead to noise. Even from a vector database (the common dbs behind LLMs), formulating a response requires it to select a subset of information and if it hased indexed a lot of noise, that doesn't bode well. Additionally, not all sources should be treated equally in the organization. Data from OneDrive should not be treated as a trusted source on a vacation policy that should instead be coming from the HR SharePoint site. Training AI agents on specific areas within the organization will likely produce better quality. Also, training users on responsible usage helps as well.

5. Do you have policies and procedures for dealing with Shadow IT? The core problem is not tackling applications that are outside the knowledge of IT, therefore no governance, monitoring, compliance, or risk best practices can be applied. The good news is that this is not an unique problem to AI, it just makes it louder. But using best practices to target shadow IT applications will help immensely.

6. Understand possible use cases? Talk with various teams and how they think they might benefit from such a tool, integrating human presence with AI to produce a better results. You can always start with a small footprint and grow as the business develops capabilities internally. Some examples might include integrating note taking into meetings, condensing heavy real-time data processing tasks such as advanced threat intelligence.

7. Adopting SaaS, PaaS, or IaaS? It might surprise you, but AI rollouts are following the same 3 models used for all cloud services. Satya Nadella had mentioned that SaaS would eventually be replaced by agents, you're still consuming it in a SaaS model for a lot of cases. SaaS would be your ChatGPT, Copilot for Microsoft, Claude, and similar applications available via web interface or integrated into end user applications such as office, you can consume the services but minimal access to setting up any policies or procedures. PaaS models would be AWS Bedrock, Azure OpenAI where cloud providers give you access to LLM models, you decide what knowledge bases to refine the models against, and how these are rolled out. These could range from customer facing chatbots to internal line of business application integrations. You get access to all well-known LLMs but the benefit of applying governance guardrails, security, and monitoring best practices without needing to worry about the underlying infrastructure. Finally, the IaaS approach means deploying the infrastructure, selecting a LLM such as llama, and training it yourself. This option obviously gives the most flexibility but also requires the most investment from a building perspective. Let's be clear, you own everything.

Is your organization rolling out AI? Do you have any fears around it? Comment Below.

Leave a comment

Mark Zuckerberg recently came out saying that he believes GenAI systems will replace intermediate developers this year. ChatGPT has progressed quickly, in fact it's passed the Turing test and found to be more collaborative than the average human. Many businesses have remote teams and developers, one has to wonder how working with an AI dev agent might translate. These agents will increasingly be making more and more decisions, and as we get comfortable that will increase with time. Given all of this you might be wondering if that's possible, should I be changing my outlook?

Let's review his statement from a few perspectives: the broader market, cost, current state of the technology, what you should be concerned about, and how you can benefit from it.

Market Trends

While Big Tech companies dominate the news cycle, the reasons behind these kinds of statements need to be analyzed. Let's peel the layers back here a bit.

1. There's a new administration in the US, with many Big Tech companies feeling the pressure to endear themselves with the upcoming administration. We've seen Facebook remove features such as fact checking due to potential concerns. Zuckerberg probably is concerned to some degree about retaliation and would want to adjust head count.

2. Zuckerberg is the CEO of a publicly traded company. Rather than admit demand for new features may be waning, it sounds better to shareholders to state that AI will take over jobs. Several years ago, Cisco, a company primarily focused on networking hardware, claimed that AI had reduced the need for jobs; I find it hard to believe they had suddenly developed the ability overnight. The better explanation would be they over-hired during 2021 and wanted to adjust headcount.

3. Meta is likely looking to reduce headcount. Looking at their layoff patterns, there was a major set in 2022, and 2023; they're likely overdue and trying to use this to build positive momentum with shareholders than paint a picture of regulatory pressures and demand drop off.

   

The point here being I take what Mark says with a grain of salt. Tech "bros" also have a history of overpromising and underdelivering - we've seen this pattern from Elon, Sam Altman, and many others in the industry. Driving hype behind something translates to more investments.

On the other hand, if we look at where investors are putting money in startups, it favors those companies with AI, the numbers seem to back this story. Bloomberg reported that AI Startups funding was at a record $97 Billion.

It is impacting the market to the point that .ai has become one of the leading domains. I've across my fair share of startups that have nothing to do with AI but use the domain as it helps from investors and clients.

There is undoubtedly an intrigue of what's possible with AI, our history as a species means we associate communication with intelligence. The fact these systems can communicate means we tend to trust what is stated.

Cost

There has been a consistent narrative that AI tooling will reduce in cost over time as it reaches market saturation similar to cloud services. I don't believe this to be true - ChatGPT recently introduced a new Pro plan costing $200/month, a 10x increase from their previous plan. I would argue this makes it less accessible.

Looking at historical context of other tech companies in this space, there tends to be an enshitification tax where the price will increase will quality decreases. Once a tech company reaches market saturation, we see the pattern occur. Netflix is a great example of this, when it launched the business model was unique for the industry and convenient for consumers. Over time the price has continued to increase and the number of shows/movies have moved to other services. It's now a worse landscape than just cable, granted lots of convenience but at a considerable cost.

With GenAI systems, it's more complicated. Every GPT that is released is magnitudes larger than the previous - for perspective GPT-2 was trained on 10 billion tokens, GPT-3 on 300 billion tokens. As such the costs of training go up, not just from the compute needed but as underlying energy for data centers increase that gets passed on. GPT-3 175B model required 3.14E23 FLOPS of computing for training, it meant millions of dollars for a single training run.

While newer chips are more capable, and quantum compute would change this discussion considerably, there is still the cost of energy. We are an energy hungry society; energy supply can't keep up with the demands. It's easy to infer the cost of such systems will increase.

Another perspective is the cost of historical conversation context it requires to run LLMs, in memory is expensive much of it needs to move into databases. To retrieve this context for new conversations is an overhead. While having a single omnipotent LLM would be awesome as it could do all tasks it becomes too expensive. It's a big reason why agentic models are being pushed, it's cheaper to have systems targeting individual domains. This introduces an overhead that exists with current engineering teams - collaboration!

How The Market Will Deviate

Now that we understand why an agentic model is necessary, what does that mean from an engineering perspective? Software development requires multi-dimensional complexity and understanding of multiple domains. Arguably the complexity of delivering products lies in the collaboration of people with different backgrounds.

Autonomous transformations will result in structures based on business focus. Tech focused businesses will invest more resources into development of AI, at least in the short term. For tech-enabled businesses (these tend to be incumbents), they will be some of the large-scale adopters of these technologies.

Translating To Teams

Agentic models will require some form of collaboration, we will see new metrics beyond DORA and SPACE to understand how efficient these agents are. Will it translate to teams of AI agents replacing developers?

Truth is I'm not entirely sure. As the price of energy continues to rise and demand increases for agents, it may become a struggle between supply and demand. It's more likely that we will see engineers deliver better quality and increase speed of development. From a business perspective, the choice becomes to increase features and explore new opportunities or focus on reducing costs.

Will development jobs be impacted? Yes, they will; another way to look at it is development will be within reach for lots of people. Your domain knowledge for the business around the industry will be more valuable. As development will be easier to access, I suspect the salaries will drop similar to what we've seen it happen in other industries where automation has taken over. Eventually, there will be a mix of human and AI developers.

Leveling The Playing Field

The struggle between incumbents (traditional tech-enabled) and disruptors (tech focused business) is going across industries. Disruptors typically have singular focus, lots of investor attention sometimes translating to significant funds, & less technical debt from decades of decisions. It also means they can often give software engineers, and their tech teams perks and salaries that incumbents often can't compete with.

If we look at banks versus fintech companies, we see this pattern. Banks have brick & mortar locations, need to pay employees related to customer service whereas most fintech companies tend to operate online only, typically have fewer regulations that they need to be concerned about.

What am I trying to get at here? I believe this skills gap between disruptors and incumbents is going to reduce due to AI tooling. Imagine having a junior engineer with Github Copilot now producing code at mid-level. It's then possible to build a world class team without the world class budget.

Everyone can have access to pair programming, and the arguments of wasting engineering resources are less of a concern.

How You Should Prepare

I had put a previous article on why I didn't believe developers were going away anytime soon. The recommendations I made at that time still remain relevant, so I am repasting them here:

1. Pair Programming 2.0 - Pair programming allowed developers to collaborate, reduce defects and build higher quality code. While there have been plenty of tools over the ages to support refactoring; CoPilot is a step better. If the developer begins navigator role and lets CoPilot be the driver results tend to excellent. We can then produce higher quality code, aligned with business needs.

2. Support with non-development engineering tasks - everything from creating QA test cases to developing user stories for product backlogs to creating documentation & even brainstorming, engineering teams will benefit from utilizing GenAI. It could offset tasks that can often be barriers for completion, additional it could be trained to produce outputs from your team templates.

3. Security Systems - This isn't GenAI specific, but broader. One of the issues with detection and incident management I often see with teams is that they don't have the resources to dedicate towards reviewing logs - it is too much data. Even with tools such as Splunk the organization can be very poor. Pattern recognition is definitely a strength, pair that with GenAI we could have level 1 support providing significantly more insights than previously. I'm just scratching the surface here.

4. Team sizes - It would be a lie to say team sizes wouldn't be impacted, you might not need to hire as quickly to grow a team. As the average output of a developer increases, we should be able to get more done with less. This is entirely dependent on the goals of the organization and timelines for releases

Thoughts? How do you feel you will be impacted by ai? Comment Below

Leave a comment

Trying to lead DevOps and platform engineering efforts at an organization are rife with challenges. The biggest challenge can be to deliver what your CTO may need but isn't aware of currently.

There are a multitude of reasons for this depending on the CTO's background. If they come from a technical background, they are trying to figure out how to go from a domain specific trench to thinking broader. If they were management IT, they are trying to figure out which pieces are valuable vs. which are unnecessary. And if they don’t have a technical background, understanding all the components of an organization's IT environment can be overwhelming.

The end result is the same - CTOs often consider most things to be cost centers and want to reduce it, and focus on the tangible functions and features they deem will add great value to the business.

This can be a critical stage when responsible for DevOps and platform engineering, where the correct decisions can change the conversation from cost center to value enabler and multiplier. Let’s look at 5 changes you can make within your team.

Platform as Product

The first step is to shift your own team's thinking to treat your platform as a product whether you're supporting line of business applications or supporting development for customers. This shift allows the team to look at internal developers as their customers, moving away from just Infrastructure as Code to trying to optimize the developer experience. You and your team can now start incorporating developer journeys, pain points, and gathering feedback sooner. This push leads to asking smart questions, gathering client feedback and improving the customer experience. Questions such as "how do we enable the self-service capabilities to help developers deploy faster?" can give key actionable insights, that once implemented, increase your team's reputation within the customer groups, and in turn within the organization.

This change is fundamental to help your CTO understand the importance of your team and be able to align it with key organizational goals. Often this translates to increased budgets and wins the entire company can understand. Historically platform engineering would be seen as a cost center, these types of discussions help sell the value internally.

By showing the incorporation of feedback, doing customer surveys, you are now gathering the information to show your value. The team may be resistant at first, or consider it to be more "overhead" but working through those hurdles will help the team in the long run.

"DORA doesn't work for us"

Most organizations try to take prebuilt metrics like DORA and implement only to come to the realization that their industry can't simply focus on lead time for when changes get pushed into production. This can be for a multitude of reasons including regulatory, operations, safety or hardware constraints. Healthtech is a great example of an industry where reliability maybe the primary driver rather than speed and frequency.

Just because one set of metrics does not work, does not mean that you shouldn't be focusing on metrics. There might be other metrics such as SPACE that could work (We discussed SPACE in the article linked here), or understand what the goal is and find ways of measuring it. Perhaps the goal is to increase frequency of deployment within your own lab environments for faster feedback. The goal should be to create faster feedback loops from your customers even if they are internal, using that feedback so that team can address it and measuring to make sure you are succeeding.

This helps the CTOs by providing them visibility on how your team is performing under your leadership by showing improvements and value adds, but also helps the CTO communicate with other executives, clients, investors and board members showing how well/efficient their department is running and delivering.

Working with Hypotheses

When developing products it's rare to know what a customer truly wants, whether internal, enterprise, or consumer. Hypothesis driven development has therefore been useful for development of new features.

When applied to your platform engineering efforts, it helps you adopt a scientific approach to measuring the impact of your work.

Imagine rather than saying,

"Let's create templates to help our developers because we need to resolve issues sooner"

it changes to:

"If we provide pre-configured monitoring templates with standard alerts, teams will detect and resolve production issues 30% faster."

In this particular example, it would be imperative to have data for Mean Time to Recover (MTTR) efforts in the organization (hence the ability to see improvement). This approach, ensures that all effort by the team becomes an experiment that can then be repeated, controlled and improved upon.

While metrics shows CTOs team performance, this layer shows the proof and helps craft the "how" the team is accomplishing it. It helps build better cases for value, future toolsets etc for you and your team without it becoming a "guess/hunch"

Enabling Cybersecurity for the Organization

In most organizations, security starts with compliance - a focus on obtaining SOC2 or ISO27001 to satisfy external customer demands. This usually falls on CTOs to figure out how to achieve. Since platform engineering teams are fundamental to organization infrastructure, it’s the right place to introduce security best practices. These practices can then trickle down to product development teams.

By being proactive and iterative in implementing security controls, your team will ensure that you are reducing the organization's exposure, and working to make sure that when the organization needs to certify or resolve a cybersecurity incident, you are in the best position to support while knowing you have controls in place that will mitigate the impacts. You may not have buy in from the areas you serve, but even something as simple as enabling logging (with good log management) will have large impacts on the organization.

Of the 8 domains in cybersecurity, platform engineering can be a driver for all of these.

Being the champion for cybersecurity within the team helps CTOs obtain compliance faster, or help troubleshoot and recover from cybersecurity incidents. It may not give accolades or even have momentum early on, but eventually the value will shine through.

Managing Outsourced Development

This has been the most consistent issue I have seen with CTOs in my 15+ years managing outsourced developers. Whether CTOs expect the entire development or product is managed by the outsourced party (which they claim they will do but never do) to having difficulties getting external developers integrated with internal teams, eventually the organization inherits a mess that then results in engineers have to figure out and make sense of.

One of the fundamental tenants of DevOps is continuous delivery, and your team is the one responsible for ensuring that that foundation is in place for 3rd parties to use. It’s imperative to setup how you will be accepting delivery and defining the parameters early on.

Most external teams will want to take the path of least resistance to deliver, and by having a mature platform engineering practice much of the requirements for testing, integration, branching strategy, etc. is pre-prescribed for them that they have to adopt. This means allows the team to become proactive to manage 3rd parties for your practices, ensure that demoed code works in your environment (they can't bluff their way) and ensure security requirements are met rather than it being an afterthought.

For CTOs, easing their burden of managing outsourced development they can accomplish their business level goals. As your team shows results, you can increase your influence in ensuring when selecting 3rd parties to ensure smoother operations.

Yes, it is often hard to get buy in even from internal teams to do extra "overhead" work, but by working to implement these 5 areas, platform teams can help CTOs accomplish their goals and ensure they are seen as an enabler, force multiplier and ultimately given more influence rather than just being seen as a road block.

What are your thoughts? Comment below.

Leave a comment

Share

As we're starting the new year, I like most of you want to make sure that 2025 brings more knowledge, skills and experiences allowing us to grow as Platform Engineers and DevOps champions.

Most of the recommended material in this space tends to be technical, often stemming from a break-fix way of living. We all make our living tackling problems head on and the ones we generally see are technical. Technical knowledge is abundant, from articles (even here on Substack), to video platforms such as Linkedin learning, but what that misses is the gaps created around things like trends, growing and managing teams and operational management.

Being successful in the platform engineering requires a broad understanding of things beyond just technical knowledge, and the 3 books I am recommending, in my humble opinion, can be the force multiplier for you in 2025.

Topic: GenAI

Book: "Autonomous Transformation: Creating a More Human Future in the Era of Artificial Intelligence" by Brian Evergreen

In 2024, GenAI took the world by storm. We live in a world where we are surrounded by ChatGPT, AI artwork, AI postings and AI in most digital products. I think it's important to understand reality versus hype. AI will have impacts, but knowing how it can/will impact will allow you to navigate those changes.

A quick GenAI primer: GenAI is software made to respond with natural language; it does NOT have to be correct or accurate in fact it often (don’t take ChatGPT on it’s word). The fact of the matter is that the underlying concepts for LLMs (on which GenAI is built) have existed with natural language processing (NLP) for decades. I actually studied it in the late 2000s. What's changed though is that LLM became possible simply because cloud computing provided cheap and quick access to lots of compute and storage. While it's good at common tasks, multi-dimensional ones such as software development can difficult - I highlighted why in the following post [linked here]. It will free you up to tasks that aren't so hands-on-desk.

We as humans associate communication with intelligence, and I think that has a lot to do with the hype that has built around GenAI. The next phase for this type of AI is Artificial General Intelligence (in this case, it would be correct more often than not and able to take on more complex tasks). It is still unknown if it is even possible do do this, let alone the timeline for such a rollout.

What muddies the waters is the sources driving the hype behind these technologies are also investors who are trying to grow interest in this space. They provide subjective opinions not objective. Nonetheless, interest in this space does mean additional funding in the coming years.

The last decade belonged to digital transformations - organizations modernizing systems to compete in a changing world. The next decade (or less?) of transformations will be driven due to AI. Autonomous systems will complete certain tasks that were previously only the domain of humans - I'm not saying this is a bad thing. We're not as good at repetitive tasks (think of error rates), pattern matching at scale, etc.

This book shows how AI agents are going to impact the way we work. Truth is your leaders are already exploring AI (or at least AI products), it's worth understanding how it will impact you and your role.

Topic: Leadership and Language

Book - "Leadership is Language", L. David Marquet

Failure is the best teacher, and sometimes it is better to learn from other peoples' failures than making the same mistakes. Leadership is Language shows how the 2015 sinking of the SS El Faro ship was largely avoidable and that good leadership could have prevented this tragedy.

As a consultant responsible for many newly anointed leaders, I see people that are transitioning into leadership roles often make mistakes assuming they have a higher output as an individual contributor. Becoming a leader requires a change in approach from always being a "doer" to becoming an "enabler." The goal is no longer to maximize your own output, but to maximize the team's output ensuring it delivers outsized results to an organization. This book has a good way of showing the mistakes we easily make as leaders (I know I have): staying the course due to sunken cost fallacy, prioritizing schedule above all else, and dismissing team member's concerns.

While many of our jobs may not be life and death, there are real world impacts to poor leadership. Platform Engineers have to lead not only their teams, but as problem solvers are leaders bringing disparate teams (like business, development and cybersecurity) to work together.

Things I have learned and adopted from this book:

1. Adopting intent-based leadership instead of command.

   Real world application: rather than telling someone in a "I need you to...." ask "What do you see?". This changes the focus to empower your team and for them to take ownership.

2. Move from binary decisions to nuanced thinking.

   Real world application: Instead of asking "Are you sure?" to "How sure are you?" will allow for a more complete picture to make decisions from.

3. Focus on learning from failures.

   Real world application: When things go wrong, don't just jump in to fix, berate or dictate what to do, instead ask "What was your thought process?"

4. Change approach to conversations.

   Real world application: Avoid asking leading questions, and focus on asking What vs Why.

5. Embrace silence and take the time for reflection.

   Real world application: The goal as a leader isn't to achieve compliance (that's more dictatorship vs. leadership).

We get promoted because we are good at our role, but leadership requires us to shift our focus which instinctively goes against why we thought we got promoted in the first place. This book helps navigate that transition for you, and will ensure that your team does too.

Topic: Engineering

Book - "Shape Up", Ryan Singer

I find in life in general, we do things because that's the way they're done. Given the million things that happen to us on a daily basis, we often don't question it. In tech, we are no different. Take a step back and ask yourself:

• Is your sprint cadence working for you and your team or do you find there's not enough time?

• Do you find by the time the team get to development/implementation, more time is wasted flushing out features/what needs to be done resulting in overrunning estimates?

• Are the processes that your team has are working against them rather than for their benefit?

This book is from the team behind Basecamp and how they run their engineering. They've done a great job of building a system that works for their team to deliver on time and within budgets - it requires features to be properly scoped and the leadership team to decide what's priority. Most importantly, once teams start working they aren't interrupted by unnecessary meetings, distractions, etc.

So, how does this apply to platform engineers? While it's more oriented towards developers, there are items that platform engineering teams can take back as lessons for adoption:

• Platform engineers work with multiple teams both vertically and horizontally in an organization. It means they need to have insights into upcoming projects, requirements, and be able to plan for those. Their 6-week sprints gives time to make significant shifts that might be necessary whereas 2-weeks can be too short especially if items haven't been scoped appropriately. Alternatively your team might using PI planning to group 5-6 2-week sprints and understand risks early on to deliver on expectations.

• Empower teams to be autonomous, they can break down their own tasks and highlight unknowns early on. This draws a balance between insights to management and ownership by team members. I've found when teams are encouraged to take ownership the quality of the work delivered is vastly improved.

• Use the betting table to force leadership to make decisions on what's a priority. You only have a limited amount of time, prioritize and focus on value. If we start treating features as hypotheses and gather feedback it can benefit planning and building next set of features.

The lessons in this book may not be implementable in your organization directly, for example, if your focus is hardware-oriented R&D it might not be an ideal fit, nonetheless the approaches and though process outlined can be adopted to improving your teams internal process.

If you have a book recommendation, or would like to share your experience with any one of the three titles, comment below!

Leave a comment

But first...

We cannot emphasize how grateful to you, our readers. In a world saturated with constant demands for attention, we appreciate you taking time out of your busy Tuesday mornings to read Code n Culture (over anything else). Your support means the world, and we’re especially thankful for the feedback many of you have shared (often outside this platform). It’s your insights and encouragement that push us to improve and keep going, even on the dark days when we are struggling to write.

What We Accomplished in 2024

1. Launching Code n Culture on Substack in the summer of 2024

Coming from a consulting background, we are always brought in to solve a problem and have to take a Swiss army knife approach in resolving it. While that makes for good consulting, it's challenging to help people at scale and make an impact within our ecosystem. Often times we are solving similar issues repeatedly. It meant we were looking for a different path with the following goals:

• Scale the impact of Gurinder’s expertise as a LinkedIn Learning Instructor, Cybersecurity expert, DevOps & Tech leader.

• Learn and grow—for me, that meant diving into DevOps and understanding how to scale a business.

Why Substack? There's a lot to like here - low barrier to writing and reaching our audience, and opportunity to build a community. We were also inspired by the thriving ecosystem of newsletters—both adjacent to our focus and in completely different spaces on Substack itself.

2. Refining Our Audience

As with any project, we grappled with a critical question: Who are we helping?

• Should we guide executives in understanding DevOps?

• Should we support platform engineers navigating their DevOps journey?

• Should we support Cybersecurity experts in navigating the complexities of DevOps?

We know that the problem exists, we’ve started honing our focus on platform engineers and managers, addressing not just tools and technology but also the cultural aspects of DevOps, and the nuances of a world where cyber threats have never been higher. This focus will continue evolving, but we see enough traction to continue our growth.

3. Rebranding to Code n Culture

6 Page Memo was the inspiration of how we wanted to help people: Good, in depth content, but distilled down to give you enough information to be able to make good decisions. While the inspiration resonated with people the name did not. so in the fall, we adopted a new name, better reflecting the areas we want to serve. We’re often brought in for the technical “code” side, much of our impact lies in driving the cultural changes required for success—think governance, RACI matrices, and change implementation. Code n Culture strives to embody this balance.

What’s Next in 2025?

Here’s what you can expect from us over the next year:

1. More Writing

We live and breathe technology, and we’ll continue sharing insights on topics that intrigue and challenge us. We are committing to this endeavor in the long run, working through challenges rather than moving on into something else.

2. Building a Community

We are working towards building a space where like-minded individuals can:

• Seek help/feedback navigating platform engineering challenges and opportunities

• Explore how emerging trends, like AI & blockchains, will shape the field

• Learn how to adopt these changes or help their teams adopt them

• Be a trusted source of information (and inspiration)

The how? We will start with leveraging the Substack tools such as chat, paid subscriptions etc and go from there.

3. More Engagement

With other likeminded people, readers, creators helping in similar spaces. Not only does it help with building a community, but the more engaged we are the more we can welcome people and help them.

Our Subscriber Goals

People often ask if we have specific subscriber targets. While we’ve certainly dreamed about the numbers, our priority is building an active, engaged community. We’d rather have 10 passionate participants than 1,000 passive followers.

Wrapping Up 2024

The next two Tuesdays will be quiet as we recharge and relax over the holiday period. However, we’re always open to comments, chats, and discussions, so feel free to reach out.

Thank you for being part of our journey. Here’s to an exciting 2025!

Leave a comment

See you in the new year,

Muhammad & Gurinder

Share

Recently a group of Chinese threat actors, Salt Typhoon, hacked 8 telecom networks in the US; it has been labelled as the worst telecom hack in US history. Given the increasing frequency of cybersecurity incidents, it's now more imperative than ever to design systems for such scenarios. While Critical National Infrastructure (energy, telecommunications, finance, defense) has a higher chance of being targeted, they aren't the only ones at risk.

We need to contend with an evolving landscape of cybersecurity threats with more complex attack vectors. Additionally, business infrastructure footprint has grown with it being common to have multi-cloud and hybrid environments. Platform Engineers need to worry not just about the security within CI/CD lifecycle but across underlying systems.

The reason why this is important to Platform Engineers is because they are often the ones that are tasked with being the ones that have to put the various pieces together navigating cybersecurity professional recommendations, developer issues and business desires.

This article is meant for those of us tasked with making it all work, and how we architect these systems to be secure.

The issue with traditional security

The traditional design with on-premise networks was to design a security moat (like those around a castle) to make it difficult to infiltrate the organization's systems. The issue with moats is while they are great at keeping intruders out, once the intruders enter they have full (or close to) access to everything.

That's not the only flaw with this design. In modern systems not all applications and services can be behind a moat. Common scenarios for breaking the moat are:

• Having bring-your-own device policies meaning people are able to access company data on their personal phones, tablets, and more. These devices often won't have uniform policies and controls applied on them.

• Using SaaS products meaning limited access to the security of those systems (single sign-on doesn't equate to secure)

• Integrating 3rd party APIs such as ChatGPT and other LLMs into your services. These systems data security controls are necessarily aligned with your organizations.

With modernization, traditional security is insufficient. In fact, with upcoming shifts in the market from blockchain systems redefining web to AI shifts causing autonomous transformations traditional security is downright dangerous.

A better approach is required.

Never Trust, Always Verify

Zero Trust focuses on building security into the architecture of modern systems, with the underlying principle being "never trust, always verify". What this means is:

• Systems need to be designed with the notion of "if breached how can we limit the damage and maintain business operations?"

• Use the principle of least privilege, provide dynamic a security policy, and on a per-session basis - few people likely need full control over resources and even if they do, it can be done with just-in-time (short-term) and just-enough access (subset of resources).

• Verify that any request is authorized and authenticated in a be dynamic and strictly enforced. This means using data such as location, devices, and identity become imperative as factors to validate access

• The business measures & monitors the security posture of all assets, and uses this information to improve security posture.

• All communication is secured.

By having a never trust, always verify approach to systems, it reduces the impact when the system gets compromised.

Zero Trust Pillars

The idea of the pillars within zero trust is to give holistic coverage in all your environments. There are 5 core pillars to evaluate for zero trust. They are:

• Identity

• Devices

• Networks

• Applications & workloads

• Data

Each pillar represents a critical dimension of an organization's security strategy, working together to create a comprehensive, adaptive defense mechanism that leaves no aspect of a digital ecosystem unprotected.

Here is a breakdown of each of the pillars:

1. Identity - This is the foundation of Zero Trust, and focuses on verifying and managing identities (can include users and entities). The goal here is only the right identity can access resources at the right time.

2. Devices - Refers to assets including hardware, firmware, and software. This will include everything from IoT devices, servers, laptops to patch management, device compliance.

3. Networks - The backbone for communication of all systems, the goal is to move beyond perimeter-based security. It focuses on micro-segmentation based on application profiles, granular access controls, traffic management within the network, encryption of traffic, and network resiliency.

4. Applications & Workloads - Software and services that run on systems. This includes legacy and modern cloud-native applications. A lot of DevSecOps and AppSec best practices fit in here both from the securing during development to monitoring and providing threat protection to live applications.

5. Data - The ultimate goal for protection is to safeguard data. It covers scenarios such as encryption, data inventory management, tracking data movement, and applying context-aware protection based on data sensitivity.

The ideal state of these pillars need to have automation & orchestration setup (in a very mature and robust environment) because it becomes difficult to manage thousands of resources without having processes, visibility, analytics and governance. While this ideal state seems daunting now, the best time to start is now and work to implement, evaluate and improve over time.

Planning your rollout

There is no single product that you can purchase to achieve optimal zero trust security. Rolling out zero trust practices takes time. Even if it is a greenfield environment where such protections can be easily applied (from the onset), the team may not have the needed resources, capacity, or capability to rollout all components. These issues are exasperated for brownfield environments.

Start by assessing where in its zero trust journey the organization is currently, ideally you want to achieve an optimal state in all 5 pillars. Reality works differently, it's a negotiation with the business to understand where efforts are going to focus. The business may have other priorities over the next few months than security alone.

Your progress for some pillars may be traditional while others advanced state of maturity. In my experience, the hardest part is to get started (and really look at the skeletons in the closet), but once you begin reaching the next level of maturity is often easier. Buy-in from business, developers and even your own team can often be difficult.

So where do we begin? The following 5 steps are a great way to approach on building it out:

1. Define the protection surface - Rolling out everything to all resources in your system isn't viable given that a surface includes data, assets, applications and services. Narrow the focus and implement low hanging fruit so that it builds momentum and gives the team time to understand the nuances. Even if a partial understanding is reached and can be implemented start with that and iterate.

2. Map transaction flows - This helps to build an application profile (and understand where systems are vulnerable) and that information will be used to develop maturity within your pillars.

3. Build your Zero Trust architecture - With a full understanding of the protection surface and transition flows, an iterative design of the system architecture can be put together to meet zero trust maturity goals.

4. Develop Automated Policies - These provide governance and visibility (monitoring and analytics) into deployed resources.

5. Monitor and Maintain - as mentioned earlier in the article, to keep this zero trust current one needs to measure the security of all assets and use this to improve our security posture and evolve the architecture as required.

Unfortunately Zero Trust is not a one time activity, but more akin to a way of life. With breaches becoming more common, it is only a matter of time before it impacts your organization. The best time to start is now.

Leave a comment

This week, Code n Culture is launching The DevOps Pulse section of the newsletter. As a working engineer and architect, along with the research I do for the newsletter, I come across many different topics, articles and relevant information that can be impactful to your jobs. My goal is to collate, share and provide insights on them on a recurring basis in an easily consumable format that gives you quick insights and wins that you can take back to your teams.

GenAI + Toolchain

GenAI is popular and many leaders I've met are only considering consuming APIs from leaders in this space (think OpenAI, Claude, etc). The issues that come with these are:

• You don't own the IP

• Are just consuming a service

• Security concerns for data (if the service is hacked)

• They can be expensive at scale

• Using a managed service (ex AWS Bedrock) you're forced to deal with vendor lock-in, limited customizability, and data portability issues

With approach it may not give you the results than running your own AI toolchain. I would argue it's worth investing time to setup your toolchain as it can be reused once your focus shifts beyond LLMs into other AI domains.

If you decide to setup your own LLM, the infrastructure management can be significant. Microsoft introduced the Kubernetes AI Toolchain Operator (KAITO) that automates tasks like provisioning GPU nodes, configuring resources, and setting up inference endpoints

Link: https://github.com/kaito-project/kaito/tree/main

It's a great project to familiarize yourself with as other AI use cases beyond LLMs increases, these tools will be necessary for scaling.

Blue Yonder Ransomware + Incident Response Plan

The supply chain SaaS vendor was disrupted by Ransomware, impacting UK vendors and even Starbucks. According to Verizon, ransomware ranks as the number one threat to organizations across 92% of industries.

Link: https://go.theregister.com/feed/www.theregister.com/2024/11/26/blue_yonder_ransomware/

Even systems designed with the best of intentions and no expense spared can become compromised so having an incident response plan in place will pay dividends in case of a ransomware attack. Imagine not have access to your email, or having backed up your data - these are the kind of things being prepared for that will make your life easier in the long run.

Yes, it requires work, time and money but this is no different than you owning a fancy car and having it detailed + garage parked. Treat your infrastructure and applications the same way you would treat your prized Porsche.

Rust Taking Over Data Engineering

Sylvain Kerkour has a great article outlining why Rust is taking over data engineering. Data engineering has heavy workloads from real-time data processing, serialization to high performance databases. Rust is increasingly used due to its performance, memory safety, and concurrency capabilities.

Link: https://kerkour.com/rust-data-engineering

It's worth spending time to learn a language on which a significant number of data engineer tools and products are written. Most organizations don't/won’t have significant data storage requirements (he references an article Big Data is Dead by Jordan Tigani that is a compelling argument), unbundled databases will be the path forward and is worth learning now.

If you have come across any articles or would like to submit one to share on The DevOps Pulse, please message us using the button below.

Thoughts on this type of article? An opinion on anything that I’ve said? Disagree on my take. I am open and happy to have a discussion. Respond in the comments below (or click the button).

Leave a comment

These days I frequently get asked (and see questions posted online) on "How do I get started in DevOps?/How do I find DevOps people?" This question is asked for a whole host of reasons:

1. New CS (computer science) graduates often ask as they see the demand and how lucrative it can be

2. Mid-senior developers ask for a challenge in their fields

3. Infrastructure engineers ask as a career shift

4. Managers and executives ask to see what kind of skills they need to bring in.

What makes answering this question is there is no real "formalized" schooling for DevOps. DevOps Engineers come in countless varieties, each bringing unique skill sets shaped by their individual backgrounds. Some specialize in specific cloud platforms like Azure or AWS, others transition from development backgrounds, and some discover through their infrastructure roles that they're already practicing DevOps, often with gaps in their knowledge.

Good DevOps engineers require a significant amount of technical knowledge, a solid understanding of people, process and technology and have experience applying across teams in organizations.

But where do we begin?

The best resource that I have found to answer this question is a roadmap for beginners called DevOps Roadmap (https://roadmap.sh/devops?r=devops-beginner). This roadmap does a wonderful job of highlighting from a technical perspective the skills and experience required. Its best used in the following two ways:

1. Technical resources (junior to senior) should use it as a way to see what areas they need to skill up on in conjunction with their job/role/industry.

   1. For example, DevOps Engineers should learn a programing language but this could be: Python, Go, Ruby, Rust etc. so pick based on the one that is being used at your job or in the jobs you are targeting

   2. Once you learn one language, learning a second one is easier. If it's a compiled language try scripting or vice-versa.

2. Managers and executives can use this as a template to build hiring/training strategies for DevOps. If someone wants to grow in their role, this is an excellent starting point to build a foundation.

From a hiring perspective, it highlights the types of technical skills you're looking for.

That said, I've compiled my thoughts on what is missing and how to fill those gaps:

1. Where to begin - As much as we would like to follow a roadmap linearly, DevOps skills are a puzzle that needs to be pieced together. I usually recommend starting to learn skills that are on the opposite side of the spectrum of what you do daily.

   • Example: If your focus is on development then operations might be a great place to start; Infrastructure as Code such as Terraform will be easier to learn and adopt; but learning the underlying principles for infrastructure are key before diving into the deep end.

2. Architecture - Jumping in to learn the details is what we generally do in IT, but having a big picture view of how systems are designed is key to being a good DevOps engineer (or when looking to hire one). If your experience today is with software systems and architectures, it needs to be augmented learning around infrastructure architecture and vice-versa. It's important to understand how these different types of architectures impact each other and limitations they produce.

   • Example: Monolithic software architectures will have limitations when the infrastructure architecture is focusing on resiliency and scalability.

3. Security - There is an entire sub-culture within DevOps that focuses around security (DevSecOps and AppSec). I would argue that security is fundamental to DevOps and needs to be incorporated early in the DevOps learning journey.

   • Begin by learning best practices, maturity of DevSecOps and AppSec can come later. A great place to start is by looking at Open Web Application Security Project (OWASP) Application Security Verification Standard (ASVS).

4. DevOps tooling - Understanding how DevOps tools work and what they are solving. It isn't enough just to learn how to use a tool.

   • Example: When you begin incorporating code quality checkers into your pipeline, the frustration from false positives (items flagged as issues but aren't) will be high. Knowing how those tools work and being able to refine the It's a passage of sorts and worth learning integrating these into pipelines.

   • Example 2: Adopting package management to have approved feeds for projects, or software composition analysis to understand potential conflicts of open source licenses.

5. Process - This roadmap focuses entirely on technologies and I would argue processes are just as important if not more.

   • Example: Learning a programming language is incomplete if you don't understand sprints and the pressures development teams face.

   • Example 2: Docker is great to understand but what you want to augment with that is container management. This way when you look at Kubernetes it will easier to understand the lifecycle of pods and how docker containers fit into it.

In case you're wondering how containerization fits into Kubernetes and the architecture I have a course on LinkedIn Learning that goes into details (Link Here).

The key to remember is that you don't need to learn it once (or that every skill is needed for a successful candidate). A good attitude for learning is key to be successful in DevOps. Taking one area and learning a skill, then refining it over time along with complementing work experience (getting involved with guilds is also a good way to get experience if its out of your scope of work) will make it a manageable experience.

What are the key skills you think you (or DevOps engineers) are missing? Comment below.

Leave a comment

Remember, maturity takes time, and that is a topic for a different day.

Subscribe now