Envision Stage

In our Pathfinder journey to establish a Cloud Center of Excellence (CCoE), we begin with the Envision Stage—the first of the stages. This stage creates a common frame of reference for your organization to define the CCoE’s purpose, structure, and alignment within the organization. If you haven’t read the introduction to this series, check out the first post: Building a Cloud Center of Excellence: The Pathfinder Journey .

Assembling the Pathfinder Team

Before the actual CCoE is established, a Pathfinder Team is formed. This team is responsible & accountable for implementing the Pathfinder Roadmap, a framework designed to guide organizations through cloud adoption and governance. It’s important to note that the Pathfinder Team is separate from the eventual CCoE members—it plays a critical role in shaping the foundational elements of the CCoE.

Introduction

The concept of a Cloud Center of Excellence (CCoE) is well-documented, and many organizations recognize its added value in driving innovation and operational efficiency. However, while there is a wealth of information on what a CCoE is, practical guidance on how to effectively implement one is often lacking, leaving organizations with more questions than answers. Even comprehensive resources like Microsoft’s Cloud Adoption Framework primarily focus on the functions of a CCoE in its end-state without delving into the intricacies of its establishment.

This is the 6th post in the category Azure DevOps Fundamentals of the blog post series on working with Azure DevOps .

In this post, I will break down Work Items in Azure Boards. Work Items are the foundation of tracking work in Azure DevOps, and understanding them is crucial for effectively managing projects. We will explore:

• The different types of Work Items.
• How Work Items tie into the Work Item Process.
• The hierarchy of Work Items.
• Where and how Work Items can be created.
• Ownership and refinement responsibilities for each Work Item level.
• Additional useful Work Item features.

Let’s dive in!

Introduction

Managing compliance and governance in the cloud can be challenging, especially when it comes to an often overlooked yet critical system: your Azure DevOps organization. Ensuring proper auditing with securely stored logs in a centralized location is vital. Audit streams address this need by enabling you to send audit logs to a Log Analytics Workspace for detailed analysis and monitoring.

In this blog post, we’ll explore how to automate the configuration of Azure DevOps audit streams using PowerShell. We’ll focus on using a fully working script that not only automates the setup process but also ensures drift control. This guarantees that audit logs are consistently sent to your desired Log Analytics Workspace without the need for manual intervention. Let’s dive in!

Understanding the Need for Management Group Automation

Managing Azure subscriptions at scale can become challenging. Management groups provide a powerful way to organize and govern resources, but manually configuring them introduces inefficiencies and risks. A common pitfall is hardcoding management group structures into deployment code, which reduces flexibility and can compromise governance. This post introduces Management Group Vending, a reusable Bicep solution inspired by Microsoft’s Subscription Vending . This solution enables you to deploy any management group hierarchy, considering Azure’s limitations while adhering to Cloud Adoption Framework (CAF) principles.

In my previous Decoding Microsoft Azure post, 🔍 Decoding Microsoft Azure: Understanding Platform, Landing Zones, Workloads, and Utilities ⚙️ , I introduced the house analogy to conceptually explain Microsoft Azure . Part of this analogy covered the Application Landing Zone and the Platform Landing Zone.

In this post, I’ll take a deeper dive into Landing Zones. We’ll explore what they are, how they’re defined by Microsoft, and how I believe we can improve upon the concept. By the end, you’ll have a clearer understanding of Azure Landing Zones and how they fit into a broader cloud adoption strategy.