Is an IT Architectural Method still required with Agile processes?

First, an analogy-

Consider this- if I am building an engine, a process must be followed along the way and I must understand what I am putting together as well as document my plan. If I do not, the pieces in the final work product may not work together and I may not have the desired outcome (a running engine). The same concept holds true in the design of any IT solution, even if I use Agile processes along the way !

Now a few words on IT Architectural Methods and Agile processes-

Before we begin, I want to establish common ground. For those who may not be aware, as part of the IT Architecture Thinking process, IT Architects use Methodologies also known as an architectural framework to guide them in the development of solutions to meet a business problem. There are many IT Architectural Methods, and a few examples might be TOGAF? (The Open Group Architecture Framework), SOMA, IBM UMF (Unified Method Framework) or IBM TeamSD (Team Solution design). Methods contain work products used to develop an IT Architectural vision for a solution/system. Since we now know a little bit about methods, let’s discuss Agile. Agile is not simply “work faster” or “work manically”.  Defined Agile processes exist and are used today to improve project delivery times. Some examples are: Scrum, XP (Extreme programming), Kanban, Design Thinking,  and SAFe (Scaled Agile Framework). As one can anticipate, Agile process are structured differently than a traditional approach, leveraging Epics, Sprints and User Stories.

Back to our topic- Let’s start with a quote from Jim Highsmith (History: The Agile Manifesto, https://agilemanifesto.org/history.html) – “The Agile movement is not anti-methodology…”. What amazes me is Jim wrote this in 2001, and it still applies today. Coming from an instructor of SIM2TG (Architectural Thinking), the short answer is YES. The question “Is an IT Architectural Method still required with Agile?” is almost always asked at least once when I teach the course.

Ask yourself why do Agile processes even exist? It’s simple, they are designed to shorten delivery cycles and provide value to the business quicker. If executed correctly, the business does not have to wait for value in order to reap the benefits of the solution. Delivering new features and functionality designed to improve customer satisfaction ultimately leads to more business and improves the financial bottom line. 

Architects fit a little differently in the agile process versus a traditional delivery. However,  the Architect is not excused from generating IT Architectural Method work products needed while on the way to developing the desired solution. For a moment, let’s discuss basic block and tackle work products and then why they are still needed, even in an Agile process. 

What Basic Block & Tackle IT Architectural work products are still needed with Agile processes and why?

First, let’s talk about what is needed to get started, requirements (functional, non-functional, constraints and future requirements). Functional requirements are simple and straight forward, even in an agile world, as they map directly to specifications which may come from use cases or user stories. However, Non-functional requirements address expectations and characteristics of the solution, are prescriptive or quantitative and can be a little more difficult to define in an Agile world. This is because, all of the pieces making up the solution are not yet defined, but you are still required to address topics like security, scalability, and availability. Constraint requirements are fairly straight forward as they are the limitations placed upon your solution. For example, if I am already leveraging an Amazon Ecosystem for all of my other solutions, it stands to reason, this may be a constraint on my solution as it will enable a simpler integration in my environment. To wrap up requirements, the last type known as “future requirements” can be an art form. They define how the solution may evolve in the future. One needs to visualize and anticipate what may be coming down the road, from business needs or even perhaps future technology. You simply do not want to “wall” yourself in with the solution and need to make certain the approach is opened to scale. As you can see, everyone involved in the effort must understand what is to be built. Documenting requirements is an absolute must. Next, lets focus on Architectural Decisions. Documenting Architectural Decisions, even in an agile world, is needed since a year from now, you or whoever follows behind you may not remember why decisions were made. As an Enterprise Architect, Architectural Decisions have saved me many times when things do not go as planned (perhaps a story for another day). Finally, lets discuss the technical solution design. Without diagrams, (e.g. Solution overview, models [LOM/POM/ALOM]) and a description of the components, we have no idea what we are building and how it will fit into our ecosystem. Let’s not forget we need traceability in the solution all the way back to requirements !

Some food for thought-

As you can see, without the above work products, chaos can ensue which can result in a failed solution or even worse. Future consequences may happen. Implications can be costly as a miss may turn into a financial impact, maybe even elsewhere in the ecosystem depending on the failure. 

One good client example I have seen historically- “using an agile approach, we designed product y as one-off solution and stop gap measure to compensate for a weakness in product x. The developer of product y has left the company along with the details in their head. Since then, product x has been altered to the point in which the stop gap measure in product y no longer works.”

Please comment and share- have you seen the above or a similar scenario in action? Assuming you have seen this play out, did anyone on the team view this differently? Perhaps from the lens of, if proper work products were in place, another mitigation might have been possible ?

-Scott Milligan