Épisodes

  • Digital Process Ethics

    Digital Process Ethics
    Jan 21 2026
    In this episode of Appian Rocks, Stefan, Sandro, and Marcel dive into a conversation that starts with the seemingly dull topic of software reviews but quickly evolves into a deep and thought-provoking discussion about ethics in digital process automation. Initially, they touch on the typical components of a code review—adherence to best practices, syntax, node counts in processes, and test cases. However, they challenge the narrow scope of this approach, questioning whether technical correctness alone is sufficient, especially when the software influences real-world decisions in complex environments. The conversation shifts to the broader context in which applications operate, especially in public sector projects. The team notes that stakeholders such as the funding agency, the users, and the beneficiaries are often different entities, each with distinct priorities. This creates a tension where developers can find themselves caught in the middle. While developers are typically not policy makers, the code they write can enforce rules and decisions that significantly affect people's lives. This leads to a central theme of the episode: software is not neutral. It embodies decisions, and those decisions can have ethical consequences. They explore how public sector automation transforms discretionary, human-driven processes into rigid, rule-based systems. This transition, while increasing efficiency, risks stripping away the nuance and empathy that experienced civil servants once applied. For example, decisions about child support or eligibility for government aid, which were previously made by humans considering context and individual circumstances, are now reduced to logic gates and business rules. The trio argues that this change demands new layers of oversight—beyond testing whether a process works, teams must ask whether it works *fairly* and *justly*. A particularly striking point raised is the lack of ethical audits in most software development projects. Stefan admits he’s never performed one, and the group collectively questions why such audits aren't standard practice. Is it because they were never needed? Or is it because ethical responsibility was previously embedded in human roles and not in the tools themselves? They agree that developers, especially solution designers and business analysts, have a duty to consider the broader impacts of their implementations. The discussion also touches on traceability and transparency. Marcel introduces the concept of traceability as a critical requirement, particularly in government software. Every feature in an application should be traceable back to a signed-off requirement to ensure accountability. This is essential not only for auditing but also for safeguarding citizens’ rights when decisions are automated. Transparency, too, is highlighted as a core value—systems should provide users with understandable explanations for decisions, such as why a child support claim was denied. As the episode closes, the hosts underline the need for ethical codes within development teams. Guidelines alone aren’t enough; teams must establish practical escalation paths and support for developers who encounter ethical red flags. Developers should feel empowered to say no to unethical requests and escalate questionable requirements. Ethical responsibility, they stress, belongs to everyone involved—not just legal or compliance departments. Ultimately, this episode calls for a shift in mindset. In an era where software often replaces human discretion, ethics must become a first-class concern in digital process design. Developers, architects, and analysts need to see themselves not just as implementers of logic, but as stewards of values that impact real lives.
    Afficher plus Afficher moins
    1 h et 2 min
  • Dealing with External Data Models

    Dealing with External Data Models
    Nov 6 2025
    In the latest "Appian Rocks" podcast, host Stefan, Sandro, and Marcel discussed managing external data models in Appian. They focused on Data Transfer Objects (DTOs) for abstracting and transferring data between incompatible systems. Marcel, a solution architect, highlighted the challenge of integrating external data, whether from microservices or legacy systems, and questioned forcing a single business object model across an enterprise. The conversation explored communication methods and the common scenario of Appian performing internal data transformations. Stefan emphasized that Appian often needs only a subset of external data. Marcel explained that a central translation layer for DTOs could consolidate logic, preventing widespread changes if a DTO evolves. They also mentioned API composition and anti-corruption layers (ACLs), which facilitate communication between systems using their own data models, with translation in the middle. Marcel likened DTOs to "DHL packages" for data, while ACLs help reduce transferred information, adhering to the "need-to-know" principle. Stefan pointed out the fundamental difference between process-driven Appian systems and data-storing backends. Marcel added that highly normalized external data might require denormalization for Appian UI performance. They also covered various forms of coupling, including data format, interaction style, semantics, order of operations, network location, temporal coupling, and network topology. Stefan shared an anecdote about time zone issues causing data discrepancies. Sandro presented a "war story" about enriching read-only external customer data. Stefan immediately suggested Appian's sync records as a solution for creating cached local copies and enhancing query speed. Marcel agreed, comparing it to a materialized view. When Sandro revealed that API-based integrations across multiple unreliable source systems led to instability, Marcel proposed an API Composer service with caching and retry mechanisms. Stefan countered that Appian's synced records can now handle unsuccessful or partial syncs. They concluded that data duplication is a pragmatic approach, especially for low-priority reference data or when sensitive data shouldn't reside directly in Appian. While reliable software is costly, local data duplication can be a cost-effective solution for individual applications. The crucial factor for data duplication is ensuring awareness of changes to keep the cached data current. Marcel, despite his skepticism, acknowledged that synced records effectively solve common problems in an approachable way, aligning with Appian's platform philosophy.
    Afficher plus Afficher moins
    46 min
  • AI Contextualized

    AI Contextualized
    Aug 27 2025
    In this episode of Appian Rocks, Stefan, Sandro, and Marcel tackle the controversial role of artificial intelligence in process implementation projects. While acknowledging AI’s impressive capabilities, they warn against the industry’s tendency to treat it as a universal solution. What demos well in sales meetings often falls short in practice, producing answers that only sound competent. The hosts argue that uncritical adoption leads to laziness, outsourcing of judgment, and a dangerous decline in deep problem-solving skills. Marcel frames the issue as the “hammer and nail” problem: with AI marketed as the hammer, everything starts looking like a nail. This obsession can stifle thoughtful analysis and push teams to skip the hard work of understanding processes. Stefan illustrates this with a client case where rethinking and simplifying steps—without AI—halved the workload. The real benefit came not from automation but from owning the thinking and redesign. If a team relies on a chatbot instead, it risks losing both control and learning. Still, the hosts emphasize that AI has valuable use cases, particularly where input is noisy or unstructured. Summarizing long documents, extracting fields from messy scans, or parsing communication are areas where probabilistic language models excel. But when data is already structured and clear, adding AI can actually reduce quality. As Stefan puts it, “the best part is no part”—if a step adds no value, eliminate it rather than overengineering with AI. The conversation then broadens to the societal and environmental costs of AI overuse. Marcel highlights the immense energy and water consumption of data centers, noting that a single AI query is vastly more resource-hungry than a standard Google search. Sandro compares the phenomenon to refrigerators: once they became widespread, people stopped considering older preservation methods and even began misusing fridges for foods that spoil faster inside them. Likewise, if developers only learn to solve problems through AI, they may never develop alternative methods, filling the industry with people who know no tools beyond the “fridge.” The panel also warns about economic risks. Current AI feels cheap because of heavy investment subsidies, but providers will eventually move to value-based pricing, charging for “man-hours saved.” This could trap organizations in costly dependencies once AI is deeply integrated into core processes. Consultants, they argue, must therefore frame adoption not only around use-case justification but also total cost of ownership, including volatile token-based pricing. In closing, the hosts underline that AI should be one tool among many. Its convenience is undeniable, but convenience alone is no justification. In low-code environments like Appian, the temptation to lean on AI for speed is strong, yet true transformation still requires creativity, critical analysis, and ownership of solutions. Overuse risks fragile systems and a loss of craft. For now, they agree: AI is powerful and promising, but it must be applied sparingly, thoughtfully, and only where it adds real value.
    Afficher plus Afficher moins
    54 min
  • Expressions

    Expressions
    Jul 31 2025
    Intro In this episode of Appian Rocks, Stefan turns the spotlight on one of the most fundamental aspects of Appian development: expressions. Though they often operate behind the scenes, expressions power nearly every part of an Appian application—from interfaces to process models, decision logic to integrations. With the right approach, expressions can elevate a project’s maintainability, performance, and developer experience. But when misused, they can quickly become a source of confusion and technical debt. TL;DL Expressions are the lifeblood of Appian applications. In this episode, Stefan explains how to write clean, reusable, and performant expressions, shares practical tips for improving readability and maintainability, and discusses common mistakes that Appian developers should avoid. On the role of expressions in Appian Expressions in Appian are not just scripting snippets—they're integral to building dynamic and flexible applications. Stefan emphasizes the importance of understanding the typed expression language deeply, especially when working with complex data structures. Expressions are used across every layer of an application, which makes writing clean and modular logic not just a best practice, but a necessity for scalability and collaboration. Writing reusable expression rules A major theme of the episode is the value of modularity. Stefan encourages developers to think of expression rules like functions: small, focused, and parameterized. Avoiding hardcoded logic and opting for reusable rules makes applications easier to update and test. Clear parameter naming and avoiding generic inputs like pv!input are also highlighted as critical for long-term maintainability. Design and performance best practices Stefan discusses how poor design choices—like deeply nested logic or repeated inline expressions—can quickly degrade both the performance and readability of applications. Instead of duplicating logic, developers should extract reusable patterns into separate expression rules. He also stresses the importance of minimizing rule chaining and understanding how and when expressions are recalculated, especially in interface contexts where performance can be affected by unnecessary re-evaluation. Making expressions readable and maintainable Readability is another key theme. Stefan suggests using tools like a!localVariables() to better structure logic in interfaces and avoid clutter. He cautions against overusing if() when constructs like a!match() or choose() would be clearer and more concise. Commenting logic is encouraged—especially for nested or non-obvious sections—to help both current and future developers navigate the application more effectively. Collaboration and team alignment Since expressions are touched by many developers over the course of a project, Stefan advocates for team-wide standards and code reviews specific to expression logic. Naming conventions, centralized utility rules, and internal documentation all contribute to making shared codebases more understandable. He emphasizes that expressions are not just technical elements—they're collaborative artifacts that should reflect collective understanding and intentional design. Avoiding common pitfalls The episode wraps up with a discussion of mistakes Stefan frequently sees: expression rules that try to do too much, hardcoded assumptions that limit reuse, and dynamic evaluation bugs caused by lack of context awareness. His advice: keep logic modular, test thoroughly, and never underestimate the power of a well-named rule and a thoughtful comment.
    Afficher plus Afficher moins
    57 min
  • Feature Flags

    Feature Flags
    Jun 4 2025
    In this episode of Appian Rocks, host Stefan explores the power and practicality of feature flags within Appian applications. Speaking from experience, he walks through what they are, why they matter, and how developers can use them to build more flexible, reliable, and scalable solutions. TL;DL Feature flags are a game-changer in Appian development, enabling controlled feature rollouts, safer deployments, and faster iteration. Stefan explains their role in dynamic application behavior, implementation strategies, and best practices, while offering insights into real-world usage and common pitfalls to avoid. What feature flags are and why they matter Feature flags allow developers to turn parts of their application on or off without needing a redeployment. This simple but powerful concept enables greater flexibility during development and release cycles. Rather than bundling all changes into a single deployment, teams can control exposure to features at runtime, making it easier to test, roll out gradually, or disable functionality if something goes wrong. How they improve agility and reduce risk Using feature flags helps teams iterate faster by decoupling feature availability from code releases. Developers can safely merge code for in-progress features into the main branch and enable them only when ready. This reduces pressure on deployment windows and adds a layer of safety in production environments. It also allows non-technical stakeholders to participate in controlling features through configuration, rather than relying on new deployments. How to implement them in Appian In Appian, feature flags are often implemented using constants, CDTs, or expression rules that evaluate whether a feature should be enabled. These flags can be referenced in interfaces, processes, or decisions to control application behavior dynamically. Stefan emphasizes the importance of centralizing flag definitions and maintaining clarity in how they’re used across the application, ensuring they’re easy to audit and update. The risks and how to manage them While feature flags offer flexibility, they come with the risk of creating technical debt if not managed properly. Flags that are never removed or poorly documented can clutter the application and lead to confusion or bugs. Stefan recommends building flag lifecycle management into development workflows—tracking which flags are active, which are temporary, and when they should be retired. Teams should also be aligned on naming conventions and ownership responsibilities to avoid surprises. Real-world experience and team practices Stefan shares insights from real-world projects where feature flags helped manage complex deployments and user-specific rollouts. He discusses how teams coordinate around flag usage, how flags are used to toggle between different integrations, and how they can improve the overall developer experience. The key, he notes, is striking a balance between power and discipline—using flags strategically, not as a shortcut for poor planning.
    Afficher plus Afficher moins
    52 min
  • A Task is a Task

    A Task is a Task
    Apr 23 2025
    A Task is a Task... Or is It? On the latest episode of Appian Rocks, I sat down with Sandro and Marcel to tackle a long-standing debate in the Appian world: User Input Tasks vs. Database Tasks. At first glance, it seems simple—tasks are things people do in a process. But should we store and manage them inside the process model or in an external database? That’s where things get complicated. What Actually Is a Task? Marcel kicked things off by questioning whether every process step is a task. In short, no. A process can involve automated actions (system-driven) and human tasks (where someone makes a decision). In Appian, these are typically User Input Tasks—but sometimes, we need a more flexible approach. User Input Tasks vs. Database Tasks - User Input Tasks (UITs): Managed by Appian’s process engine, providing built-in assignment, escalation, and tracking. Great for structured workflows. - Database Tasks (DB Tasks): Stored in a database, offering flexibility but requiring custom-built task management. Often favored by developers from traditional backgrounds. The key takeaway? UITs handle structured processes well, while DB Tasks are better for case-driven workflows. The problem arises when teams mix both approaches, leading to complexity and redundancy. When Does It Matter? If you’re managing millions of tasks (like Joe Longworth in Episode 20), UITs might struggle, and DB Tasks can scale better. But for most use cases, UITs prevent unnecessary complexity—unless your process is inherently dynamic. Another challenge? Cross-application task lists. If every Appian app implements DB Tasks differently, you lose the ability to provide users with a single, unified task list. What’s the Right Approach? There’s no one-size-fits-all answer, but here’s our advice: - If UITs work for your process, use them. - If your workflow is case-driven, DB Tasks might make more sense. - Don’t mix both unless you really know what you’re doing. - Ultimately, good Appian practitioners challenge assumptions. It’s not about what’s easy to build—it’s about what truly optimizes the process. What do you think? Drop us a comment, and check out the full episode for the deep dive!
    Afficher plus Afficher moins
    57 min
  • Terminating Processes

    Terminating Processes
    Mar 5 2025
    The podcast delved into the critical role of UX design in Appian projects, highlighting the direct link between user trust, satisfaction, and the overall success of an application. It emphasized that while building functional systems is essential, creating intuitive, user-centered designs is what ensures long-term engagement and trust. Poor UX design, whether in the form of unclear processes, lack of transparency, or unexpected system behavior, can lead to frustration, distrust, and ultimately, disengagement from users. A key focus was the importance of understanding user behavior and designing systems that align with their needs while anticipating their challenges. Users come to systems with habits and expectations, often shaped by their previous experiences. While it’s essential to consider these habits, it’s equally important to recognize when these expectations might hinder efficiency or innovation. For example, if users are accustomed to a manual confirmation process but a single-click solution is more efficient, the transition must be managed carefully. Clear communication about why a new approach is beneficial can help users adapt while maintaining their trust in the system. Transparency and communication were recurring themes in the discussion. When processes or tasks change unexpectedly—such as when a task is canceled or a process terminates due to an error—users need to be informed promptly and clearly. The group stressed that system actions, especially unexpected ones, should never leave users guessing. Notifications that explain what happened and why, alongside safeguards like preserving any work completed before a task's cancellation, contribute to a system that feels reliable and user-focused. The conversation also highlighted the importance of designing with empathy. UX design isn’t just about creating interfaces; it’s about crafting experiences that make users feel understood and empowered. This involves asking questions like: What is the user trying to achieve? What challenges might they face? What might frustrate them? For instance, when users are multitasking or working under pressure, a system that proactively supports them—such as preemptively filling in data fields or guiding them through complex workflows—can make a significant difference in their overall experience. Another point raised was the balance between automation and user control. While automation can streamline workflows and reduce manual effort, over-automation without user input can erode trust. Users need to feel they have some level of control and visibility over system actions. For example, automating a task without providing users with an option to review or intervene can lead to dissatisfaction if the automation doesn’t align with their expectations or needs. The team discussed the importance of striking this balance to ensure automation enhances the user experience rather than detracting from it. The discussion also touched on the need for iterative design processes. UX is not a “set it and forget it” discipline; it requires ongoing evaluation, testing, and refinement. As users interact with a system, their needs may evolve, or unforeseen issues may arise. By actively collecting feedback and incorporating it into the design, developers can ensure their systems remain user-friendly and effective over time. Ultimately, the episode underscored the idea that good UX design in Appian projects goes beyond aesthetics or technical features. It’s about creating systems that feel seamless, intuitive, and empowering for the users. Thoughtful UX design fosters trust, builds engagement, and ensures that technology serves as a true enabler of productivity and innovation. The conversation emphasized that when UX design is prioritized, the result is not only a better user experience but also a more successful and impactful application.
    Afficher plus Afficher moins
    59 min
  • Highly Regulated Appian

    Highly Regulated Appian
    Jan 29 2025
    In this episode of Appian Rocks, I, along with my co-hosts Marcel and Sandro, explore the intricate challenges of using Appian in highly regulated environments, particularly within the financial services sector. We kick off the discussion by defining what constitutes a highly regulated environment. Essentially, it is one where external stakeholders impose specific requirements that go beyond the functional needs of the software being developed. These requirements often include compliance with various laws, best practices, and standards related to data protection, auditability, and traceability. Marcel draws from his extensive experience in financial services to provide valuable insights into the regulatory landscape. He emphasizes the importance of understanding the sources of these regulations, which can stem from formal laws or best practices that organizations are expected to follow. For instance, regulations may dictate how data is handled, how processes are audited, and the level of traceability required for software development. This understanding is crucial for Appian developers, as they must balance functional requirements with the need for regulatory compliance. Failing to meet these standards can have severe consequences, including the potential loss of a company’s license to operate or facing significant fines. Throughout the episode, we stress the importance of engaging with compliance teams early in the development process. This proactive approach helps ensure that all regulatory requirements are clearly understood and integrated into the software development lifecycle. We discuss the challenges associated with traceability and documentation in Appian, noting that while the platform facilitates rapid application development, it does not inherently simplify the compliance processes that must be followed. One of the key takeaways from our conversation is the need for a robust compliance framework that aligns with the organization’s existing practices, particularly those used in high-code environments. We encourage developers to leverage the knowledge and expertise of compliance officers and other stakeholders within their organizations. By actively engaging with these individuals, developers can ensure that all regulatory requirements are met without compromising the efficiency of the development process. We also touch on the importance of documentation and the need for clear communication regarding compliance requirements. It is essential for developers to document their processes and decisions thoroughly, as this documentation serves as evidence of compliance during audits. We highlight that while Appian allows for quick development, the complexities of regulatory compliance require careful planning and collaboration. Moreover, we discuss the trade-offs that organizations must consider when implementing Appian in a regulated environment. While the platform offers the advantage of rapid application development, the associated compliance requirements can introduce additional overhead. Organizations must weigh the benefits of using Appian against the potential challenges of meeting regulatory standards. In conclusion, we remind our listeners that while Appian simplifies software development, navigating the complexities of regulatory compliance requires a strategic approach. It is essential to foster collaboration between development teams and compliance officers, ensuring that all parties are aligned on the requirements and expectations. By doing so, organizations can successfully leverage Appian to create innovative solutions while remaining compliant with the necessary regulations. This episode serves as a valuable resource for Appian professionals looking to understand the intricacies of working in highly regulated environments and offers practical insights for navigating these challenges effectively.
    Afficher plus Afficher moins
    1 h et 5 min