『Appian Rocks』のカバーアート

Appian Rocks

Appian Rocks

著者： Stefan Helzle
無料で聴く

Where No Code Has Gone Before© 2022 Stefan Helzle
エピソード
  • Ambiguous Terms

    Ambiguous Terms
    2026/07/01
    The Trap of Ambiguous Terms in Appian Projects In this episode of Appian Rocks, hosts Stefan, Marcel, and Sandro step away from the AI hype to explore a more fundamental challenge in software development: ambiguous terms. The team discusses how common industry jargon can lead to "situations gone foobar" when project stakeholders assume they are speaking the same language but are actually operating from completely different definitions. 1. Big Data: More Than an Excel Sheet The discussion kicks off with the frequently misused term "Big Data". While some clients consider anything that crashes Excel to be Big Data, the hosts define it more strictly as data sets so large or variable that it becomes more efficient to "bring the compute to the data" rather than moving the data to the compute. They clarify that while Appian is excellent for business processing and can handle millions of records, it is not an original Big Data tool like a Spark cluster. 2. Input Management: A Spectrum of Meaning The team explores "Input Management," a term that scales from a private person scanning a single letter to an enterprise highly automatically processing "truckloads" of documents. They warn that this is often confused with "blind processing" (Dunkelverarbeitung). In the Appian world, two people might both claim to be doing "input management"—one focused on a scanning station and the other on a complaint business process—despite having almost nothing in common in their daily work. 3. Business Analysis: The "Why" vs. The "What" Sandro and Marcel delve into the evolving role of the Business Analyst (BA). They argue that while many BAs focus on turning needs into user stories for developers, the most valuable BAs challenge assumptions and find the "why" behind a process. They note that as developers become more senior, they often find themselves performing business analysis naturally to prevent building bad applications based on missing context. 4. Architecture: The Art of Decision-Making Finally, the hosts tackle the term "Architect". Marcel offers a thought-provoking definition: "Architecture is decision-making in the face of ignorance" and the art of "postponing decisions" to maintain system flexibility. The team highlights the confusion that occurs in "Architecture Boards" where infrastructure, cloud, and software architects meet, only to realize they are all speaking from different, non-overlapping perspectives. The Solution: Signposting and Clarification The episode concludes with practical advice for avoiding these traps: Signpost your perspective: Start sentences with "From a security perspective..." or "As an Appian developer...". Define roles early: Clearly explain your understanding of your role at the start of a project to avoid mid-project surprises. Ask qualifying questions: Don't assume you know what someone means; ask for their story to ensure your definitions align.
    続きを読む 一部表示
    1 時間 1 分
  • AI and Product Love

    AI and Product Love
    2026/04/08
    In this latest episode of the Appian Rocks podcast, hosts Stefan, Marcel, and Sandro tackle the complex reality of integrating AI into the Appian platform. Recorded in January 2026, the conversation highlights a growing tension between high-level marketing promises and the practical constraints faced by developers on the ground, particularly within the strictly regulated markets of Germany and the broader European public sector. Stefan shares his "stomach aches" regarding the pressure to sell Appian as an "Enterprise AI" tool when data protection laws often prohibit the use of foreign AI technologies in public services. The discussion distinguishes between two main branches of AI: customer-facing capabilities, such as document extraction and semantic search, and developer-facing tools designed to accelerate the build process. While the hosts praise features like the AI-powered documentation chatbot for its immediate utility, they express skepticism regarding the "AI Composer". Though the Composer can generate an application from a requirements document, the hosts argue that the output often lacks the long-term maintainability, scalability, and architectural integrity required for professional enterprise solutions. A significant portion of the episode is dedicated to a "Quality of Life" wishlist, with the hosts urging Appian to prioritize fixing long-standing product deficits over adding more AI "hype". Major pain points identified include the tedious nature of managing translation sets across multiple applications and the lack of automated schema management for record types. Sandro highlights the frustration of rigid UI alignment options, noting that achieving professional layouts often requires "hacky" workarounds. Additionally, the team requests simple yet impactful features like a native sticky footer and a fix for a persistent autocomplete bug that incorrectly selects items based on mouse cursor position. The episode wraps up with a technical deep dive into the need for an application-scoped sandbox plugin environment. Such a feature would allow developers to extend the platform’s capabilities safely, ensuring that custom AI models or libraries can be used without compromising enterprise-level compliance across the entire environment. Ultimately, the hosts call for "a bit more love" for the day-to-day tools that keep developers efficient and happy.
    続きを読む 一部表示
    52 分
  • Training Appian

    Training Appian
    2026/03/04
    In our latest episode, Sandro, Marcel, and I explored a topic crucial for anyone working with Appian: training and educating developers. Many prospective clients approach us, noting Appian is a low-code/no-code platform and wondering if they even need to train their "citizen developers." Our consensus? Training is absolutely essential. The true value of a citizen developer is their functional, business-side knowledge. They can become a valuable team member and steer development because they know how the application is intended to be used. The ideal team is a mix—technical experts ensure a technically good application, and business experts ensure it solves the actual problem. Being a developer, regardless of the technology, requires a specific approach. People need to understand how software in general works and become "software designers," not just coders. A developer must be able to analyze a complex situation and turn something from a problem domain (like complaining about too many emails) into a solution domain (like reducing manual workload by 80%). A key indicator of a good potential developer is the capacity to ask clarifying questions instead of jumping straight into a solution based on vague or assumption-loaded descriptions. The goal for training juniors is to get them to an Associate Certified Appian Developer level. Both traditional and non-traditional IT backgrounds need to understand processes and process-driven software, recognizing that a process has a lifecycle with a start and an end. Traditional IT professionals often grasp the technical context quickly, while non-traditional backgrounds often excel at understanding the messy human context in which Appian operates. Juniors must master methodical thinking and debugging, including knowing the Appian platform's monitoring and debugging options. We encourage juniors to try solving a problem on their own for 30–60 minutes, check the community, and then come to their lead prepared to explain: what they are trying to do, what they have tried so far, and what the current issue is. This structure helps them self-solve and makes the assistance more effective. Asking "why" repeatedly, a technique officially known as the "Five Whys Method," can also help break a person out of a narrow view to fix the root cause. We follow a structured training path. People first complete the Appian Developer Learning Path to understand the platform's components and intended use. This is often followed by a one-week on-site boot camp where a group works on one application with a prepared use case. During the boot camp, we cover our internal developer's wiki, including naming conventions and reusable components, ensuring a common understanding for working within our teams. Finally, working in teams and providing regular code review is crucial to avoid reinforcing bad habits, which is why training is expensive—it requires your best people. Becoming a senior is less about writing quicker SAIL code and more about broadening context and developing consultancy skills. A senior needs to have empathy, understanding that the person paying for the solution has a valid problem and doesn't necessarily speak your technical language. They also must recognize that process-orchestrating software is an organizational change, requiring an understanding of change management to design transparent processes that don't frighten users. Seniors need to understand UX/UI design, business processes, and guesstimating non-functional requirements like performance and memory consumption. A true senior has experienced the pain of running something they coded in production and dealing with user issues, which enforces understanding of maintainability and responsibility. We're always happy to talk about these topics! If you have any questions, please feel free to send them in!
    続きを読む 一部表示
    55 分
adbl_web_anon_alc_button_suppression_t1
まだレビューはありません