This post originated from an RSS feed registered with Agile Buzz
by Marty Andrews.
Original Post: Defining software architecture roles.
Feed Title: Ramblings of the Wry Tradesman
Feed URL: http://www.wrytradesman.com/blog/index.rdf
Feed Description: Marty Andrews talks about the day to day issues he faces as an agile coach on large enterprise applications in Australia.
As a member of the software development community, I run into a lot of people who claim to be software architects. Its a heavily overloaded term in the industry, and is a source of confusion even for others experienced in dealing with them. Sometimes I've even claimed to be one myself, even though I know it can cause confusion. There are a few consistencies that I see filter through though, at least in the industry in Australia.
A System Architect, sometimes also known as an Application Architect is someone who typically designs and builds a single system. They care about the internals of the software system at least at a coarse grained level. So they might describe what internal components a system has for example. In addition, they probably will influence what frameworks or 3rd party API's are used to build those internal components. They may or may not be interested in finer grained details like the classes or patterns used by developers on a dail basis (if they're any good, they will, but I'll talk more about that later). Finally, they will probably care about a deployment environment for the system as well. The application server, database, operating system, firewalls etc are all in their scope of concern.
A Solution Architect is someone who designs and builds interactions between multiple systems to provide a solution to some business problem. They care about the edge points of systems so they can figure out how to wire them together. This might be databases, queues, web services, or other programming API's that can be used. The internals of individal systems aren't so much of interest to them. Deployment environments are often even more of concern to Solution Architects, as they need to get multiple systems to play nice together in the same environment.
An Enterprise Architect is someone who designs and builds interactions between multiple solutions in an organisation. They typically exist in organisations that have been around for decades, so therefore have built up literally dozens of legacy systems. They don't really care so much about technology, except at a very high level. Solutions will often be identified by Enterprise Architects, so they may allocate a Solution Architect to drive further detail on the problem.
Almost all developers in the industry will come across System or Solution architects in their time. In Australia, architects sometimes get a bad name because of the increasing number of ivory tower architects around. This results in poor alignment of authority and responsibility. The architects have the authority to make decisions on the project, whilst the developers are responsible for implementing them. If things don't work, the developers get blamed, even if it was a result of a poor decision.
Previous Topic
