3. Architecture

Main Points

• Hardware Architecture Setting up your physical system: computers, networks, servers, etc.
• Stack Architecture Choosing and configuring the technology stack your software will depend on.
• Software Architecture Creating, configuring, or building your software platform.

Architecture involves a number of different kinds of concerns, and it means different things to different people. I've heard developers talk about architecture as a "technology agnostic" process, however I couldn't disagree more. If you are a specifically web developer and you only consider the software architecture of your application, then you can make an argument that architecture allows you to stay above specific technologies. However, in order to do this, you've already assumed several decisions that you ought to consider and choose. There are many different kinds of architecture besides online, web-based models. In short, it's best to consider the full range of solutions open to you before you lock yourself into such a narrow solution and then pretend that your options are wide open.

Hardware Architecture

This is fairly fundamental to the successful completion of any project. If you're going to write a program it needs to run on a computer, somewhere, somehow. For the type of web based development that we're focusing on primarily, these are a pretty easy questions: PC vs. Mac and / or Windows vs. Linux? Nor is this usually a difficult question. Most people have strong feelings about the options and reams have been written about it across the internet. Rather than rehash this argument, which is pointless since the odds are 99% you've already made up your mind anyway, let's take a moment to consider the alternatives; a little outside the box thinking if you will. If you are interested in the topic please feel free to Google it to your heart's content.

When you write a program, is a web-based solution really the correct approach? There are others and they dramatically affect hardware requirements. Just because you determine you have a technology-based solution which requires a program, doesn't instantly demand a web-based solution. A web-based solution is online and accessible by anyone. Really accessible. If you would prefer not to do that because the information is sensitive, then there are other options. The primary advantage of web-based solutions is exactly this openness; it's so easy to communicate with the application anytime, anywhere.

If you like this idea and it works well for the purposes of your project, you will need to obtain hosting or your own web server; this is the hard drive on a computer which is connected to the internet and makes your website available to anyone 24 / 7. Then purchase a domain name (e.g. "earthchronicle.com") and point the DNS records to the IP of your web server. Effectively, your web server (or web hosting) website has two addresses where people can find it; however the "physical" address, the IP address, looks like this, 255.7.172.202. Since no one wants to remember the IP for all the websites they visit, websites have domain names which are simple and easy to remember. When you enter the domain name into your browser (like Internet Explorer or Firefox), the browser finds one of the many directory computers on the internet and translates the domain into the IP address and finds the website for you. Setting the DNS records configures one of those directory computers which then talks to the rest of its "friends" ensuring that within a few hours to a few days, every directory on the internet knows how to direct visitors to your site.

Alternatively, if you don't want your information to be that available, you can construct a desktop program, a program that people install on their computers and which is otherwise completely inaccessible. This is a good choice if you don't want the information to be widely accessible. With the rise of "always on" broadband connections, this distinction is declining in importance, since desktop computers are now regularly connected to the internet for long periods of time. However, with proper security in place, this is still the most secure way for people to store data, and they have only themselves to blame if the data is compromised. This is also a good choice if you would have to transfer large amounts of data or use extensive processing or memory on the web server. If those are bottlenecks in an online application, then allowing people to simply download the program one time is likely the better workflow. Then no further data transfer is required and users can take advantage of the much more extensive processing power and memory available on their own desktop computers.

There is also the networked client-server option. On a local network, the network server can run an application which all of the client computers can access. This was the first version of a web application; programs run on small to large networks before applications became possible on the internet, the largest network ever. Client-server applications run very similar to web applications as well and have many of the same hardware and configuration needs. However, while access is reasonably simple across the network, the use of firewalls and other security usually make it pretty difficult to access the information from outside the local network. It should be noted that networking is a non-trivial endeavor. But depending on your situation you may find a desktop, client-server, or web-based solution fits your hardware needs best.

Stack Architecture

OK, so you've got a computer to run the solution on. Big deal – how do you expect to do anything with it? For desktop applications, your options are limited. MS Windows is the operating system which dominates the market for desktop computers. There are a reasonable percentage of Macs and Unix / Linux-based systems, but well over 90% of computers are running under Windows. So a desktop program is likely to be built in a Windows based framework using a language like C++, or designed directly on Microsoft's own versions of Visual Studio. For client-server and web-based applications, however, the question takes on a little more meaning.

