The Battle of ‘What’ and ‘How’

In the world of product architecture and design, I find that the lines can sometimes get crossed between what a product should do and how it should be architected. Often, this can stem simply from differences of opinion of those involved from the developer side, as well as the stakeholder side.  I am sure a lot of product engineers and enterprise architects out there face this same issue on a regular basis. This line gets more blurred with products/services that are technology-driven and platform-dependent, rather than business-driven solutions.

All parties have the same end goal in mind- to create a great product.  So, how do you identify and implement the right paths for product development or product evolution?  I think understanding the differences between the driving factors and executing a plan that stays within the boundary of each invested party is key for a successful product launch.  For me, this all begins with winning the battle of the “what” vs. the “how”.

Identifying the Problem (What)

We tend to focus more often on how to solve the problem rather than understanding the problem itself. We are all problem solvers, it is human nature to think we are. Even if we don’t know the true technical details involved in implementing the solution. We start trying to solve the problem BEFORE we realize or understand how complex the problem is, what its impacts are, scalability, security, maintenance, monitoring, etc.  A well-defined problem can lead to a clean solution, however complex the problem is. So, the problem definition is ‘What’.  That is step 1.

The Solution (How)

Now that you know your ‘what’, you can tackle your ‘how’.  That simple, right?  Not really.  With so many technologies out there, and the fast evolution of cloud platforms and blending of server-side vs client-side libraries, the options are limitless. With Microservices, Serverless functions, cloud databases, containers, ever new (JS) frameworks, we have a lot of tools at our disposal to solve the problems.

With that said, just because software updates become available, or new versions roll out, doesn’t mean any of these will actually help solve your problem or make your product better. 

This question gets even murkier when products are actually services and cloud migrations, where the technology itself governs ‘what’ can be done. Figuring this out is not just a battle limited to the stakeholders and solution architects. It applies to all stages of product development. Within each stage of development, if we break-up things into smaller units, there is always a task (what) and an implementation (how).

So, what do you do?

As the director of application development for Orbis, Inc. where I wear many hats, the battle of identifying “what” and “how” is something I constantly face. Whether it’s trying to keep myself out of solving tasks before assigning them to the team, or trying not to define the product features based solely on technologies in mind, finding the right path for each product can be tricky.

Coming from development background, I might be biased. But I have been a part of both sides of the equation, developer and stakeholder, for long enough to understand that DEFINING the problem is more important initially than actually SOLVING the problem. At the end of the day, ideally both teams should work alongside each other to get to a successful product, and not against each other.  The goal is to find that balance of creating solutions that address the stakeholders’ needs, supported by the guidance and leadership of the development team.

I would love to hear from fellow architects, designers, developers, what your thoughts are on this and your experiences in dealing with it.  We’re always looking for ways we can improve.  Or if you have any design questions or needs we can assist with, please don’t hesitate to contact us.

Thanks,