Attacking any project in life usually requires some amount of planning. When building a home, you usually want some kind of architectural design, possibly including blue-prints, perhaps a few notes as to where important aspects of the home should go, like plumbing or, boundaries, entry points, ventilation, electricity. These are all important aspects of a home that without would prevent the building of the home, at the very least limit its functionality.
Building software is no different. You have some idea as to what it does, who will use it, why it should be written, but there is no solid idea as to how to do it. Actually putting this down on paper, or virtual paper, gets us in the mindset of how to put our grand ideas into fruition. Let’s dive in a little more into this.
So what exactly is Software Architecture anyway?
Software Architecture is pretty much exactly what’s written on the tin. It’s a way of organizing your plans for a putting together a full, working application by defining its individual parts, or features, defining how they work with each other, and deciding on what resources we will need in order for them to work.
Features are the important pieces of the project that define the functionality of the software. These can be items like what will be displayed on an output device, what calculations the application will make in order for it to do what you want it to do, or what input the application will take from the user. These are considered the basic units of action that your application will achieve. You would want to break down these features into bite-sized defined actions to make planning them easier.
Feature interactions are an important aspect of any application. It’s essential to know how one feature will affect another when applied. Mapping this out and possibly drawing out a feature flow in some kind of chart will help guide this process and allows for easier implementation. In the house metaphor, this would be similar to mapping out where the light switches and air ducts go. If you don’t plan for them ahead of time, the wall may not have space for them. It’s always best to plan out the details for what your feature and how it affects others.
Resources can mean many things in a software project including people, languages, IDE’s (Integrated Development Environment) and other tools necessary to complete the project. People and IDE’s are usually pretty static in any organization. It’s very rare that these change. The languages used and data storage medium, or how we store information used for the application, can be chosen to appropriately write the application in an efficient manner.
So why bother with all this?
Making an architecture plan is important because it allows us to organize and optimize application development within a given timeframe and budget. This allows us to maximize the skills and abilities of everyone involved, not just the developers, in achieving the goals we set ourselves out to do. What this means is that we can efficiently handle any project from start to finish as we will have made plans to do so.
But I just want to get to coding!
Without proper planning and architecture, you more often than not will realize that what you had in mind cannot be achieved with a single session in front of your keyboard. You may end up doing double the amount of work in writing something you’ve already done for another part of the project. You would find that you have missed important features or interactions that were critical in deploying a functional application and ultimately take significantly more time and money in development cycle than you would have had with a initial amount of time and effort spent planning out and architecting your software application in the first place. Some examples of things that can be missed might be some of the more mundane details like security items for instance. If you were storing user-specific Non-public information like birthdates or addresses, you might not want that data in the clear, but it’s not something you may be thinking about when coding for a deadline. Another might be memory storage. A lot of the time without paying attention we might be storing multiple copies of data in memory which, if unchecked, could grow beyond the capacity of the server causing performance issues with the application. Another might be if you had a back-end service that cost money to access calls for data. You’d want to limit these accesses as much as possible. Spending a little time beforehand planning around them would alleviate these issues.
There is a lot to think about when developing a software application. You are trying to build a complex system. Sometimes the system you’re trying to build may be more complex than your organization has capacity to complete. Searching for external consultants could help in this case. These could be individuals or companies, however you may want to keep an eye on whether they are taking the time to do some initial planning as well and share those ideas with you rather than diving straight into development. Coordinating with them would make certain that all are in agreement for how to approach the development process. Just adding a small amount of time and effort to plan out what it is you want to create and how to get it done initially can save you a lot time, money, effort, and frustration. Following these ideas could significantly help in writing your next software application.