The Law of Diminishing Returns

As an architect you often encounter requirements that are better off not implemented, requirements are triaged through several activities one of them is impact analysis. The law of diminishing returns comes into play here given that the how the complexity of a requirement and its return are often inversely proportional. Its often more productive to partially implement the requirement rather than going to the full extent as the cost will far exceed the return.

The law of diminishing returns states that in all productive processes, adding more of one factor of production, while holding all others constant, will at some point yield lower incremental per-unit returns.

This behaviour can be represented using the following formula with X being the unit of incrementation and i the number of increments.


Screen Shot 2016-01-19 at 11.40.19 AM

To put it in a more colloquial form, the more seeds you plant in a field the less yield you get per seed, another example would be developers per project there is a certain infliction point afterwards it doesn’t matter how many developers you add to the project the return remains the same.

An example of requirement that exhibits a highly diminishing result are service assurance requirements, requiring a 99.9% accuracy would cost far more than what it would cost to have a manual workflow to manually verify the deviation. OCR (optical character recognition) projects come in mind and hence you find projects like captcha relying on users to verify the output of the OCR algorithm.


This is not very different from NP-Complete problems and approximation algorithms reaching an acceptable solution at a fraction of the cost is favoured over reaching the solution to a certain problem set with a potentially infinite solution time.


Solution Architect: Skills

Screen Shot 2016-01-17 at 3.17.29 PM

Such as with conventional architects there is no right and wrong decisions while constructing a solution. The combination of all of the decisions made throughout the project results in the success or failure of the final product being able to pick a certain approach or another can be compared to conventional architects picking a certain architecture style for a certain arch or a certain paint colour, decisions that can’t be fully defended/justified while the project is still in progress. Being able to make such decisions requires a certain set of skills that combine multiple disciplines. I compiled a list of the skills I believe should be available in a solution architect.


  1. A broad cross sectional knowledge of the industry s/he is designing solutions for.
  2. Attention to details while being keeping an eye on the bigger picture.
  3. A Strong sense of business and market requirements.
  4. Ability to abstract the requirements to design generic building blocks.
  5. The ability to make confident decisions ( or seemingly confident ) in murky situations.
  6. Out of the box thinking that’d allow him to reuse existing building blocks in none conventional ways.
  7. Ability to document a design in a clear form that can retain the details without being too confusing.
  8. Communication ability with both business as well as technical stakeholders.
  9. The ability to conduct cost benefit analysis to be able to triage the requirements.
  10. Broad knowledge of the technologies being used within the industry he is designing for.
  11. Flexibility to evolve and pivot his design as needed yet the resilience to resist development requirements that  do not add value.
  12. Sales ability to be able to sell the design to the developers and the solution to the requester.

Some nice to have skills include :

  1. An attractive projects portfolio.
  2. Ability to construct proof of concepts if required.
  3. A business degree.
  4. TOGAF certification.


This is an open list and you are more than welcomed to add to it to do so please comment with the skill you believe should be added to the either lists.