Marty Andrews

artful code

Tuesday, September 26, 2006

Defining software architecture roles.

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.

Wednesday, September 20, 2006

What do you need to be agile?

Diana Larsen has commented about the building blocks she thinks are fundamental to Agile. I have held a theory for a while now that iterations and retrospectives are all that is required for an agile process to evolve. I can imagine that first retrospective discussing items like "Hey - our communication isn't so good. Lets try having stand-ups next iteration." Similar conversations could occur for any practice discussed by the agile community. Bootstrapping practices in a team can accelerate the evolution of the process, but it also means imposing more decisions on the team rather than having them manage themselves. Mileage will vary widely depending on your people.