Requirements are dangerous

Software architecture it's much more than satisfying requirements. Requirements can be tricky and several times misleading. Requirements are easy answers and they often shut down important discovery processes. Requirements are old as snakes, they were heavily praised by RUP, CMMI, PMI and still in vogue nowadays. The requirements list is just a wish list someone made. Requirements gave the false sensation of doing the right thing but this is just a lie. Requirements are often lying. Software architecture is a continuous process that requires thinking, judgment, leadership, and critique. Requirements are some easy to be gamed and often they are. So why people do it? Well, I think thats the wrong question. Software is full of sudo-science being used for ages and just does not work like estimates for instance. 

The Issues with a 'List of Requirements'

Anyone can create a list of things they want. But the right way to see it because mostly requirements lists do not have goals often they have just decisions. Decisions in a particular direction or even belief. So why that's wrong? Well for several reasons such as:

 * What around the nature of the problem we are facing? Problem space. 

 * What about trade-offs, could we do things in a different way? would that be a better way? 

 * What about the future? would that be a solid direction? 

 * What about non-technology aspects? How we address them? 

 * What about Short Term and Long term? Or we just have project thinking in short term? 

 

It's easy to skip the whole architecture and design thinking process and just have a list and call out the day. That's not Software Architecture. It's easy to give a list to a group of architects and say sign off, thats what we gonna do. It's easy to say we are doing the right thing because we have a list of requirements. It's easy to fool ourselves with process artifacts and no real deep thought. Why people still do it? Well lack of real software architecture skills, just a way to game the current process and move one. Unfortunately, consequences take time to appear. JIRA, Wikis, and paper accept anything. 

It's all about Vision

Well, not that Vision. Software Architecture is about having a solid foundation and making sure we are going in the right direction. Going in the right direction requires vision but it can be summarized as:

 * Approaching the problem with the right Design Lens. 

 * Make sure we dont have Design Gaps

 * Make sure the solution will work as expected 

 * Make sure we can scale users and engineers

 * Make sure this will be maintainable

 * Avoid coupling, Avoid unnecessary complexity   

 * Right Build vs Buy evaluation 

 * Right strategy with a proper migration plan 

  

Requirements lists do not capture 5% of the important things. Requirements lists do a very poor job communicating and driving people and teams in the right direction. Most of the so-called software architects are just SR engineers. Meaning they just can think about creating binaries. So why these problems still happen nowadays? IMHO there is a list of reasons:

 * Lack of proper software architecture skills. 

 * Teams and management just caring about delivering software on-time. 

 * Increasing complexity and pressure to delivery making teams not think much before executing.

 * Inertia - Just doing the same without reflecting about it (Lack of Retrospectives and ACTIONS). 

 * Wrong vision about what software is and what healthy software development means.

 * Not running Design Sessions and Design Review. 

 * Not having proper guidance and guidelines.

 * Missing the Big Picture (Often not using DDD)

 * Not paying attention to detail and for sure not being Data-Driven.

 * Not understanding that Design > having Tests.

 * Lack of action Twards Debit and Hidden Costs.

Lack of Product Thinking

To be 100% clear SOA always had product thinking. Product thinking is continuous and long term different from project thinking with is short term. Often have a requirement list is a process step. So once you do it you can move one, then you build it, and then you are done. That's project thinking. What are the criteria for success? How we maintain things after they being done? Project thinking does not worry about that. Doing software architecture with a project mentality is completely different than doing Architecture with a product mentality. IF you understand that software might run forever as long as the product exists you might think with a completely different lens. Applying product thinking to software architecture and working with real software architecture process means going beyond a simple requirement list and embracing:

 * Clear comunication of direction and Strategy  

 * Governance: Ownership & Continuous Improvement. 

 * Inventory: Catalog of Services and asserts with SLOs

 * SOA Contracts and Isolation mentality(avoid coupling)

 * Right Design Process (focusing on trade-offs) 

 * Proper Review and Continous Learning Process 

The architecture will make a huge difference at Scale. Architecture is about design and continuous improvement is not about a static list of whises and poor decisions. Architecture is a result of a process that requires leadership and review and care.  

I hope you like it - take care.  

Cheers,

Diego Pacheco