Definitions of Software Architecture

Every definition of architecture I have ever heard has never really helped me in any way after hearing it except one:

"Architecture is that which contains entropy."

Software Architecture is different than being a Software Architect...

I always relate my processes to home building, especially when i am speaking with non-technical people. For every project I work on there are numerous roles where technical skills and understanding are not required (e.g. accounting, schedule management, and sometimes the entire client side does not know email from a toaster oven.

As a Solutions Architect, I often design Software Architecture, but I also design developer workflows and host infrastructure, set up a test environment and work on the more technical aspects of the project schedule, coordinating materials with clients that will go into the home building project, solving problems and constraints as they arise, all without having to deal with budget issues beyond not exceeding cost. So in this case, relating the situation to home building, Here I work as a General Contractor on the home building process - managing plumbers, electricians, carpenters, etc...

As a Software Architect, I create all of the diagrams for the software's design, usually in conjunction with devs, but a lot of the time all on my own. At this point I mostly make critical decisions about what framework is used after finding what dev talent is available and conducting interviews if the team is not already assembled. Then I usually set up project management tools and documentation tools, attend requirement gathering meetings, and actively contribute to development and code reviews, while also contributing to pretty much every other aspect of the project that involves technical detail, like the schedule's design, prototypes and demos, and resolving security issues in conjunction with DevOPS teams. So in this case, relating the situation to home building, Here I work as a home architect would. I regularly create "floor plans" and diagrams to drive techs in finishing the project, while actively working with groups to ensure quality and resolve issues based on my designs...

The Software Architect role has grown a lot and will keep going. I remember when employers used to squeeze this role out of me as an underpaid dev... But Architects are now considered essential to pretty much all high value projects because they dramatically improve quality and organization while keeping things on schedule.

Lastly, the Software Architecture consists of the documentation that comes out of planning, requirements, and design sessions for the project. The way an application is designed, the requirements from the customer that are incorporated, the way deployments are being made for updates, all of the things that involve a system's design and maintenance become the Software Architecture. Relating this to home building, it is just like the architecture of a home, the framing, plumbing, the window locations, etc... The architecture here serves as "blueprints" for the development process, and the home can be built with substituted materials while are equivalent to changing platforms, APIs, or even languages altogether just like a bathroom tile can be changed without changing overall functionality of the bathroom.

I have a really hard time with the idea that there is this thing called Architecture and it is separate from some other property or activity like Code/Coding.

If you show me the implementation of a low-level component (a file, class, namespace - depending on your design idioms and PL) in your system... basically, a set of functions/methods organized and composed into a whole -- then I can tell you if you have an Architect on your hands.

For any business offering (any system/product line) the skill set required to factor this into a decoupled/maintainable whole is the same skillset required to compose a lower level subsystem or component.

(Granted there is typically some knowledge/experience at the higher level system required --eg, around database systems/tradeoffs/theory, distributed system tools/properties/theory, etc -- but the core skillset of factoring is the same.)

If you can't decouple a component into set of compose-able functions serving some component contract (I call this coding by the way), then you should not be trusted to compose an architecture for a system/offering. Similarly if you can do this decoupling at the low level and do it well, then you can do it at the higher level -- again, assuming you have experience and are familiar with the data structures typically found at those higher levels (queues, dbs, coordinators, stream processors, etc).

There's a single fundamental skillset. It's the ability to instinctive decouple a system -- any system at any level -- into proper parts.

One might say - well, an Architect is someone with this skillset. The non-Architects, the Juniors can be left to code up the smaller pieces, where problems stemming from their lack of skill can at least be marginalized.

This is weakly true and a simplistic view, however. Because decisions made at lower levels can have permeating effects quite rapidly. Another way to put this is that as one problem-solves within an overall system architecture, one encounters novelty on the regular, so to speak. And the solution/s to this or that novelty has to be slotted first at the right level of the system... in one instant, you will find that the top-level systems need a slight adjustment to accommodate things, in another you'll find that nothing needs to be perturbed above the component at hand.

If you say the Junior needs to tap the Architect's shoulder in each such instance, then you'll find quickly that this is pointless and the Architect would do better to write some code.

You either have people with the skillset or you don't. If the skillset is there, the architecture will be organically established. If the skillset is absent, whether you have an Architect in title bears less on the technical quality of your system but you may get a win on the team/organizational side of things.