Module 1: Business Processes

Modern organizations are inseparable from their information technology infrastructure. Whether a company manufactures physical goods or delivers digital services, the hardware, software, and networks that constitute its IT environment shape what the organization can accomplish, how quickly it can respond to market changes, and how effectively it can serve its customers. BET 210 provides a conceptual map of this landscape — not by teaching programming languages, but by building the managerial and analytical fluency needed to understand IT operations, assess systems, and communicate effectively across the boundary between business and technology.

The course uses The Phoenix Project as a running case study — a novel depicting the chaos and eventual rescue of IT operations at a large manufacturing and retail company in the automotive industry. The protagonist, Bill Palmer, steps into the role of Vice President of IT Operations on the same day a payroll system crisis erupts across the organization. What begins as a story of firefighting and damage control becomes a structured account of organizational transformation: from an IT function dominated by unplanned emergencies to one that operates with discipline, visibility, and strategic purpose.

A key early lesson from the novel concerns change management. Even seemingly minor modifications to hardware or software — ones that appear inconsequential — must be documented and approved. An undocumented change to the payroll system triggers company-wide chaos. The incident underscores a foundational principle: in a complex, interdependent IT environment, there are no truly isolated changes. Every modification ripples outward in ways that can only be tracked if the change was recorded in the first place.

What Is a Business?

A useful framing for business processes comes from Michael Porter’s concept of the value chain: the sequence of activities through which a firm creates value for its end customers. Porter identifies two categories of activities within a firm.

Primary activities are those that directly create and deliver the product or service:

• Inbound Logistics — acquiring the inputs required to deliver the product or service (raw materials, components, data).
• Operations — transforming those inputs into something of value (manufacturing, processing, service delivery).
• Outbound Logistics — getting the finished product or service to the customer (shipping, distribution, digital delivery).
• Marketing and Sales — informing customers of the available product and facilitating the economic exchange.
• Service — managing post-sale interactions (warranty, support, returns) that influence customer satisfaction and perceived value.

Support activities do not directly create customer value but are essential for the firm’s successful operation: procurement (acquiring all organizational inputs), technology development (design, simulation, knowledge management), human resources management, and firm infrastructure (facilities, finance, legal).

To make this concrete: consider a bread manufacturer. Inbound logistics manages flour, yeast, and packaging suppliers. Operations mixes and bakes the loaves. Outbound logistics ships finished product to grocery retailers. Marketing and sales negotiate shelf space and inform consumers. Service manages complaints about stale product or late deliveries. The same framework applies to a service business — an accounting firm completing tax returns, for instance — with the activities taking different forms.

Supply Chains

Related to the value chain is the supply chain — the network of firms that provide the inputs consumed at each stage of a value chain. At each node in the chain, the receiving firm performs its own value chain activities, transforming inputs and passing outputs downstream. Supply chains can become extraordinarily complex: a large retailer like Canadian Tire sources from hundreds of suppliers whose own supply chains extend further back. From an IT perspective, supply chain complexity drives requirements for inter-company information exchange, inventory tracking, and delivery coordination.

IT Across the Value Chain

Information technology is embedded in every primary and support activity, though the specific systems vary by industry and organizational type. Consider a manufacturing firm:

Inbound Logistics may use inventory tracking systems, broker management software (matching shippers to freight services), and supply chain management systems that coordinate delivery schedules with upstream suppliers.

Operations may rely on Materials Requirements Planning (MRP) — software that calculates the materials and components needed for scheduled production runs — as well as maintenance management systems, workforce scheduling tools, and production line monitoring.

Outbound Logistics requires warehouse management systems, shipping interfaces (connecting to carriers like FedEx or UPS), fleet maintenance software for company-owned vehicles, and order management tools that confirm delivery to customers.

Marketing and Sales increasingly depends on Customer Relationship Management (CRM) systems (such as Salesforce), business intelligence and data analytics tools that identify patterns in customer behaviour, e-commerce platforms, content management systems, and search engine optimization tools. The phrase “high touch marketing requires high tech” captures the idea that building responsive, personalized customer relationships requires significant IT investment in analytics, CRM, and communication infrastructure. An incoming service call, for instance, is most effective when the representative can immediately access the customer’s full purchase and interaction history — a capability that depends entirely on a well-maintained CRM.

Service uses call centre management platforms, FAQ and knowledge management systems, field service dispatch software, and return management tools.

On the support side, Procurement uses supplier management, order management, and inventory tracking systems. Technology Development employs simulation software, Computer-Aided Design (CAD), document management, and project management tools. Human Resources manages employee databases, payroll systems, and document management for onboarding, benefits, and compliance. Finance operates accounting systems, budgeting tools, accounts payable and receivable systems, cash-flow management, and audit-support software. Firm Infrastructure encompasses communications systems, facilities maintenance, work order management, and workflow management.

The key insight is that IT is not a single “department” but a competency distributed throughout the organization, with different systems supporting different parts of the value chain. As Bill Palmer comes to understand in The Phoenix Project: “IT is not simply a department. It is a competency critical to the company.” Effective IT management therefore requires understanding the business processes being supported — not just the hardware and software.

Module 2: Business Process Modelling

Having established that organizations run on business processes, the next challenge is representing those processes clearly enough to analyze, improve, and automate them. Business process modelling is the practice of creating formal representations of how an organization processes information or materials to achieve its objectives. A well-constructed model serves multiple purposes: a business analyst can use it to diagnose inefficiency, a developer can use it to design an automated workflow, and an executive can use it to communicate organizational change. Critically, modelling forces precision — it surfaces gaps and ambiguities in process understanding that informal descriptions leave hidden.

Process Narratives and Storyboarding

When mapping a business process for the first time — or reviewing one to determine whether it has changed — a useful starting point is process narratives and storyboarding. A process narrative is a plain-language description of what people do: who is involved, what artifacts they work with, and what happens at each step. The narrative then becomes a storyboard: a sequence of illustrated scenes, each depicting one episode in the process.

Consider mapping the onboarding process for a new employee. The storyboard might begin with an HR representative presenting the employment agreement. The next scene shows the employee’s information being manually carried to another desk and entered into an employee database. Another scene shows the employee completing a weekly paper timesheet. A final scene shows the employee receiving a paycheck — but with a gap: something “magical” appears to happen between timesheet entry and paycheck production. That gap signals an incomplete understanding of the process: critical steps are missing from the model.

