"Architecture" is a funny word in software development. Funny because what they call "software design" is still considered "architecture" to some. And what they call "architecture" I prefer to call "topology".
But regardless of what you call it, I generally agree with the article that application topology should be loose and adapt to changing requirements. Use well known software patterns and principals when writing modules, etc. Refactor cruft swiftly as needed.
Maybe it's just me, but after a decade of building software systems it's all fairly obvious. Yet still important to teach and mentor to juniors.
- working with people in software who hold a title of architect
- being referred to as an architect personally
- having the work that I do referred to as architecture
Design looks much less cool on a resume but is far more accurate and portrays a certain nimbleness. Anecdotally, the people I've ever worked with who did consider themselves "Software Architects" were generally quite poor at their jobs.
I happen to work with both folks who hold the title "Architect" and others "Designer". In practice there's often overlap in skills in those roles. In my experience there are different types of architect, some focused on infrastructure, perhaps the "topology" you're referring to and some focusing on the solution. The solution architect tends to focus on delivering business solution and capability while the designer is focused on software implementation.
In a large organisation you'll typically have a number of different architecture roles, i.e. its always something Architect. For example, there are Enterprise Architect, Line-of-Business Architect and Solution Architect roles for differing levels of vertical alignment within the business, and there are Information Architect, Data Architect, Infrastructure Architect, etc. roles for differing levels of horizontal alignment. Similarly within design you'll find a number of design roles, e.g. UX Design, UI Design, etc.
I've found that different organisations seem to have completely different definitions of "Enterprise Architect" - some use to to cover infrastructure and applications and others applications and business processes.
Granted I'm an old timer, and not a commercial software developer right now, but to me, the article brings to mind what I learned about "top down" versus "bottom up" design.
I understand what the author's point is but a good architect will use a light touch to help guide an effort toward solution. The sentiment is basically to avoid the temptation to over architect toward perfection in favor of building something based on an expression of business need. I generally agree with this sentiment, however in large organizations where outsourcing prevails, a deliberate architecture is a guard rail against bad practice and bad outcomes. In my experience, architecture is a needed practice that can help communicate the big picture and connect business goals to technology solutions.
I think part of the problem is that Software Architect is a bad term. An Architect makes a blueprint. That blueprint can be given to many different builders who can then all construct basically the same building.
If you tried to build equivalently detailed software blueprints, you end up just coding the whole thing. The problem is, the software is the blueprint.
Casey Muratori summed it up best in a handmade hero episode. He thinks that a better analogy for software architect is an urban planner. I think that if you approach your design phase more like urban planning, you'll accomplish most of what the article author is going for.
From what I've heard of it, that was their plan, but these types of projects always run into the same issue. If you build a high level system powerful enough to generate code that can solve general problems, the high level system eventually becomes a general purpose programming language itself.
The title of Architect only makes sense in enterprise Java or .NET OOP software projects where the architect's work product is UML diagrams and dataflow diagrams, and the implementation of the classes is delegated to a large number of developers.
I think that whole paradigm is a bad idea, but I also think that if you've already decided you're going to use one of those languages and run your project that way, it does make sense to have a person responsible for the high-level system design.
"architect's work product is UML diagrams and dataflow diagrams"
IMHO this is one of the worst ever ideas in software development - largely as if you never actually get your hands dirty with real code and the whole messy business of getting it developed, deployed and actually used you never actually see what actually works and what doesn't.
The thing about architects is they often aren't bound by engineering realities. Let's take your analogy a little further... A builder could construct a small house, and they wouldn't be described as an architect. But if you want to build a skyscraper, you would hire a team of architects, engineering specialists, etc.
The point is, the larger the project, the more important it is to invest in the right expertise at the beginning. The problem we have in software engineering is that successful projects almost never start from a position of major financial backing. Instead, the usual process is, start lean and cheap, hopefully gain traction, grow the product, get the investment, hire the talent. Honestly, I think it's a miracle if these types of projects are ever recovered.
I have mixed feelings about this. An experienced programmer might know the best way to structure a application simply from past experience. In this situation, a blueprint ensures that everyone is on the same page and saves an enormous amount of time that would have been spent refactoring code.
I'm not sure what to make of this piece. It draws you in with the curious challenge to "choose design over architecture" but uses terms loosely and merely gives broad claims like "Unfortunately, this kind of a grand plan usually leads to technical-debt that collapses towards complete immobility."
It then wanders to the topics of "SOLID," "Optimize for change, but don't optimize in advance," "Commit to refactoring," and finally concedes "There is still a place for architectural planning"
I think I made a mistake reading this piece; the complexity of the relationship between architecture and customer asks is much too complex to be answered with a few quotable phrases. Maybe I should have known this going in.
Same impression here. This piece had a surprising lack of depth given the vastness each topic the author decided to drop in the middle of it without any honest attempt to tie them together to the broader narrative.
The article is indeed an odd mix. As for Architecture vs Design -- I think "Software Architect(ure)" is a bit of a misnomer -- in as much as architecture makes sense as a term, it is a property of a System. And like the original MVC was MVCU: Model-View-Controller-User -- a system consists of more than just code.
I keep going back to the original REST thesis[1] -- and it's wonderful use of architectural constraints as a lens in which to say something general and useful about the nature of hypertext applications. And other architectures, which people seem to ignore all the time -- REST is just one sub-set of constraints that emerges for a rather particular application type. I really think the chapter that details all the other architectures is at least as interesting as the REST-part.
Notice how this article talks about "web servers" and "APIs" -- as if they were general, universal, system level properties -- rather than some very specific instances of RPC -- shaped by the architecture of hypertext applications and REST.
[Ed: note the illustration. On a cellphone, so a little painful to read through - I just remember Trygve mentioning it in a presentation I had the good fortune to attend a few years back]
[Ed2: Here's at least one reference to MVC-U, from one of the presentations on DCI (a successor to MVC of sorts):
"Most programmers think of MVC as a fancy composition of several instances of the Observer pattern. Most programming environments provide MVC base classes that can be extended to synchronize the state of the Model, the View, and the Controller. (Model, View and Controller are actually roles that can be played by the objects that the user provides—we'll talk more about roles later.) So it's just a housekeeping technique, right? To think of it that way is to take a nerd's perspective. We'll call that perspective "Model-View-Controller." More deeply, the framework exists to separate the representation of information from user interaction. In that capacity we'll call it "Model-View-Controller-User," capturing all four of the important actors at work—MVC-U for short."
As I recall, in the presentation, it was indicated that this was the an emphasis on what MVC originally was about, and that the User-bit originally was such a central part of the whole thing, that it was also part of the name -- but that the "U" got dropped at some point (ie: in the late 70s when they were writing up this stuff initially).]
the way it was written sounds like it was a business analyst or a agile-transformation consultant but not a person who understands engineering. Also it does not offer any proof/sources to the claims being made. e.g.:
"Unfortunately, this kind of a grand plan usually leads to technical-debt that collapses towards complete immobility. Complexities in even one of these services can take down the entire project. Unknown problems at the beginning can't be rolled into the new plan easily because all services are dependent on this architectural contract."
why?? it totally depends on the design/architecture on how flexible it will be.
or:
"In short, architectural plans push the team towards waterfall development, a system that has fallen out of favor as more and more projects have failed."
This article was probably written by a UE/UX designer.
IMO you always need a "big picture"/vision/plan (whatever you call it) before you think about UI aspects. How flexible that plan is in regard to user-experience depends on how well it was designed. Also the type of design doesn't dictate if whether you have to chose lean/agile/waterfall as your development process.
I think the author confused "Architecture" with "Big Desing Up Front" (BDUF), meaning the architecture is defined ahead of time in static (design...) documents that do not interact with the actual code.
This is somewhat excusable because that is pretty much how architecture works today. However, it shouldn't be, and Objective-Smalltalk[1] is an attempt to bring architecture into the fray of actual code, allowing it to participate in the feedback cycles of building real systems.
My concern with this (and my general pet peeve with the "user stories" in software engineering) is: how do we make sure the "user stories" are faithful to real-world usage of the software being built? tl;dr: how do we know the user stories are relevant?
The article defines user stories as "simple scenarios told from the point of view of a person using the software. There can be many types of users for an application". This is very, very problematic. How can I be sure that software developers are able to walk on the shoes of the user? That they even know who are the real users? Their needs, their context?
I have little to no faith in user stories, on software development. It takes a lot of UX knowledge and experience to be able to faithfully depict scenarios and personas, and even more so to have the maturity to do such things grounded on data and not on our preconceptions. I just can't assume software developers will have this kind of knowledge and experience and, as such, user stories will end up being a reflex of their preconceptions, not of the real-world usage of the software.
I've been in many projects where people would iterate numerous times over architecture while completely forgetting what real-world problem they are actually trying to solve. Architecture becoming art pour l'art.
I don't see the point of the article being that every software developer becomes a fully-fledged UX guy, but understands the context in which the system is going to be used and not get lost in the technical rabbit hole.
> I've been in many projects where people would iterate numerous times over architecture while completely forgetting what real-world problem they are actually trying to solve. Architecture becoming art pour l'art.
I completely agree. Unless constrained, software developers will entertain themselves with architecture stuff ad libitum. But this is one problem; the other - a full-blown, bigger one - is truly knowing the real-world problem.
> I don't see the point of the article being that every software developer becomes a fully-fledged UX guy, but understands the context in which the system is going to be used and not get lost in the technical rabbit hole.
The premise is a noble one, and correct IMO. But, as above, truly knowing the real-world problem is hell. We can't really hope to solve the technical rabbit hole just by focusing in the real-world, or simply assume that we know it.
Software developers won't understand the real-world context, most of the times. They aren't trained to do so. Most of the times, companies won't help: organization keeps software developers very far from customers. Hell, I'll say it: many software developers even lack the basic empathy skills to understand the user. Their model of the software is the implementation model, not the usage model. And many times they're too stubborn, and talk very cheap regarding users and usage: software developers say "this is what the user wants" as cheaply I say "the sky is blue". But the thing is that "what the user wants" is not that obvious; the only obvious thing is the mis/preconceptions we have.
The programmers don't have to write the user stories. A UX guy or a product owner can write the stories (which is how you ensure they're relevant). The job of the programmer is then to create a technical solution that solves a user requirement.
I absolutely agree; that's how it should happen. My main contempt is that, in reality, it doesn't. You get "implementation" guys writing user stories, and - in many ways - implementation model thrown into usage model. And, of course, nowhere in this article I found any discussion regarding who should - and which skills are needed to - write user stories.
P.S. As I said above, this is a pet peeve of mine. I'm doing a generalization; of course there are developers which are great at writing user stories and understanding users.
It's just that I believe in being professional and knowledgeable. If user stories matter, you should get someone with the valid skill set to do it. Not only should you get the skill set on your team, you should get the process! User stories without user data are just plain fiction. It's just the movie your team plays in their heads regarding how the software is used.
Software Architecture is the complete system, including the hardware and protocols. The complete system of an airplane is a software architecture.
It is very scary how naive and misinformed this article is coming from a .gov site. Given the misuse of terms and purely ridiculous suggestions, I wouldn't even show this to grade schooler.
36 comments
[ 3.3 ms ] story [ 64.5 ms ] threadBut regardless of what you call it, I generally agree with the article that application topology should be loose and adapt to changing requirements. Use well known software patterns and principals when writing modules, etc. Refactor cruft swiftly as needed.
Maybe it's just me, but after a decade of building software systems it's all fairly obvious. Yet still important to teach and mentor to juniors.
- working with people in software who hold a title of architect
- being referred to as an architect personally
- having the work that I do referred to as architecture
Design looks much less cool on a resume but is far more accurate and portrays a certain nimbleness. Anecdotally, the people I've ever worked with who did consider themselves "Software Architects" were generally quite poor at their jobs.
If you tried to build equivalently detailed software blueprints, you end up just coding the whole thing. The problem is, the software is the blueprint.
Casey Muratori summed it up best in a handmade hero episode. He thinks that a better analogy for software architect is an urban planner. I think that if you approach your design phase more like urban planning, you'll accomplish most of what the article author is going for.
I think that whole paradigm is a bad idea, but I also think that if you've already decided you're going to use one of those languages and run your project that way, it does make sense to have a person responsible for the high-level system design.
Actually trying to live up to the title of architect and including blueprint level detail into those high level diagrams is asking for trouble.
IMHO this is one of the worst ever ideas in software development - largely as if you never actually get your hands dirty with real code and the whole messy business of getting it developed, deployed and actually used you never actually see what actually works and what doesn't.
The point is, the larger the project, the more important it is to invest in the right expertise at the beginning. The problem we have in software engineering is that successful projects almost never start from a position of major financial backing. Instead, the usual process is, start lean and cheap, hopefully gain traction, grow the product, get the investment, hire the talent. Honestly, I think it's a miracle if these types of projects are ever recovered.
It then wanders to the topics of "SOLID," "Optimize for change, but don't optimize in advance," "Commit to refactoring," and finally concedes "There is still a place for architectural planning"
I think I made a mistake reading this piece; the complexity of the relationship between architecture and customer asks is much too complex to be answered with a few quotable phrases. Maybe I should have known this going in.
I keep going back to the original REST thesis[1] -- and it's wonderful use of architectural constraints as a lens in which to say something general and useful about the nature of hypertext applications. And other architectures, which people seem to ignore all the time -- REST is just one sub-set of constraints that emerges for a rather particular application type. I really think the chapter that details all the other architectures is at least as interesting as the REST-part.
Notice how this article talks about "web servers" and "APIs" -- as if they were general, universal, system level properties -- rather than some very specific instances of RPC -- shaped by the architecture of hypertext applications and REST.
[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_...
I would have expected there to be a mention of this on c2.com[1]. Any other places I might find it?
[1] http://c2.com/cgi/wiki?ModelViewControllerHistory
[Ed: note the illustration. On a cellphone, so a little painful to read through - I just remember Trygve mentioning it in a presentation I had the good fortune to attend a few years back]
[Ed2: Here's at least one reference to MVC-U, from one of the presentations on DCI (a successor to MVC of sorts):
http://www.artima.com/articles/dci_vision.html
"Most programmers think of MVC as a fancy composition of several instances of the Observer pattern. Most programming environments provide MVC base classes that can be extended to synchronize the state of the Model, the View, and the Controller. (Model, View and Controller are actually roles that can be played by the objects that the user provides—we'll talk more about roles later.) So it's just a housekeeping technique, right? To think of it that way is to take a nerd's perspective. We'll call that perspective "Model-View-Controller." More deeply, the framework exists to separate the representation of information from user interaction. In that capacity we'll call it "Model-View-Controller-User," capturing all four of the important actors at work—MVC-U for short."
As I recall, in the presentation, it was indicated that this was the an emphasis on what MVC originally was about, and that the User-bit originally was such a central part of the whole thing, that it was also part of the name -- but that the "U" got dropped at some point (ie: in the late 70s when they were writing up this stuff initially).]
"Unfortunately, this kind of a grand plan usually leads to technical-debt that collapses towards complete immobility. Complexities in even one of these services can take down the entire project. Unknown problems at the beginning can't be rolled into the new plan easily because all services are dependent on this architectural contract."
why?? it totally depends on the design/architecture on how flexible it will be.
or:
"In short, architectural plans push the team towards waterfall development, a system that has fallen out of favor as more and more projects have failed."
This article was probably written by a UE/UX designer. IMO you always need a "big picture"/vision/plan (whatever you call it) before you think about UI aspects. How flexible that plan is in regard to user-experience depends on how well it was designed. Also the type of design doesn't dictate if whether you have to chose lean/agile/waterfall as your development process.
This is somewhat excusable because that is pretty much how architecture works today. However, it shouldn't be, and Objective-Smalltalk[1] is an attempt to bring architecture into the fray of actual code, allowing it to participate in the feedback cycles of building real systems.
[1] http://objective.st/About/
The article defines user stories as "simple scenarios told from the point of view of a person using the software. There can be many types of users for an application". This is very, very problematic. How can I be sure that software developers are able to walk on the shoes of the user? That they even know who are the real users? Their needs, their context?
I have little to no faith in user stories, on software development. It takes a lot of UX knowledge and experience to be able to faithfully depict scenarios and personas, and even more so to have the maturity to do such things grounded on data and not on our preconceptions. I just can't assume software developers will have this kind of knowledge and experience and, as such, user stories will end up being a reflex of their preconceptions, not of the real-world usage of the software.
I don't see the point of the article being that every software developer becomes a fully-fledged UX guy, but understands the context in which the system is going to be used and not get lost in the technical rabbit hole.
I completely agree. Unless constrained, software developers will entertain themselves with architecture stuff ad libitum. But this is one problem; the other - a full-blown, bigger one - is truly knowing the real-world problem.
> I don't see the point of the article being that every software developer becomes a fully-fledged UX guy, but understands the context in which the system is going to be used and not get lost in the technical rabbit hole.
The premise is a noble one, and correct IMO. But, as above, truly knowing the real-world problem is hell. We can't really hope to solve the technical rabbit hole just by focusing in the real-world, or simply assume that we know it.
Software developers won't understand the real-world context, most of the times. They aren't trained to do so. Most of the times, companies won't help: organization keeps software developers very far from customers. Hell, I'll say it: many software developers even lack the basic empathy skills to understand the user. Their model of the software is the implementation model, not the usage model. And many times they're too stubborn, and talk very cheap regarding users and usage: software developers say "this is what the user wants" as cheaply I say "the sky is blue". But the thing is that "what the user wants" is not that obvious; the only obvious thing is the mis/preconceptions we have.
P.S. As I said above, this is a pet peeve of mine. I'm doing a generalization; of course there are developers which are great at writing user stories and understanding users.
It's just that I believe in being professional and knowledgeable. If user stories matter, you should get someone with the valid skill set to do it. Not only should you get the skill set on your team, you should get the process! User stories without user data are just plain fiction. It's just the movie your team plays in their heads regarding how the software is used.
That is true... I've seen a fair share of user stories that start "As a developer"...
It is very scary how naive and misinformed this article is coming from a .gov site. Given the misuse of terms and purely ridiculous suggestions, I wouldn't even show this to grade schooler.
http://disi.unal.edu.co/dacursci/sistemasycomputacion/docs/S...
And ironically, their website kept crapping the bed as I try to find their page on it, so I'll just have to post a few examples from outside sources:
https://en.wikipedia.org/wiki/San_Francisco_Federal_Building http://www.archdaily.com/416001/som-breaks-ground-on-los-ang... http://www.gsa.gov/portal/mediaId/190803/fileName/2014DA--Aw... (PDF)