Software Architect's Role
I am back. It took quite some time until my last posting. This was due to the work load I had in the last twelve months. From now on I am trying to be more verbose.
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?
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?
posted by Michael at
10:57 AM
7 Comments:
I read your article with interest and intregue. It would be soooo nice to have project managers with even .25% of the understanding as expalined in your article.
I have been a software dude for alomst 20 years and have been working as an architect and framework guy for some years now and I can tell you that most of the 'architects' i've met have never written a commercial grade system. In fact, they seem to think that it's 'above' them to get their hands dirty. Let me give you a classic example.
I was working on a rather large telecom project and met some architects that wanted to create a fancy middle tier using .NET remoting. They had fancy visio diagrams and some UML!! My first reaction was to keep quite, then go away and spend a couple of weeks immersed in .NET (Framework 1.1) remoting - building prototypes within the context of our domain. A couple of weeks later i found many short falls in the technology for our particular domain, and presented my findings. Later i realized not one other 'architect' even took the liberty to go through what i did. By the way they were from a VERY expensive consulting company!! Alas! they were also a lot younger than me!! Call me old fashioned but these young software guys these days just think that software works 100% right out of the box!!
By
Anonymous, at 8:05 PM
Great one Michael !
--S Kumar
By
Anonymous, at 8:44 PM
I have been for some time a project manager with the capabilities of a team leader and the understanding of an architect.
I think that the project manager cannot be with more then 25% of the understanding of the architect. he should be a more managerial type.
there should be a big seperating gap of understanding since the project manager is suppose to be a PM with his own skills.
By
Anonymous, at 8:05 AM
Great article, but still too technology oriented. Here's what I think an architect should have (In order of importance):
1. Vision
2. Communication Ability
3. Proven Technology Experience / Skills etc.
Anyone who is missing the first two is really just an experienced developer.
By
Anonymous, at 7:33 PM
Hi sysarch,
the whole article is a message that technology in only one side of the coin. And I hope to have made clear how important communication skill are. Thus, I am not sure whether the article is really too technology-oriented. Said that, I must agree that some of the worst project failures I have seen were due to the fact that architects were good in specifying but had no idea about the implication of technologies, tools, etc. For example, it is interesting how bad projects can evolve if configuration management is neglected. Betrand Meyer is right with his statements "Bubbles don't crash. All you need is code". I guess, the whole agile method movement is an answer to processes where architects are just wizards of UML drawing tools.
I am not sure what you mean by vision. Is it about creativity or more about being prepared to future evolvements of the architecture? Could be an interesting point to discuss.
-- Michael
By
Michael, at 7:56 PM
Just read your post. From my perspective, the software architect's most important role is to assimilate and articulate the final solution. The architect is the client's representative in the software construction process.
That implies the architect should be versed in all the skills and tools, whether technical or non-technical, that are required to deliver a functioning solution that meets the client's requirements.
By
awachs, at 12:58 AM
An interesting post for architect There is so much that could be said about.
http://www.innotect.co.uk
By
http://www.innotect.co.uk/Blog, at 4:42 AM
Post a Comment
<< Home