Ah! The post Christmas slump. In the final run-up to Christmas Day there were the usual stories in the press and in the news about the commercial side of things. Black Friday, Panic Saturday…
Every day of the week must have its own adjective based on the degree to which people are rushing to buy last minute gifts.
Of course, as well as all the commercial aspects of feasting, drinking, visiting and present giving, there is the celebration of the birth of Jesus Christ. This dichotomy – between the spiritual and the commercial – got me thinking about the connection between TOGAF and EA. You’re probably thinking that I must be crazy, and that there can’t be any connection between Christmas and TOGAF… and there isn’t a direct link. So what’s my point?
Well, TOGAF has become a de-facto “standard” approach to EA. This is partly because there are few international organizations with the infrastructure to establish a new discipline, such as enterprise architecture. And partly because there wasn’t a single agreed approach to enterprise architecture until TOGAF came upon the scene. So TOGAF filled a great need, and although it isn’t perfect it does this job quite well.
But we shouldn’t forget that TOGAF is about Enterprise Architecture. TOGAF and Enterprise Architecture are not equivalents. TOGAF does not cover everything in Enterprise Architecture. Just as Christmas is a time for celebration, commercialism and Christianity. Without enterprise architecture there would be no TOGAF, but without TOGAF, enterprise architectures would still exist and we would still be using our skills and experience to make changes to them.
Why is it Important to Remember This Distinction?
- Well it certainly causes problems if we teach TOGAF without placing it in the broader EA context. TOGAF is better in some areas than others: the ADM is a pretty good overview of the generic process for developing architectures; the Enterprise Continuum is a highly relevant concept, but its practical value is often glossed over…So when I refer to TOGAF, it’s helpful to explain any limitations through practical case studies and examples from the real life EA.
- It’s also important to remember that something like TOGAF is going to lag behind the latest thinking and practice. Some estimates would say that TOGAF represents EA practice as it was ten years ago!For example, several of the example artefacts in TOGAF come from IT disciplines such as information engineering or object oriented programming, which do not necessarily highlight the architectural characteristics or attributes of components.
- And it’s also important to remember that TOGAF is going to work better within an enterprise if it fits with other disciplines, approaches and methods. Some of the key ones include strategy planning, business management, business process modelling, IT development, program and project management, and change management…But within any enterprise there could be a vast range of more specialized disciplines, such as Six Sigma, Lean, TQM, ITIL, or COBIT. Again – a focus on TOGAF alone does not provide this broader context.
Of course it’s important to remember that many students simply want to gain the TOGAF certification, and that is a perfectly valid goal. But getting certified without understanding something of the bigger EA picture won’t adequately prepare TOGAF graduates for the practicalities of real life EA….
Which brings me back to my comparison between TOGAF and Christmas. Enterprise Architecture takes place in the mad, chaotic, complex, frantic, political context that is a vibrant enterprise. It is not just the neat, contained, documented approach described in the TOGAF documentation.
