TOGAF Demystification Series: TOGAF Sucks, Incomplete and Overly Complex

True or false

Do I have your attention now?

Given this is the first post of the series about the myths, misconceptions, fiction and even some facts  behind TOGAF I want to be open and honest about my affiliation with the Open Group. I do have personal affiliations with the Open Group. Like many others, I am certified as an Open CA Distinguished Chief Architect, I have participated in the Architecture Forum building out TOGAF v-Next and I speak at their conferences. However, I am not financially or otherwise compensated by The Open Group. My interest is my own and to evolve the EA discipline. 

Now let’s get into it.

So just to set the record straight, I don’t believe that TOGAF sucks. Quite the opposite. Does it need work, yes. Are there areas in which I would do something different, yes. But like anything else I think it’s a work in progress but thats no different than anything in the EA space. 

This generalization of TOGAF not living up to the right level on the quality bar can be found all over the place (e.g., Linkedin, Twitter, blogs and even in competing training organizations) . To be perfectly honest it seems like people either love or hate TOGAF. But why is this the case? Surely with such a pervasive complaint there is merit behind it, right? Well with this one, yes and no. But we need to decompose this into three areas to first.

  1. TOGAF You Suck
  2. TOGAF is incomplete
  3. TOGAF is Overly Complex 


TOGAF You Suck

Wow, what a generalization. Many things might come to your head when referring to something “sucking’ (and yes that’s the technical term). Here are the common complaints:

  • Missing core elements
  • Hard to understand
  • It’s so long
  • Too Academic

I’m not going to address these items specifically as I will talk about them in later posts or refer back to them directly and indirectly. I would much rather take a step back and look at the macro point here. I’ll do so by telling a story about my own experiences and a negative perception that I had on TOGAF. 

So this story dates back to the mid 2000’s when I was still very skeptical of TOGAF and the industry was even more disjointed than now. I had used elements of TOGAF and had done a deep analysis of the framework. I looks at what a good framework and methodology should have along with the practicalities of applying to my company at that time. 

I went to the Open Group Architecture Practitioners Conference and sat through the TOGAF 101 pre-conference seminar (for the second time) and jotted down notes with all the gaps I had identified. I was thinking, “I can’t believe they didn’t think about that”, “what about [xxxx]?”, “that would never work…”

I wasn’t the only one with similar thoughts. At that time TOGAF was on version 8 and was still very IT focused. So that added fuel to the fire as well. 

Being the not so shy guy that I am I confronted a very senior member of the Open Group staff and had a very passionate conversation with them about my thoughts. This turned into a multiple hour conversation over drinks (thankfully for him) in which I proceeded to tell him my thoughts: “Let me tell you about this…”, “don’t you know you have a gap here?”, “I could never apply this…”

As the conversation progressed, most of my feedback was received quite well, even a great deal of agreement on what my view was. But at the end of what might of seemed like the Spanish Inquisition  for him, he simply replied back to me:

Those are all great ideas, why aren’t you participating to apply those changes?

He then proceeded with the statement that the Open Group itself doesn’t write a single line in TOGAF, it’s member companies do.

That was the ah-ha moment for me… A whole new perspective arose. It’ an important distention to keep in mind. It also reenforces an open source feel for EA once you understand that. I have personally been able to influence the standard, just in one meeting. If what you have is really compelling for the practice then donate it to the greater good. I see a lot of folks trying to monetize this and that causes further disruption in the practice. 

The Open Group provides a forum / platform / stage (or whatever you want to call it) for collecting industry consensus on what an Enterprise Architecture Framework should be. This isn’t to say that the current participants in the Architecture Forum  “suck”, but maybe there isn’t enough people participating or enough challenging of the status quo.

So I’ll leave this final thought on the topic…

If TOGAF sucks, aren’t we to blame? 


TOGAF is Incomplete

This is one I hear quite a bit as well. For me, this is a push (both true and false). 

Let’s start with the true piece. I think it’s fair to say that there are components that are missing from TOGAF. I will also say that there are elements of the method that could be enhanced. A great example of this is the Business Architecture phase. 

However, this is misleading. This gets us to the false aspect of this. TOGAF was built to be a general purpose platform that is extended. The intent of TOGAF is not to create all those modules (necessarily). At the beginning of most phases the first step is to establish what methods, models and tools you will use in that phase. There is a general “happy path” provided in the method along with some diagrams, matrices and catalogs. However, it is expected for the EA to know what to plug into the method, even if it is not TOGAF (which is recommended by the method). 