Storyboarding is particularly effective because it is accessible to non-technical stakeholders and encourages teams to surface workarounds — the informal adaptations that people develop around poor interfaces or broken processes. Humans are very good at finding informal solutions to inadequate systems; storyboarding makes those workarounds visible. Questions to ask at each scene include: What inputs does this step receive? Who performs it? What system or tool is used? What does the step produce? What happens when something goes wrong?

Business Process Modelling and Notation (BPMN)

Once the narrative understanding of a process is established, Business Process Modelling and Notation (BPMN) provides the standardized visual language to represent it formally. BPMN uses a defined set of symbols that can be understood by both business stakeholders and technical implementers.

Key BPMN concepts include:

• Pools and Swimlanes — A pool represents an entire organization or process. Within the pool, swimlanes partition responsibility by actor (e.g., Employee, HR, Payroll System). Each task appears in the swimlane of the actor responsible for it.
• Events — Start events (circle) and end events (thick-bordered circle) mark the beginning and end of a process.
• Tasks — Rectangles represent individual activities.
• Gateways — Diamond shapes represent decision points where the flow branches (exclusive gateway) or where parallel paths merge or split.
• Sequence Flows — Arrows connecting events, tasks, and gateways, showing the order of operations.
• Message Flows — Dashed arrows showing communication between separate pools.

A BPMN diagram of a payroll process, for instance, would show swimlanes for the employee, the HR clerk, and the payroll system, with sequence flows tracing the timesheet from completion through entry to paycheck generation. The diagram makes immediately visible which actor is responsible at each step, what decisions are made (is the timesheet error-free?), and where information crosses organizational boundaries.

Software tools for creating BPMN diagrams include Microsoft Visio and Lucidchart. The key workflow is: start with a process narrative, turn it into a storyboard, and then formalize it as a BPMN diagram, adding detail and precision at each stage.

Unified Modelling Language (UML)

While BPMN captures operational workflows, Unified Modelling Language (UML) is the standard notation for designing software systems. UML provides a family of diagram types that collectively describe how a software system is structured and how it behaves.

The entry point for UML in this course is the Use Case Diagram, which provides a high-level representation of the features and functions of a system being developed or maintained. Key components include:

• Actors — The entities (people, other systems) that interact with the system. A primary actor initiates an interaction; a secondary actor is called upon by the system. In a payroll system, the employee is a primary actor (submitting a timesheet) and the payroll database is a secondary actor (providing stored records).
• Use Cases — Ellipses representing distinct functions the system performs (e.g., “Submit Timesheet,” “Approve Timesheet,” “Generate Paycheck”).
• System Boundary — A rectangle enclosing the use cases, distinguishing what is inside the system from external actors.
• Relationships — Lines connecting actors to the use cases they participate in.

A UML use case diagram generated from a BPMN process model makes the leap from “how does the business process work?” to “what must the software system support?” UML also includes activity diagrams (similar to flowcharts, suitable for both business processes and software logic), sequence diagrams (showing message flows over time), class diagrams (defining data structures), and deployment diagrams (showing system topology). These additional diagram types become relevant as software design progresses beyond the initial requirements stage.

The Software Development Life Cycle

The Software Development Life Cycle (SDLC) provides the broader context for these modelling tools. It is the end-to-end framework governing how software is conceived, designed, built, tested, deployed, and eventually retired. Process models feed directly into SDLC activities: a BPMN diagram of a manual process becomes the specification for its automated replacement; UML use cases become the basis for software requirements.

The SDLC is not a single fixed process but a framework that different methodologies instantiate differently. Agile and Waterfall represent two archetypal approaches that Module 9 examines in detail.

Module 3: Basic IT Infrastructure

Every modern organization depends on an IT infrastructure — the ensemble of hardware, software, and networking components that enable digital operations. Understanding this infrastructure at a conceptual level is essential for anyone who will make or influence decisions about technology investment, architecture, or change.

Hardware Fundamentals: From Home to Data Centre

A useful way to understand IT infrastructure is to build it up from familiar components. Start with a home computing environment: a laptop, a desktop PC, a Wi-Fi-enabled printer/scanner, and a smartphone. Without any network connecting them, these devices are islands — they cannot easily transfer files or share services.

Adding a router connects the wireless devices over Wi-Fi (shown as dashed connections in network diagrams) and provides a wired connection for devices lacking wireless capability. The router enables devices on the local network to communicate with one another and share resources like printers and storage drives. This local network is a LAN (Local Area Network).

To reach the internet, a modem is required. The modem connects the local network to the Internet Service Provider (ISP), a company that provides a gateway to the wider internet. Common modem types include:

• ADSL (Asymmetric Digital Subscriber Line) — uses the existing telephone line; asymmetric means download speed is higher than upload speed.
• Cable modem — connects via the coaxial cable used for television.
• Fibre optic — uses light transmission through a cable for very high-speed communications.

When a user types a web address (URL) into a browser, the request travels through the modem and ISP to a DNS (Domain Name System) Server, which translates the human-readable domain name into a numerical IP (Internet Protocol) address (e.g., 123.456.789.012) that routing hardware can understand. With the IP address resolved, the request is routed to the destination web server.

Inside the Client

Every computing device is built around a motherboard — the main circuit board that connects the CPU (Central Processing Unit), RAM (Random Access Memory), and input/output controllers for devices like keyboards, mice, monitors, and network adapters. The operating system (Windows, macOS, Linux) sits above the hardware, managing system resources — CPU scheduling, memory allocation, device access — and presenting an environment in which applications can run. Applications in turn run atop the operating system, using its services without needing to manage hardware directly.

The CPU is characterized by its clock speed (in GHz) and its number of cores. Each core can independently execute a thread — a unit of program execution. A multi-core CPU can run multiple threads simultaneously, enabling faster execution of programs designed to take advantage of parallelism.

The Client-Server Model

The most fundamental distinction in IT infrastructure is the client-server model.

The clean separation between client and server underlies almost every digital interaction. When a browser loads a webpage, it is a client requesting content from a web server. When a mobile app checks for messages, it is a client querying a server.

The number of clients a server can effectively handle is a function of its CPU characteristics and available RAM. For high-traffic environments, organizations build data centres (also called server farms): facilities containing hundreds or thousands of servers, potentially requiring millions of square feet of space, with very high power and cooling requirements.

Network Configurations

Networks vary in scale from a LAN (Local Area Network) covering a single office to a WAN (Wide Area Network) spanning continents. Common network topologies include:

