The Product Management Interface — The Architects

The Architects look at the engineering competence of the organization, build engineering capabilities and ensure the technology is the best in the market. A product manager must involve engineering early, ascertain the larger context of the product is understood, and capabilities exist before the actual delivery cycle or the build phase of engineering. The architectural involvement in a project must be in the planning phase.

The Common Sense Trap

Most people, who engage in average engineering skills, tend to focus on common sense and get engineering into a common sense trap. I state a few examples here to describe why common sense is a trap; you need a little above common sense to excel in engineering. I will discuss four geometry problems, their common sense implications, and not-so-common engineering interpretations.

Problem 1 — Point Coincidence

Given two points: A and B, in 2 dimensions (on a piece of paper), we want to know if the 2 points are the same.

Common Sense Interpretation — If Ax = Bx and Ay = By, Then we know A = B, what your average engineer will code.

Computer Scientist’s View Point — Fixed-bit floating point numbers, used in computers, cannot represent all the numbers to the mathematical exactness. They have rounding-off errors. For example, a number like 0.1 decimal does not have a 32-bit binary representation. Like, 1/3 does not have a fixed decimal representation; a recurring number of 0.33333..3. So if you did a few computations to arrive at the number Ax or Bx, you would be off from the ideal values. So equality does not hold. So, a typical computer scientist would say:

If the distance(A, B) < pcTol, then A = B. pcTol or Point Coincidence tolerance is a fundamental computation premise in most CAD and graphics floating point systems.

Problem — 2 — How to know if three points form a triangle?

Common Sense Interpretation — We know a triangle has 3 points. If any 2 points are coincident, the triangle does not exist. So, if distance(A, B) > pcTol or distance(B, C) > pcTol or distance(C, A) > pcTol, then there is no triangle. Does this mean if: AB = 10.0, BC=20.0 and AC=10.0, it will be a triangle? The answer is no.

Common Sense+ Interpretation — The sum of 2 sides of a triangle has to be greater than the third. That leads to the statement: AB + AC = BC, in the earlier case, So ABC is not a triangle. But what if AB = 10.001 and AC = 10.001; will that make ABC a triangle?

The CAD Triangle Area test — The sum of 2 sides is a good enough metric. However, it does not tell you how pcTol you accepted as the fundamental of point coincidence, is related to the triangle. If you look closely, while AB, AC or BC none of the values are anywhere close to pcTol, the vertical distance of point A from the line BC can be small due to the lengths of AB and AC relative to BC; if assuming the vertical projection of A on BC is D (AD can be smaller than pcTol). So for a CAD engineer, the triangle area test looks something like this:

max(AB, BC, AC)*pcTol > 2*area(ABC) means the triangle is invalid

Corollary 1–3 points are co-linear when they do not form a triangle.

It comes from the principles discussed in problem 2.

Problem- 3 — How do you find n-points are co-linear?

Common Sense Interpretation: Once I know 3 points are co-linear, I can consider three consecutive points together every time and check if they are co-linear. If all such point sets are collinear, they are co-linear points. Unfortunately, the answer is negative. The solution will be to check all three point sets and compute co-linearity. But if you have n-points, your complexity will be n³, a sub-optimal solution from a computation standpoint.

Computer Scientist Interpretation: You will be surprised to note data scientists use this with principle component analysis. So they will try to fit a line through the n-points and measure the distance of the line from each of the points. If one of the points is at a distance above pcTol from the imaginary line, the points are not co-linear. Cross-correlation of multivariate analysis under ANOVA is a similar concept.

Problem — 4 — Find one point which is definitely inside a polygon.

We all know polygons comprise an infinite number of points. We are interested in just one point guaranteed to be inside the polygon. It seems like a trivial puzzle of picking up one from an infinite. Polygons can be concave and can have holes in them. The solution is here: http://www.faqs.org/faqs/graphics/algorithms-faq/ (Subject 2.06). You are a born CAD architect if you arrive on your own.

Why Architects?

You must be thinking, why talk about 2-D geometry and seemingly naive puzzles? The 2-D systems are the most common geometry that we deal with in day-to-day interactions. We have studied them for almost 12 years of education. But when it comes to CAD, answers cloud our minds into corner cases. Common sense fails. Common sense is good enough for most problems. If you want to differentiate even a bit in the market from competitors, it is best common sense kept at a distance. Good architects help you avoid these traps. Most serious organizations have architects who have industry-level contributions in the domain or are close to making those transitions by making their presence felt through patents, industry articles, standard bodies, etc. Software architects have understood and designed large-scale systems deployed in the market. They also contribute significantly to scale and operational excellence. Sometimes, there are engineering leaders who play roles are architects to build consensus in teams. I will not discuss them in this section as their roles are mostly part of the engineering interface. In simple terms, the title does not truly matter. The level of technical competence a person brings is what defines an architect.

Engage the Architect in Early

The PM is focused on understanding the customer problem and has some understanding of the possible implementation but may not know the engineering feasibility. Workflows not aligned to engineering feasibility create problem statements that do not lead to reasonable solutions. With AI and Machine Learning integrated into newer systems, the dependency has grown further. These fields mostly require higher-order mathematics and statistics that may be outside average skills. An architect can quickly identify those complexities. Being aware of the internal engineering capabilities can reasonably estimate the complexity. If needed can guide the product management to request for building or acquire the skill set to develop capabilities.

Outside-in-View of the Latest in Technology

Architects bring an understanding of the latest technology needed in the product to support the next generation of products, for example, the new web technologies, the latest in REST APIs or Web Services. Things like this do not directly impact the customers; there is an inherent requirement to upgrade to ensure the product is maintainable in future versions of the operating systems. The performance and scale requirements are another continuum of improvements to look into. Upgrades and remote deployments are some standard day-to-day use cases with a need for architectural inputs though customers do not explicitly request them.

How to Apportion Architectural Requirements?

It’s crucial to develop a portion of the product backlog for the architects to fill in and continuously assess their immediate needs and capacity requirements due to those changes. From a feature value perspective, they do not add a straight addition to the product needs, but they are for the ultimate success of your product. Hence, there has to be some portion of the development cycle allocated for such activities. No PM can approve a pure bug fixing, stability or architecture enhancement release. But, every release can have a few product sanity improvements or pay back the technical debt.

The Engineering and Architect Barrier

In most product organizations, the architect reports to the engineering management, but the scope of both roles is different. While the architect focuses on the eventual quality, longevity and scalability, the engineering acts on timely delivery to an agreed-upon quality metric. Any change to the interlocked scope is frowned upon. Sometimes, architects lock horns with their immediate management. And may find themselves in a situation of limited help. PMs sometimes need to assess the organization dynamics and impress upon engineering leadership to support the cause for the product accepting scope creeps and schedule deviations.

Conclusion

Product architecture is for the longevity and success of a product. Architects add to a significant part of that. A PM should understand the usefulness of this interface and look beyond the immediate release needs. And more importantly, work closely with the architects to ensure the success of the products.

Originally, published at https://www.linkedin.com.