I’ve defined here under what my vision is on the tasks and responsibilities of a Agile Software Architect role should have in the Enterprise. The Enterprise usualy also has another role that could be defined as the Enterprise Architect whose role is more strategic and cross project. The list here under is applicable to the first category, the once actively participating in software projects.
Project Tasks
- Take final responsibility for the quality of the software produced
- Take the important technical decisions taking all quality aspects of the project into consideration (Cost, Maintainability, Availability, Scalability, Security and all other ty’s)
- Mesure the quality through metrics and code reviews
- Enforce changes if quality is not in line with standards
- Select, in the context of the project, what the software engineering practices should be and how they are applicable for the concrete project
- Define code coverageCode quality and encouragement of best practices
- Coaching of and adherence to "Agile" software development principles for module design and implementation
- Take the lead when building prototypes, common tools, general solutions and reusable components
- Engage the teams in both defining and executing on such tasks
The people often best suited to build prototypes are those with knowledge of the intimate details
- Building reusable components comes from first building usable components
- Management of common libraries
- Define based on stakeholders requirements what the Performance, scalability and high-availability requirements are.
- Interface between technical teams (Service team, Project, Development Center, Quality Assurance…), business stakeholders and development teams on technical matters
- Coordination with QA and release engineers
- Integration, performance and load testing strategies
- Release, migration and upgrade strategies
- Coaching and working directly with development teams on a regular basis
- Technical customer to the agile development teams
- Able to add technical user stories to the product backlog
- Works directly with the product owners to prioritize and trim the product backlog
Responsabilities
- Participate in the design of the software engineering process(es)
- High-level technical vision, planning and documentation
- Automate and define the tools that support the software engineering process(es)
- Technical oversight in specific technical domain
EAI, .Net, Java, Packages, ….
I would like to underline what in my opinion differentiate an agile software architect from how our role is usually perceived.
An Agile software architect doesn’t take part to a project only at its beginning, but during the whole project’s lifecycle to ensure a right implementation of the design and architecture. He also has to keep listening to new requirements to adapt solutions if needed.
Even if I acknowledge that an architect has to step back from his work and the teams’ work, I don’t conceive an architect who would remain far from the implementation team. Indeed, an architect can have to write lines of code (at least to create prototypes), but also has to get his hands dirty with code to validate the quality of what is produced or resolve a particularly technically difficult situation.
Further I would like to refer to some toughts of Martin Fowler expressed in the article by Martin Fowler “Who needs Architect”
http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
“architecture is the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other”
“A guide is a more experienced and skillful team member who teaches other team members to better fend for themselves yet is always there for the really tricky stuff.”
I would also recommend the following webcast with again Martin Fowler on the role of an architect in an Agile Organization:http://www.infoq.com/presentations/agilists-and-architects
GVD
These are, what I consider to be the 5 most desirable quality attributes of a unit test:
1. Unit tests should be accessible, everyone should be able to run them
Running a unit test should not involve more than getting the source code from a source controller, compile the SUT/Test code and clicking on a button to run all the tests. No configuration should be involved. Your tests should not require to setup external components like a DB or SMTP server.
2. Unit tests should be repeatable
What is the value of a test you can’t trust? Unit tests results should only change when modifications are introduce in the SUT. When the SUT remain the same the unit tests should always return the same result. Therefore unit tests should be state independent and in anyway they should never be dependant on a shared resource like a file or persistent memory.
3. Unit tests should be easy to write and maintain
In an software shop we should only use a practice or tool when this is economical viable meaning that the cost of writing the tests and maintaining it should not exceeds the costs of having a bug and fixing it. To minimize the cost of creating and maintaining tests we should use appropriate practices and tools. We should also have the same quality requirement for test code as for production code. Refactoring is as important for test code as for production code.
4. Unit tests should be resistant to change
We should write our test in such a way that the amount of tests failing when introducing a change is minimal. When testing the SUT it is common to set his variable in proper state so it can be tested. This type of setup test code is very fragile. We should always try to isolate this type of code so it is easy to change.
5. Unit tests should run quickly
ideally unit tests should be executed after every build. Having to wait more than 1 minute to execute all the unit tests will decrease the overall productivity of the tests. Unit tests should never be dependant on costly resources to invoke like web services or DB.
Is there someting missing here?
GVD