I've read several posts about what people feel the role of SOA architect is or should be, and can generally agree with a portion of most of them. Traditionally, a technical (e.g. software) architect is responsible for taking requirements provided to them and putting together an architecture or design that best fits the project. In my experience, due to a lack of understanding on what SOA is, the role of SOA architect is generally relegated to technical/software architect.
However, this is not what the role should be in my opinion. A primary driver for adopting SOA in an organization is to support business agility and re-usability. Based on these characteristics then, it seems apparent that the SOA architect must be involved in understanding the business, business drivers, and overall roadmap to make the best decisions that support re-usability and business agility. This requires the SOA architect to be involved in the communication of project, product and program roadmaps. Sadly, this seems rarely to be the case from many organizations, where requirements get thrown "over the fence" for service developers to create services, without any design discussions of how this service fits into an overall portfolio, reusability of the service in other projects, etc.
I believe it's due to these situations where we get a large amount of services in production environments that are not tracked/monitored or cataloged in a repository, and then hear how SOA doesn't work and is dead. I'd love to hear others' experiences as a SOA architect or with a perspective on the role of SOA architecture whether good or bad.
