One might turn the question on its head: when does coding stop and design begin? Architecture? Business analysis ? Programme management?
To (correctly) assert that you can't define the boundaries doesn't mean that you can move freely from one to the other. There is a point where your skills (whatever they may be) aren't best suited to the tasks for which you are responsible. So how big (and blurry) must the picture get before it's outside your core skills?
As a concrete example, I'd offer up creating the five-year technical strategy for developing an internet platform that had to be resold to various clients at differing levels of cost and service level. I spend most my time coding, but what was my role when I helped conceive the strategy, checked it was viable, looked at the costs? I think my responsibilities were sufficiently far from coding to be considered outside.
An example that might be closer to the boundary is whether to use distributed transactions or corrective actions. It clearly has immediate impact on development activities and is understood by most (good/experienced) developers. Whether an "architect" makes this design choice or the development team sit in their beanbag room to make it doesn't really matter: it's still architectural*.
E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).