• Star — all devices connect to a central hub or switch; failure of the hub affects the entire network.
• Mesh — devices connect directly to multiple other devices; highly resilient.
• Bus — all devices share a single communication line; simple but vulnerable to single points of failure.
• Ring — devices form a loop; data travels around the ring until it reaches its destination.

Operating Systems

The operating system (OS) mediates between applications and hardware. Its core functions include CPU scheduling (determining which process runs when), memory allocation (assigning RAM to running programs), and I/O device management (coordinating access to disks, keyboards, displays, and network interfaces). Different operating systems — Windows, macOS, Linux, and their server-specific variants — make different trade-offs in performance, security, usability, and cost that matter when provisioning infrastructure. Server operating systems typically offer features like remote management, higher uptime guarantees, and support for multiple simultaneous users that consumer operating systems do not.

Server Types

Servers can serve different roles within a network:

• Web servers — respond to HTTP/HTTPS requests, delivering web pages and web application content.
• File servers — provide shared storage accessible to multiple clients (analogous to cloud file services like Dropbox).
• Email servers — manage the sending, receiving, and storage of email messages.
• Database servers — host database management systems and respond to queries from applications.

In practice, a single physical server can run software that fulfils multiple roles, and a single logical role (like hosting a high-traffic website) may be distributed across many physical servers.

Module 4: Computing in the Cloud

Cloud computing has transformed how organizations acquire, configure, and operate IT infrastructure. Rather than purchasing physical servers and housing them in on-premises data centres, organizations can now rent computing resources on demand from providers such as Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform, and IBM Cloud.

Key Infrastructure Considerations

When an organization decides whether to host systems on-premises or in the cloud, it must evaluate several dimensions:

Security rounds out these considerations: who can access the system, how is sensitive data protected, and what compliance obligations must the organization meet?

Cloud Service Models

Cloud providers offer infrastructure at different levels of abstraction, each trading off control for convenience:

Cloud Deployment Configurations

Public cloud configurations (AWS, Azure, Google Cloud) are accessible to any paying customer. The infrastructure is shared across many tenants, with isolation provided by virtualization.

A private cloud is exclusive to a single organization and operated on their behalf. It provides the benefits of cloud computing (scalability, managed infrastructure) without sharing infrastructure with other tenants — important for organizations with strict security, compliance, or data sovereignty requirements.

A hybrid cloud combines elements of both. For example, an organization might place factory operations and financial systems on a private cloud (for security and performance) while using a SaaS CRM like Salesforce on the public cloud.

Virtual Private Networks (VPNs) can be hosted by service providers to give organizations the appearance and security properties of a private network while leveraging the provider’s infrastructure.

Virtualization and Virtual Machines

Virtualization is the enabling technology that makes cloud economics possible.

In a virtualized system, the physical machine is the host; the VMs running on it are the guests. Between the hardware and the guest VMs sits a software layer called the hypervisor (or virtualization management system). The hypervisor can be implemented in two ways: as a standalone operating system that interfaces directly with hardware (Type 1, “bare metal”), or as software running atop an existing operating system (Type 2, “hosted”).

The course distinguishes several types of virtualization:

A potential drawback of VMs is performance overhead: because the hypervisor must schedule each VM’s access to physical hardware, VMs may run somewhat slower than native applications.

Containers and Kubernetes

An alternative to full virtualization is containerization. Containers package an application and its key software dependencies (libraries, configuration) but share the host operating system, rather than each running a separate OS. This results in lower computing overhead and greater efficiency: many more containers than VMs can run on the same physical machine.

As the number of containers in a system grows into the hundreds, managing them manually becomes impractical. Kubernetes — container orchestration software open-sourced by Google — automates the grouping, scheduling, scaling, and load balancing of containers across large server clusters. Kubernetes has become the standard tool for managing container-based systems at scale.

Module 5: Application Development

Software applications are the layer through which organizations realize the value of their IT infrastructure. Understanding how software is built — and managed — is increasingly important for business professionals who must collaborate with development teams, evaluate build-versus-buy decisions, and articulate requirements across the business-technology boundary.

What Is Software?

Software can be thought of as a sequential set of instructions that tells a computer what to do to achieve some outcome. More formally, a program takes a set of inputs and transforms them into a set of outputs. When a user presses keys on a keyboard, operating system software reads those inputs from hardware and makes them available to other programs. A calculator program receives the keystrokes, performs arithmetic, and displays the result — all mediated by the operating system.

Software Development Processes

Software development is broadly a process of analysis, design, development, testing, and implementation:

• Analysis — Eliciting and modelling the system’s requirements: understanding what the software is intended to do.
• Design and Development — Creating a software design based on the analysis, then coding (“developing”) the design.
• Testing and Implementation — Verifying the software works correctly, then releasing it to users (deploying it to “production”).

This cycle of development, ongoing maintenance, and eventual replacement is the Software Development Life Cycle (SDLC). Multiple approaches exist for structuring it:

The Waterfall Model is the oldest and most sequential. Requirements are gathered exhaustively upfront, a design is finalized, development takes place, testing follows, and the finished product is delivered. Work Breakdown Structures (WBS) are a common planning tool. Waterfall is best suited for projects where requirements are stable and can be completely defined before development begins — rare in practice, which is why Waterfall has largely given way to more iterative approaches.

The Spiral Model is incremental and iterative: the project is broken into cycles, each of which revisits risk assessment, requirements, design, and prototyping. It accommodates changing requirements better than Waterfall.

Agile is the most widely adopted iterative approach today. Requirements are broken into smaller chunks and developed in short cycles, with working software delivered frequently. Agile is explored in depth in Module 9.

DevOps (Development-Operations) brings development and operations teams together much earlier in the process — rather than handing finished software from development to operations as a discrete event. DevOps treats the release process itself as a continuous activity, which Module 11 examines in detail.

Software Architecture and Modularization

One of the main challenges in software development is problem decomposition — dividing a large problem into pieces that can be solved independently. This challenge is addressed through modularization: breaking software into logical units called modules. Ideally, modules can be developed independently, with simple, well-documented interfaces between them.

Two properties characterize well-designed modules:

• Cohesion — each module does one thing well. High cohesion means the elements within a module are closely related in purpose.
• Low coupling — modules depend minimally on the internal details of other modules. Low coupling means a change to one module is unlikely to require changes elsewhere.

These properties make individual modules testable in isolation, replaceable without cascading rewrites, and understandable in their own right. Poor modularization — where everything depends on everything else — produces systems that are brittle, expensive to change, and difficult for new developers to understand.

