Appian Rocks: Recent Episodes
Stefan Helzle
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 Blueark, 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.
When we hear people saying things like “Just because it’s low code doesn’t mean it’s low complexity!” we feel the urge to start a conversation. Does simplified software development mean that we cannot build complex applications? Why do we think that low-code platforms like Appian are underestimated? And why do we stress the Lego bricks metaphor again?
https://jaylittle.com/post/view/2023/4/low-code-software-development-is-a-lie
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.
Architecture documentation framework Arc42: https://arc42.org
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.
Find some relevant documentation methods below:
- Arc42
- C4-Model
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.
The links to the two great resources we reference:
- Jon Skeet about asking questions
- Stack Overflow “How do I ask a good question?”
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 clients.
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.
Find additional information about Marcel’s demo here: Appian AI Claims Prototype Supportive Content
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.
In our 10th anniversary episode, we discuss why it is a good idea to throw error messages at other developers in case they are using a component in an unexpected way. This concept helps in embedding junior developers in a team and saves a ton of time and effort hunting down weird bugs. We explain how to implement this design pattern using it in expressions, processes and interfaces. And somewhere, deep in this stream of thoughts, we find out that this kind of error handling sometimes must be optional. Sic!
I asked the more than 120 book lottery participants which topics they would like us to discuss. We have picked out three of the most interesting suggestions: "Querying Records", "Composable Architecture" and "Integration Error Handling". A huge "Thank You!" for that inspiration goes to Laurens, Andrew and Souvik. As usual, we managed it to turn simple questions into a complicated multi-dimensional and mind-bending problems, and still finding some good answers.
Are you still trying to convince your stakeholders with boring PowerPoint presentations? Take advantage of Appian's power to be bolder and more progressive! Take the chance to amaze people with a demonstration of a fully functional prototype. Our special guest Marcel, Marcel and Stefan discuss how we build prototypes and what to consider.
Marcel and I started a conversation about the the need for more advisory in Appian projects. People, roles, company structures, change management, requirements, processes, methodologies .... and once again we are deep in the rabbit hole of ideas, concepts and our daily business. Follow us on our journey to escape this, and get back to the light of day.
Sandro, Marcel and I are trying to get a handle on technical debt, compare good and bad design decisions and understand why this is still a problem, even though now with low-code everything has become so easy.
In lower level language environments, developers spend a lot of time building reusable pieces of code to encapsulate technical complexity. Like Appian’s low-code approach eases the way of building process driven applications, it also puts “don’t-repeat-yourself” on a different level. Join us in our conversation on concepts, practical use cases and horror stories about code reuse.
Typical employees take pride in the work they do. If the content of their work changes (i.e. due to a new Appian app), their first reaction might be to feel threatened, because now the ‘machine’ does things ‘only they could do’.
We talk about turning users into makers and developers into consultants and the difference between an Appian Developer vs. Appian Designer vs. Appian Consultant.
We also touch the importance of process maturity, how key users can help, and why product ownership is crucial.
While discussing some case studies, we try highlight the differences of business processes and technical processes. The SIPOC methodology helps us to discuss technical processes with business analysts and we talk about the importance of making software organise our processes.
Simplified software development is not just a matter of selecting the right tool. You also need to reconsider your way of designing applications. In this episode, Sandro, Marcel and I talk about process driven versus data driven paradigm and the impact on data modelling. Then we discuss what we mean with process thinking and how to incorporate our stakeholders directly into application design.
For this first episode we where able to invite a very special guest. I met Malcolm Ross about 10 years ago at one of the first Appian meet-ups in Europe. As the Vice President of Product Strategy, he is the brain behind the Appian platform. We talk about his career, Appian (the company), Appian (the software), as well as the development team and do not miss some details down from the technical rabbit hole.