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)
SPA2006 (Moving Beyond UML)
Eoin Woods and I ran a workshop at the BCS SPA conference 2006 in March 2006, called Describing Information Systems: Moving Beyond UML.
This arose from our continuing frustration with trying to use UML (which is primarily an object-oriented software design notation) to describe software architectures. During the workshop we attempted to identify the key requirements of a language for describing software architectures, and consider how (or if) UML is lacking as a solution to them. Our audience then attempted to improve on UML by sketching their own visual language for defining software architectures.
You can find more details here.
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
SPA 2005 ( Using Principles to Justify Architectural Decisions)
OT2004 (Viewpoints and Perspectives)
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.
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
What Software Architects Can Learn from Building Architects
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.