POC as an Architecture Output

In this post, I am going to explain the needs to use Proofs of Concepts, from now on mentioned as POCs. I will talk about concepts, assumptions and positive and negative impacts in order to show you the benefits of using POCs as an architecture output.

Here in Brazil, POC has a very interesting meaning linked to the LGBT community, that even resulted in a new musical style, the pocnejo (ramification of sertanejo). You can google it to know more about it because it’s not that kind of POC that I’ll talk about in this post. I’m here to talk about Proof of Concept and why we need start using it as an artifact of our architecture design process. But before I start talking about POCs, I need to contextualize you first, starting at the main motive that is architecture:

So, what is software architecture?

According to Wikipedia “Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems”.

In reality, software architecture has no strict definition.

To me, an Architect must break large rocks into small pieces. It must have system thinking. It must have critical thinking. It needs to embrace chaos and analyze trade offs. And finally, an Architect must make a software easily understandable to stakeholders (business analysts, designers, developers, users, managers) and show the way to lower level design and implementations.

But how can we show this kind of information?

It’s not easy to understand software, software is nothing tangible. Almost 60% of human brain evolved to process three dimensional information, so we can see and interact with our world. We didn’t evolve to understand software. Talking about large scale development, it is hard to a developer to see the whole and understand each component and how it communicates to the rest. So we need ways to make software more visible and understandable to our brain, describing it using tools that build a common communication language between different people. We usually think (intuitively) of describing software and architecture as documents, PPTs, diagrams and models using some common language like UML or BPMN. We can use view model frameworks like 4+1 view model or Zachman Framework, which are frameworks and ways of describing software in a language understandable by different types of professionals. But, is it enough? “Our process is working, we are succeeding, why would we change?” or “We just need to define what engineers need to do and they find a way to do it.” are assumptions that we hear a lot.

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.

Fonte: https://medium.com/@gusdlim/poc-as-an-architecture-output-cf0ef4a42e10

POC as an Architecture Output

Ficamos felizes que você tenha interesse em nosso conteúdo.