I know all technical articles these days are supposed to be about artificial intelligence, but I think many organizations are still working to modernize their application development lifecycles. I was going through my file archives this weekend and came across an old graphic I used often, and it made me reflect. Having spent over 30 years in the IT space, I’ve witnessed the evolution of technology from mainframes to desktops, cloud computing, and handheld computers, which we now refer to as phones. Keyboards have given way to mice, and now our fingers and voices are the primary input methods. Our access to data has transformed from being limited to being fully searchable, and now it can be dynamically generated in a summarized form using AI. My journey began with coding in C, Pascal, and Visual Basic, and I later transitioned to C#, JavaScript, and Python. The languages may have changed, but the processes remained consistent. We would gather requirements, design the solution, code, test, and deploy. Occasionally, we would deploy and let the user test, but that’s a different article. One of my favorite jokes from my development days was, “You start coding, and I’ll go find out what they want.”
I liked it so much that I asked my talented son, the Graphic Artist, to create my own graphic for the saying. I liked this joke because it allowed me, as a developer, to call out to my business partners the importance of understanding their business processes and requirements. How could I ever build a solution if I didn’t know what they needed? This spawned the role of the Business Analyst. Their role was to get the requirements, document the processes, and help the developers deliver a solution that meets the user’s needs. We built solutions using a waterfall method. Gather the requirements, analyze the rules and processes, design the solution, code it, test it, and deploy it. The joke was that bad development teams would have someone start coding while someone else went and found out what the user wanted. It was illogical in a waterfall development model to work this way.
However, as technology has evolved and our development methodologies have modernized, I find myself reconsidering the use of this diagram. It is now less tongue-in-cheek and a more optimal approach. This reevaluation is also tied to my transition in my career from the developer’s chair to an Enterprise Architect (EA) role, which has given me a broader perspective on solution development.
The beauty of our modern development methodologies is that we CAN start building the application as we gather the valid requirements. The concepts of Minimum Viable Product (MVP) and Packaged Business Capabilities (PCB) have revolutionized our approach, allowing us to accelerate our time to market and deliver quality solutions quicker than ever before. As an EA, I’ve coined my own architectural principle, ‘Always is cheap, sometimes is expensive.’ ™ This approach allows us to standardize specific components of our applications and have scaffolding ready to go when the business calls for a new solution. We know we’ll need user management for most applications, logging, and a pre-defined look and feel. These items can be in our base application, accelerating our application development lifecycle.
If we rely on Process Architecture in our organization, our development team should understand how the business operates. Our business architects work with our solution architects to leverage operating and organizational models aligned with business capabilities. Then, we can start to work on the critical elements of the solution as we harden the requirements. The business architecture is tied to the key business value, or North Star, for the desired solution we will deliver.
If we use a Service-Oriented Model, we can use mocking endpoints to show the developers what the payloads might look like. These endpoints can quickly be built out for testing and consumption to demonstrate end-to-end integration without actual endpoints yet developed. The business partners can review the data elements and accelerate the information architecture validation for the desired solution.
As new technologies emerge, I often think that what is new is old. We still gather solid requirements and ensure our solution designs have proper security. We need to worry about scale and performance. However, I am energized by the emergence of business architecture and other enabling capabilities like CI/CD and API-driven development. These tools will allow us to deliver quality solutions quickly if we embrace them.
So go ahead. You start coding, and I will go find out what they want.