Good software design also prioritizes documentation. If information required to use a module is not obvious, it must be clearly documented. Hidden dependencies (things that must be understood but are not stated) are a significant source of defects and maintenance burden.

Databases

Relational databases organize data into tables with defined relationships between them (connected by keys). SQL (Structured Query Language) is used to query and manipulate relational data. Non-relational (NoSQL) databases offer alternative structures — document stores, key-value stores, graph databases — optimized for different workloads such as large volumes of unstructured data or highly connected data.

Service Architectures and APIs

As systems grow in complexity, different architectural patterns become more important.

Consider a simple contact manager program: a monolithic application containing a database and three modules (enter client data, search client data, update contact notes). It runs on a single machine, serves one user, and cannot easily be extended. Now suppose the application needs to display customer addresses on a map. Rather than building a mapping system from scratch, the application can call Google Maps through a publicly available web service.

This illustrates Service-Oriented Architecture (SOA): features are broken into smaller units delivered by independent services. Each service exposes its functionality through a well-defined Application Programming Interface (API) — a contract specifying what requests the service accepts and what responses it returns.

The Google Maps Static API, for example, accepts an HTTP request containing a location (e.g., “Brooklyn+Bridge,New+York,NY”), zoom level, map size, and type, and returns an image of the requested map. The calling application does not need to know how Google stores map data — only how to form the request and interpret the response.

In a cloud-based system, a large number of services communicate through APIs. If each internal module is itself deployed as an independently manageable service, the architecture is called microservices. Microservices offer development advantages (teams can develop, deploy, and scale individual services independently) but introduce operational complexity (managing many small services requires robust orchestration, monitoring, and API versioning). Every architecture involves trade-offs, including impacts on response time and operational overhead.

Module 6: IT Management Priorities

A functioning IT operation is not merely a collection of servers and software; it is an organizational capability that requires active management. This module examines the priorities that drive IT management decisions and the types of work that occupy IT organizations daily.

Uptime and Mean-Time-to-Repair

A key operational objective for any IT organization is providing reliable service. The dimension most immediately felt by users is uptime — the proportion of time a system is available for use. In some enterprise contexts, systems target 99.999% availability (sometimes called “five nines”), which corresponds to no more than approximately five minutes of downtime per year. Achieving this level of reliability is technically demanding and operationally expensive: it requires well-managed processes, extensive automation, redundant hardware, and continuous monitoring.

When failures do occur, the recovery speed is measured as Mean-Time-to-Repair (MTTR), also called Mean-Time-to-Resolve — the average elapsed time between a system failure and its resolution.

MTTR encompasses time to detect the failure, time to diagnose its cause, and time to implement the fix and restore service. Reducing MTTR is a primary driver of investment in monitoring infrastructure, incident management practices, and on-call operations. The relationship between availability and MTTR is direct: a system that fails infrequently but takes hours to restore will have worse overall availability than one that fails more frequently but recovers in minutes.

Value Streams in IT

To understand how an IT organization impacts operations, it is necessary to examine how it contributes to the delivery of value. The concept of a value stream — introduced in Module 1 — applies directly here.

Value stream mapping extends process modelling by attaching quantitative data to each step: the lead time (total elapsed time to complete the step), the value-added time (the portion of lead time actually spent transforming the input into something useful), and the percent complete and accurate (%CA) (a measure of the quality of the step’s output).

To illustrate: in a manual payroll process, completing a weekly timesheet might have a lead time of one hour (to find the paper form and fill it out) but a value-added time of only 15 minutes (the actual filling-in). The remaining 45 minutes is non-value-adding time — searching for the form, waiting, handling misplacements. If 25% of timesheets have errors, the %CA is 75%. When this analysis is applied across all three steps of the process (timesheet completion → payroll entry → paycheck generation), the course example reveals a total lead time of 41 hours to accomplish only 45 minutes of value-added work. The mapping identifies where process improvement effort will have the greatest impact.

Value stream mapping can also be integrated into BPMN diagrams: lead time, value-added time, and %CA information can be added at each process step, making the BPMN diagram a richer tool for operational analysis.

The Four Types of Work

A critical framework for understanding IT workload comes from the four types of work that appear throughout The Phoenix Project:

Business Projects originate from and are sponsored by parts of the business organization. They address strategic priorities — expanding IT capacity, launching a new product feature, digitizing a manual process. Business projects typically have formal budgets and cross-functional stakeholders.

Internal IT Projects are identified by the IT operations group as important for improving system reliability, reducing MTTR, or building future capacity. They are budgeted within the IT department and managed internally. Examples include upgrading monitoring infrastructure, automating a deployment step, or replacing end-of-life hardware.

Changes and Updates are modifications to existing production systems — operating system patches, application updates, configuration changes. At organizational scale, what appears to be a routine update can have company-wide implications. Changes and updates must be planned and carefully executed to avoid disrupting production.

Unplanned Work — referred to in the novel as “firefighting” — encompasses hardware failures, software defects discovered in production, security incidents, and other emergencies that demand immediate attention. Unplanned work is the most disruptive category because it preempts planned work, generates further unplanned work downstream, and is inherently unpredictable. The novel dramatizes what happens when unplanned work consumes an IT organization entirely: no capacity remains for the strategic improvements that would reduce future unplanned work, creating a self-reinforcing spiral of crises.

An important principle: IT operations should seek to ensure that unplanned work is not “self-inflicted” — that is, not caused by poorly planned changes to production systems. Every change introduced without sufficient testing or approval is a potential source of future unplanned work.

Production and Non-Production Environments

The production environment is the live system serving customers. Non-production environments include development (where code is written and initially tested), staging (a production-like environment for final validation), and testing (where quality assurance activities take place). Changes that have not been validated in lower environments should never reach production. The stakes of a production failure are direct and measurable — in lost transactions, degraded customer experience, and reputational damage.

Module 7: Cybersecurity

Cybersecurity has become one of the most consequential domains of IT management. As organizations digitize operations, partner ecosystems, and customer data, the attack surface they present to adversaries grows correspondingly. Understanding cybersecurity is no longer the exclusive concern of IT specialists; at every level of an organization, individuals make decisions that create or close security vulnerabilities.

The complexity of modern cybersecurity is driven by increasing connectivity and technologies such as the Internet of Things (IoT) — networks of smart devices including power meters, appliances, and home security systems — and the proliferation of mobile banking and financial transactions.

Malware

Viruses are programs that insert code into other legitimate programs and can spread to other computers. They require an infected host program to execute.

