Architecture Iterations and Buy vs. Make Decisions

We are currently running the first sprint for our next-gen platform., Since I like to open my projects with a few architecture iterations, or exploration iterations, we are now identifying architectural requirements and core components -- and making a few fundamental decisions.

In this particular project, it is relatively easy since this is a "next-gen" which means there was also a previous generation. Thus we have a better idea on what to expect from the platform. One type of decision we have face involves buy vs. make. Actually this should be called "buy vs. adapt vs. build from scratch" since we can also choose to extend existing assets. However, let's focus on the buy side for this post.

There are two distinct decisions here:

• One is to identify the components which you will want to buy instead of develop.
• The second is to decide what is it that you want to buy.

I divide this into two decisions because you can separate them in time. For instance, you can make a decision early on to use a database rather than develop a persistent solution of your own. (In most IT projects that's an obvious choice, but in other project this is not always true.) However, you may be able to postpone the decision on what RDBMS you choose to a later time and just hide the database behind an O/R mapper or a data access layer. The decision to buy is important though, since otherwise you can find yourself spending development hours and days on implementing persistence functionality which you would throw away later.

To give you two examples from the project mentioned above: We need a secure database, we are storing biometric data and privacy is very important as well as preventing tampering. We definitely want to buy something here and we're debating several options. The other example is the computation heavy parts of the application where we think we may need to add Grid computing to cope with extreme scenarios. However, we have many other requirements that are ranked higher in the product backlog, so we just identified the block, decided on the approach we'll take if we'll get there but we aren't doing anything else about it for now.

We will proably won't even add an empty block just now. We may just identify the point were we will refactor it in later. But the fact that we know it can be needed there means our porcesses will allow accomodating it later and it won't be too difficult to weave it in if it will be needed. Granted, that's not exactly YAGNI, but it isn't exactly big design either -- it is something in between. I think it is just enough

Posted by Arnon Rotem-Gal-Oz at 04:43 PM  Permalink