Appian Rocks

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.

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.

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.

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!

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.

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.

Welcome to Appian Rocks, the podcast for Appian professionals. Today's episode delves into the "illusion of control," a cognitive bias where people overestimate their ability to influence events, even when their control is limited. This concept is particularly relevant in Appian, a business process management platform designed to automate many tasks traditionally handled by humans. The hosts, Marcel and Sandro, introduce the episode by explaining how people naturally desire to control their environment, often believing they can control aspects even when they cannot. This overestimation can be seen in everyday examples like pressing a pedestrian button at a traffic light or monitoring a progress bar during a download. In the realm of Appian, this illusion becomes significant because the platform streamlines and automates processes, often reducing direct human control. For instance, tasks might be routed automatically based on algorithms, which can lead to resistance from users accustomed to manual processes and direct intervention in their workflows. Balancing this automation with an understanding of human psychology is crucial for creating a comfortable user experience. While automation is beneficial for efficiency, it can make users feel disconnected from the process, leading to distrust in the system. The challenge is to design Appian applications that retain a sense of control for users. This can be as simple as ensuring intuitive and visually appealing interfaces, making users feel engaged and at ease. Stefan joins the conversation, providing practical examples like "Save" and "Refresh" buttons. Despite modern software's capability to autosave and push updates in real time, users still look for these buttons because they offer a tangible sense of control. These design elements are crucial for user satisfaction, as they mimic the control users perceive they have. Marcel illustrates the illusion of control with everyday software experiences. Progress bars during file downloads provide users with a sense of monitoring and involvement, even though they can't influence the process. In video games or cloud-based applications, users often tweak settings or press save buttons frequently for the comfort of being in control. The term "illusion of control" isn't dismissive; it's about respecting users' psychological needs. Control is a profound need, and providing interfaces that accommodate this can enhance user experience and trust in the application. The conversation shifts to the implications for change management. Introducing new software that automates tasks can be daunting. Trust in the system is crucial, and maintaining elements that provide users a feeling of control can facilitate smoother transitions and greater acceptance. Sandro raises a key point about distinguishing user requirements from the illusion of control. While users may express a need for control, often it's a deeper requirement for trust and understanding of the process. Consultants and developers must listen carefully to discern whether the desire for control is a fundamental need or a manifestation of this cognitive bias. The episode wraps up by reflecting on the necessity of balancing automation with user comfort. By integrating elements that cater to the illusion of control, designers can create more user-friendly and trustworthy applications. This approach not only respects user psychology but also aligns with the broader goals of digital transformation. In conclusion, addressing the illusion of control in Appian development isn't about manipulating users. It's about creating applications that are both effective and psychologically comfortable, bridging the gap between efficient automation and user satisfaction. This nuanced understanding is key to fostering trust and adoption of new, automated processes in any organization.

In our latest episode my co-hosts, Sandro and Marcel, and I delved into our personal experiences with process reports within the Appian platform. Sandro shared his journey of initial struggles and eventual breakthroughs in understanding and utilizing process reports effectively. Throughout the discussion, we highlighted the challenges we've faced with process reports, including their complexities and limitations compared to other Appian objects. Despite these obstacles, we emphasized the importance of mastering process reports and the value they bring to Appian applications. We encouraged our listeners to explore and embrace process reports, despite their complexities, and to share their feedback and experiences with us. We hope to foster a community of learning and improvement in the realm of process reporting functionalities within Appian. Join us on our journey to unlock the full potential of process reports!

