A systems approach involves the integration of multiple independant commercial and custom software products to work in unison towards a common goal. A systems approach allows flexibility by allowing for the upgrade or discard and replacement of individual components as requirements change.
Advantages
- Flexible; can evolve as process evolves
- Best of breed components can be used
- Portability of knowledge (Spotfire, R, SQL)
- Adaptable to containerization
Disadvantages
- Components on different upgrade cycles
- Components use different technologies with scattered expertise
- Configuration challenges: missing libraries, auxilliary software
- May depend on external network connectivity
- User training can be challenging
- Integration can be challenging
References
Microservices
as innovation enablers best practices == common practices
Split
the monolith
Trulia
switches to “Islands”
A
contrarian’s (with vested interests) view
Related
Case study of monolith implementation: Why Doctors hate their computers Discusses feature creep and the “Tar Pit”
Proprietary IT give big companies their edge.
Rob Brigham, Amazon AWS senior manager for product management: “Now, don’t get me wrong. It was architected in multiple tiers, and those tiers had many components in them. But they’re all very tightly coupled together, where they behaved like one big monolith. Now, a lot of startups, and even projects inside of big companies, start out this way. They take a monolith-first approach, because it’s very quick, to get moving quickly. But over time, as that project matures, as you add more developers on it, as it grows and the code base gets larger and the architecture gets more complex, that monolith is going to add overhead into your process, and that software development lifecycle is going to begin to slow down.”