Worms are self-replicating malware that spread independently through a network, launching disruptive code on each computer they infect. Unlike viruses, worms are standalone programs — they do not require a host. The Stuxnet worm (first identified in 2010) is the most famous example: a sophisticated, state-sponsored cyber weapon that lay dormant until it encountered specific industrial control systems (Iranian nuclear centrifuge controllers), then activated to cause physical damage.

Trojan horse software creates a “back door” — an alternate entry point into a system — that attackers can use to access stored information. Unlike viruses and worms, trojans do not self-replicate.

Ransomware encrypts the files on an infected machine, making them inaccessible. The attacker then demands a ransom (typically in cryptocurrency) in exchange for the decryption key. Ransomware has been used against hospitals, municipalities, and businesses, with devastating operational and financial consequences.

Spyware monitors activity on a target computer — recording keystrokes, capturing screenshots, tracking user behaviour — and transmits collected information back to the attacker. Unlike viruses and worms, spyware does not self-replicate; infection typically occurs through malicious websites or downloaded content.

Types of Cyber Attacks

Man-in-the-Middle (MITM) attacks place the attacker in the communications path between two parties. Once positioned, the attacker can intercept and potentially modify messages. A compromised Wi-Fi router (such as a public hotspot) or an infected browser can enable MITM attacks. A Man-in-the-Browser (MITB) variant involves malicious code injected into the browser that redirects users to fraudulent websites while making them believe they are at the legitimate site.

Phishing uses deceptive messages — typically emails — designed to appear as if they come from a trusted source (a bank, a vendor, a colleague). The goal is to trick the recipient into revealing credentials, clicking a malicious link, or installing malware. Spear phishing is a targeted variant directed at a specific organization or individual, using personalized information to increase credibility. Because phishing exploits human psychology rather than technical vulnerabilities, it is classified as social engineering.

Denial-of-Service (DoS) attacks overwhelm a target system with traffic, making it unavailable to legitimate users. Since a single machine generates limited traffic, attackers typically use Distributed DoS (DDoS) attacks: networks of compromised machines (botnets) infected by worms and controlled remotely, directed simultaneously at the target.

Zero-day exploits take advantage of undiscovered vulnerabilities in hardware, firmware, operating systems, or applications. The term “zero-day” refers to the time between when a vulnerability is first exploited in the wild (day zero) and when it is patched. During this window, systems remain exposed even if they are running fully up-to-date software.

Cyber Defence: Layers of Protection

Cyber defence is organized in layers — often called defence-in-depth — combining proactive and reactive measures.

Proactive measures aim to prevent attacks before they occur:

• Cybersecurity hygiene training — educating employees about phishing, social engineering, password management, and proper handling of sensitive information.
• Password management — enforcing strong password policies and two-factor authentication (2FA), which requires a second verification factor (a code sent to a phone, a hardware token) in addition to a password.
• Physical security — controlling access to data centres and server rooms.
• Firewalls — hardware, software, or hybrid systems that block unauthorized traffic based on configurable rules (blocking specific IP addresses, restricting unused network ports). Of the 65,000+ TCP ports available for communications, most systems only need a handful; firewalls block unused ports to reduce the attack surface.
• Patch management — keeping all software updated. Zero-day exploits become ordinary vulnerabilities once a patch is released, but only if systems are updated promptly.

Reactive measures come into play after a breach has occurred:

• Network traffic analysis — monitoring for unusual patterns that may indicate an ongoing attack.
• System isolation — disconnecting compromised systems to limit the spread of damage.
• Forensic analysis — investigating how the attacker gained access and what was compromised, to prevent future incidents.
• Risk management procedures — notifying regulators of data breaches, resetting credentials, communicating with affected customers.

The human dimension of cybersecurity cannot be overstated. Phishing, social engineering, and credential mishandling are consistently among the leading vectors for breaches. Technical controls are necessary but not sufficient; building a security-aware culture is equally important. DevSecOps — the integration of security practices into every phase of the software development and deployment pipeline — represents the organizational response to this reality, treating security not as a compliance checkpoint but as a continuous discipline built into development from the start.

Module 8: Streamlining Workflow

Many of the most effective approaches to IT operations improvement derive not from technology but from principles developed in manufacturing. This module examines three frameworks — Kanban, the Theory of Constraints, and the Three Ways of DevOps — that together provide a coherent approach to managing and improving IT workflow.

Lean Manufacturing and the Toyota Production System

Lean thinking originates in the Toyota Production System, developed over decades of manufacturing practice and formalized by researchers including Jeffrey Liker. The core idea is that processes can be continuously improved by identifying and eliminating waste — any activity that consumes resources without adding value from the customer’s perspective.

The objective of a lean process is to deliver:

• Best possible quality
• Lowest possible cost
• Shortest delivery time

Lean achieves these objectives through mechanisms like reduced batch sizes (working on smaller units of work at a time), shortened work intervals, and building quality in at each stage rather than inspecting it at the end. These principles transfer directly to IT operations and software development.

Kanban Boards

Kanban is a lean tool for managing workflow through visualization and work-in-progress limits. Originating in the Toyota Production System, Kanban has been widely adapted for software development and IT operations.

A basic Kanban board consists of:

Task cards representing individual units of work. Effective task cards describe work that can be completed in hours or days — not weeks or months. A card that says “build the house” is too large to be useful; “order doors and windows” is a well-defined, completable task. Good tasks have a clear definition of done.

Columns (queues) representing stages in the workflow. At minimum:

• Prioritized Backlog (To-Do) — tasks committed to but not yet started
• Work-in-Progress — tasks currently being worked on
• Complete — tasks that are finished

An optional leftmost column holds the full list of known tasks for a project (the backlog), from which tasks are pulled into the Prioritized Backlog based on priority and resource availability.

The WIP Limit is the most important feature of the Work-in-Progress column: a maximum number of tasks that can be in progress simultaneously. The WIP limit prevents overloading team members, which leads to context switching, decreased quality, and longer cycle times. When the WIP column is full, no new tasks can start until one completes. This creates productive pressure to finish work rather than accumulate it.

The Kanban board makes invisible work visible. Bottlenecks become apparent in real time as tasks accumulate in specific columns, signalling a constraint downstream. Software tools like Trello implement Kanban boards digitally, enabling distributed teams to manage work using the same principles.

Theory of Constraints

In any process, there is always at least one bottleneck — the step that limits the flow of the entire system. Improving any other step does not improve overall output; it merely creates inventory (work piling up) in front of the bottleneck.

