Options thinking is a useful way to approach systems architecture. Although the options approach is nothing new, its usefulness was not well known because of lack of formal framework(applicable to systems engineering/software engineering) for options thinking. This post tries to summarize how options can be used in the systems architecture and development.
Options can be present in the project or in the process or both.
It can be noted here that moving away from a waterfall method of system development to spiral or agile development methodology creates options. At each spiral you can assess the costs, risks etc to decide whether to proceed or to abandon the project before making too much investment. You can delay the decisions where there is uncertainty and wait till data is available thus creating options. The presence of options should be considered while carrying out project valuations. Instead of the traditional all or none kind of thinking about the projects, options thinking enable you a variety of options in between limiting the downside losses and unlimited upside potential gains. It can also help in getting management budget approvals by staging the project/product development rather than project the entire project/product cost upfront.
Systems architecture should be built using the options approach. Since the external environment is changing very fast the system should be able to ‘adapt’ to the new situation very fast. This requires lot of flexibility in the systems architecture. The system should be able to scale up, scale down, put to alternate uses, addition of new functionalities rapidly with less cost cost are some of the features of systems with ‘options’ built into them. Modular, scalable, open, generic architectures include of these options in them. We still need to discuss, debate and understand the options more in depth. I welcome your suggestions, comments, observations, experiences in this regard!