For many aspects TOGAF links out to other frameworks. This is a very good thing. If something works, don’t break, change, reinvent it. This happens so much in our industry. There is a level of humbleness about the approach that wants to create unity in the EA space. 

With all of this said, I think TOGAF provides a solid foundation. I would like to see more in the “Core” framework to fill those holes that are there, and there are many. That’s ok, in my honest opinion, TOGAF is the best universal general purpose EA framework out there that has the strength of the top 5 high-tech companies with a ton of passionate people behind it. It is a defacto standard for our practice with a ground swell of certified practitioners. 


TOGAF is Overly Complex

My first response to this is… What part of enterprise architecture isn’t complex. Of course EA is complex. If it was easy we would’t need it. There is a great deal of rigor and skill need to architect for enterprises. So let’s separate out two issues:

  1. Is the practice of enterprise architecture complex?
  2. Should the customers / consumers of an enterprise architecture framework be complex?

In the case is the EA practice complex, as I stated above, of course it is. Given that’s the case expect to see complexities in the framework. I think that is OK.

 However, to the second point with the consumption of framework I tend to agree that it is difficult (for some people) to consume TOGAF without formal training. I do think there are things that can be done to make TOGAF more consumable. But I don’t think that it has unnecessary components to it. I think TOGAF is more at the optimization stage rather than re-engineer stage.

For example, I have a dozen or so of my staff reading TOGAF as a study group. I find myself clarifying aspects of the standard quite a bit. Some of this is purely structural of the content, conflicts in terminology (for example the fully loaded term”capability”)  and the nuances in the intent of TOGAF. 

The second area in the complexity area is less about complexity and more about the sheer volume of pages in the standard. This comes to the degree where people refer to the book or online version as  the TOGAF Bible or the 900 page gorilla. This is where I get conflicted in my response because this statement is usually from the same folks that say that there isn’t enough in TOGAF. 

Is this a deal breaker for the usage of TOGAF? No.

The good news is that the members the Architecture Forum (where the TOGAF standard is created) already know this. We see evidence of simplification of TOGAF with 9.1. TOGAF 9.1 was a point release to address inconsistencies, duplications and other areas that these very issues. In TOGAF v-Next I would expect you to see a major update that would keep this in mind too. 


So what is the conclusion here? Does TOGAF “Suck”? Simply put, I don’t think so. 

I walked us through some of the common things I hear when people say TOGAF is no good or “Sucks”. Just like with anything I there is certainly work that needs to be done with the standard. However, it is clear that TOGAF has all the essential elements that you would want from an EA framework:

  • Open (Source) Standard Enterprise Architecture Framework that is driven by practitioners
  • TOGAF is MEMBER driven based in industry consensus
  • Industry standards setters on proven practices NOT to foster trends or fads
  • TOGAF is a general purpose framework that is built to apply to all companies of all sizes, in different industries,  supporting any organizational model and maturity of EA.
  • It has a method and a framework
  • Continually evolves and adds to the standard. A great example of this is architecture modeling with ArchiMate. 
  • Serves to partner rather than duplicate other standards. We see this with the better together materials on Zachman, TMFourm and SABSA to name a few.

It’s not perfect but I will go back to what are you doing to make it better. This is your call to action!

For the creators of “-AF” frameworks

  • Stop creating duplicate methods that are essentially or close to the same as TOGAF
  • Take the methods that would complement TOGAF and give back to the community. If you’re a consulting firm, take a page out of the IBM playbook. They donate a great deal methods and models that are common for everyone and the thing that differnates them (special sauce). That shows the industry that they are the leader and setting the standard. 
  • Before commenting on how bad TOGAF is, get trained in it (ideally certified). To protect the guilty I’ll omit names. I have sat in on training courses on other frameworks and I hear comments made about TOGAF that are just plain wrong. I have a problem with that as a practitioner. This send false information to EA’s which ultimately hurt our profession. STOP IT!

For the practitioners 

  • Ask yourself what are you doing to advance the profession and what you can do if you’re not.
  • Join an Open Group forum or workgroup
  • Take a step back and look at the broader industry. Take a look at another area such as Service Management with ITIL or Program Management with PMI and contrast it with the TOGAF approach. 
  • Get your colleges involved.