In IT, bottlenecks frequently appear at:

• Code review — scarce senior developers reviewing all commits
• Testing environments — shared environments that create queues
• Change Advisory Board (CAB) meetings — infrequent approval meetings that batch changes and create waiting

The Theory of Constraints prescribes a disciplined approach: identify the bottleneck, exploit it (make the bottleneck as productive as possible), subordinate everything else to the bottleneck’s needs, elevate it (increase its capacity), and repeat — because removing one constraint inevitably reveals the next.

This is why The Phoenix Project’s team focuses so heavily on Brent, the person that every critical task seems to route through. Brent is the bottleneck. Making Brent more available — by documenting his knowledge, training others, and routing non-critical work around him — is the highest-leverage intervention available.

Key Performance Indicators

In IT operations, relevant KPIs might include MTTR, system availability percentage, deployment frequency, defect escape rate (bugs that reach production), and customer satisfaction scores. The choice of KPIs shapes organizational behaviour — teams optimize for what is measured — so KPIs must be selected carefully to ensure alignment with actual organizational goals.

The Three Ways

Gene Kim’s “Three Ways” provide a unifying framework for DevOps improvement, drawing on lean manufacturing and systems thinking.

The First Way: Systems Thinking focuses on the flow of work from development through operations to the customer. The objective is to understand and optimize the entire value stream — not any local piece. Key practices include making work visible (through tools like value stream maps and Kanban boards), reducing batch size, shortening work intervals, and eliminating non-value-adding steps. The First Way demands that teams look at the whole system and resist the temptation to optimize locally at the expense of global flow.

The Second Way: Amplify Feedback Loops focuses on ensuring that the output of each step can be checked against intentions — rapidly and close to the point of origin. Feedback enables detection of problems before they become expensive or irreversible. In software terms, automated testing provides feedback within minutes of a code change; production monitoring provides feedback about system behaviour in real time.

Feedback can be positive (reinforcing — an effect that amplifies change, potentially leading to instability) or negative (corrective — an effect that reduces deviation, promoting equilibrium). High employee turnover increasing error rates, which reduces morale, which increases turnover, is a positive feedback loop. Understanding these dynamics in an organization helps predict unintended consequences of management decisions.

The Third Way: Culture of Continual Experimentation and Learning focuses on building an organizational culture that can operate effectively in the first two ways over the long term. This requires high trust (so that the causes of problems can be surfaced without fear), psychological safety (so that people can experiment and fail without punishment), and institutional learning mechanisms (retrospectives, post-mortems, knowledge sharing). Repetitive small failures generate the insights that underpin large sustained improvements. An organization that suppresses failure reporting cannot learn from failures.

Module 9: Being Agile

Traditional approaches to software development treated projects like construction: requirements were gathered exhaustively upfront, designs were finalized before coding began, and the finished system was delivered months or years later. This Waterfall approach proved ill-suited to software development, where requirements evolve, technology changes, and user needs can only be fully understood through interaction with working software. Agile software development emerged as an alternative: an iterative approach that breaks projects into short cycles, delivers working software frequently, and welcomes changing requirements.

The Agile Manifesto and 12 Principles

The Agile mindset is captured in the 2001 Agile Manifesto, which prioritizes:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

These values do not reject process, documentation, or planning — they insist that these serve human goals rather than substitute for them.

Agile also specifies 12 operating principles:

1. Focus on the customer (customer-centric approach)
2. Welcome change and adapt to changing requirements, even late in development
3. Release software frequently and encourage feedback
4. Measure progress through working software
5. Foster teamwork and trust
6. Build projects around motivated individuals and give them the environment they need
7. Create empowered, cross-functional teams
8. Favour frequent, face-to-face communication among stakeholders
9. Keep designs and solutions simple
10. Focus on technical excellence and good design; avoid shortcuts that create future problems
11. Frequently reflect on performance and adapt accordingly
12. Promote sustainable development — teams should be able to maintain a constant pace indefinitely

Scrum

Scrum is the most widely adopted Agile framework. It organizes work into sprints — fixed-length iterations, typically one to two weeks — during which a cross-functional team commits to completing a defined set of work.

The Scrum workflow begins with user stories: descriptions of desired features from the end user’s perspective. A well-formed user story follows a template: “As a [role], I want [feature] so that [benefit].” For example: “As a customer, I want to view my order history so that I can track past purchases.” User stories are estimated for complexity using either hours or story points (where a simple story is assigned 1 point and more complex stories are assigned proportionally higher values).

The collection of all desired user stories is the product backlog. The subset selected for the current sprint is the sprint backlog. The product owner is the person responsible for ensuring the product meets customer needs; they prioritize the backlog and provide feedback during sprint reviews.

Scrum tools include the burndown chart — a visual representation of estimated versus actual work completed day by day through the sprint. The slope of actual completions (the burndown velocity) can be extrapolated to project whether the sprint will complete on time. Burndown charts make the team’s progress (or lack of it) visible.

Scrum rituals provide the communication and learning infrastructure:

• Sprint Planning Meeting — The team selects user stories for the sprint and estimates their effort.
• Daily Stand-Up (Daily Scrum) — A brief (~15-minute) synchronous check-in where each team member answers: What did I accomplish? What will I do today? What is blocking me? The stand-up surfaces impediments before they compound.
• Sprint Review — After the sprint, the team presents completed user stories to the product owner for feedback.
• Sprint Retrospective — The team reviews their own process: what went well, what could be improved, and what specific changes to make in the next sprint. Retrospectives are the Scrum mechanism for the Third Way — continuous learning.

Batch Size

Batch size — the number of features worked on simultaneously before any are released — has a profound effect on flow. Large batches create long feedback cycles, hide integration problems, and increase the coordination overhead of releasing. Small batches produce faster feedback, simpler integration, and lower risk per release. Scrum’s short sprints are, in part, a mechanism for keeping batch sizes small. In The Phoenix Project, Erik challenges the team to reduce batch size radically — ultimately proposing ten software deployments per day — as a way of forcing discipline around small, testable, releasable units of work.

Kanban as an Agile Framework

Kanban, introduced in Module 8 as a workflow visualization tool, can also be used as an Agile development framework. Unlike Scrum, Kanban has no fixed iterations — work items flow continuously from one stage to the next, governed by WIP limits. Both Scrum and Kanban are pull-based systems: work is pulled into active stages as capacity becomes available, rather than pushed in by managers.

Key differences between Scrum and Kanban:

