Most of the roles that we associate with software development teams are relatively well understood ... developers, testers, ScrumMasters, Product Owners, business analysts, project managers, etc. The software architecture role? Not so much. I regularly ask software teams whether they have a defined terms of reference for the software architecture role and the usual answer is along the lines of "no" or "yes, but we don't use it". Often people working for the *same team* will answer the question differently.
Although the need for thinking about software architecture is usually acknowledged, the responsibilities of the software architecture role often aren't clear. In my experience, this can lead to a situation where there is nobody undertaking the role, or where somebody is assigned the role but doesn't really understand how they should undertake it. If the role isn't understood, it's not going to get done and we have little hope of growing the software architects of tomorrow.
Regardless of what you call it (e.g. architect, tech lead, etc), my advice is simple. If you don't have a shared understanding of the role, start by doing this for the role within your team. Here's a simple starting point for what the role could look like. The role is also described in my book and here on InfoQ.com.
Another approach is to define it collaboratively using a workshop or game storming techniques. Here are some photos from a tutorial I did at QCcon London 2012 called "Are you a software architect?".
Make sure that you base any role definition on your own context to ground the role in reality. Then, once you understand what the role should look like on a team, you can start thinking about whether to achieve consistency across your organisation. This may or may not be necessary/desirable.
Creating a shared understanding of the role will help to avoid questions like this and situations where software architecture falls between the gaps.