In this episode of Appian Rocks, I had the pleasure of hosting Josh Fischer, the leader of the Appian practice at Blue Ark, a woman-owned small business focused on federal government projects. Our conversation began with Josh's journey into the world of information technology, starting from his time at the State Department to his service in the Navy, where he honed his skills in computer systems and information technology. Josh shared his initial exposure to Appian while working on significant projects for the Federal Communications Commission and the Food and Drug Administration. He reflected on how Appian's training and documentation have evolved over the years, noting the shift from basic PDF guides to comprehensive video training sessions. We discussed the challenges faced by new developers in adapting to the platform's growing complexity, particularly with the introduction of features like data fabric and records. As we delved deeper into Appian's capabilities, Josh highlighted his experience with the Live Build Challenge at Appian World, where he learned the importance of balancing speed and best practices in development. He also shared insights into the evolution of Appian's features, including the transition from process-centric to data-driven applications, and the significance of modular design in handling complex data processing tasks. One of the key topics we explored was the challenges of working with large datasets and the limitations of Appian's current data sync records. Josh emphasized the need for efficient data processing, especially when dealing with millions of rows of data from various sources. He expressed excitement about the upcoming Apex execution engine, which promises to enhance performance but also raised concerns about potential latency issues compared to traditional database processing. Throughout our discussion, we touched on the nuances of Appian's documentation, the importance of understanding the differences between on-premise and cloud implementations, and the need for better visibility into related action security. Josh's passion for Appian and his commitment to optimizing processes shone through, making for an engaging and informative episode. As we wrapped up, we acknowledged the ongoing evolution of Appian and the community's role in shaping its future. Josh's insights and experiences serve as a valuable reminder of the importance of adaptability and continuous learning in the ever-changing landscape of technology.

In this episode of the Appian Rocks podcast, I, Stefan, along with my guests Sandro and Marcel, delve into the often misunderstood realm of low-code development. We kick off the discussion by addressing a common misconception: that low-code tools are only suitable for building simple applications. This notion stems from the marketing strategies surrounding low-code platforms, which often emphasize ease of use and accessibility for citizen developers. However, we argue that this oversimplification can lead to underestimating the complexity involved in creating robust applications. We explore the idea that while low-code platforms like Appian can streamline development processes, they do not inherently reduce the complexity of the applications being built. In fact, the potential for complexity increases as developers leverage low-code tools to create intricate systems. We emphasize that effective low-code development requires a solid understanding of software design principles, regardless of the absence of traditional coding. Throughout our conversation, we highlight the importance of proper planning and design in low-code projects. We share anecdotes from our experiences, illustrating how underestimating the effort required for enterprise-level applications can lead to project challenges. We also discuss the role of citizen developers, noting that while they can contribute to projects, they may not possess the necessary skills to manage complex use cases effectively. Ultimately, we conclude that low-code does not equate to low complexity. Instead, it offers a different approach to software development that can enhance efficiency and collaboration when used correctly. We encourage developers from all backgrounds to embrace low-code tools while maintaining a focus on thoughtful design and architecture.

In this episode of Appian Rocks, host Stefan is joined by Sandro, Marcel, and special guest Joe Longworth to discuss the pros and cons of using database tasks versus process tasks in the Appian platform. The conversation was sparked by a discussion on a Discord server where Joe shared his extensive experience with running large applications involving hundreds of thousands of users and tasks. Joe’s preference for database tasks over Appian's built-in process tasks led to an in-depth discussion about the design considerations and challenges associated with each approach. Joe explains that one of the main drivers for his decision to use database tasks is security and the complexity of managing Appian groups. In large deployments with tens of thousands of clients and numerous dimensions of security, using Appian groups can become unmanageable. Joe points out that assigning tasks to groups in Appian can lead to a situation where hundreds of thousands of groups are needed, making it difficult to manage users and their permissions. By contrast, using database tasks allows for more flexible and scalable management of task assignments based on attributes stored in the database. Stefan and Marcel also share their perspectives on the topic. Stefan prefers using Appian tasks for their simplicity and built-in features, which are sufficient for many use cases. However, he acknowledges that for large-scale deployments or scenarios requiring complex security and task management, database tasks may be the better option. Marcel adds that while database tasks offer advantages in terms of scalability and flexibility, they also require more development effort and a higher level of technical expertise. Joe provides insights into his background and experience with Appian, having worked with the platform since 2011. He currently leads a team that manages a large environment with around 10 million active tasks and a user base of 3,500 internal and 200,000 external users. Joe emphasizes the importance of scalability and performance in his decision to use database tasks, as well as the need to integrate with third-party systems and manage tasks completed outside of Appian. The discussion also touches on the challenges of implementing database tasks, such as building custom features like task notifications and managing task reassignment. Joe highlights the benefits of database tasks, including the ability to restart tasks easily and the flexibility to aggregate and work on multiple tasks simultaneously. He also notes that database tasks can simplify the process of upgrading and changing processes, as they are not tied to specific process instances. The episode concludes with a summary of the key considerations for choosing between database tasks and Appian tasks. Factors such as the number of tasks, the complexity of security requirements, the need for integration with external systems, and the distribution of tasks over time should all be taken into account. The hosts agree that while Appian's built-in tasks are suitable for many scenarios, database tasks offer significant advantages for large-scale and complex deployments. Overall, the episode provides valuable insights into the decision-making process for task management in Appian, highlighting the trade-offs and benefits of each approach. The conversation underscores the importance of understanding the specific requirements and constraints of a project to make an informed decision.

