I hope that while reading this, you've asked yourself why making these distinctions should matter.  And I mean more than just so you can feel macho by saying you’re an architect.  In fact, if we take the delineation as above, it is no more macho to be an architect than it is to be a developer.  Being an architect is not a natural or implied progression from being a developer; it's no longer simply an überdeveloper (as is the common impression one gets today), but instead it is simply an alternate career path. 

Those who truly get more satisfaction from expressing their intellect through code can progress along a career path that values at its core such expression, leaving broader business concerns to those who care about them.  Similarly, those who enjoy technology (and are, hopefully, good with it), but who also enjoy thinking in terms of the business and ensuring that the business' various and distinct needs that pertain to software are met, can pursue the path of architecture.  Nor are these paths mutually exclusive.  One may find at some point in his life that specializing in a particular technology or viewpoint is what he enjoys the most and then later find that focusing on meeting business needs is what really floats his boat.

Developers are renowned for their disinterest in business, and the proposed definitions enable them to maintain that disinterest while still providing value where they're most able and wont to.  Architects can, thanks to the support of developers, focus more on ensuring business needs are met with due diligence (and not, as is often the case, as an afterthought or a bother).  It is an ecosystem of distinct and mutually dependent roles, as opposed to a competition between them.

We, as an industry, are guilty of confusing the issue because there is an implied hierarchy, where architects are at the top and paid the best.  As long as that's the case, we'll always have this confusion because those who truly prefer to focus on technology will continue to claim to be architects.  If we change the way we view the distinction between the roles, we see that it is not a hierarchy but a complementarity.  And once that is recognized and communicated, businesses will learn to pay well for good developers without asking them to be architects.  I think, in fact, that this is the case with some companies, though by and large, I still imagine that most have the misconception that architecture is somehow implicitly more valuable than development.

Further, this approach enables us to express, in terms that businesses will understand, the distinct value that the two roles add to their businesses.  Businesses would welcome the idea of a distinct role that is responsible for ensuring all business needs are met, having a person that is extensively focused on the business but who can adequately translate the business needs into a software solution.  Certainly, this isn't a panacea; we'll still have bad architecture and bad coding, but I think it is a step in the right direction in further maturing our industry and lessening the number of failed or ineffectual software applications by enabling a proper division of concerns.

I'm not suggesting anything that changes the mechanics of what is involved in software development--we already have all these competing concerns built into most software methodologies today.  The only novel idea here, if it is even particularly novel, is that we make the intentional and conscious division of these two roles in software development, not just along the lines of responsibility, but also along the lines of the role's primary concern as well as the individual's interest, that we formally acknowledge the distinct value that each role brings to the table, and that we encourage individuals to excel in the role that best suits them rather than always expecting developers to be architects and architects to be developers.