Let me first introduce myself. My name is Dan Orchard, and I'm an on-campus student, living in Urbana. I did my undergrad in CS from this fine university, and graduated in May of 2007. I'm currently in the Professional MBA program, class of 2010, and I'm taking this course as my elective for that degree. I also work full time (the Professional MBA program is designed for those who do). I'm the SVP of Software Engineering for my firm, PosTrack Techologies (www.postrack.net), in charge of a small software development team in Joliet, IL.
The software engineering courses that I took as an undergrad are among my favorite, and I expect to continue that trend with this course. In this day and age, meeting the functional requirements for a new application is easy. Continuing to do so, while maintaining acceptable levels of other (nonfunctional) quality metrics is not so easy.
Currently being a business student, the focus of my studies generally follow the themes of creating value for customers, cutting costs through efficiency, creating competitive advantage for the firm, being agile to changes in the business environment, etc., and viewing these goals superficially, it can be easy to take the shortest path to features/release (the purely functional requirements), and gloss over the elements that support the long term success of the project/company. If you ask anyone on my development team, they'll tell you that I'm constantly talking about software architecture, and how we can leverage structure to provide longevity, quality, and performance in our applications, and I know that this class will help me take my skills to the next level.
The job of the software architect is a difficult one, challenging even the most experienced architects with constantly changing technological and business environments, perspectives, goals, and the arbitrative role that the software architect must play between stakeholders with conflicting demands. Try telling a building architect that they must build a structure with materials whose physical properties are debatable, building site subject to change, climate undetermined, and intended use open to interpretation, and they would probably laugh you out of their office--yet that is the job that software architects are charged with pursuing every day. Even musical composition is subject to far fewer variables than software. Hence, I believe that analogies of software architecture to other forms only function when describing its role to a lay-person, and that attempts to extend the analogy to the tasks at hand fall on their face.
In an age when time-to-market is king, and what was difficult-to-build, cutting edge functionality a year ago is taken for granted and simply expected today, the right type and amount of architecture is critical to success.