Software Architect 2008
Just a short note to plug a handful of sessions that Kevin and I are presenting at the upcoming Software Architect 2008 conference, 3rd-5th June, London.
1. Coding the Architecture : From Developer to Architect
The first is a re-run of our popular all-day workshop/tutorial, which is an introduction to software architecture.
This session is an interactive introduction to software architecture and what it means to be a software architect. It’s aimed at software developers who are looking towards their first software architect role, as well as architects that are new to the role. By attending this session you will gain:The session is interactive; with a combination of presentation, group discussion and group working. Throughout the day you’ll be solidifying everything you learn by defining the architecture for a small software system. The overall goal is that you can take the experience gained here and apply it to your own projects.
- An understanding of what it means to be a software architect, and the responsibilities associated with the role.
- An understanding of the trade-offs that are made when making architectural decisions.
- Some experience of what it feels like to be an architect on a bespoke software development project; including gathering non-functional requirements, determining the drivers for architecture, and defining an architecture.
- An understanding that, as a software architect, it’s okay to do some coding.
Read more...
2. Why Software Projects Fail
The next session takes a look at why software projects fail, and how software architects can prevent this from happening.
The industry has a love/hate relationship with the Software Architect role, with many organisations dismissing it because of their negative experiences of architects that dictate from ivory towers and aren’t engaged with the actual task of building working software. This reputation is damaging the IT industry and inhibiting project success. Things need to change. This session looks at some of the reasons why software projects fail, and presents the view that a good, hands-on software architect can be invaluable in addressing these issues and driving the project to a successful conclusion. Software architects are here to help, not to hinder.
Read more...
3. Sharing Architectures
And the last session we're presenting is about *sharing* architectures (as opposed to just writing them down in a document).
The transition from architectural vision to production code is not always an easy one. Of course we plan for a certain amount of change and accept that some decisions will, on occasion, be wrong. However, without effective communication of the architecture and timely feedback mechanisms, can we really expect to see software that we recognise? Whether we’re up to our elbows in an agile team or riding a barrel down a waterfall project, our choice of what we define and how we convey it can have an enormous bearing on how the architecture is reflected in the software. This session takes a look at some techniques for sharing the architecture and not just publishing it.
Read more...
Should be a really good conference ... if you're coming along, please do stop us and say hello. :-)
Mind the gap
Reducing the gap between software developers and software architects
Our industry has a love/hate relationship with the software architect role, with many organisations dismissing it because of their negative experiences of architects that dictate from "ivory towers" and aren't engaged with the actual task of building working software. This reputation is damaging the IT industry and inhibiting project success. Things need to change. This essay looks at the gap between software developers and software architects, offering some suggestions on how to reduce this gap and ensure projects are driven to a successful conclusion.
What is architecture?
Towards a definition of architecture
Architecture is a widely-used term within software development yet is very hard to define rigorously. Indeed, it changes meaning from domain to domain, company to company, project to project and even from employee to employee.
