What is Systems Architecture?

At its simplest, systems architecture refers to the infrastructure supporting the application you're planning on building.

However, this doesn't just limit its scope to the specifications of your server hardware. You're looking at the servers, network, Internet connectivity, firewall, load balancing, and software running on each server.

This is, as you might have guessed, a big topic. We only scratch the surface over the next few pages, but we can at least point you in the right direction.

Why is it Important?

Getting the right infrastructure for your application is vitally important. As an application developer, it's highly plausible that you have just one development server in your studio. This may double up as both a Web server and a database server, maybe running both MySQL and PostgreSQL. If you develop in more than just PHP, you may have the Java SDK installed, too, along with Jakarta or some other application server. If you've been in the business for a while, you may still have a PHP4 installation to support legacy applications.

This setup probably suits you just fine. Although your development server is clearly under a lot of strain, with only a handful of users ever connecting to it, it's rarely going to show that strain outwardly. And, with little or no outward access to or from the Internet at large, the server could probably quite happily connect to the Web using a treehouse phone.

Of course, when you go live, you go to an environment in which your application can be hit by literally hundreds of simultaneous users, some of whom will be on high-bandwidth connections. Your application must perform under such conditions.

In a later chapter we look a little more at the principles of Quality Assurance (QA), but you can save yourself a lot of time and hassle now by designing an effective systems architecture to complement and support the software architecture you've already developed.

What Needs Doing?

Your systems architecture is effectively a battle plan for your live environment. You may well wish to draw up a document to support it, or incorporate its contents into your existing technical specification. This is yet another decision-making process that is mainly up to you, but for which you should also endeavor to obtain client ratification and approval, just in case it goes wrong and you need some leverage.

That's not to say it will go wrong, of course just that if you have a signed piece of paper saying "the application will have not more than X simultaneous users, hence we have specified Y,'' then if your application falls down under X + 1 simultaneous users, you can sit there looking smug while your client writes out the purchase order.

Assumptions or prerequisites like these form the heart of your systems architecture. This knowledge developed between you and your client needs translating into effective systems decisions.

The key decisions to be made are the following:

Hosting where is the application to be physically housed? Is it a suitable environment, that is, air conditioned and equipped with uninterruptible power supplies?
Internet connectivity what kind of link to the Internet is required? Who will provide it? How much is it likely to cost?
Servers what number and specification of servers are required to support the application?
Network what kind of topology is best to support those servers?
Redundancy and resilience what kind of guaranteed availability is required? Can there be a single point of failure?
Maintenance who will be responsible for maintaining each server and its software?
Security how will the infrastructure be secured from the outside world?

We consider each of these in more detail in a little while, but first let's look at how best to translate your client's commercial objectives when designing a systems architecture.