Entries in architecture (2)
Software as a Service (SaaS)
Designing systems that can scale to very large sizes is a challenge. The requirements are demanding or become so very quickly. Commercial success of your product is also a two-edged sword.
- Will your architecture handle the initial demand?
- How quickly can you expand resources to meet new demand?
- Are you paying way too much money to an OS or database vendor?
- How quickly will you need to duplicate your NOC/SOC?
I put together a slide deck discussing some of these issues for a small-group presentation a few weeks ago. I have posted the slides here because I wanted to share those thoughts.
Cheers!
-Eric
Software Architecture and Design
I am responsible for the architecture of an "Enterprise Level Product". What does that really mean? The software is big: well over a million lines of code (probably closer to 1.5M) incorporating something like 20 different software technologies. When we need to add a new feature there is rarely a perfect solution. Why? Because the solution needs to fit in with the rest of the product. If we simply chose the best options for that feature in isolation from the rest of the product we would have Frankenstein's Monster. Entropy would take hold, the cost of change would skyrocket, and progress would grind to a halt.
My thoughts on architecture are added to my previous gentle rant about the specific topic of SIMPLICITY and architecture, of course.