Software Architect's Role
One of the topics I encountered in the last months was when I gave a talk at the OOP 2006 conference in Munich. An attendee told me offline he was going to manage a big software project and wanted some recommendations how to hire the right people for the software architect's role in his team. So what is the qualification an architect needs for software engineering? Is it just mastering UML and MS Project? Is it mastership of patterns? Of course, all these experiences are important but there is more. Personally, I would identify the following areas where a software architect should have expertise:
Software Engineering Skills: It is really obvious, that a software architect should have deep knowledge about all relevant technologies in software engineering such as UML, patterns, frameworks, components, services, requirement analysis, OOP, etc. She or he must also know upcoming trends, for example Model-Driven and Aspect-Oriented Software, Domain Modeling, Feature Modeling.
Software process: In addition, it is also important to know how software projects are organized in terms of roles, disciplines, phases, and activities. Rational Unified Process, Agile Methods are absolutely important here. Think about Unit Testing, Refactoring, Iteration Planning. Of course, quality-assessment and improvement are essential, i.e. techniques such as as metrics or methods such as CMMi.
Project Management: An architect must make sure that a software project is well organized in terms of resources and participants. The reason for that is simple: A software project should also be considered a (partial) failure when it does not meet its deadlines or resource constraints. As architects are the people that have all the experiences and knowledge already illustrated, they should definitely take care about project management, even if there is a dedicated project manager. And keep in mind: organizational issues such as project members coming from different departments might also be disturbing and counterproductive for any project. There is an old saying "show me your architecture and I know your company organization". Thus, architects should be proactive.
Business Skills: Every software projects - well at least most of them - follow some business case, meaning that management expects some benefits from the software system being developed. Thus, it is important to calculate whether a software development project is able to achieve all of the financial objectives. If, for example, stringent requirements are expected to be met by a customer such as "build this complex embedded system with a group of unexperienced developers in three weeks" then an architect must be able to evaluate the propability that the project might succeed. And, of course, if soime important requirements are not met by a software architecture, this might imply significant losses. Take commercial systems (software or hardware) as an example that revealed inappropriate architectures. Such problems are not very well received by customers.
Technology Expertise: Architects are not those people who develop Powerpoint and Word documents full of bubbles that can't crash. Software engineering is not a discipline where you can develop high level visions from 10000 feet without ever checking whether the real-world technology choices are able to implement the visions. For example, a software architect who is completely unfamiliar with Java EE won't ever be able to come up with an architecture that meets all requirements. If the software architects are domain experts they might be able to define the appropriate decomposition and relationships. But ... they are unable to meet most of the operational and developmental requirements. Believe me, most failed projects I've seen so far often failed exactly for that very reason. So, always keep up to date with the newest middleware, platforms, programming languages, paradigms.
Implementation Expertise: Architect always implements. That basically means, "eat your own dog food". An architect must design an implementable software architecture. And she or he must be able to refactor when necessary. Thus, an architect needs to participate in implementing and unit-testing. It is definitely not recommendable to introduce a BDUF (Big Design Upfront) approach where a couple of software architects sets up some architectural visions behind closed doors in a few weeks and then throws the architecture specification over the fence to the developers without being involved in subsequent development phases. If you don't trust your architecture you shouldn't be a software architect, anyway.
Social skills, the most important being communication. As an architect you will talk to customers, team members, business accountants, and all the other stakeholders. It requires huge efforts to keep all of them motivated and synchronized. For this purpose, an architect's daily agenda consists mainly of talking to other people. An architect must clarify requirements with customers, set the scope of the domain, design architectures with other architects, supervise the development team so that there is no deviation between architecture and implementation, make sure the testers are tightly integrated. And even more. Architects should motivate others and convince them.
As a consequence, someone who just has received an university degree, no matter how smart and knowledgeable, will not be able to be a software architect in the beginning. This requires years of experience.
There are even more issues here. But as always, space is void and can never be filled completely. Any further suggestions what makes up a good software architect?