Nick Rozanski's Published Work

This page contains information on material I wrote or presented in the past. Refer to my new company website for more recent information.

Software Systems Architecture

See the architecture page for information on my architecture book.

Introduction to Object-Oriented JavaScript

OK, this is a bit of a cheat since it is not by me but by my son!

He has written a very good article on how to write object-oriented JavaScript. This is not as straightforward as you might think, since you have to define methods and variables at run time using prototypes, rather than using a static declarative syntax as you would in C++ or Java. Here's the introduction:

Many JavaScript programmers overlook or do not know of the ability to write object-oriented JavaScript. Whilst not conventionally an object-oriented language, JavaScript is a prototype-based language, which means that inherited classes are not derived directly from a base class, but rather are created by cloning the base class which serves as a prototype. This can be used to one's advantage in implementing encapsulation, inheritance and polymorphism in JavaScript, therefore creating a sense of object-orientation.

Object-oriented JavaScript also has several advantages. As it is an interpreted language, it means that methods and properties can be added to the class at any time, and do not have to be declared in the class constructor, like other object-oriented languages such as C++. As JavaScript supports variable data types, class properties do not have to take a fixed data type (such as boolean or string) but rather can be changed at any time. Furthermore, object-oriented JavaScript is more flexible and efficient than procedural JavaScript, as objects fully support encapsulation and inheritance and polymorphism can be implemented using the prototype property.

You can find the article on the Code Project website here. If you find it useful, you can vote for it here (free registration required).

SPA 2007 (Systems Continuity and Anti-Patterns of Project Execution)

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.

SPA2006 (Moving Beyond UML)

Article in Computing on Architecture vs. Design

I wrote an article in Computing discussing the differences between architecture and design. As the article concludes:

In my experience, the two roles [ IT architect and designer ] are equally valuable and important, but there is no common, accepted definition of them - especially the role of the architect. Because of this, large projects often end up with the wrong decisions being made at the wrong time by the wrong people - architectural decisions being made at design time by designers, or design decisions being made by architects much too early in the project lifecycle.

The most successful projects and IT departments employ both architects and designers working as peers, understanding the differences between them, and using them appropriately.

You can find the text of the article here.

There was an interesting follow-up letter in Computing talking about how the title 'architect' is protected in UK law. I've included the letter, and my response to it (edited extract below), in the downloaded file.

Without training, assessment, and professional oversight, I could not call myself doctor, engineer, or for that matter building architect. Why should IT be different? We may not kill people if we get it wrong, but poor IT decisions can affect thousands of people and cost millions.

Perhaps we should only call ourselves IT architects, designers, analysts, or programmers if we had proven competence and suitability, and would face professional sanctions for failing to maintain acceptable standards of conduct. This would be a major step forward in turning IT from an occupation, which it is today, into a profession, which I hope it will be one day.

InformIT Article on Software Architecture

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.

SPA 2005 ( Using Principles to Justify Architectural Decisions)

Eoin Woods and I presented at BCS SPA conference 2005. SPA2005 continues the 12-year tradition of the OT conferences by once again bringing together software development practitioners to share their latest thinking and develop new ideas.

The title of our talk was Held to Account: Using Principles to Explain and Justify Architectural Decisions. The session presented a simple but powerful technique to formally map business drivers through to architectural decisions by means of architectural principles. This tutorial will draw upon our real experiences of applying this technique on large programmes. Starting with a pre-prepared set of business drivers, we will over a couple of iterations turn these into a set of principles for an architectural design.

You can find more details here.

OT2004 (Viewpoints and Perspectives)

Data Management Conference 2003 (Large-Scale Package Implementations)

I gave a presentation at the Data Management and Information Quality Conferences Europe 2003 on 28 October 2003.

The subject of my talk was Effective Data Integration in Large-Scale Package Implementations and you can find more information here.

Here is the synopsis:

A common view of implementing package software in large organisations is that the largest part of the development effort is taken up with configuring and customising the software. Because this is a known and repeatable procedure, risks are low, timescales can be accurately predicted and the probability of a successful outcome is high.

In practice, this view could not be further from the truth. Virtually every package implementation programme brings with it two massive data architecture challenges: migration of your existing data and integration of your existing applications. This presentation will help you understand how to develop and validate an end-to-end information architecture model which encompasses your legacy systems, the new package, and the interfaces between them. It will also address a range of package implementation issues such as data quality and acceptance, heterogeneous systems management, resilience and recovery, and performance.

You can find a copy of this paper here.

Architecture Talk to BCS

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.

What Software Architects Can Learn from Building Architects

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.

Knowledge is Power

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.

Configuring Multi-Boot Personal Computers

It is possible (although not straightforward) to install several operating systems onto the same PC, each in its own partition, and select between these partitions at boot time. With some restrictions, it is possible to exchange information between them and even run cross-platform software.

This technical article addresses the first challenge, that is how to install, configure and manage a PC so that it can boot up into any of several different operating systems. The article discusses disk partitioning, the boot process, boot managers and file system sharing. Now updated for Windows 2000.

You can find it here.

Software Documentation

You can find documentation on my free software here: