Zachman architecture model
20 April 07 - 00:00
Area: default -
Link to this article
In 1987 John Zachman created a model for describing enterprise architectures. The Zachman model is a classic under the architecture models, and one of the first.
A picture of the model can be found here (PDF file).
The model has 6 basic questions (What, How, Were, Who, When and Why) that can be asked to 5 stakeholders (Planner, Owner, Designer, Builder and Subcontractor). This gives a matrix with 30 cells.
The answers to the questions give a general overview of an enterprise architecture. The final architecture description can be based on these answers.
A complete description of all cells can be found here (PDF file).
A problem with the model is that it can create a large amount of paper, when everything is described in full detail. Furthermore, the model is mainly meant for architects, and not very suited for end-users, developers or management.
Zachman describes no method for filling in the matrix. TOGAF (The Open Group Architecture Framework) has an Architecture Development Method (ADM) that can be used for this.
The Zachman model is originally created when John Zachman worked for IBM (He is retired now), and IBM has put the framework in the public domain. Therefore no license is needed for using the model.
High Availability clusters
06 April 07 - 00:00
Area: default -
Link to this article
On operating system level, two cluster architectures exist: High Performance clusters and High Availability clusters. This article describes high availability clusters.
High availability clusters are groups of computers (nodes in a cluster) that can failover applications in case one of the computers fails.
Cluster software
Special clustering software is needed to setup an high availability cluster. The most popular choices for operating systems are:
This software is used to let applications running on a node in a cluster failover to another node as fast as possible. The software periodically (for instance every minute) checks if the application on a node still works as expected. If the application fails, a failover is initiated: the application is stopped on the failed node (if this is still possible), and restarted on another node in the cluster.
The intention is to have minimal interruptions for the end-users, so they can continue to work as if nothing happened.
Cluster-aware applications
The above description is used for cluster- unaware applications. The applications don't know they are running on a cluster. There are also cluster-aware applications.
An example of a cluster-aware application is Oracle RAC (Real Application Cluster). This way Oracle can run on multiple nodes at the same time, and can cope with node-failures. The end-users will not know a node failed (they might experience some reduced performance though).
Testing
It is crucial for High Availability Clusters to have them tested regularly.
I have experience with a 2-node HP-UX Serviceguard cluster, that was setup correctly once, but was never tested since. Everyone assumed the cluster would perform a correct failover in case of a node failure. But when after some years a node actually failed, the cluster did not function. A considerable amount of downtime was the result.
This could have been prevented if the cluster was tested a few times per year.
There is also a 
Master Certified IT Architect
CISSP (Certified Information Systems Security Professional)
TOGAF Certified Architect