Need help in deciding the software design/architecture for product development?

Question

Regarding an Online Web-based Software application, we are facing difficulty in deciding the approach to product development.

We are working on the system design for an online web application that has the potential to be offered as a SAAS service. We're facing difficulties here in deciding following system design and implementation-related decisions, also having a lot of cost considerations.

Approach A:

We design and develop everything to consider basic requirements that are just fulfilling the basic requirements solve the given problem at hand, and launch it. A good enough system to support a few hundred users without focusing too much on micro-optimizing everything.

We add new features as and when clients request by adding new modules.

So, Simple design, single development, scale when necessary by either upgrading infrastructure or optimizing when required, and might replace the system with a totally new system as required in the future.

We keep the same server but have different db for client accounts. Again, different applications are hosted for each client accessing separate db, etc. When the need arises we may add new servers. Although a little difficult to manage/maintain and upgrade.

Approach B:

We study full requirements, and possible features to add that might add additional value (although we're still not sure about which such additional features add how much value?) and design the system that supports very large numbers of users (with a heavy set of hardware) from the beginning.

We launched a full-featured application that is also very well optimized from the beginning.

We design it to support multiple client accounts in single db and application hosting, and implement it on cloud servers/load balancing servers with architecture like a matured SAAS application. However, this makes it very difficult to code and maintain. And takes more time to implement.

Note that,

We are prepared with a features list, UI, and possible technology setups we might be using. I want to understand what could be the best approach to address this situation.

Earlier I saw another product development project that, with a set of all features, took too long to complete, and even it has features that are not being used at all. The cost considerations are very high with such projects, I would prefer to go with approach A because that is quick, easy, and predictable. Moreover, I will have user feedback very soon compared to the second approach, which might help me decide which features to focus on and why. Moreover, when the need arises, we might rewrite the complete application with a focus on a system that is similar to approach B.

I would like to learn how other companies manage this kind of situation, and what could be the best way to implement such a project.

Answer 1

It depends.

Rules of thumb:

• "Nothing" is better than "broken".
• An 80% solution is better than nothing.
• The first 80% will consume 80% of Your resources.
• The following 20% will consume another 80% of Your resources.
• If You do not ship at 80%, someone else will.
• Before reaching 80%, You do not know the remaining 20%.
• The environment and requirements change more than You think. Even after the application of this rule.

Do not scare away Your customers by letting them wait to long, shipping a broken or unmaintainable product. Do not waist money on infrastructure You do not need (yet).

Answer 2

Approach A sounds sensible... and if you could adopt agile SCRUM as well, it would mean you could iteratively work with clients in Sprints, you would develop and deliver the product versions and features after each sprint. Client get to see smaller units of the software being delivered ....and more often than not, clients change their minds on what new features they want.

Hence you would always have an opportunity to respond to client needs, and only build what clients need.

Answer 3

That's a new version of the classic Big Design Up Front (BDUF) debate: Shall we design be completed and perfected be completed before implementation or shall we design incrementally?

I've seen pretty good arguments pro-BDUF and against-BDUF. Personally, I prefer a middle point: It is necessary to do some up-front design - otherwise your design would have radical changes through iterations- but this phase shouldn't take too long or you'll only have an Architecture Document and bored programmers after months of work.

So, I'll do some Approach A with a little of Approach B.