Software Architect 2008

Software Architect 2008Just 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:
  • 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.
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.


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.


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.


Should be a really good conference ... if you're coming along, please do stop us and say hello. :-)

About the author

Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.

You can find Simon on Twitter at @simonbrown ... see for information about his speaking schedule, videos from past conferences and software architecture training.

Add a comment Send a TrackBack