Let system administrators participate in projects

I have very good experiences in having system administrators participate in IT projects.

Usually an IT project is setup with only the required functionality in mind. To increase the chance of success, the scope of the project is limited. Very few projects incorporate in their project plans that the developed systems must be administrated as well.

Usually at the end of a project planning is stated “Go in Production”, and as far as the project is concerned this is the last step. Systems can be developed in one year, but will be in production for (dozens of) years. For all these years, they must be administrated.

There are expectations about performance, creating backups, failover in case of a disaster, solving incidents, etc. These expectations are seldom managed in advance by the project.

System administrators feel the new systems are “thrown over the wall” when the project ends, without having influence on how the systems are setup. It is therefore not strange that administrators resist the new system, and feel many of the problems with managing the system is the fault of the (already closed) project.

Therefore, I suggest to have system administrators participating in IT projects as early as possible. They can advise the project on the issues stated above, they know the production environment and can make implicit expectations from the project explicit.

My experience is that deliverables of a project are accepted and will go in production much easier when administrators have been working in the project.

An obvious disadvantage is that if administrators are participating in project, the administration of production systems could suffer. This has to be acknowledged and addressed by line management.

The 7 Habits of Highly Effective People

Dr. Stephen R. Covey is an organization advisor in Provo, Utah and the director of FranklinCovey. The 7 habits of Highly Effective People is Covey's bestselling book (15 million copies sold worldwide).

The book leads the reader to a better way of working and living in seven steps (habits). These seven habits are:  

• Be Proactive
• Begin with the End In Mind
• Put First Things First
• Think Win/Win
• Seek First to Understand, Then to be Understood
• Synergize
• Sharpen the saw

Each of these habits are of course well known and nothing new. Still, Covey's book is very inspiring and certainly worth reading (while on some points somewhat religious, as Mr. Covey is a very religious man). The seven habits are described extensively and Covey points out why it is important to develop your own 7 habits further.

The book contains many figures and models (like the famous circle of influence).  The power of the book is in the excellent examples and the way it inspires you to take action on the seven habits described.

Highly recommended.

Archimate

Archimate is a modeling language for IT architectures.

It was developed by Telin - The Telematics Institute in The Netherlands together with large companies and institutions like Capgemini, The Dutch Tax department, Getronics, Ordina, and several universities.

The Archimate language is mostly based on UML technologies. It is used to model architectures that span multiple domains. By using Archimate one can get a layered model of the business, with business- application and technology architectures in one picture. The main idea behind Archimate is that the impact of a disruption or a change in one architectural component will be reflected in other components, possibly on other layers. As an example, one can create what-if scenarios: What if we would phase out the mainframe? What components of our architecture would be affected?

The Archimate language relies heavily on a concept called Services. These services are not to be confused with the SOA services. Services in Archimate are mainly drawing techniques. The services are not necessarily implemented in software. An example of this can be seen here:

Every layer presents a service for the next layer.  

Several tools are available for modeling architectures using Archimate. The best known tools are BiZZdesign Architect , ARIS ArchiMate Modeler and Casewise Corporate Modeler. There are also (free) Visio templates available if you want to gain some experience in using the Archimate symbols. Here is a quick reference of the symbols used.

Archimate's value is to create a high-level model of an enterprise architecture.

When architectures are modeled with Archimate, The next step would be to model in more detail. This should be done using techniques most suitable for the specific domain. For instance, on the application domain architectures are best modeled in more detail using UML. Technical (infrastructure) models are usually drawn using Visio.

The board of the ArchiMate Foundation and the board of The Open Group have expressed their intentions to adopt ArchiMate as an independent standard for enterprise architecture modelling and analysis under the aegis of The Open Group. This will probably make Archimate a more international standard.

A meeting with John Zachman

Last week I met John Zachman. I wrote about Mr. Zachman and the Zachman model he created earlier.

Mr. Zachman gave the keynote speech on the EAM congress in The Netherlands for about 150 IT architects. The talk was about architecture, and why it is needed. Check here for the slides (push the right-hand button for the next slide).

According to Mr. Zachman, architecture is needed in any system (in IT or otherwise) that has much complexity and a need for change. The reason for this is that if you cannot describe a system, you cannot build it, let alone change it. For systems with low complexity, a architecture description is not always needed, a technical design is enough.

The most important skill an architect needs is what Mr. Zachman calls "drafting skills".

Next, Mr. Zachman explained the reasoning behind the Zachman architecture model. He calls the model an Ontology (no methodology), because it describes what needs to be done to create complex systems. The model was created after consulting many construction engineers, architects and other specialists.

Mr. Zachman pointed out that no one can get his brain around the complete architecture, so it has to be cut into pieces. As he stated: "creating for instance a data model is hard enough in its own right, let alone understanding the connection with interfaces, processes, strategy, etc.". When the architecture is cut into pieces, like it is done in the Zachman model, it can better cope with change.

It is a misconception that flexibility can be reached by creating higher granularity. Flexibility can only be created by separating independent variables, like it is done in the ISO networking stack.

Mr. Zachman is a gifted speaker who speaks faster and faster as he gets excited telling his story. He used old fashioned overhead foils instead of PowerPoint. After the talk I met him and talked about half an hour with him about my thoughts about the position of architecture, his family and his frequent travelling.