Home Authors Posts by Roger Evernden
Browse All Posts By: Roger Evernden
In this TOGAF blog we discuss the 7 habits of any highly successful Enterprise Architects
Read this TOGAF blog: 'TOGAF: What's the Difference Between Scope and Partition?' to better understand the criteria of both scope and partion in the TOGAF framework.
In this case study we examine the three types of gaps in enterprise architecture and how to manage transition from Current to target Architectures.
Both TOGAF and ArchiMate have been developed by The Open Group. TOGAF describes the process of developing an enterprise architecture and ArchiMate is a modeling language which compliments TOGAF. This blog outlines the difference between these standards.
Well it turns out that some of the billboard headlines for TOGAF are the same: TOGAF is billed as the cure for all enterprise woes, as the silver bullet for IT development, or the one-stop solution for cutting costs and simplifying infrastructures. But when you get a bit more inquisitive it turns out that although it could be the answer everyone’s been looking for, it is actually just one of many new management ideas that require a lot of effort if they are to be successful.
There are some things in TOGAF that confuse practitioners over and over. The difference between scope and partition is one of those confusions that comes up as a regular question. In this blog we explain the key differences, and explain why TOGAF can be confusing.
When we focus on teaching and learning TOGAF we sometimes forget that TOGAF is just one aspect of enterprise architecture in general. This blog explains why we need to remember that TOGAF is part of EA, but EA is more than TOGAF.
For some companies, the New Year coincides with the start of their planning year, and there are still many companies that go through an annual reorganization of the management structure charts. In any case, New Year is a good time to take stock and think about the future - so here are my recommendations for using TOGAF as your guide.
TOGAF is largely about identifying and documenting architecture requirements... but what is an Architectural Requirement? Frequently we document requirements, not "architecture" requirements! In this blog I explain what we need to do to make requirements architectural.
Architects sometimes see the ADM as reactive, but EA should never be passive - it needs to respond to concerns, but add architectural thinking and then make a unique contribution to stakeholder needs. This blog explains some of the proactive aspects of ADM that are not so obvious.