Learn about the importance of building in an decision archival process into your development workflow, to mitigate the risk of information loss and accelerate similar future initiatives.
Explore all of the launches and capabilities announced at the 2026 AWS Summit in New York City, including Amazon Bedrock Managed Knowledge Base, AgentCore harness, AWS Context, and AWS Continuum.
AWS will end support for Amazon Pinpoint on October 30, 2026. Learn what's going away and what's surviving, what your migration options are, and how to quickly audit your environment to see your exposure.
Explore all the exciting announcements from Dr. Ruba Borno's partner keynote. From the general availability of AWS Transform compatibility to new AWS Marketplace capabilities, the updates showcased powerful new ways for partners to deliver value.
Mark Olson, Caylent's Portfolio CTO, is passionate about helping clients transform and leverage AWS services to accelerate their objectives. He applies curiosity and a systems thinking mindset to find the optimal balance among technical and business requirements and constraints. His 20+ years of experience spans team leadership, technical sales, consulting, product development, cloud adoption, cloud native development, and enterprise-wide as well as line of business solution architecture and software development from Fortune 500s to startups. He recharges outdoors - you might find him and his wife climbing a rock, backpacking, hiking, or riding a bike up a road or down a mountain.
View Mark's articles
Randall Hunt, Chief Technology Officer at Caylent, is a technology leader, investor, and hands-on-keyboard coder based in Los Angeles, CA. Previously, Randall led software and developer relations teams at Facebook, SpaceX, AWS, MongoDB, and NASA. Randall spends most of his time listening to customers, building demos, writing blog posts, and mentoring junior engineers. Python and C++ are his favorite programming languages, but he begrudgingly admits that Javascript rules the world. Outside of work, Randall loves to read science fiction, advise startups, travel, and ski.
View Randall's articlesWhen people build out their first version of an application and then maybe move on to a new project, a lot of the history around the decision making process is lost. Why did you pick this architecture over another architecture? Why did you build out a certain part of the application and not the other part of the application? What are the concerns and the things that were rejected? Such information can give you so much context when you're coming into a project around why certain decisions are made and what controls you have there.
Typically, we’ve seen that there's tribal knowledge in an organization. I know to go walk down the hallway and knock on my colleagues door to talk to her about why she made a certain decision on an architecture and understand it a little bit better. However, with the sort of great resignation, if you will, people are shifting jobs and maybe that tribal knowledge is now leaking out of the organization. Hence maintaining an archival process to record decisions can help mitigate that risk of losing some very key information that helps accelerate similar future initiatives. Another use case for this could also be an auditor who may come back to ask why a decision was made and how an encryption or security decision was made and implemented.
The best way to do it is to almost have it live alongside your code. It can just be a plain text document with links to some of the other resources. If it lives alongside your infrastructure-as-code, your TerraForm, your AWS CDK or your AWS CloudFormation, it just records the reasoning behind the decisions that you've made over years and years. That accumulated history is incredibly valuable for educational purposes, for understanding how your application operates. And it also prevents a lot of the redundant work that people will do in future projects.
Adding an archival process is also seamless to a normal development process. You might have a peer review process where you're taking a look at the code. And part of that involves asking where's the decision record for a certain feature or project? Where is the context for it? We can make sure that keeping track of that is committed along with the feature. So it’s not adding anything to the development team other than to help the next person that needs to take on the project and understand how decisions were made and, and what the history of the feature or the platform might be.
It's a great handoff for, for maybe a vendor like Caylent coming on board, or a vendor like Caylent handing off back to a client team, making sure that we've captured all of those decisions so that their team can run with it. So wherever there's a handoff, it feels like it'd be a valuable artifact for the next team to take on that project.
If you’re building applications and would like to leverage the capabilities of the AWS cloud, get in touch with our experts to learn how we can help!
Mark Olson
Randall Hunt
