ArchSummit 2012 in China and WICSA/ECSA 2012 in Finland
Although I'm on holiday this month, I've still managed to sneak in a couple of conference trips as follows...
ArchSummit 2012 (Shenzhen, China)
I'll be presenting two sessions at the International Architect Summit 2012 (organised by InfoQ China) that is taking place in Shenzhen, China. My first presentation is a morning keynote/plenary session entitled "The Frustrated Architect", which looks at the architecture role on modern software development projects, explaining how having an obsession with the latest trends doesn't necessarily guarantee success. Here's a Chinese translation of an interview with InfoQ.com on the same topic.
The frustrated architect
The IT industry is either taking giant leaps ahead or it's in deep turmoil. On the one hand we're pushing forward, reinventing the way that we build software and striving for craftsmanship at every turn. On the other though, we're continually forgetting the good of the past and software teams are still failing on an alarmingly regular basis.
Software architecture plays a pivotal role in the delivery of successful software yet it's frustratingly neglected by many teams. Whether performed by one person or shared amongst the team, the architecture role exists on even the most agile of teams yet the balance of up front and evolutionary thinking often reflects aspiration rather than reality.
If we really do want to succeed, we need to get over our fascination with shiny new things and starting asking some questions. Does agile need architecture or does architecture actually need agile? Have we forgotten more about good software design than we've learnt in recent years? Does any of this matter if we're not fostering the software architects of tomorrow? How do we move from frustration to serenity?
The second presentation looks at security, which is a crucial aspect of most software systems yet often neglected. This talk features guidance on how to tackle security within software projects; including the security concerns associated with the design, development, deployment and operation of the resulting software. Of course, the irony of this talk is that I'm not a security expert and that's really the point. As a technical lead/software architect, you can't be a specialist in everything but you do need a general awareness and breadth of knowledge so that you can try to do "the right thing".
How to design a secure architecture
Security is an important quality attribute of most, if not all, software systems regardless of whether the security requirements are explicitly given to you. Security is about much more than the traditional authentication and authorisation concerns though, which means that anybody undertaking the software architecture role needs to have a basic knowledge of security across a number of different perspectives. This session will look at security from a holistic point of view and provide guidance on how to tackle security requirements across your software architecture; from development right through to deployment and operation.
WICSA/ECSA 2012 (Helsinki, Finland)
I'll be running a full-day tutorial at the WICSA/ECSA 2012 conference that is taking place in Helsinki, Finland. The conference is a joint event for the 10th Working IEEE/IFIP Conference on Software Architecture and the 6th European Conference on Software Architecture. My tutorial is titled "Effective architecture sketches", which will allow delegates to practice collaborative software design and provide an environment for them to focus on how they can effectively communicate the result. Since the tutorial is about communication, I'm hoping that we have some good discussion with Philippe Kruchten about the 4+1 architectural view model. :-)
Effective architecture sketches
Collaboration and "moving fast" aren't terms that many people associate with the software architecture role, yet they're both essential. Why? Because collaborating on the software design process provides a basis for coming up with a better solution and paves the way for collective code ownership. And moving fast requires "just enough" up front design to avoid costly rework, which sits conveniently in that vague area between ivory towers and foolishly hoping for the best. Costly rework can be caused by a number of things ranging from not mitigating the key technical risks through to the team not understanding the high-level structure and therefore being able to work towards the same vision. This, as with agile in general, requires good communication skills and not being able to effectively communicate your software architecture will slow you down at best.
Most people don't get to practice the software design process all that often and fewer get to hone their communication skills. Join us if you want to practice collaborative software design and learn about how to communicate it through a collection of simple effective architecture sketches.
As always, the slides from all of my sessions will be available to view online/download from http://www.codingthearchitecture.com/presentations/ after the events.