I discovered TOGAF some times ago, and it has sounded to me as a revelation: a new insight on how to build and maintain a sustainable Information Systems (IS). Sustainable here means a way to survive with minimal effort.
Wait… I’m not saying that TOGAF brings off-the-shelf solutions, I dare even say that it doesn’t ;)
TOGAF doesn’t say what to put into the IS nor how to get it. But taken as a meta-solution to the Architecture question, which is the key point for sustainability matters, TOGAF brings a very decent way to deal with the core IS life-cycle question: how to organize a sustainable (thus living) architectural foundation?
I view TOGAF as a kind of new way of organizing democracy around the IS. Given business requirements, TOGAF induces a way to organize the collective process of building or improving the IS Architecture. The ADM (Architecture Development Method) cycle takes also into account existing constraints. This is an absolute condition to sustainability since each business and IT stakeholder takes part into the decisions cycle.
TOGAF just let me think about how Agile (= democracy) entered the IS/IT field some decades ago, and now Agile applies to Architecture! We could even say that this Agile way also includes DevOps’s concern as IT people are around the table in the Technology Architecture phase while Dev people are there too during the Implementation Governance phase.
White box approach
I also view TOGAF as a white box tool kit: TOGAF gives a complete Architecture life-cycle canvas but also provides a Preliminary phase whose aim is to… customize the life-cycle. It seems perfectly clear that nobody is intended to learn and apply the 692 pages making TOGAF 9.1. However we can for sure find answers in it if we lack some. And even more, when knowing that TOGAF contributors do not pretend to have reinvented the wheel, TOGAF is clearly a compilation of best practices. And that is its real strength.
On another hand, I don’t see much practical value in the Reference Models parts of TOGAF. Nor in Archimate, a new notation aiming to help modeling Enterprise Architecture. It’s not that these contributions are not good as themselves, it’s just that I think what we need most is just to speak altogether about Architecture. In a Lean way: the less we put artificial descriptive artifacts better, faster and further we go. We certainly need some artifacts to persist Architectural ideas, and models may do that, but they should be as simple as possible (and not simpler): the NoUML trend may probably help efficiently for that.
There is one thing though that let me still unsatisfied in TOGAF. Enterprise Architecture clearly embraces other matters than the sole IS, even if the IS is clearly an essential piece of the Business Execution capacity.
TOGAF may help to build an IS Architecture that complies to requirements but as stated in page 70 of the main TOGAF 9.1 document: “Normally, the business principles, business goals, and strategic drivers of the organization are already defined elsewhere in the enterprise”.
Normally, the business principles, business goals, and strategic drivers of the organization are already defined elsewhere in the enterprise.
That means, without any doubt, that TOGAF does not address this fundamental question directly. By the way, TOGAF doesn’t neither provide a detailed way to manage requirements. Even if focus on requirements is a central concern in the TOGAF approach.
On second mind, I think that it is better this way. I hope TOGAF won’t develop any more. In France we are used to say: “Qui trop embrasse, mal étreint” (Grasp all, lose all).
On Enterprise Architecture, I read a terrific book: “Enterprise Architecture As Strategy”, by J.W.Ross, P. Weill and D.C.Robertson. Probably my best professional reading since 20 years. This book tells exactly what Enterprise Architecture is: EA is the way the Enterprise, and thus its IS but not only, is organized to ensure business plan execution.
EA is “A Foundation for Business Execution”
And I take the opportunity to thank the guy at Arismore who recommended this reading to me :)
Featured image borrowed to http://www.josebaldaia.com/intuinovare/uncategorized-en/team-roles-innovator-motivator-and-networker/?lang=en.
Doing Architecture is like preparing a big collective jump: when on air it will be too late to think about how things ought to have been prepared :-P