It’s ok to change. We live in an agile world, lets not be cascade. Currently I’m working on a project using DTA (dual track agile). In this method, we think about architecture in a separated track, discovery track, before get on the hands of a delivery team. Without this track, architecture, business analysis and UX are overlooked by short deadlines, top down releases pressure and any other usual reason (but that’s a topic for another post). In this evolutive discovery process, I have noticed some things:
- Arch documents don’t reflect user requirements properly.
- Issues masked behind an architecture design may pass unnoticed.
- Differences between designed architecture (docs) and implemented architecture (masked/hidden) on the development.
- We cannot guarantee and test whether the architecture really works as expected.
So how can we evolve and fix these issues? We achieved that in a simple way, which was POC’s as an architecture output of our discovery track (besides docs).
A POC is a proof of concept that we can validate architectural challenges, complex scenarios, validate the right tech stack, trade offs, etc. By doing POCs we can:
- Validate if a tech stack works in our context.
- Mitigate “fogs” between business and tech, where we don’t know how it works or how it should be done.
- Create a common and effective communication tool among every different type of stakeholder. In the end, every one wants to see running software.
- Make sure we met all non-functional requirements validating this architecture. It also, helps to understand the system bottlenecks, finding issues and difficulties faster, so we can improve faster.
- Enhance the delivery team implementation speed and quality using POCs of complex problems as implementation template and guidance. Besides that, it speeds up the developer understanding of the architecture, where they can work with both doc and code.
A POC is not a simple “hello world” with a new technology or a dummy test of a cool stack. A POC needs a concept to be proven, an objective, a true meaning. For example, we may want to prove that we can build a face recognition algorithm with at least 80% of accuracy or validate if least outstanding requests routing algorithm has better results in our scenario than round robin algorithm. Remember to focus on the objective, so build your PoC project as simple as possible.
It’s good to make it clear that POCs are not silver bullet as well as they should not be a complete solution with many hours of work spent (as a final product). Proofs of concept must focus on complex problems, focusing on business and tech critical parts. We need to think whether it’s really worth doing a POC before necessarily doing it. For small and simple problems, doing a POC, may be unnecessary, taking time away from really critical and complex scenarios (validating a rest call, for example). But if it is really the case, PoCs can dramatically decrease complexity and development issues, breaking the larger rocks into small pieces.