Both use user stories, both have daily stand-ups, reviews, and retrospectives, and both encourage frequent releases by breaking work into small units. Many teams adopt a hybrid: Scrum’s cadences alongside Kanban’s explicit WIP limits.

Module 10: Development Meets Production

One of the persistent friction points in software organizations is the boundary between development (which writes code) and operations (which deploys and runs it). Development teams measure success by shipping features; operations teams measure success by maintaining stability. These incentives create organizational tension that traditional structures manage poorly. Continuous Integration (CI) and Continuous Delivery (CD) are technical practices designed to resolve this tension by making integration, testing, and deployment routine, frequent, and largely automated.

The Deployment Value Stream

Understanding the path from a developer’s keyboard to a production system — the deployment value stream — is the prerequisite for improving it. This value stream encompasses every step from code creation through build, test, staging, approval, and production deployment. Like any value stream, it can be mapped to identify lead times, value-added times, and bottlenecks.

A key requirement for efficient continuous delivery is environment synchronization: ensuring that development, quality assurance, and production environments all run the same versions of operating systems, libraries, databases, and configuration. Without synchronization, tests that pass in the development environment may fail in production — one of the most common and costly sources of production defects.

Automation

Automation does not mean fully autonomous: an automated coffee maker still requires a person to configure it. In continuous delivery, some decisions (particularly the final approval to release to production) may remain human, while the mechanical work of building, testing, and staging is automated.

Steps are automated through scripts — programs written in scripting languages (Python, Shell, Ruby, etc.) that execute sequences of tasks programmatically. A test script might submit a form with specific inputs, verify the output, then repeat with invalid inputs to check error handling. Understanding the underlying business process being tested is essential for creating realistic test data.

The Deployment Pipeline

The three primary stages of a deployment pipeline are:

Commit and Build — When a developer completes a unit of code, they commit it to a shared version control repository. The build system compiles the source code into executable binaries and links it with required software components. This step verifies that the code is syntactically correct and that all dependencies are available.

Test — The built code runs through progressively more demanding automated tests. Early tests check individual functions and modules in isolation (unit tests). Later tests check how components interact (integration tests). Near the end of the pipeline, the code is tested under realistic production conditions — different operating systems, browsers, hardware configurations — and under load (performance testing). If any test fails, the pipeline halts and the team is notified.

Deploy — Code that passes all tests is deployed first to a staging environment for final validation, then to production. In continuous delivery, the final promotion to production requires a human decision. In continuous deployment, this decision is also automated.

Continuous Integration

For large projects with multiple developers working in parallel, keeping everyone’s code compatible is a significant challenge. Continuous Integration (CI) addresses this by requiring developers to merge their changes into a shared main branch frequently — ideally multiple times per day — and automatically running tests on each merge.

Code is “checked out” from the repository when a developer begins working on it and “checked in” (merged) when ready. Upon check-in, automated tests run before the code is accepted into the main branch. This prevents the “integration hell” familiar from Waterfall projects, where large batches of separately developed code are merged all at once and require weeks of debugging.

Continuous Delivery vs. Continuous Deployment

The difference between continuous delivery and continuous deployment is the presence or absence of a planned “pause” before production release. Continuous delivery preserves the pause — a human decides when to release. Continuous deployment removes it — the pipeline goes directly from passing tests to production.

Module 11: Deployment and DevOps

The final stages of the software delivery pipeline — quality assurance, deployment, and the ongoing operation of production systems — are where the value of earlier investments in testing and automation is realized.

Quality Assurance

Software Quality Assurance (QA) is the systematic process of monitoring software for problems before they reach users. In the Waterfall model, testing was largely a post-development activity: once code was written, it was handed to a QA team that ran their test plans. A significant problem with this approach is that the volume of testing grows exponentially with system complexity, and testing is frequently incomplete due to pressure to release.

The Agile approach improves QA by incorporating testing into each sprint, reducing the size of code units under test, and catching defects closer to where they are introduced. However, if testing remains primarily manual, it still creates a bottleneck. Automation of testing is therefore critical for achieving high deployment frequency. The testing process typically proceeds through levels of increasing complexity: unit tests → integration tests → functional tests → performance tests.

The seven principles of software testing (a widely cited framework) include:

1. Testing shows the presence of defects — it cannot prove their absence.
2. Exhaustive testing is impossible.
3. Early testing (starting testing as early as possible) reduces defect costs.
4. Defect clustering — defects tend to concentrate in a small number of modules.
5. The pesticide paradox — repeating the same tests eventually stops finding new defects; tests must evolve.
6. Testing is context-dependent — appropriate testing depends on the type of system.
7. Absence of errors is a fallacy — a system that is technically bug-free but does not meet user needs has still failed.

Deployment Strategies

Different deployment strategies manage the risk of introducing changes to production systems.

Big Bang Deployment releases new code to all users simultaneously. This is manageable for small or low-risk deployments but risks affecting all users if an undetected problem exists. A production failure under Big Bang deployment is immediately company-wide.

Canary Deployment (Phased) releases new code to a small, randomly selected subset of users first. If problems are detected, the release is withdrawn and revised before reaching the broader user base. The name references the practice of using canaries in coal mines as early warning systems. This approach significantly limits the “blast radius” of a defective release.

A/B (Blue-Green) Deployment maintains two identical production environments — “A” (or “Blue”) and “B” (or “Green”). The new version is deployed to the inactive environment. After validation, traffic is switched to the new environment, while the old environment remains on standby. If problems emerge, traffic switches back immediately. This approach enables instant rollback but requires maintaining two full production environments, which is expensive.

Push vs. Pull Deployment represents another dimension:

• Push deployment sends code to all users, similar to an automatic operating system update. Advantages: universal adoption, essential for security patches. Risk: if defective, all users are affected immediately.
• Pull deployment makes code available in a repository for users to download when they choose. This creates a naturally phased rollout and limits the impact of defects, but adoption may be incomplete.

Feature Flags (Feature Toggles) allow new functionality to be deployed to production but kept invisible to users until explicitly enabled. This separates deployment (moving code to production) from release (making a feature available to users), enabling fine-grained control over feature availability.

DevOps

DevOps is more than an extension of Agile — it is a cultural shift that removes the organizational boundary between the team that writes code and the team that operates it. Key DevOps practices include:

