Introducing The App Building Cookbook
With the learnings and insights I have gathered over the years, there is a successful pattern I’ve seen regarding business application development. I like to refer to it as the App Building Cookbook, as pictured above. Lately, I’ve been guiding many customers and potential customers through this path and how it relates to the technology I specialize in through a mix of strategic and hands-on engagements. Join me as I dive deeper into what makes this cookbook tick along with some general observations, starting with architecture.
I am a software/solutions/technical/technology (there are so many different ways to describe the same position, haha) architect by trade, so you can bet your bottom dollar that I would have a fair amount to say regarding the subject of architecting a system. The first thing I’d call out is how important it is that we get the architecture right before kicking off our projects and initiatives. Using the analogy of building a house works great here. I might not necessarily care about detailed finishings and paint colors at this stage. In fact, it can be detrimental to do so early on in the process and is typically referred to as “missing the forest for the trees.” What is important, though, is ensuring we establish a strong foundation that is grounded in the realities of what the needs are and what can be delivered. Otherwise, we are setting ourselves up for just another failed app (JAFA for short).
Outside of avoiding “missing the forest for the trees,” how can we build these solid foundations and avoid the dreaded JAFA? To answer this question, I draw in part from Buddhism’s Eightfold Path. I believe it all starts with achieving the right understanding between all key stakeholders. This is easy to state but can be incredibly difficult to execute as there are many pitfalls. You also cannot throw expensive software at this problem and have it go away. We could reach a common understanding and have great unity as a group on a cause, but if that cause isn’t the right one for our organizational needs then we have missed an opportunity to be more targeted and focused and perhaps wasted time and resources as a result. In order to have the right vision, you have to establish a safe space where people feel included and diverse viewpoints can be heard based on their merit and not a hierarchy. This safe space has the pre-requisites of being a place of respect and mindfulness. And it needs to be a fun and engaging environment that encourages people to participate in the effort. The prevailing methodology out there that I believe enables this right vision is called Design Thinking. I ascribe to this methodology and utilize it regularly. It is a bit too involved of a subject to adequately explain here so I recommend you do some research on your own if you are unfamiliar.
Let’s say that we now have the right vision established and under our belts. That’s awesome 🌈. We next need to narrow our focus to an agreed-upon use case and ensure we have the right understanding of it. This is often done through a process called Discovery. I start discovery by opening the floor to the customer to explain the use case while doing my very best to be an active listener. We want to avoid making assumptions if at all possible. We want to ask probing and open-ended questions while also being mindful of the time we have allotted to the effort so that we don’t derail the conversation from other topics that would have been more beneficial. I try to capture notes during this process, honing in on relevant technologies I think could align well with the challenges they are facing currently along with the goals they would like to achieve. After the customer feels like they have said their piece, I demonstrate concepts and capabilities to show that I have understood what they have shared with me during discovery. If that lands well, it means we have reached alignment between a use case and a technology and can now start moving forward with a solution.
Frankly, I find solution architecture to be the driest and most monotonous part of the process. This is in part due to its repetitive nature and that human beings have figured it out to the point that it is very formulaic. That doesn’t change the fact that it is still required. If we don’t go through the effort of thoroughly capturing our use case alignment, then we cannot expect the implementation of the solution to be a success. This capture is typically done with diagramming, requirements gathering, and wireframing. In my current role, I do this rapidly over the course of a few hours to show that it can be implemented. True solution architecture typically takes much longer and can stretch out into weeks or even months. With the advancement of Agile Methodology, solution architecture often occurs over the course of a project as new requirements and challenges are discovered during implementation. I feel that implementation teams would benefit greatly from being involved earlier in the process because even the best capture doesn’t shed light on all the dynamics that happen earlier on in the process. This would provide valuable context to the builders of the application, but oftentimes organizations fail to value this over keeping them productive and actively implementing solutions.
With that, I conclude my story on architecture in the context of what I call The App Building Cookbook. I’m sure there are many similar stories that have been told, but this one is mine 🙂 I’m thinking of having this be a potential series where I go through the other aspects of the cookbook, so stay tuned!