Server-based applications tend to be relatively easy decisions. Just as the hardware / operating system decisions generate a strong opinion for a lot of developers, the stack you use defines the server-side technology you'll be using, and most developers have strong feelings about that too. On Linux, you are typically looking at deploying some version of a LAMP (Linux-Apache-MySQL-PHP) stack. Linux, of course is a PC-based operating system. Apache is the world's most widespread and powerful web server. It is an excellent choice. MySQL is an amazing DB which works well configured for either production or development needs. And PHP was the world's most popular server side language, though it is starting to show its age. You can also use the same basic stack with Apache and MySQL supporting Java. Simply install and configure the stack with Java processors instead of (or in addition to) PHP processors.

On the Windows side of things, you have several options here as well. There are also Mac computers, but their use as servers is virtually unheard of. You can program PHP or on Windows using a WAMP (Windows-Apache-MySQL-PHP) stack. The way these integrate is virtually identical to the way a LAMP stack works. Similarly, you can swap out Java for PHP. It just depends on your preferred technology.

Another popular deployment for Windows is the Microsoft stack. Windows serves as the operating system and IIS is Microsoft's proprietary web server; this is combined with virtually any database and a wide variety of languages which run under the .NET framework. One of the advantages of Microsoft's stack is that there are so many customization options – there is even a Linux-Apache version of the framework, called Mono, though it has a relatively small community. However, all lip service aside, MS is not shy about promoting its own technologies including the MS SQL Server database and the C# programming language. While I find OOP using C# to be the optimal configuration for me, VB.NET does have significant support from Microsoft and if you like going your own way without extensive support, there truly are more than a dozen languages compatible with programming in .NET, and databases are even better. In fact, Earth Chronicle actually runs on a MySQL database and while it does not plug into the developer tools as naturally as MS SQL Server, in a number of ways I find it much preferable.

Regardless of your stack architecture, once everything is set up and configured, you can begin working on the actual software. I should note here that efficient deployment can be greatly improved by a well structured architecture; to find out how, click here. Now we are ready to take a look at the software architecture of the application.

Software Architecture

In certain environments, this is what people mean when they talk about architecture; this is the programming code which will be part of your application. The data access classes, helper classes, utility functions, and other components which provide the foundation for all the other code you're going to write. I find software architecture usually betrays a developer's personal predispositions. That's not a bad thing, just an observation. There are some software architecture issues that may be required by the problem under consideration, however, this is more an artistic issue defined by how you think, design, and construct code.

Some guys plan out MVC systems because they like that best. I like to define the large-scale structure of my project in layers (i.e. n-tier architecture). Other people prefer using design patterns, or other methods of defining the project architecture. Nor should this be taken to mean that these ideas are mutually exclusive. I frequently use design patterns within my layers, and MVC itself is simply a large-scale, complex design pattern. Design patterns frequently break out into modules or layers, and I frequently wind up with UI classes that look somewhat similar to an MVC controller. There is a lot of flexibility here depending on the skillset of the developers, and the type and purpose of the project.

For some people, software architecture also involves constructing those pieces of the program. For obvious reasons, I disagree. For one thing, we can't build increments until we've finished the design phase which comes next. For another thing, think about the parallel being made here. Software architecture is based on the work of developers who based their ideas on physical architecture textbooks for constructing buildings; and an architecture firm doesn't build anything, you need a construction firm to build a building. Logically, I feel that building these pieces is part of construction. Architecture is about laying out the broad strokes of the plan for how you're going to approach the project.

Where the distinction breaks down is in the parallel that you need to build the foundation first and then each floor after it in order. While a physical building needs a foundation before you can start on the first floor, software can technically be built in any order you want. There's no technical reason you couldn't code the equivalent of the 17th floor first; followed by the 15th floor and save the 16th floor between them (and the foundation at the bottom) for later. I prefer to highlight risk management and testing as the key elements of construction priorities and this defines the order in which I execute increments of the project – but more on that later.

Software architecture is extremely high level, depends greatly on personal preference, and is not very detailed, but it's absolutely critical that this be defined in writing and that everyone is on the same page. It does no good for one developer to be building an MVC view while another builds classes for a UI layer which has overlapping responsibilities; that's not flexibility, that's a mess. The outlines of the software architecture gets everyone mentally unified in order to proceed with detailed software design, which is where all the specifics will get filled in.