Architect Your Product Before It Holds You Back

By Avi Deitcher

Architecture determines capabilities.

This is not new. Anyone who has planned and architected a new product, or has tried to retrofit capabilities for which a platform has not been architected, knows it first-hand.

Yet, time and again, I come across products that have not been planned, and therefore architected, around reasonably expected capabilities.

Sometimes I see these as a user.

Last week, a client wanted to give me access to their Dropox Team account, so we could share information. They did the apparently smart thing: they sent me an offer to join their Dropbox Team.

That is where the problem began. If I join their team, my entire account is part of their team. Sure, I get all of their account permissions, and they pay if I use too much storage, but my entire account is open to them. I have some personal materiel there, but far more importantly, I have confidential client information there. Many clients have used Dropbox to share plans, materiel, even code with me.

This client should not have access to that data. It might even violate my confidentiality agreements to join their Dropbox Team.

Obviously, I am not the only person with this problem. What does Dropbox recommend?

Set up a personal and a business dropbox account and link them.

Of course, you only can do that for two accounts. They are asking me to limit how many to whom I can connect. Making it worse, each device on which I use Dropbox is connected to just one account.

The workflow I want is simple: let me remain me, and let a subset of me (a folder) become part of this client's Team space. Dropbox does noted cannot provide this feature.

Essentially, Dropbox is designed and architected around the idea that a person's account belongs to a team, or company, in its entirety. The idea that multiple people collaborate independently is foreign to how they first built Dropbox users, or at least teams. Put in other terms, Dropbox users and teams are built around 1970s or 1980s work environments.

  • You have a job; you work there, and everything you do there belongs to the company.
  • You have a home; you live there, and everything you do there belongs to you.

Based on the feedback and company responses in the forums, it seems clear that they started this way, and now are constrained from doing anything different without significant re-architecture.

Other times I see this issue from within companies with whom I have worked. It always is unfortunate to see CEOs frustrated that a relatively simple change is difficult to nearly impossible, requires multiple "hacks", and challenges the stability and scalability of the product. Product says, "we need this feature/capability/flexibility to grow the business"; engineering says, "implementing this feature/capability/flexibility will risk the very service we need to run the current business, let alone grow it."

Part of the root cause is the severe constraints inherent in the early days of a company. These manifest themselves in two ways:

  1. Plans: Some companies know that they need to plan for reasonably expected use cases, yet do not have the time to do so. As the saying goes, "Having scale (or usage, or diverse market, or ....) problems is a good thing to have. It means we are making it. Why waste energy beforehand?"
  2. Skills: Many companies, on the other hand, simply do not have the product management capabilities and architectural chops to think these issues through. They plow ahead, gain some success, and become frustrated when bolting on additional capabilities becomes expensive and even dangerous to product growth and stability. (When the founding team for a tech startup has no engineer, watch out.)

Even if you have the skills, and you think it through, it is a real challenge. How do you build for the future, without sacrificing too much precious early time, blood and treasure, to those potential future plans?

The answer is specific to each and every case. But a simple rule of thumb is to plan sufficient flexibility that you do not constrain yourself in key areas, while implementing only those parts that you need for the immediate future.

A simple example is complex access control. Your future targeted enterprise customers will insist on complex levels of role-based control and auditing; your early customers, the ones who get you enough traction to go after the whales, just want simple access.

  • If you build a simple binary yes/no for access or sharing, you may have to rip out the entire thing and replace it with something that can do enterprise-level controls and audits while replicating on top of it the exact same interface and methods you had before, all without causing disruption. Worse, other parts of the system will start to assume this design, making future changes a massive undertaking.
  • If you build a full-blown access-control system, with audits, management interfaces, APIs, you may never get to early stage customers, let alone enterprises.

I dealt with this precise issue with a company. My recommendation? Build in enough flexibility for the future, but only implement the parts you need now.

  1. Access:
    1. Build a role-based access control system now using off-the-shelf (or off-the-github) components.
    2. Implement precisely one role right now, "owner". Provide no management interface, no cross-account controls, nothing.
    3. In the future, add new interfaces and new roles, but rip out nothing.
  2. Audits:
    1. Log every activity somewhere.
    2. Do absolutely nothing with these logs now. In the future, we can add review capabilities.

Unsurprisingly, it worked. It took, at most, a few weeks longer to get the first version, but we had bought ourselves a sufficiently flexible platform to do what we needed in the future.

Far more importantly, we had forced every other part of the system to be aware of access and auditing as they were built, making the future transition several orders of magnitude easier.

Summary

It is critically important to plan, design and architect your systems to be able to support reasonably expected future capabilities, while only implementing the minimum you need at each stage. Minimum Viable Product must be viable, not just minimum.

If you have reached the point where your early designs and their implementations struggle to deliver the capabilities you need now, find where you need to rearchitect, but get those areas you can with minimum disruption... and do it in a way that you plan for the next stages as well.

Struggling to plan for that future? Challenged by your current platform's ability to deliver your requirements? Ask us to help.