• Automated testing — comprehensive test suites that run on every code change.
• CI/CD pipelines — automated integration, testing, and delivery of software.
• Infrastructure as Code (IaC) — treating infrastructure configuration as source code, subject to version control, peer review, and automated testing. This makes infrastructure changes as disciplined as code changes.
• Observability — instrumenting systems to make their behaviour visible through metrics, logs, and distributed traces, enabling rapid diagnosis of production issues.

DevSecOps integrates security into this continuous delivery model. Rather than treating security as a compliance checkpoint at the end of development, DevSecOps builds security testing — static analysis, dependency scanning, penetration testing — into the deployment pipeline. Security teams define policies as code and participate in the development process from the start.

The DevOps movement is closely associated with the Fourth Industrial Revolution — the confluence of digital, physical, and biological technologies (AI, IoT, robotics, advanced analytics) that is reshaping entire industries. Organizations that cannot rapidly adapt their software and IT capabilities are increasingly unable to compete.

Module 12: Review and CRM

The concluding module synthesizes themes from the course and introduces Customer Relationship Management (CRM) as a capstone application domain that illustrates nearly every concept from the preceding eleven modules.

The Arc of the Course

Reviewing the journey of The Phoenix Project: Parts Unlimited begins in financial trouble and IT chaos, dominated by unplanned work, organizational politics, and poor coordination between development and operations. Through a structured transformation — introducing Kanban boards, limiting WIP, applying the Theory of Constraints, embracing Agile sprints, building a deployment pipeline, and ultimately adopting DevOps — the IT organization becomes a reliable, strategic capability of the company. Bill Palmer’s reward for leading this transformation is a path to becoming Chief Operating Officer — a recognition that mastery of IT operations is now a prerequisite for enterprise leadership.

The technical practices adopted — Kanban, continuous deployment, small batch sizes, fast feedback — are not ends in themselves. They are means to the organizational goal of delivering value to customers reliably and continuously.

Software Architecture in Review

When understanding or building any software system, the starting point is its architecture: the components, their responsibilities, and the data they exchange. An Enterprise Resource Planning (ERP) system illustrates architectural complexity at scale. A manufacturing ERP might include modules for:

• Human Resources (employee management, payroll)
• Customer Relationship Management (sales pipeline, customer data)
• Business Intelligence and Analytics
• Supply Chain Management
• Manufacturing Resource Planning (MRP — bills of materials, production scheduling, inventory)
• Financial Management (accounts payable, receivable, budgeting)

Each of these is itself a complex software element with its own data requirements and internal architecture. Data flows between modules: a customer order entered in the CRM triggers production scheduling in MRP, which checks inventory, schedules manufacturing, and triggers procurement if materials are insufficient. Integration between these components — and with external systems via APIs — is the principal engineering challenge of ERP implementation.

The LEARN learning management system provides a familiar architecture example: a login page authenticates against a user database, retrieves course enrolment data, and renders a personalized course listing. Selecting a course renders module content, concept checks (automated testing), and assignment submission interfaces. In the background, different development teams continuously update security patches and bug fixes without disrupting the academic term — continuous delivery in a production environment that cannot be taken offline.

UML and BPMN in Review

BPMN represents how a process works — the sequence of tasks, the actors responsible for them, the decisions made, and the information exchanged. A BPMN diagram of this online course might show swimlanes for the student, instructor, and system, tracing the workflow from reading module content through completing concept checks (automated), submitting assignments, and receiving instructor feedback.

UML Use Case Diagrams represent what a system must support — the key actors and the tasks they perform within the system boundary. A use case diagram for this course would identify the student as primary actor, the system and instructor as secondary actors, and document use cases like “complete assignment,” “view module content,” “receive feedback,” and “check grades.” From such a diagram, interface requirements can be inferred: assignment submission requires an upload interface; instructor feedback requires a grading and annotation interface accessible to both instructor and student.

Together, BPMN and UML cover the “what the business does” and “what the software must support” dimensions of analysis, feeding into all subsequent development activities.

Customer Relationship Management

The sales pipeline (also called the sales process cycle) describes the stages through which a potential customer progresses, from first contact to closed sale:

1. Prospecting — Identifying potential customers. Data sources include trade show registrations, website form submissions, and referrals.
2. Lead qualification — Assessing whether a prospect meets criteria (budget, authority, need, timing) to become a genuine opportunity.
3. Needs analysis — Understanding the prospect’s specific requirements.
4. Proposal — Presenting a solution and pricing.
5. Negotiation and objection handling — Addressing concerns.
6. Close — Completing the sale.
7. After-sales support — Managing the ongoing customer relationship, including service inquiries, renewals, and upsell opportunities.

CRM systems like Salesforce, Zoho CRM, HubSpot, and SugarCRM automate and track this pipeline. When a salesperson calls a customer, the CRM surface the customer’s complete history — every previous interaction, every past purchase, every open support ticket. This creates the impression of personalized, “high touch” service at scale. CRM systems also generate analytics: which sales reps are converting prospects most effectively, which lead sources produce the most valuable customers, where in the pipeline deals most often stall.

Modern CRM platforms integrate with marketing automation tools (which trigger email sequences based on prospect behaviour), e-commerce platforms (connecting purchase history directly to the customer record), and ERP systems (so that a sales rep can see current inventory levels before promising delivery dates). This integration is accomplished through APIs, making CRM implementation a direct application of the service architecture concepts covered in Module 5.

CRM as a Synthesis of Course Concepts

CRM implementation illustrates nearly every major concept from BET 210:

• Business process modelling — mapping existing customer interaction workflows before automating them, using BPMN.
• IT infrastructure decisions — choosing between cloud-hosted SaaS CRM (Salesforce) and on-premises deployment, weighing scalability, availability, and data sovereignty.
• API integration — connecting CRM with marketing, billing, support, and ERP systems through APIs.
• Application development and SDLC — customizing CRM workflows and interfaces to fit organizational processes, managed through Agile sprints.
• Cybersecurity — protecting sensitive customer data in compliance with privacy regulations (GDPR, PIPEDA); applying DevSecOps to CRM development.
• DevOps and CI/CD — deploying CRM updates continuously without disrupting active sales operations.
• Value stream analysis — mapping the sales process to identify where time is wasted and where automation (automated lead scoring, email follow-up sequences) can accelerate the pipeline.

The value of CRM is only realized when the technology serves well-designed processes. Deploying a sophisticated CRM onto a poorly understood set of customer interaction workflows makes those workflows more expensive without improving them. This is the final, unifying lesson of BET 210: technology amplifies the quality of the underlying process, for better or for worse. Understanding the business process is always the prerequisite for deploying technology in its service.