I like the idea of conceptual grouping of what we do when developing software. RUP defines 4 such groups that can be used to describe the various phases a software project can go through.
- Inception
- determining whether its worthwhile going through with the project
- setting up prototypes
- gauging the complexities
- Elaboration
- gathering most significant functional requirements
- building candidate architecture and functional skeletons
- defining the non functional requirements
- setting up the project (defining standards etc. etc.)
- hiring people, etc. etc.
- Construction
- implementing more functionality and features
- gathering more requirements
- changing requirement and implementation if needed
- Transition
- finalization, making battle ready
- releasing
We can think about software development in this way:
- There is a need for computer program to be implemented, and the reasons can be:
- economical (we need to save money or make more money)
- human (as a tool, visualization, training)
- Try to define what we need this computer program to do for us
- Try to come up with the best possible way known at the time to do this, best here can be:
- fastest
- most elegant
- cheapest
- most compliant
- Commence with implementation following some kind of process, best practise here:
- iteratively
- incremental
- use case/scenario/story/task/feature drive
Some tools and principles that I have found that will aid in this activity:
- Continuous integration
- TDD
- Refactoring
- Scripting languages
- RAD
- Separation of concern
- Issue tracker
- Wiki (with support for active discussions)
- There is no substitute for skill and experience!
- Communication and feedback
- KISS
- YANGNI
- Code reviews
- Curtness, humbleness and mutual respect
- Managing expectations
- Avoid rather than detect problems but handle gracefully when so
- Collective ownership
- Delegation is a great way manage time
- Open source tools of all kinds...
Here are some of the responsibilities I would expect from a software architect in short form:
- Requirements gathering and synthesising
- System architecture - servers, routers bandwidths and so on
- Nonfunctional requirements - capacity planning, scalability and performance conformance
- Application architecture and design coming from some kind of analysis based on the above
- Setting up project and hiring people
- Setting up candidate architecture and skeletons
- Establishing coding guidelines and standards
- Establishing project methodology and process
- Deciding on tools for development, communication and management
- Training people
- Documentation
- Analysis, Design and Implementation - Hands on!
These are some of the attitudes I think a software architect should have:
- Enthusiastic
- Evangelistic
- Humble
- Clear and to the point
- Agile
- Pragmatic
The architect is the driver, the leader and the motivator. Without a good architect there can be no supper tomorrow :)
No comments:
Post a Comment