TOGAF 9 Templates

Here is a set of templates for TOGAF 9 deliverables, made publicly available on the website of the OpenGroup. It includes templates for:

• Architecture Definition Document
• Architecture Principles
• Architecture Vision
• Business Scenarios
• Request for Architecture Work
• Requirements Impact Assessment
• Statement of Architecture Work

It comes as a zipped set of Microsoft Word documents (doc and dot files).

TOGAF 9 Released

Last February 2 the Open Group finally announced their awaited release of TOGAF 9

Named key enhancements on this version are:

• how to apply on infrastructures like SOA and security architecture
• formalized definition of Enterprise Architecture
• modular structure
• guidelines for creating hierarchies of architectures within organizations

Critics point out the missed opportunity to integrate the efforts from the ArchiMate working group.

TOGAF 8 Certified

I just got from the OpenGroup the confirmation of my TOGAF 8 certification.

What about the Project Start Architecture (PSA)?

I notice increasing interest on the Project Start Architecture (PSA) artifact as more and more organizations enters the Enterprise Architecture arena. Unfortunately not everyone is on the same page concerning the usage of this document. As this keeps heating arguments in circles around me, I thought I would collect my thoughts on this subject.

The PSA, as I know it, is an architectural artifact of DyA, the enterprise architecture framework of Sogeti. They have made available a template as well as a whitepaper written by Joost Luijpers, but this is currently only available in Dutch.

The document can be divided in two main parts. The first one identifies those pieces of the reference architecture that are relevant to the project by the time it starts. This imposes an architectural framework to the project team. It is important to notice that this part of the PSA can not be modified during the project. Constrasting with that, the second part of the PSA ussually will be amended in the course of the project. In this one we record two different kinds of information. First we put there design decisions made by the project team within the limits of the PSA (conform the enterprise architecture) if they are candidates for standardization. Next we also record there agreed deviations from the framework imposed by the PSA. That’s it. The PSA contains no more and no less.

Where I see people frequently go wrong with the PSA is by recording project specific design decisions on it. In fact they (ab)use the PSA as a replacement for the software architecture document (SAD).

Maybe a good deal of the confusion derives from an "unfortunate" selection of the name of the role responsible for creating and updating the PSA. In DyA this role is called the project architect. But that’s also the name of the role for the lead designer within the project team for many development methodologies (like RUP). What DyA really means is the enterprise architect assigned to the project. But I can understand why.

TOGAF vs RUP Architecture?

There's a great deal of interest today on the subject of Architecture. But not everyone is meaning the same by that term! Even within large IT organizations embracing open methodologies such as RUP and TOGAF there's lots of discussion and misconception about this issue.

I recently got to an ah-ha point on this, partly due to a discussion at the Application Architecture masterclass I'm doing, but also thanks to this article from Vitalie Temneco (from which I have also temporally borrowed a couple of great pictures bellow).

As I currently look at it, the major differences can be summarized like this:

	RUP	TOGAF
Level	Software Architecture	Enterprise Architecture
Scope	A Project	The Enterprise
Purpose	Timely and effective delivery of software	Realization of the business vision
Artifacts	Vision Uses Cases Non-Functional Requierments Software Architecture Document	Architecture Vision Business Architecture Data Architecture Technology Architecture Architecture Contract
Application Architecture	The internal structure of the system determined by its components and their inter-relationships	The collection of applications that work together to realize the enterprise vision

Looking clossely it is clear where the RUP and TOGAF lifecycles actually overlap!

The point where the TOGAF process intercepts RUP is at the begining of phase F, when enterprise architecture artifacts are handed over to RUP implementation teams. This is completed when both parties agree on the scope of the implementation in the form of the Architecture Contracts in phase G.

Next picture shows the actual flow of artifacts crossing from the TOGAF to the RUP domain.