I gave two presentations at the BCS SPA conference 2007 in March 2007.

Systems Continuity

Eoin Woods and I ran a workshop called The Shape of Survival: Strategies and Patterns for Systems Continuity. Our participants identified architectural strategies and patterns for ensuring the survival of their systems and IT infrastructure in the face of failure, disruption or disaster. Here's the abstract:

Recent changes to company law in Europe and the US mean that business continuity (that is, the ability of an organisation to continue to function in the event of a disaster or other disruption) is now a key concern. The role of IT in achieving business continuity is to ensure that critical systems achieve high availabilty (HA) in normal operation, and that in the case of disastrous failure, the crucial parts of the IT environment can be reliably and swiftly recovered to remote sites using a disaster recovery (DR) plan.

This has a significant implications for architects since these qualities must be designed into systems and infrastructures from the outset - it is very difficult to add such capabilities later on in the development lifecycle, or worse still, after deployment.

This session will explore possible solutions for high availability and disaster recovery, and how they can be combined to address possible threats that are faced by today's IT systems and infrastructure.

You can a copy of our presentation here.

Anti-Patterns of Project Execution

Andy Longshaw and I ran a workshop wittily entitled Methodology Used on Project, Not Many Dead: Anti-patterns for project execution and how to avoid them.

Our objective was to get the participants to identify "anti-patterns of project execution" (undesirable behaviours which lead projects into disaster) and explore how we could "refactor" these into behaviours which lead to success. Here's the abstract:

Use of a software development methodology, whether it's based on waterfall, iterative or agile approaches, is now mandatory on most software development projects. However in our experience, these methodologies are almost universally loathed and derided by all concerned - sponsor, users, management and developers. At best, the project is successful in spite of the use of the methodology, rather than because of it, and at worst, the project suffers delays, descoping, quality issues and sometimes even cancellation.

In this workshop we will identify some of the undesirable behaviours which tend to subvert the successful application of a methodology - "anti-patterns of project execution" - such as analysis paralysis, methodology kerplunk , governance façade, zombie march, and the ball and chain of responsibility. We will then work as a group to work out why we end up with these. (For example, a practice may have been useful in some form of project when the methodology was first developed - we will look at why it might have been useful then, but not on the project where it was observed as an anti-pattern.)

We will then decide whether these practices should be dropped or adapted ("refactored") in particular project contexts (skills, size, system type, budget and timescale constraints etc.) - based on what actually works in the experience of the presenters and the session attendees.

Our goal is not to come up with an "uber-methodology" which is applicable to any project, but rather to understand how better to apply the methodologies we've got, how to identify those parts of them which are genuinely valuable to your particular project and those which can be ignored, and recognise anti-patterns early on and change course before it's too late.

You can a copy of our presentation and the raw material we captured here.

Eoin Woods and I wrote an article for InformIT, the website of Pearson Education (whose subsidiary Pearson published our book).

InformIT contains a wealth of software-engineering reference material, including articles on everything from Business and E-commerce to Web Development via Digital Lifestyles, IT Management and of course Architecture. Much of it is free (registration required for some services) and you also get a book discount when you join. Even if you're not interested in my article, InformIT is worth a visit.

The title of the article is So Now I'm A Software Architect. What Do I Actually Do? and it describes the role of software architect and provides answers to some key questions, such as:

• Who are our clients?
• To whom are we accountable?
• What are we expected to deliver?
• What is our involvement once the architectural design has been completed?
• Where are the boundaries between requirements, architecture, and design?

The article focuses on the practical tasks you must undertake to produce the architectural description. You can find it on the InformIT website here, or in PDF form here.

Eoin Woods and I gave a sold-out presentation at OT2004.

The title of our talk was Getting to Grips with Architecture Using Viewpoints and Perspectives and in it Eoin and I explored many of the themes in our book. Here's the abstract:

Most proposed approaches to software and systems architecture today suggest an approach to design and description based on the use of a number of related viewpoints. A recent IEEE standard for recommended practice (1471) standardises this approach for architectural description.

In practice, a lot of software architects haven't really heard much about viewpoints and their use in architectural description. Fewer still have had the chance to work with other architects to identify the set of viewpoints that are necessary and useful when designing systems of various types.

This tutorial will introduce the viewpoint oriented approach for those unfamiliar with it and provide an update on recent developments (such as IEEE 1471). It will then introduce a number of different existing viewpoint sets and move on to a group exercise where the tutorial participants work together to identify the viewpoint sets relevant to the kinds of systems that they work on.

A limitation of the viewpoint oriented approach is that it doesn't explicitly guide the architect in dealing with the system's quality properties that are so crucial to building effective large scale systems. A new concept - the perspective - will be introduced for dealing with quality properties during architectural definition. Again, a number of existing perspectives will be introduced and a group exercise will allow participants to identify those which are of most relevance to their application domains.

More details can be found here.

Here are the slides I used to give a talk on Architecture to the London Branch of the British Computer Society on 21 March 2002.

You can find the slides here.

I wrote this article for The Connection, the magazine of the Tandem User Group. It compares the practice of software architecture with the much older and more established practice of building architects. Although there are some superficial similarities, we can actually learn a lot more from the differences between these two professions.

This article was published late in 2001. Here is a proof copy.

This is an article I wrote for EAI Journal. The executive summary reads as follows:

Data architectures address the context, semantics, and inter-relationships of data components at the enterprise level. But how should you go about building one? A data architect needs to consider ownership, latency, and transaction management to turn raw data into information - and ultimately knowledge.

You can find the article on-line here, and I have a copy of it here.