TOGAF 9 - What's new?

TOGAF 9 will be formally presented at the Open Group conference in San Diego at 2-4 February 2009. Today I received my pre-ordered TOGAF 9 book. Strange. TOGAF 9 is not published on the Open Group site yet, and Amazon seems not to sell it either yet. I got the book here by the way.

TOGAF 9 is the latest version of the TOGAF framework. The previous version was 8.1.1. The new version is not much different from the 8.1.1 version, but is more evolutioned, modernized (TOGAF 8.1.1 was published in 2006) and elaborated.

Parts of the book seem to be a bit re-arranged from the previous one. I think some topics are on on more logical places. many pictures are new with a refreshed look and the overall feeling is that the book is more easily readable because of a new letter front and better graphics.

TOGAF 9 also describes more topics, like security architecture and SOA. It also elaborates much more on the topics than TOGAF 8.1.1. There is a good glossary of terms (in TOGAF 8.1.1 building blocks were used without any explanation on what they were, the same goes for for instance the Enterprise Continuum and boundaryless information flow) and a better introduction. In general more attention was given to business issues and business alignment.

The iteration of the ADM is better described as is the use and implementation of the ADM in the different domains. Risk management, capability based planning and architecture partitioning are more elaborated and enriched with lots of pictures that can be used when implementing these subjects in businesses.

The book is now a whopping 744 pages long (the 8.1.1 version was 508 pages). It is a good reference guide with lots of tips, templates and checklists on Enterprise Architecture and helps architects to better implement TOGAF in enterprises. I highly recommend the book.

Stakeholders for technical architecture

At a recent assignment I had a discussion with a colleague about who is the main stakeholder of a technical architecture. We came to the conclusion that there was only one real stakeholder: the system manager(s).

In the discussion many stakeholders were mentioned, like the end user and business management. But because the discussion was about technical architecture only, we found that the end user and management would not be interested in the technical architecture of the system at all. If they would want something new from the system or if they had complaints about the performance, availability or any other non-functional requirement, they would ask their system managers.

The system managers would then translate the demands of the users and managers to technical demands and would end up with the technical architects to find and create a solution.  

If the technical architecture of a system is created correctly when the system is designed, the future demands of the system managers are easier to realize than when the system was not created on top of a good architecture. If the system is created to be scalable, future demands on performance are easier to implement. If the system is setup with solid redundancy in mind, future demands on availability are easier to comply to.

Therefore, during creation and exploitation of a new system, the systems managers are the main stakeholder of a good technical architecture.

DYA: Development without architecture

I come across it regularly: Organisations implement a new service or application under high time-pressure.

Products or services need to be on the market fast, before the competition does (for instance in the telecoms sector), or some law is approved by the government which leads to a short-term change in applications (for instance in the Insurance business).

The problem here is that the application or service is built fast, but it does not comply to the company's architecture, or it does not comply with the security policy.

After the application or service is deployed, it takes much effort to manage the service. The extra cost of  managing this non-compliant service can be very high and will be apparent for many years after the original deployment. Also, the new service could introduce security issues that need to be solved later. Furthermore, the connectivity to other systems might be difficult or not rubust, because the other systems do comply to the architecture.

A solution for this problem is introduced in the DYA architecture method.

In DYA, one can choose to develop a project under architecture, or perform development without architecture. Systems that have to be introduced fast, don't have to comply to the architecture of the company. However, after the system is deployed, the development team is committed to start a new development cycle for the same system, but now developed under architecture. This second development cycle can take all the time it needs to develop the system using the normal architectural guidelines and principles.

A nice model.

I have never seen this working in practice. When a solution is in production, it is seldom replaced, just to comply to the architecture. Temporarily solutions usually remain permanent. On the short term the new development under architecture costs money, time and manpower, and it will deliver value only in the long run (mostly system admin costs). Usually system administration is on a different budget than the projects.

The only possibility I see is that the architecture must be followed always. When a project wants to circumvent the architecture, it can only do it if the cost or re-development under architecture is budgeted at the start of the project, and is an integral part of the total cost of the project. This way the cost of developing without architecture is known to the stakeholders of the project in advance. It makes it possible to make a balanced decision if the additional cost for de-development are worth the fast delivery of the service or application.

Obviously this only works if working under architecture is thoroughly embedded in the organisation (the so-called architectural governance), and has enough mandate from higher management.