With Infrastructure I mean all hardware, software and systems management needed to support IT applications. Infrastructure Architecture is the overall design of the complete IT infrastructure.

The book explains how infrastructure architecture works, the specific issues when designing and implementing IT infrastructures and how to address them. It provides practical solutions and examples for infrastructure architects and provides background information for IT managers, solution architects, system managers and others.

The book does not provide in-depth details on IT infrastructure components like servers, routers, switches and operating systems, nor does it explain details about protocols like TCP/IP, HTTP and other technical issues. Instead a more holistic view is chosen. All infrastructure components are described as one infrastructure ecosystem providing the fundament for applications running on it.

A short description of ITIL based systems management is provided, especially focused on managing the infrastructural parts of an IT system.

Infrastructures are complex by nature and provide many non- functional functions for building IT solutions on top of it. Non-functional attributes like performance, availability and security are key to a good infrastructure that provides the basis for running high performance, highly available and secure applications. Apart from these three most important attributes all other non-functional attributes of the ISO 9126 norm are described in this book, including tips on how to address them in an infrastructure design.

I found that there is no such nook available on the market today. Writing this book provides me with the opportunity to publish the knowledge and experience I have gained over the years. Apart from that much research is done to refresh my  knowledge and to get all details right. At this moment only 15% of the main text is finished, so I have a long way to go. I expect I need at least a year to finish the book, and probably more.

I am planning to publish parts of the books on this website, both to give you a sneak preview, and to invite you to reply to me on the published subjects and text. My email address is in the right hand column...

For those of you following me via an RSS feed, this means that you will see many posts yu have seen before.

My apologies for this. I hope the website works normal again from this moment.

Sjaak.

To become ITAC certified one has to create a so-called certification package. The certification package includes up to 50 pages and describes the experience of the architect. Here are some tips for completing the certification package:

• Take the Open Group "self-assessment test" to make sure you fulfill all conditions.
• Take your time. As a guideline for completing the certification package approximately 80 hours should be allocated. If this is done in addition to your regular work a lead time of several months is not uncommon.
• Make certain your costs are covered. By submitting the certification package a fee be paid, otherwise the certification package is not reviewed.
• Start with reading all questions in the template to get a picture of the amount of work to be done.
• Make a list of three projects in which most of the required experience is gained. These three projects are described in the certification package and can be referred to. If the project descriptions contain much information, much can be reused to avoid duplications of text in the certification package.
• Start by describing the three projects (in the last part of the document). Then enter the rest of the information in the document. This helps in getting the right mindset and you can refer to the text already described.
• Provide the requested credentials. Arrange with the clients at which you have implemented projects to have them send a letter (or an email) to explain that you really have completed the project successfully. Send them a standard text template stating exactly what The Open Group wants to hear and do not let them create their own text.
• Inform your client that The Open Group could verify the credentials. In my case they called at least 1 of my clients for a reference check!
• Check the length of your certification package. It's easy to write much and very difficult to limit yourself to 50 pages. Your certification package will not be accepted if it is 51 pages or more!

After completion of the certification package it can be submitted to The Open Group. The process is entirely via web forms. You need a credit card for the payment.

The Open Group certification board reviews your package and provides feedback. You (once) get the opportunity to re-submit your certification package. Use that opportunity to update the document with The Open Group's feedback - even if it only states some spelling errors.

After the final submission the document is reviewed again. When all is well you receive an invitation for the next certification board meeting. In this meeting you will be interviewed by three different people. The interviews (each 1 hour long) is a 1-on-1 interview assessing whether the claims in your certification package are trusted.

If all goes well you receive a notification of your certification. This can take up to 6 weeks after the interview. A few clicks on another web form will make you the next Master Certified IT Architect.

This link leads to a PowerPoint presentation from Terry Bahill of the Systems and Industrial Engineering department of the University of Arizona, on A Zachman Framework Populated with Baseball Models. To explain the Zachman Framework mr. Bahill uses baseball as an example to fill-in all cells in the framework. In the process he used scientific documentation to describe all aspects of baseball.

I think this is an excellent way to show how the Zachman Framework can be used in general, without going into an IT architecture discussion.

The EPIC is meant as a guideline for building systems based on Commercial Off The Shelf (COTS) components. The guideline describes the steps to be taken to create systems starting from four "spheres of influence". These spheres are:

• Stakeholder needs and business processes (requirements)
• Marketplace (what COTS technology is available)
• Architecture and Design (general setup of the system)
• Programmatic and risks (the management of the project)

The EPIC described a process to have these spheres overlap as much as possible creating a coherent system based on the Rational Unified Process (RUP). In the Inception and Elaboration phases the system is designed by accumulating knowledge about the four spheres leading to increased stakeholder buy-in.

The EPIC describes the steps to be taken to create a system, but I found the last part of the document (section C) the most interesting. In this section guidelines and artifacts are presented that can be used as checklists when actually creating systems. It presents for instance a market survey checklist describing the steps and questions one could ask to market parties about their COTS products and component screening criteria to evaluate COTS components. It even includes business process change management guidelines to check the readiness of the organization to work with COTS based solutions.

I found the EPIC very useful indeed and recommend it to anyone creating systems based on COTS products.