Systems Architecture or Product Architecture

What is Systems Architecture?

The "structural" aspects of a system that shape the whole thing and may be hardest to change: how responsibilities are divided between subsystems and the interfaces that support this. Often also the environment and services assumed and the technologies employed.

Why is it important?

It supports some changes easily, but makes others hard or even impossible. The architecture of a product or service is largely determined by the first release, but will affect all later releases in terms of:

Releases are traditionally divided based on impact:

minor
install by just replacing existing components with little or no impact on users
major
follow a formal process to preserve and migrate customer data, with possible user re-training etc. Needs business commitment and scheduling. Some service disruption.

Benefits of a good Systems Architecture

Rewriting an existing product is very costly, and technically risky if the product is not well documented and upward compatibility is required.

If existing customers are not charged the full initial purchase price, there may be insufficient new revenue to pay for the development. Providing a new release as part of a maintenance contract can be the worst of all worlds: