This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # architecture (29)
- # beginners (244)
- # boot (5)
- # cider (2)
- # clara (8)
- # cljs-dev (58)
- # clojure (93)
- # clojure-australia (1)
- # clojure-dusseldorf (4)
- # clojure-france (1)
- # clojure-greece (16)
- # clojure-italy (9)
- # clojure-norway (1)
- # clojure-romania (1)
- # clojure-serbia (3)
- # clojure-spec (68)
- # clojure-uk (103)
- # clojurescript (41)
- # code-reviews (4)
- # community-development (4)
- # cursive (11)
- # data-science (2)
- # datascript (6)
- # defnpodcast (4)
- # docs (21)
- # duct (4)
- # emacs (118)
- # fulcro (120)
- # graphql (1)
- # jobs (1)
- # jobs-discuss (43)
- # leiningen (12)
- # off-topic (39)
- # onyx (11)
- # parinfer (13)
- # perun (1)
- # re-frame (2)
- # shadow-cljs (4)
- # spacemacs (5)
- # unrepl (6)
- # yada (1)
Thanks for all the feedback. I see how it takes lots of practice and experience, which can’t easily be condensed. I’m curious if there isn’t a market for learning about design though. Like assemble a panel of 4 people from different backgrounds and present a problem. For example, build a TODO app, now scale it (in some way). Then they would discuss designing it at a architectural level. I assume there could be different approaches and different problems they could imagine as things grow or possible change. I think being part of that, or even listening to it, would give a lot of insight. At conferences i feel like i here one approach, but i would like to hear a more open ended discussion sometimes. Or maybe its that i would like to be able to ask questions more so i could be more sure i understand and remember the information. Given that everyones time is so valuable, its hard to see how that would work. I mean, typical people dont have time to spend on real problems, why would they spend them on toy ones? Maybe if they felt it was worth the feedback from there peers?
To some extent, chatting with people online is similar to what i’m talking about… so maybe i’m just not asking the right kinds of questions often enough.
It seems like a lot of things are learned on the job, on real tasks, which i understand. I just worried that often the context skews a lot of the information. Also, it makes the barrier to entry into some positions very high. I dont see a path to architect except for being mentored by an existing one and getting tasks along those lines. The spark for this line of questions was that i got a whiteboard question about designing a URL shorter service and i’m always somewhat caught off guard sense i’m rarely tasked with such things currently. But if i could easily answer that type of question i would be given the task, i have no doubt. Chicken and egg problem.
There are often conference talks about architecture -- The Strange Loop has some good ones and the Clojure conferences also have some. Part of the problem with those talks tho' is that what works as an architecture for one situation won't necessarily work for another situation.
And your situation can change over time as your problem space changes. As data volumes grow or traffic grows or any other factor.
@drewverlee I'd definitely recommend attending The Strange Loop one year if you can. It tends to have a higher level range of talks than a lot of other conferences.
Thanks for the suggestion @seancorfield. I didn't get to go this year, i have watched most of the last couple years worth though. My brother took me to strange loop right as I got into software, I'm extremely grateful to everyone involved with that conference and look forward to it this year.
There is http://isaqb.org. They call themselves „international“, but i feel like it is Germany-driven (where i am from). They offer trainings and certificates for different skill levels of architects. They sure teach good stuff, and a certificate is something you can show a new employer, but at least in Germany IMHO certificates are not that important. Most architects i know have no certificate regarding software architecture. Experience is the key in many cases.
my 2c … attempts at formalising architecture (like TOGAF for example) are overwhelming and deadened by the weight of turgid and largely irrelevant documentation. We are simply not at a place in the industry where the architect role makes any sense when compared to those for physical buildings. Literally all of the material we operate on is incredibly unstable. The title is often conferred on a trusted person with experience. Which means that it’s essentially a BS title. IME the title is used to confer authority / thought leadership.
for real world examples of computer architecture consider the intersection of cloud and mobile
both are compromised by platform choices so making a decision about which way to go on the mobile / cloud are highly dependent on the context of the service and its target audience
further complicated by whether the motivating organisation is a startup, established or multinational corporation … they each have different constraints around skills, costs and integration
It's the kind of thing that's best communicated as a set of foundational principles, as it has always been. Those generally lead you to head the right directions. The nuances around those principles are what you learn through experience, and the only way to navigate some of those waters is just to listen to others who have also navigated similar waters and see if you can catch a whiff of the same smells they talk about. Over time, you start to gain an intuitive sense of how these general principles push and pull on one another; you begin to see how the tensions created by one set of principles leads to systems with one set of properties, while a different set of principles leads to a different set of systems. This kind of knowledge is locked into intuition, discovered by trying, sensing, changing, re-sensing; far too much micro-experimentation on a daily basis to pack into robust lessons. In the end, principles are the most compact method to communicate known architectural 'laws' that we can find.
> Over time, you start to gain an intuitive sense of how these general principles push and pull on one another; you begin to see how the tensions created by one set of principles leads to systems with one set of properties, while a different set of principles leads to a different set of systems. ☝️:skin-tone-2: I like the way you've expressed this!
@fellshard Do you have any recommendations for material online about foundational principles?
(and I agree with @raymcdermott that most attempts to formalize actual architecture are pretty much doomed by the way they are approached)
I’ve often been asked to define architectural principles but if I’m honest there aren’t any universal ones other than you mentioned @seancorfield which is to remain curious
Heh, and also that the title is mostly B.S. 🙂 I think I was first given the title when I joined Macromedia as the lead on a team of specialized architects -- and I've had variants of it most everywhere since (although I will confess to it being a self-chosen title at World Singles, but mostly for continuity on my resume!).
I gave up being Chief Enterprise Architect when I looked up and realised that I was spending all my time arguing about the relative (non-) merits of products by MS / Oracle / SAP / Salesforce that the business (or the CIO or one of the IT Directors) had bought despite our advice that we could build something for 1/10th of the price
@raymcdermott LOL. When Adobe acquired Macromedia, my role was eliminated because -- and I quote -- "Adobe does not have any architects"...
They will have „architects“ anyway. Unexperienced ones that are not aware of being in the process of architecting…