Categories
Software Architect

The ROI variable

Every decision we make for our projects, be it technology, process or people related, can be a viewed as a form of investment. Investments come associated with a cost, which may or may not be monetary, and carry trust that they will eventually pay off. Our employers choose to offer us salaries in the hope that this investment will positively affect the outcome of their venture. We decide to follow a specific development methodology in the hope that it will make the team more productive. We choose to spend a month redesigning the physical architecture of an application in the belief that it will be beneficial in the long run.

One of the ways of measuring the success of investments is by rate of return, also known as return on investment (ROI). For example, “we anticipate that by spending more time writing tests we will have less bugs in our next production release”. The cost of the investment in this case is derived from the time spent writing tests. What we gain is the time saved from fixing bugs in the future, plus the satisfied customers experiencing better behaved software. Let’s assume that currently 10 out of 40 working hours in a week are spent fixing bugs. We estimate that by devoting 4 hours a week to testing we will reduce the amount of time spent on fixing bugs to 2 a week, effectively saving 8 hours to invest in something else. The anticipated ROI is 200%, equal to the 8 hours we save from bug fixing divided by the 4 hours we invest in testing.

Not everything need directly translate in monetary gains, but our investments should result in added value. If for our current project, time to market is essential to the stakeholders, maybe a bulletproof architecture which requires a lengthy up front design phase will not offer ROI as interesting as a swift alpha release. By quickly going live, we gain the ability to adapt to audience reactions that can form the deciding element to the future direction and success of the project, whereas not thoroughly planning can incur the cost of not being able to scale the application easily enough when the need arises. The ROI of each option can be determined by examining its costs and projected profits and can be used as a base for selection between what is available.

Consider thinking of architectural decisions as investments and take into account the associated rate of return, it is a useful approach for finding out how pragmatic or fit for purpose every option on the table is.

'Coz sharing is caring
Categories
Software Architect

Record your rationale

There is much debate in the software development community about the value of documentation, especially in regards to the design of the software itself. The disagreements generally cluster around the perceived value of doing a “big upfront design”, and the difficulties of maintaining design documentation synchronized with an ever-changing code base.

One type of documentation that ages well, doesn’t require much effort and almost always pays off is a record of the rationale behind decisions that are made regarding the software architecture. As explained in the axiom “Architectural Tradeoffs”, the definition of a software architecture is all about choosing the right tradeoffs between various quality attributes, cost, time, and other factors. It should be made clear to you, your managers, developers, and other software stakeholders why one solution was chosen over another and what tradeoffs this entailed (did you sacrifice horizontal scalability in the name of reducing hardware and licensing costs? Was security such a concern that it was acceptable to increase the overall response time in exchange for data encryption?).

The exact format of this documentation can vary according to what is appropriate for your project, from quick notes in a text document, wiki or blog, to using a more formal template to record all aspects of each architectural decision. Whatever the form and format, the documentation should answer the basic questions “What was that decision we made?”, and “Why did we make that decision?”. A secondary question that is often asked and should be documented is “What other solutions were considered, and why were they rejected?” (actually, the question usually asked is “Why can’t we do it MY way?”) The documentation should also be searchable so that you can easily find it whenever it’s needed.

This documentation may come in handy in a number of situations:

  • As a means of communication to developers regarding important architectural principles that should be followed
  • To get the team “on the same page”, or even head off a mutiny, when developers question the logic behind the architecture (or even to humbly accept criticism if it turns out a decision doesn’t hold up under scrutiny)
  • To show to managers and stakeholders exactly why the software is being built the way it is (such as why an expensive piece of hardware or software is necessary)
  • When handing off the project to a new architect (how many times have you inherited a piece of software and wondered exactly why the designers did it THAT way?)

However, the most important benefits that come from this practice are:

  • It forces you to be explicit about your reasoning in order to verify that your foundations are solid (see the axiom “Challenge assumptions – especially your own”)
  • It can be used as a starting point to re-evaluate a decision when the conditions that influenced the final decision have changed

The effort required to create this documentation is equivalent to jotting down a few notes whenever you have a meeting or discussion on the subject. Whatever the format you choose, this is one type of documentation that is worth the investment.

'Coz sharing is caring