I am rarely, becoming often. Just in the last year or so -- since my software architecture class at Georgia Tech -- I've been trying to do 4+1 view models for new software.
It's been really interesting! Typically I start with use cases, and then do one sequence diagram per use case. I then gather the entities named in the process view and their messages into a logical view. After that, I refactor, and feed that back to the process view. (For example, if I break up a big class, I'll change the process view to show the new classes instead.)
Then a deployment view, and finally a development view. And that's when I'm ready to start coding.
A lot of annoying problems come up with this. Like, parts of the stack that are missing, and I have to go back and add them, which usually means more sequence diagrams, changes to the logical view, and other cascading effects.
I kind of had an "aha" moment with this, realizing that finding and fixing problems at the architecture stage is way easier than finding them in production. Like, this is why we do software architecture; to think about the hard stuff early.
@evan I've come to really appreciate how much time and pain is saved long term by analysis and planning, but building small experimental prototypes to analyze is often a necessary step to inform planning in my work, so idk if there's always a clean distinction.
@evan
As an architect I try to convince all of our devs to consult our solution architects. However, our products are based on different levels of architecture designs. So, in general always. With a deeper level of detail often to rarely (unfortunately). But it's a learning process. 😉🤷
@evan
What do you consider "doing architecture"? Since I view it pretty much as thinking about what I'm about to build and how I'm going to approach it, it's nigh impossible to not do it before coding (I chose "always").
Add comment