In this episode of Appian Rocks, host Stefan welcomes special guest Matt, a seasoned IT professional with nearly 20 years of experience, including a decade working with Appian. The two met at the last Appian conference in Washington, where they decided to have a more in-depth discussion about Matt's career, his experiences with Appian, and his thoughts on the platform. Matt introduces himself as a freelance consultant from Montreal, Canada, with a background in information technology. He shares his journey from working with PeopleSoft and Java web development to becoming a solution architect at a Crown corporation in Montreal. This role marked his first significant encounter with Appian, which the organization chose for a major modernization project. Matt describes the challenges of maintaining a complex technology stack and how Appian helped simplify operations, allowing the IT team to focus on modernization rather than just maintenance. The conversation shifts to Matt's appreciation for Appian's low-code platform, which he found to be a game-changer compared to traditional open-source development. He praises Appian for its ability to streamline business processes and reduce the time spent on technical issues. Matt also highlights the intelligence and professionalism of Appian's support staff and the company's intentional, purposeful approach to product development, drawing a parallel to Apple's focus on cohesive, well-thought-out solutions. Stefan and Matt discuss the potential of AI in software development, particularly in the context of low-code platforms like Appian. While Matt sees value in AI as a co-pilot for developers, helping with tasks like refactoring and code optimization, he emphasizes that AI is only as effective as the instructions it receives. He believes that the true power of AI lies in its ability to assist developers who already have a clear understanding of their goals. The conversation also touches on Appian's new Process HQ feature, which leverages record events for process mining and transparency. Matt expresses some reservations about the need to intentionally record events, as opposed to having an automatic observability feature. He shares his current approach of recording various events to see what insights can be gained, but acknowledges that more experimentation is needed to fully understand the feature's potential. Matt shares two success stories from his career. The first is the modernization project at the Crown corporation, which has been running successfully for nearly a decade. The second is a current project involving a modular design approach, allowing for parallel development and easier maintenance. This project, though not yet complete, shows promise in terms of scalability and efficiency. In terms of challenges, Matt recalls moments of frustration when seemingly simple tasks took longer than expected, highlighting the importance of perseverance and problem-solving in software development. The episode concludes with Stefan and Matt expressing their enthusiasm for future conversations and collaborations, both within the Appian community and beyond. They look forward to continuing their discussions on various platforms and exploring new developments in the world of low-code and AI. Overall, this episode provides valuable insights into the practical applications of Appian, the benefits of low-code development, and the evolving role of AI in the industry. Matt's experiences and perspectives offer a compelling look at the challenges and rewards of working with Appian, making this a must-listen for professionals in the field.