0 thoughts on “TOGAF Demystification Series: TOGAF Sucks, Incomplete and Overly Complex”

  1. Very much agree. It is important to reflect on the “questions” (quoted because the first one is indeed too much of a generalisation) because any effort to work on a framework or a standards body will elicit these responses.
    A problem with any body of knowledge is the path to mastery. This is a human cognitive process which requires not only deep knowledge but also a lot of feedback from practice. In the meanwhile the framework evolves and we always feel as if we are running behind a snowball rolling down a mountain slope deep in snow. The developers of the framework need to be aware of this, and “pause” from time to time, to give heuristics time to catch up, and to give practitioners time to “ingrain” the knowledge and master it.
    Mastery shows more in knowing what *not* to apply from a framework. It is the novice’s mark to attempt to use it all, or as much as might be needed. We need more “masters” exemplifying this.


  2. @RobVens: Thanks for taking the time to comment Rob.
    I like that comment a lot. Reminds me of the Tuckman Forming – Storming – Norming – Performing model. IMO EA as a discipline (overall, not just looking at TOGAF) is still in the Storming stage with many different ideas competing for consideration and adoption. TOGAF is more in the Norming. However, that storming of the industry certainly impacts the standard, what gets built further, etc.
    I think no matter what change is going to happen. TOGAF has a conservative release cycle of 3 to 4 years between each version. The next version may be closer to 4 years. Personally I believe that if you are a member of the Open Group it is incumbent upon you the seasoned expert in EA to understand and plan for the change management proactively to address the People, Process and Technology change that will need to occur. There is no doubt that I think some of this burden should be in the TOGAF standard as a way to elevate EAs to the latest standard.
    Thanks again and great points!


  3. @Chris Detzel: Chris from Forrester Research responded to this post on LinkedIn ( Thank you Chris for your insights here. See his response and then mine.
    “Mike, looks like a great series about TOGAF and Open Group. I work with a lot of EA Leaders and believe that TOGAF is a great tool for these leaders to use and guide them, but I think they should tailor to organization needs and their EA practice. There is a lot of stuff in there that an EA Practice will not be able to get to. I think it’s a good way of getting folks to think the same ways. In saying that, I hear way more EA Leaders using a framework like TOGAF more than any other framework out there. Right now, it’s the most evangelized and sought after certification out there in the US. I’m not saying that it should or shouldn’t be, but I think some EA’s focus too much on a Framework.”
    My response:
    @Chris Thanks for commenting. This is great info to share with the community. When I was in an advisory role for Microsoft I would talk to Chief Architects, CIOs and other senior roles and this was consistent. What was the real tipping point for me was when we would see RFPs for EAs that instructed the should be TOGAF certified. These weren’t the exception but was a healthy percentage of the requests.
    I agree with you on tailoring TOGAF. I alluded to that as well but could of made it a bit more clear. I might have to make it more clear in another post. I like to think of you “configuring” TOGAF rather than customizing it.


  4. Mike, you asked
    “If TOGAF sucks, aren’t we to blame?”
    You have not proved that TOGAF does not suck. That we are to blame for accepting something that sucks is a different matter. There are explanations.
    People usually, prefer to use the frameworks coming from reputed firms or open fora because they believe that there are less chances to suck. And they would readily adopt them because not everybody wants to define own EA and its framework, again and again. They just need to deliver EA not to re-invent it.
    Besides people claim they do TOGAF because employers demand it now. And TOGAF does not easily vanish because it makes profit for too many today.
    TOGAF has not acknowledged or integrated frameworks like Zachman, concepts like business and operating models… So much about its openness to change.
    that “TOGAF is incomplete”
    TOGAF ADM is a solution rather than EA development process. It just tell us the phases of a process that those with experience know better. That’s why it talks endlessly about requirements rather than strategy, roadmaps… and business or operating models for that matter.
    TOGAF is not the modeling framework we all need, either because it does not tell us how to put the parts together in the whole.
    On top, TOGAF is IT. And is not even integrated with Archimate.
    I would say that “incomplete” is not strong enough.
    that “TOGAF is not complex”.
    Its content is not, the form is though. It’s simply a too large, unstructured, not integrated collection of views coming from various work groups. How do you find an item when you need it? The only thing hard to understand is what to use, how and where is it in that tome. And how does one reconcile all those conflicting or overlapping definitions? They did not even bother to align definitions. There are surely, good bits but how do you find them in that lot?
    The reality is that most of us do the training and certification but don’t use TOGAF in practice if you watch what they say in discussion groups. Except bits and pieces.
    To me you either do TOGAF or EA. At the end of the day, the firms lose though.
    See this too:


  5. @AdrianGrigoriu : Thanks for taking the time to comment. I can’t say that I agree with most of your feedback but I do thank you for establishing the conversation.
    To be perfectly honest I find a great deal of the feedback to be extremely high-level, abstract, uninformed and conjecture. To my point in the post, if folks don’t like TOGAF….
    Why are you not participating in making it better.
    You have written a number of articles about why TOGAF Sucks, I challenge you to focus your efforts and make the standard better. Take the time and energy spent talking about why it is wrong and be proactive to really move the needle forward for our industry. With all the bashing out there it just creates more fragmentation of our profession. This is not good for any of us.
    Every point you made below you have the ability to influence. If it comes down to your company wont sponsor membership, I’ll partner with you to propose your feedback into the Architecture Forum for consideration and provide you full attribution. Just let me know how I can help.
    ———— Feedback on your comments ————-
    “People usually, prefer to use the frameworks coming from reputed firms or open fora because they believe that there are less chances to suck. And they would readily adopt them because not everybody wants to define own EA and its framework, again and again. They just need to deliver EA not to re-invent it.”
    [Mike Walker] Agree, that’s what standards bodies are for. They should take the collective wisdom of the industry and still it down to reusable framework, method, components, etc. This is no different than any other industry known to man.
    “Besides people claim they do TOGAF because employers demand it now. And TOGAF does not easily vanish because it makes profit for too many today.”
    [Mike Walker] I’m not convinced that employers are demanding TOGAF. I think that is a strong position. What I do believe is that EA organizations have standardized on some EA framework. That part could be a mandate, and frankly that’s a good thing (whether that is TOGAF or something else). As far as TOGAF is concerned, like you said above, if I am a business person I will go to the standards bodies first. No need to re-invent what the industry has already defined. That’s just good business sense.
    “TOGAF has not acknowledged or integrated frameworks like Zachman, concepts like business and operating models… So much about its openness to change.”
    [Mike Walker] This is clearly not true. I will reiterate my position in this post. Do the research, it’s a simple google search to find, on the Open Group website these mappings. See below:
    Zachman –
    SABSA –®-sabsa®-secure-architecture-methodology
    DODAF –
    COBIT – Part 1: Part 2:
    TMForum Framworx –®-and-frameworx/
    C4ISR Architecture Framework –
    CORBA –
    Enterprise Architecture Planning (EAP) –
    Federal Enterprise Architecture: Practical Guide –
    FEAF –
    ISO/IEC TR 14252 (IEEE Std 1003.0) –
    NCR Enterprise Architecture Framework –
    ISO RM-ODP –
    SPIRIT Platform Blueprint Issue 3.0 –
    TAFIM –
    TEAF –
    “TOGAF ADM is a solution rather than EA development process. It just tell us the phases of a process that those with experience know better. That’s why it talks endlessly about requirements rather than strategy, roadmaps… and business or operating models for that matter. ”
    [Mike Walker] I don’t follow this at all. You will have to explain this a better to help me understand why you don’t think the TOGAF is an EA process. Your can orchestrate the ADM in the context of building a strategy. I’ve done this many times in partnership with business leadership. You can also find guidance for this as well. So I don’t buy this at all.
    With your second statement around the references to strategy, I would take another look. Strategy is referenced throughout the ADM. Specifically in the places you would expect, Preliminary, Vision and Business Architecture. Quoted directly from the first chapter of TOGAF:
    “The purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.”
    WRT Roadmaps, there is an entire phase dedicated to that. Check out Phase F. The very first object is to:
    “Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan”
    WRT Business and Operating Models, yes they are not “explicitly” called out. But there not supposed to be. The very first step in B – D is to select appropriate reference models. Thats where these would plug in. It’s that simple. Would I like for these to be incorporated into the core, possibly. We have to ask ourselves if this applies to everyone or just a select few at a certain maturity level. That is for a larger forum to decide.
    “TOGAF is not the modeling framework we all need, either because it does not tell us how to put the parts together in the whole.
    On top, TOGAF is IT. And is not even integrated with Archimate.
    I would say that “incomplete” is not strong enough.”
    [Mike Walker] TOGAF isn’t supposed to be a modeling framework. EA isn’t modeling. Modeling is a means to an end.
    WRT TOGAF is IT. You’re going to have to explain that a bit more. An untrained person looking at the ADM may think that but many certified TOGAF professionals use it for true EA. Like myself, I’ve used this for EA not EITA.
    WRT modeling and ArchiMate: They are closer than you think. Check out this article from Serge Thorn:
    Also let’s be fair to a recent merging of these two. This is just like with any M&A. It takes time to bring them together. I have no doubt that will happen. If you want more information and why I’m so confident, join the Open Group and participate in the forums and you will see for yourself. I don’t think it’s fair to say this at this point in time. If they re not brought together formally in TOGAF v-Next then I’ll agree with you.
    “Its content is not, the form is though. It’s simply a too large, unstructured, not integrated collection of views coming from various work groups. How do you find an item when you need it? ”
    [Mike Walker] AGREED!!!!
    To me you either do TOGAF or EA. At the end of the day, the firms lose though.
    [Mike Walker] Not sure I follow. You will have to back that statement up with some hard facts.


  6. @AdrianGrigoriu @Mike
    I’ll join the conversation – First a disclosure – I’m one of the people who wrote the tome. My fingerprints are all over TOGAF 9.1. I’m Chair of the Open Group Architecture Forum (the body that author’s TOGAF), worked on TOGAF 9, worked very hard on the team that created TOGAF 9.1, have worked on most of the integration whitepapers released in the last few years, and am very active on the next release of TOGAF.
    So, I’ll start – TOGAF doesn’t suck.
    Is it as good as I want it to be, not a chance. Can I change it? Of course, all I have to do is obtain a consensus of a project team. The Architecture Forum then reviews this consensus, and then the member companies of the Open Group review it. At every point comments, concerns, objections & improvements must be addressed by consensus. I live Mike’s challenge.
    Now a few points that rattled my cage:
    I do not understand the charge that TOGAF fails because it focuses on requirements? All I can assume is that special meaning is carried into TOGAF. Wherever possible in TOGAF we try to use a concept that can carry a range of specific detail – requirements is one of my favorite examples. TOGAF defines requirement as “a statement of need that must be met by a particular architecture or work package”.
    TOGAF’s requirements are a nice broad concept – a statement of need that must be met by the architecture. What else an I going to find in the strategy, goals, objectives, hopes, fears, dreams, courses of action, and constraints other than requirements? The set of needs that must be met by the architecture.
    Further, no weaseling in TOGAF. If we follow the thread in requirements & stakeholders, TOGAF highlights that best practice is provide a name. No hiding behind vague assertions like ‘shareholder value’, or ‘the strategy’. Instead we take those requirements and trace them back to a stakeholder. Show me who wants something and then I can perform trade-off between that stakeholder’s requirements and the requirements of the other stakeholders. I can weigh, assess, rank, and refine. And following best practice: review with my stakeholders and use the governance process to provide assurance. My only escape from this tyranny is to get one-or-more stakeholder’s to change the requirement, at which point I have a different set that must be met. No wonder TOGAF talks about iteration.
    Doing real architecture is hard because of this point – it must address the complete set of requirements. No hiding. Get out in the open and show your work. Describe a target that best addresses the complete set of requirements and deliver a roadmap that will move the organization from where it is to where it wants to be within the capability of the organization to change. (Phase A, B, C, D, E & Requirements Management)
    Second, I cannot see how TOGAF’s ADM can be considered a solution approach. If I’m doing solution architecture why would I develop an Architecture Vision (Phase A), develop a Roadmap (Phase E) then integrate the Implementation & Migration Plan into the organization’s portfolio (Phase F) and manage the lifecycle of my architecture (Phase H). I’ve heard many ways people wrap a solution approach, complete with proof-of-concept and RFPs into the ADM. But, in my opinion it’s a stretch.
    Now, doing EA – I can see the point of Phase A, E, F, G & H.
    Do TOGAF or do EA? Sorry I don’t do TOGAF. I get paid to either deliver useful architecture or improve the capability of an EA team. TOGAF is a tool, not a goal. It is an EA Framework that provides scaffolding for capability, content & method. To quote TOGAF Part I, “the purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy”
    In my opinion, too many words. In essence darned good – optimize across the enterprise the activity of the enterprise to create an integrated environment that is agile and supports current strategy… That’s worth getting out of bed for.
    Lastly, you contend TOGAF fails because it isn’t hand-in-glove with Archimate. Here, I may run into trouble at the next set of member meetings. Archimate is a subset of the concepts required to completely describe an enterprise architecture.
    This is not a slur on Archimate, by being a subset it allows me to use a reasonable set of entities, perform traceability between the entities and have a graphical notation I can learn quickly. Beautiful. Truly beautiful.
    But, if I need to describe organizational culture, fully map strategy, associate capital allocation, participation of multiple third parties, return on equity and taxation, identify information entities by provenance & usage restriction, clouds and account for last mile connectivity to a specific restricted platform – I may find Archimate limited. When I pull out the complete set of modeling techniques to describe these entities I may have the richness of a 1/2 dozen domain specific modeling techniques and have to perform acrobatics to link them. There never is a free lunch. Don’t forget, I enjoy aerobatics.
    When I do EA I need the freedom to describe what I need to describe to address the problem at hand – I will never let the toolset be constrained to a general-purpose saw. Sometimes a spoke shave, or coping saw or Mintzburg’s Organigraphs are needed. By the same token, I am very glad that I have a general-purpose tool that works reasonably well most of the time.


  7. Continued
    TOGAF aligns to my need for freedom and my expectation for a comprehensive toolset – there is a reasonable content-meta-model that provides a reasonable set of entities. I can read the mapping papers to Archimate. Or, I can roll my own and use Mintzburgh’s Organigraphic, Osterwalder’s Business Model Canvas & the OMG’s Business Motivation Model: exquisite richness and an integration challenge. Clearly a job for daveML. Or, use Archimate, and have a reasonable set that provides pre-defined end-to-end traceability. TOGAF is clear, use the tool needed. Describe what is necessary to understand, create a target that meets the set of stakeholder requirements, create a roadmap to traverse the gap and govern the builders to keep them on the path of goodness.
    Regardless of my tooling, if I have the elements of TOGAF calls for – governance, appropriate team, integration with corporate process, consistent method to develop an architecture & roadmap, stakeholders and requirements I have the underpinning to create a very good understanding of how the enterprise ‘works’. Then I can do my job and optimize the future against the complete set of requirements. Good thing TOGAF is general purpose and provides a scaffold so I can address the problem I have in a manner consistent with the guy in the next office. When we use a minimum set of consistent entities we can even use each other’s work – although the guy in the next office does look askance at Organigraphics and Goal Structuring Notation.
    I’d be happier if TOGAF was crisp on the distinction between concept and instantiation. Today I sometimes read an instantiation and have to derive the concept so I can re-instantiate appropriate to my problem. Perhaps the next release will make me happier.
    I’ll re-iterate Mike’s challenge. Want to make the EA world better, join us in the Architecture Forum. But, be prepared to work to consensus with many of the world’s leading practitioners. It’s a tough crowd. Specialist boutique consultants, global consulting practices and some of the most advanced in-house architects will review your work. You will be challenged to find what consistently works for a very broad set of problems. Not just mine, or yours, or Mike’s.
    Sunday January 23rd at the Open Group’s Newport Beach conference, I had 23 people from 3 continents in a workshop looking at EA Capability – we started at 9:00 AM. I look forward to seeing you at the next member meeting or a TOGAF next release call (your employer must be a member of the Open Group).
    Dave Hornford @davehornford
    Enterprise Architect
    Managing Partner, Conexiam
    Chair, Open Group Architecture Forum


  8. @Dave, I wished your comments are shorter, unlike TOGAF. It’s hard to follow them.
    Dave, yes we all do work hard. I do, you do,… they do. But no matter how much work we do, it’s the results that count.
    One does not need to join the forum and participate at meetings in sunny places in order to contribute to the EA field. In fact it should be the other way around. The TOGAF team, if true to their mission, should research, invite and adopt EA developments from the outer world rather than forcing them to go through your narrow and politicized channels.
    By the way, I know how these fora do things since I worked as the Chief Architect of TM Forum’s Frameworx for a while. Well, at least the framework exhibited Business Process, Applications and Information maps.
    I had too, a few posts about TOGAF in my blogs. Had you read them, you might have found suggestions. But it’s not worth opening the issues in this discussion. You had the opportunity to respond to my blogs. You didn’t. Anyway, it looks like you are not talking to me – since you have not addressed my many arguments – but to a world wide TOGAF audience.
    I published an EA book, presentations and articles on EA where I proposed an EA/BA framework. But nothing outside its circle seems to capture TOGAF’s attention.
    Some time ago I even proposed that TOGAF adopts GODS, a single page generic model for a business architecture which TOGAF lacks. To no avail. But, if I am right, who loses for this self centered approach of TOGAF? The end customer, the enterprise, the architect, TOGAF, you, me… all?
    Nevertheless, since you brought it up, the concept of requirements applies to a solution (architecture). You don’t document the current EA based on requirements. What requirements? And you draw the target EA based on vision, goals, strategy and tactical solutions architecture developments. The tactical and strategic programs aligned by EA have to gather and document the specific requirements not the EA. Have you seen any EA team to gather all the requirements for development in an enterprise as TOGAF recommends? I repeat the fact that TOGAF was defined as a solution architecture process was stated somewhere in TOGAF 8.x, but you know better.
    Mapping of other EA approaches, – you say you do that – is not the solution. It makes it look like TOGAF does the same thing in a different way. It doesn’t.
    And what should the architect do, go through the ADM and afterwards check the mappings? The approaches, if good, have to be incorporated in your method, with credits indeed. Not even Archimate was incorporated today. What subset? Not even the metamodels or basic definitions coincide.
    In any case, EA does not equal TOGAF and vice-versa. There are alternatives to TOGAF even if some are equally inefficient and distracting us from the EA job. While you keep talking about TOGAF, some do EA.
    And the question for many is, is why TOGAF, in its current shape or form, and not another method? Let’s go for it. Why not FFLV-GODS?
    By the way, I am an independent consultant right now. And my duty is to deliver EA rather than adopt or improve TOGAF. The TOGAF team has to be proactive inviting other contributions and making it simple for everybody to contribute rather than the other way around.
    @Mike, I think it is you who has to back up your TOGAF statements – even the statement that TOGAF sucks that upset Dave – with hard facts or at least, something arguable.
    Enterprises lose because the TOGAFers deliver TOGAF rather than EA, that is they check the ADM deliverables lists rather than coming with what the business and IT need.


  9. @AdrianGrigoriu
    If we are to converse we may need to narrow the field. I’ll start on on three points structure, extending TOGAF and a single model. The latter is most interesting to me.
    First, structure – I have no idea how the TM Forum works so I cannot compare Chief Architect of TM Forum’s Frameworx with my role in the Architecture Forum. The Open Group is a consortia of member companies who join, and participate in one or more Forums. My company, Conexiam, is a member.
    Chair of the Architecture Forum is a volunteer position. Annually elected by the members of the Architecture Forum. I have a limited ability to lead. Everything we do is by consensus. I even need approval at the quarterly member meeting of the agenda. In the projects I have one voice – in fact one of my participation values is testing my experience with my peers.
    TOGAF is a standard published by the Open Group, created through the Open Group’s standards process. The core is member consensus about member work. Sadly, Newport Beach wasn’t sunny on the two days my consulting commitments allowed me to attend.
    The upside, the members represent a very board range of industries, regions, and approaches. I am comfortable when we send a draft of TOGAF to some 3,000 people on the Architecture Forum mailing list, many of whom represent more people, we are hitting a significant cross section. Last time, we got more than 500 substantive comments. Are we hitting everyone possible? No. Frankly, I don’t lose any sleep.
    The downside is significant. People outside the process don’t understand it. Like Mike, they try and talk to ‘The Open Group’. In this blog, Mike invited people into the process. A few years ago I invited him to attend the framing meeting for the next release of TOGAF and represent his own ideas. While we are all influenced by our experience and learning, a member had to carry the influence in. We also do everything under non-disclosure.
    Second, extending. Since I have been Chair we worked consistently on integration and extension. The Architecture formally created joint projects with TM Forum, SABSA, BAIN, DAIMA, DODAF and interestingly the Open Group’s SOA Work Group, Cloud Work Group, Security Forum, Real-time & Embedded Systems Forum & Archimate Forum. The last five may sound odd, but every Forum or Work Group is an independent entity under the umbrella of the Open Group, and has a different set of members.
    Staying with TM Forum, SABSA and BAIN (the whitepapers are published and available) Our intention was three-fold:
    – clarify how the special needs of telecommunication, enterprise security and financial services are served with a general purpose framework. We use a clear phrase ‘TOGAF and’. A general-purpose framework should not have the depth, specificity and richness of a focused body of work.
    – extend TOGAF without the Architecture Forum having to pretend it knew everything and wrote everything
    – informally, learn where TOGAF may have used unduly specific concepts where a general purpose concept could allow the specialist’s richness and specificity.
    What I personally took away from the work and conversations, and from my work enabling effective EA teams as a consultant informed my proposal on the next release of TOGAF. I saw a need for TOGAF to be conceptually clear, internally consistent, easier to consume and easier to extend; for the framework to be separated from guidance on how to use it.


  10. @AdrianGrigoriu
    Third, adopting single models. This can be a conversation – structure I can explain, but we can’t change how TOGAF is created.
    I am working on the next release and am interested in learning. In fact the trade-off this evening was a draft of TOGAF or replying.
    Here, even thought I have not had the opportunity to look at your suggested models, I suspect we will part company.
    I am inherently suspicious of the perfect model – and run two tests in my head: How about defense, government, financial services, packaged goods, retail & resources? What about coverage for different purposes, archetypes or schools of EA? If it misses one or more, it is not fit for everyone, regardless of fit for some.
    TM Forum has a rich set of models in Frameworx I have used in telecommunications and banking; DODAF has a specific set of models I have used in defense, oil & gas, electrical utility and public sector; FEAF has a set of mandated models; Canada’s Government Services Reference Model (GSRM) is one of the best service reference models I have used. I can go on. We can all go on. In my experience, most of us specialize and absorb the inherent foundation of our specialization as universal constructs.
    I believe that TOGAF needs to support rich domain, purpose or organizational, specific approaches. Without, favoring or constraining one, or another, rich approach. Today, I believe it is unnecessarily hard to utilize the available richness because we have confused a specific instantiation, or specific concept for a universal concept.
    My real problem is a current need to describe organizational culture, fully map strategy, associate capital allocation, participation of multiple third parties, return on equity and taxation, identify information entities by provenance & usage restriction, clouds and account for last mile connectivity to a specific restricted platform. When I look at TOGAF’s content meta-model and partially associated viewpoint library there are significant gaps between what is there and what I need: however useful an application/data matrix usually is I have a problem that needs to be addressed before one of these is useful.


  11. Dave, thanks for your views.
    To me, the fundamentals of TOGAF are shaky. As for instance having requirements at the centre of ADM rather than the strategy. Besides it’s basically only a process stating recommended practices at each phase.
    And if you add more to the existing base, TOGAF would become even bigger and less productive. I would rather remove the unnecessary parts.
    But I won’t go into that again.
    To deliver an EA we need more. That is why I came with the GODS-FFLV method that consists of
    1. a development process (+governance, principles, site, team, value measurement, business case essentials…) (essentially what TOGAF intends to provide)
    2. an EA framework, FFLV, showing how Functions, Flows (processes), Layers and Views come together in an EA, how all parts fit in
    3. a generic business architecture model (GODS) showing a general value chain value, typical value streams (flows) and the key functions of an enterprise. That will start the design of the business architecture
    4. an architecture design process (illustrating sequence, types of diagrams, metamodel…) (a bit like DODAF attempts)
    5. off the shelf models such as process maps, IT infrastructure architecture, information… organization templates that allow customisation rather than starting from scratch
    It’s all in the Kindle and web site.
    That’s it from me. All the best.


  12. Adrian,
    Been delayed: work & my life intruded. In the process of keeping the conversation focused I see two threads: requirements and contents of a framework.
    First Framework – It appears you are aligning all of TOGAF with one of its parts – the ADM. Roughly TOGAF has three parts: EA Capability, EA Method & EA Contents (these are my words and I’m generally unwilling to debate the which term is better)
    Within the EA Method there is a need to address development, consumption and life-cycle. In TOGAF 9.1 these are are addressed by the ADM and Governance Framework. This is the most developed part.
    EA Capability addresses purpose, process, team, organization, skills, value, etc…. In TOGAF 9.1 there are a number of these elements, which frankly are improved upon with work done after TOGAF 9 in the World Class EA Whitepaper series.
    Third EA Contents. In my opinion, TOGAF 9.1 has serious terminology drift in this part and uses the terms content framework and content meta-model as synonyms, when the content framework is a superset. This conceptual structure recognizes there is a need for contents that describe an architecture and surround an architecture.
    If I followed, most of what you identified as an EA framework aligns with this part of TOGAF – a set of models that describe an architecture. By explicit design this part is the most easily replaced part of TOGAF. There are a number of sets of excellent models to describe an architecture. I have not seen one set of models and associated viewpoints that will work for everyone: for defense, government, financial services, packaged goods, retail & resources. Especially, given diversity driven different purposes, archetypes or schools of EA.
    My team doesn’t use TOGAF’s content framework. We use the rest of TOGAF, but this part doesn’t align to the problems we normally address. We call the set of tools we use Navigate. Simple customization for purpose, keep the baby & replace the bathwater.
    Moving to requirements. I’m quite intrigued about your issue with requirements at the centre of the ADM graphic. The ADM speaks to method not structure, and the graphic is descriptive. If I followed, the issue is traceability of architecture decision from strategy.
    In this case we need to look to the meta-model in TOGAF 9 (mostly chapter 34). The meta-model has no clear statement “strategy”. Without any question this is an issue. I work around a broad concept of strategy and finding the set of motivations, goals, objectives and requirements necessary to realize the ‘plan of action or policy designed to achieve a major or overall aim’.
    Regards Dave


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s