
Definitions of Software Architecture - qznc
http://beza1e1.tuxen.de/definitions_software_architecture.html
======
james_s_tayler
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."

~~~
westoncb
Something like that is basically my guiding principle when evolving
architectures.

I generally start with minimal grouping/barriers, but eventually areas start
appearing as likely candidates as things that could end up developing
complexly.

When those surface, I see my job as something like setting up bulkheads to
constrain the flow and development of complex regions.

------
winternett
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.

------
wellpast
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.

~~~
nighthawk648
Having worked at a company with a useful architect described above, it’s
impressive to see what can be made to streamline developer lives.

Also, the amount of knowledge developers can absorb from the arch team code
base to use in the future is amazing. Ie; personal projects, etc...

I think to help offset the junior bothering the arch. Team, knowledge transfer
meetings + documentation is always necessary.

Thank you for the other perspective of how architect can go wrong!