In the latest episode of "Appian Rocks," we had the pleasure of interviewing Mike Schmitt, a seasoned Appian evangelist with over 12 years of experience, making it a truly special episode. Mike began his Appian journey in 2012 as a trainee at an Appian partner company. Starting at the ground level, he got his initial exposure by helping with QA for new releases and mobile app versions. Mike's first major project involved building an HR onboarding and lifecycle management system for the Treasury Department, implemented in the then-new Tempo interface. He fondly recalls the transition from the legacy forms designer to the newly introduced SAIL forms, albeit the project’s timelines exposed him to both systems. Mike’s background is quite eclectic. He graduated with a computer science degree from the University of Maryland but found his initial post-college years murky, working in various IT support roles—first as a bus driver, then a field service tech. His transition into software development was somewhat serendipitous, spurred by a frustrating encounter with a new manager. This prompted him to refresh his job profile, eventually leading him back into a development environment with Appian. In describing his early development days, Mike emphasized the importance of practical experience. His initial foray involved a lot of hands-on learning, thanks to a supportive training environment. He described his first impressions of Appian as challenging, particularly with the older portal tasks and legacy interfaces. Nevertheless, the eventual proficiency led to his enthusiasm for the platform, influencing him to leverage Appian in various ways, including convincing his company of Appian's potential for new tools. Mike was candid about the highs and lows of his Appian journey. One of his early successes was developing a system for generating customizable Word documents for the Treasury Department, showcasing his knack for innovatively using Appian’s capabilities. Over the years, his experiences expanded, particularly through mentoring a junior developer at his current workplace. Mike stressed that despite Appian being labeled "low-code," it still demands the diligence and detail-oriented nature typical of traditional software development. The conversation also touched upon the evolution of Appian, from its early days to the modern incorporation of AI and other advanced features. Mike provided insightful critiques, elaborating on how newer features like user-facing report builders and AI components are potential solutions yet to find their principal problems. He shared a desire for more accessible proof of concepts, particularly for portals and AI capabilities, to better demonstrate their value. On the topic of training and onboarding new developers, Mike emphasized the importance of foundational education, recommending a combination of online courses and instructor-led boot camps. He also underscored the patience required in dealing with Appian’s unique nuances and suggested not shying away from plugins, contrary to some restrictive practices he encountered. True to his pragmatic approach, Mike concluded with practical advice for new developers and seasoned professionals alike: invest time, read the documentation, and engage with the community. His perspective offers a balanced mix of optimism for Appian’s benefits and a realistic view of its current limitations. Developers should apply a patient, open-minded approach to mastering Appian's unique environment, and actively participate in the community for continuous learning and improvement. Mike's contributions to the Appian community, coupled with his rich experience and critical insights, make this episode a must-listen for any Appian enthusiast or professional. Through detailed anecdotes, practical advice, and a candid tone, Mike Schmitt offers invaluable lessons and perspectives that resonate with both novice and seasoned Appian developers.

While chatting on Discord, I had the idea to meet Mat and Mike at Appian World '24 to discuss some ideas. Then we decided to turn this into a spontaneous podcast recording together with Josh. When then discussed the latest Appian features which were just announced in the keynote. A huge "Thank You!" goes to Appian's April Schuppel and Ben Dudley for organizing a quite room in the executive meeting area for us. We discovered that the time was far too brief, and we're eager to do more. Stay tuned!

In this episode, we discuss why software architecture is crucial for any non-trivial application. That has not fundamentally changed with low-code, but we still have to adapt our ways of developing software architecture to the building blocks available. Yes, this means that there are no micro-services in Appian. We also discuss Marcels recent experience with the documentation framework Arc42

The applications developed by us in Appian can have a variety of features. From simple database frontends for create-read-update-delete operations, this can lead to case management, process-driven, and ultimately fully automated processes without human intervention. Our perspective and opinion as experienced Appian consultants often differ from the ideas that someone from the business operations field, a business analyst, COO, or a young Appian developer may have about process operation, process design, and process digitization. We try to cover the important aspects of this topic while focusing on raising awareness of other perspectives and showing respect for them.

Just like whether androids dream of electric sheep (Philip K. Dick), we do not really know if developers dream of documentation. But we still do our best to address most stakeholders in a software project with their specific needs for great documentation. And, as someone gotta write it, we discuss why and how to make documentation a crucial part of each project.

Asking for help is easy, but only one side of the coin. Giving a great answer is the other, and not that simple. We discuss what it means to give great answers, and what is needed to make this a satisfying experience for both sides of the coin.

Based on Marcel van den Berg's well-received demo at the Appian Europe 2023 conference, we explore various aspects of AI, large language models, technical details and the impact of these technological marvels on us and our customers. Large language models allow us to treat a computer just like a human. Using natural language, we can ask for things. In the context of business process automation, we need to tell that model in which specific context of semantics, data and knowledge to answer our questions. Wo discuss what is needed to add this to a typical Appian application. And alongside all the excitement about AI, we cover some important questions that are critical to its use in a business.

User stories are such an important part of our project life that we may have already stopped thinking about their true value for agile project teams. In this episode, we won't bother you with another 5 methods you need to follow to be successful. With sociologists on the team, we discuss the value of user stories for fostering communication and collaboration. Good user stories explain what is needed, focusing on the why, and help business users and developers to have a clear picture of what is needed and delivered.