More on TOGAF and certification

Yikes! Talk about misinterpreted in a sound-bite… :-(

(Before I go any further, a note to all in the TOGAF training/education community: from what you’ve read elsewhere, you may at present believe that I’ve been attacking you personally. As you’ll see below, this is not the case – so please accept my apologies for others’ interpretations of what I wrote. Do read on – and thank you.)

There are a few Tweets going round that suggests I’m attacking TOGAF (again), this time by suggesting that TOGAF training is worse than useless:

harsh deduction by @tetradian: TOGAF certification almost an indication that one is NOT capable of doing #EA

“… close to … a TOGAF certification is an indication that someone is not capable of doing enterprise architecture.” http://bit.ly/uZDZd

I’ll admit my original post summarising the London TOGAF conference last month does indeed include that latter quoted text. But it’s quoted way out of context: so please, do read the whole post before you jump to that conclusion! – because it isn’t what I’m saying at all.

First, it’s not my own ‘deduction’: it’s a near-verbatim report from a broader discussion at the TOGAF conference. From the certification perspective, four key themes came up from the conference, all from leading members of the TOGAF community:

  • the reference-architectures (Part VI of the TOGAF spec: ‘Technical Reference Model’ and ‘Integrated Information Infrastructure Reference Model’) are way out of date, and at the least need a complete overhaul, if not dumped altogether [that was from the Open Group's lead Allen Brown, in one of the plenary sessions]
  • “almost no-one” uses the ADM in the form described in the TOGAF specification [in my last post I said I thought that was one of the guys from Deloitte, but my notes indicate it was Mike Lambert from Architecting the Enterprise, one of the lead TOGAF training groups]
  • enterprise architecture is much broader than IT, and must now encompass the whole of the enterprise [that theme came up at least a dozen times, in plenary sessions and elsewhere]
  • enterprise architecture needs to be understood as a professional discipline, comparable to other professional disciplines such as medicine and building-architecture [again, many people, but particularly Len Fehskens, Open Group VP on Skills and Capabilities]

These are all points that, yes, I have personally pushed hard over the past few years: but you can see from the above that it’s not just me that’s saying it – it’s being echoed now right from the centre of the TOGAF community itself. (Just this once, I’m not ‘the Outsider’ here! <wrygrin>)

So, to the problem of certification. The key point is that certification alone is not an indication of professional competence. Back in my aero-engineering days, it was common knowledge that newly-graduated engineers were a potentially lethal danger to everyone in the place: they knew just enough to think that they knew what they were doing, with that arrogant certainty of the newly-qualified, but had no idea of how to work with the subtle complexities and constraints of the real world of engineering. For example, they would specify components that couldn’t actually be made, or assemblies that could be made but couldn’t physically be assembled. Even for the best, it usually took a year or two at least “to learn how to make my mathematics sufficiently imprecise to be usable”, as one of them put it. Crucially, there were a few who never learnt that lesson, and instead clung on to their certification as ‘proof’ that they were competent – which in practice more proved that they were not competent to be let loose on a real aircraft. Or, in this context, a real enterprise.

On its own – and again I’ll emphasise, on its own – an enterprise architecture certification does not and cannot indicate competence: it needs to be balanced by real-world practice. For which, again, crucially, this profession at present has no means to monitor or measure.

Next, look at what’s actually covered in the existing TOGAF certification: it’s primarily about the ‘standard’ ADM and the reference-models – which are no longer used in that form in practice. And – as also indicated in those themes from the conference – real enterprise architecture is much, much broader than IT: yet everything in the existing certification is centred on IT. So anyone who does slavishly follow the ‘standard’ will be almost guaranteed to create an architecture that might at first seem ‘efficient’, but will be so outdated, so IT-centric and so far off the real mark that it will at best be useless, and possibly much worse than that.

What the old TOGAF 8 certification exam did not cover was how to adapt the ADM to the enterprise, or how to create reference models and use them for compliance-monitoring and risk-management – which is what is actually most needed in those stages of architecture that the TOGAF spec aims to cover. And there’s no way that any of that kind of context-dependent knowledge could be assessed in a simplistic multiple-choice exam such as is still used for TOGAF certification. As I mentioned in the previous post, I nearly failed my TOGAF exam because in many parts of the test, none of the options shown on the screen actually matched what I knew from experience works in practice, and the nearest available guess turned out to be ‘wrong’ according to the specification in the book. Conversations at the conference made it clear that I was far from alone in that experience: in effect, anyone who presents a high score in their TOGAF certification may have the book-knowledge but know nothing about the practice, whereas many will score low because they are competent in practice. So as it stands, the TOGAF certification not only tells us nothing about professional competence, but can be actively misleading: a high score may well indicate that someone is not competent to do the work, whereas a low score indicates either high competence or complete failure, with no apparent means to distinguish between those two extremes.

All of which adds up to a serious problem.

It does not, however, mean that TOGAF training is wrong. Quite the opposite: many of the trainers I talked with at the conference made it clear that their training-courses emphasise the importance of adaptation of the ADM, development and use of reference-models, and all the other skills needed to assess and adapt to the enterprise context, and how to extend EA beyond the IT domain itself. To develop those professional skills, we’re likely to need more training, not less; and much of that training needs to be context-specific, too. The catch is that almost none of this material is in the current TOGAF specification, and none at all is assessed in the current TOGAF certification. So yes, whilst to my mind the TOGAF specification is still annoyingly limited and limiting, that’s not the real problem in this case. The point here is that, as it stands, the TOGAF certification is not only meaningless but actively misleading: and right now that is a real, genuine, active, in-your-face, fundamental problem for the profession.

This is a problem that’s being addressed: as I said in the previous post, Len Fehskens is specifically tasked with this on behalf of the Open Group, and others are tackling it in other ways with other groups. But we must first acknowledge that it is a real problem, and one that won’t go away simply by ignoring it, which is all that had been happening to date. So, yes, whilst it’s an uncomfortable fact to face, one of the key signs that the EA profession is maturing as a profession is that it is now willing to face up to such uncomfortable facts.

‘Bad’ news that’s good news all round, in fact. :-)

Tagged with: , , , , , ,
Posted in Enterprise architecture, Knowledge, The Outsider
14 comments on “More on TOGAF and certification
  1. Colin Wheeler says:

    I can’t say that I disagree but it is a pity we have such a hard time listening to our customers rather than debating this stuff on such an ongoing basis in amongst ourselves.

  2. Kevin Smith says:

    Well since most of what you report are facts its hard to disagree.

    Some of your points are not facts but reasoned beliefs but I have no reason to question them, most of the refer to what I have depressingly witnessed over the last 5 years or so.

    I know this is going to sound like a plug but this is why I created PeaF. (www.PragmaticEA.com)

    Training and Certification are now available worldwide.

    But don’t think of PeaF as closed and proprietary and therefore bad. It’s pragmatic and that counts for a lot. It deals with EA head on in a concise and pragmatic fashion. An EA Framework for EA’s by EA’s.

    Another way to look at it is as a vehicle for learning how to do EA but also to provide a lot of the toolkit required to do it. It just happens to have a name.

    I know training, a toolkit and certification alone are not enough for people to become EA’s but good quality training a toolkit and certification is deeply needed right now to start to turn the minds of people from where thy have been looking to where they should be looking.

    Cheers,
    Kevin.

  3. Len Fehskens says:

    Two preliminaries, and then two quibbles.

    P1: I have considerable respect for Tom’s thoughts, and I always look forward to chatting with him at Open Group events.

    P2: I wear two hats, as Open Group staff, and as an architect. I’m speaking now as an architect, not as Open Group staff.

    Q1: Tom writes:

    “The point here is that, as it stands, the TOGAF certification is not only meaningless but actively misleading: and right now that is a real, genuine, active, in-your-face, fundamental problem for the profession.”

    This just doesn’t follow from your legitimate concerns about how TOGAF certification might be misinterpreted. TOGAF certification means no more or less than what it purports to mean — that a TOGAF certified individual has demonstrated a knowledge of TOGAF. There is nothing misleading about that assertion, it’s a simple statement of fact. And it’s just as silly to conclude that it means that TOGAF certification implies incompetence as a practicing enterprise architect as it is to concude that it means that TOGAF certification implies competence as a practicing enterprise architect.

    Q2: Tom wrotes:

    “it’s primarily about the ’standard’ ADM and the reference-models – which are no longer used in that form in practice.”

    I don’t know that your sample size is large enough to conclude that the ADM or the reference models are *never* used as described in the TOGAF specification, but that’s not really the issue. All the professional disciplines I can think of that require adaptively creative thinking in practice teach some form of “you have to learn the rules before you can break them”. It’s called the Architecture Development Method, not the Architecture Development Algorithm, for a reason. They’re called Reference Models, not Universal Models. for a reason.

    To wrap up, I don’t see it as a problem that one of the tools we have (TOGAF certification) for advancing the professionalization of the discipline of enterprise architecture is only one tool of focused applicability. The problem is that we don’t yet have all the tools we need. That doesn’t mean we should discard or malign, or more directly to your concern, misuse the few tools that we do have.

    len.

  4. Tom G says:

    Hi Len – and first, thanks for joining in here, ’tis much appreciated.

    On your Q1, I agree with the intent of what you’re saying, but that’s not how it works in practice, out there in Recruitment-Land. We may indeed think it’s “silly” to believe “that TOGAF certification implies competence as a practicing enterprise architect”, but that’s exactly what most recruiters _do_ believe – as I’ve discovered the hard way. They also believe that its absence indicates that a candidate is _not_ an experienced enterprise architect. Yet since – as indicated in my post above – the TOGAF certification is now quite a long way distant even from current enterprise IT-architecture, let alone true whole-of-enterprise architecture – it’s now quite easy to fail certification by giving the correct answers to current practice; and it’s also relatively easy to pass if you’re good at rote book-knowledge without any experience at all.

    So if the only thing that TOGAF certification indicates is a knowledge of TOGAF, yet the certificable sections of TOGAF itself (i.e. the static, _definable_ items such as the ADM sequence and the reference-models, which can be tested in a multiple-choice exam) no longer align with current enterprise-architecture practice, what on earth is the point of the certification? That’s not a trivial ‘quibble’, as I think you must agree…

    The new TOGAF 9 ‘Foundation’ level, which covers terminology, does have real value in enabling meaningful conversations about architecture; but beyond that point the only certification that would make sense is an ITAC-style ‘viva’ interview. In my own case ITAC itself also wouldn’t work, because to pass certification for the level I work at – Level 3 Enterprise Architect – would require me to first pass Level 1 and Level 2, which I can’t because they are specifically about experience in detail-level IT-architecture implementation, which is at best only peripheral to the work I do. The same will apply to almost everyone who joins EA from the business side – something I think we all agree we want and need in the profession. So my concern is not ‘silly’ at all: it really _is_ a very serious problem right now, that really _is_ blocking further development of TOGAF towards the acknowledged requirement of alignment to the true enterprise-architecture space.

    On your Q2, agreed, “all the professional disciplines I can think of that require adaptively creative thinking in practice teach some form of ‘you have to learn the rules before you can break them’.” But what came up in this conference was that the ‘rules’ that are described in the TOGAF spec – certainly those which can be assessed in a multiple-choice exam – are less and less those that are actually used in practice. As you know, Allen Brown openly called for the removal of the two reference-models: personally, I think that’s too extreme – we do need _some_ kind of example reference-models – but it does illustrate the scale of the current misalignment between certifiable spec and real-world practice. Anyone who slavishly follows ‘the rules’ of the TRM and IIIRM reference-models in a real present-day enterprise is not going to produce the ROI savings that would justify the scale of the architecture work required. It’s all very well saying that this would be sorted out in a training course (and yes, the guys from RealIRM and Architecting the Enterprise made it clear that they already do this); but it’s the ‘out-of-date’ rules that are tested in the certification exam, and tested in a rule-based way which expressly excludes – almost denies – the centrality of the need for adaptation to the enterprise context. That is _not_ good: not good at all.

    Pretending that this is not a problem does not help TOGAF: we _must_ be honest about, and face the seriousness of the problem directly. It’s not my intent to malign the very good work being done by the trainers, or the work that I know you’re doing at present – as I hope I’ve made clear in my posts on this. What I _am_ concerned about is that the certification _is_ being misused by recruiters and others who’ve failed to understand its limitations, and that the current certification method is not suitable for the role it purports to play.

    There’s also another, deeper, more subtle concern which you’ve also discussed in your own TOGAF presentations: what exactly is TOGAF for, and how well – if at all – does it fit with the Open Group’s own remit? The Open Group’s raison-d’etre is around information in general, and certain categories of information-technology in particular – hence “boundaryless information flow”. Enterprise architecture in the TOGAF style grew out of trying to get a workable architecture at the IT-hardware level; but to make that work, we need to include the applications, the data, the business-information, the business, and ultimately the broader enterprise beyond the organisation itself – most of which would seem to be way outside of a conventional IT scope. All of those links are referenced bottom-up, centred around IT: hence the ADM’s ‘business architecture’ is in essence ‘anything not-IT that might affect IT’. But a proper enterprise-architecture needs to come the other way – top-down, not bottom-up – and _does_ need to include a whole lot of other areas such as quality-systems and manual-only or machine-based processes that barely touch at all. (The same applies to security-architecture and service-architecture, as you’ll know from the respective streams at the TOGAF conferences: we can’t them to work either unless we cover the whole enterprise and not just the IT.) Which is kind of hard for an organisation that, by its own charter, is _and needs to be_ focussed primarily on IT-related concerns. IT-architecture is a proper concern for the Open Group; business-architecture is way of its remit, and true enterprise-architecture is even further ‘way out’ (pun intended).

    I’m beginning to believe that the way forward is for the Open Group to start building a consortium with others who _do_ work in those broader-scoped spaces – particularly the business-architecture groups – and hand TOGAF on to that consortium, in the same way that TAFIM was passed to the Open Group in the first place. That would then free the Open Group to concentrate on what it does so well in the IT-architecture space, whilst still retaining engagement and leverage on TOGAF’s further development. (The Open Group’s Collaboration Unit, or whatever it’s called these days, has a _lot_ of experience in setting up that kind of consortium: it should be easily doable with the right consortium partners.)

    What we definitely do _not_ want is for the enterprise-architecture space to fragment into a myriad of incompatible would-be ‘standards’. That’s one reason why, in my own work, I’ve been careful to stick very closely to the spirit of the ADM, doing the minimum practicable change and within the ADM-adaptation ‘rules’, to make it workable for any required scope and business-issue in whole-of-enterprise architecture. My concern about the current TOGAF certification and the certification-process is that they risk accelerating that trend towards fragmentation – and also risk damaging the credibility of the profession itself.

    I don’t think any of us in the TOGAF community can risk ignoring these problems any longer: we _must_ act now, before more serious damage is done. And we _must_ act openly, to make it clear that we _are_ addressing those problems, and not simply trying to sweep them under the carpet again. That’s all I’m asking here.

  5. Len Fehskens says:

    There’s far too much here to respond to in this context, so I’m just going to focus on a few essential things.

    “but that’s exactly what most recruiters _do_ believe … They also believe that its absence indicates that a candidate is _not_ an experienced enterprise architect.”

    Well, TOGAF certification is never going to be the equivalent of a masters degree in enterprise architecture (which still wouldn’t guarantee competence). I don’t know how TOGAF (or any) certification can be changed to address recruiters’ foolish beliefs. TOGAF certification certifies knowledge of TOGAF.

    “yet the certificable sections of TOGAF itself … no longer align with current enterprise-architecture practice, what on earth is the point of the certification?”

    I really don’t understand why you insist that TOGAF no longer aligns with current enterprise architecture practice. What are the thousands of people
    who download the specification and buy the books doing with them? For a huge number of people doing EA, TOGAF pretty much defines current practice. I think you’re making far too much of Mike Lambert’s off the cuff pronouncement, which I also suspect he did not intend be interpreted so sweepingly.

    “it really _is_ a very serious problem right now, that really _is_ blocking further development of TOGAF towards the acknowledged requirement of alignment to the true enterprise-architecture space.”

    First, why does this have to be TOGAF’s responsibility? Why can’t TOGAF just be a good way of doing Enterprise IT Architecture? Second, how does some other profession’s (recruiters) misunderstanding of what TOGAF certification means determine or constrain the content of TOGAF?

    “it’s now quite easy to fail certification by giving the correct answers to current practice”

    But that’s not what TOGAF certification is (or should be) trying to do. It’s not intended to certify knowledge of “current practice” (whatever that might mean, and my suspicion is that it is highly locally defined), it certifies knowledge of TOGAF.

    Even ITAC doesn’t try to certify anything about “current practice”. It’s utterly pragmatic, and basically just asks that you demonstrate that whatever “current practice” is, you’re doing it successfully and in a repeatable fashion.

    This is a very young and immature profession. The notion that there is a single canonical version of “current practice” and that TOGAF is “irrelevant” if it doesn’t codify this platonic ideal is a strawman. TOGAF (or rather the people who contributed to it) certainly aspired to capture in some integrated fashion not so current best practices (because you can’t tell what works best until it’s been used for a while). And there are several other communities doing similar things (e.g., DoDAF).

    “tested in a rule-based way which expressly excludes – almost denies – the centrality of the need for adaptation to the enterprise context”

    Testing for knowledge of some starting point does not deny in any way the need for adaptation. Agreed, it does not test for one’s ability to adapt the starting point to the specific needs of some real world situation, but practicality intrudes. But again, that’s not what the certification tries to do. You keep insisting that it do something it’s not intended to do, and in fact can’t do. You also keep asserting that the “starting point” is “irrelevant” by virtue of it being apparently unrecognizably different from “current practice”, and that this perception was widely shared by the participants in the London conference. That’s not at all the sense that I got from the Architecture Forum meeting, or from routine conversations with the conference attendees.

    TOGAF is about EITA, and that is OK. Yes, EA is much bigger than EITA, but how we address that larger scope is a separate question from TOGAF’s fitness for purpose for EITA, and TOGAF certification’s fitness for purpose for an emerging profession. That TOGAF and TOGAF certification are not everything we need to ensure rigorous vetting of practitioners is not an impending disaster, it’s an integral part of the evolution of a still very immature profession.

    len.

  6. Tom G says:

    Len – thanks again for engaging in this, though I fear we’re going to have to agree to disagree.

    The only point I’ll pick up on is “why does this have to be TOGAF’s responsibility? Why can’t TOGAF just be a good way of doing Enterprise IT Architecture?” (which you also return to in the last para above).

    The reason why is that TOGAF isn’t ‘sold’ as Enterprise IT Architecture: it’s purporting to be Enterprise Architecture, and as you agree above, they’re not the same thing. If we are to restrict TOGAF solely to an IT-architecture scope – which we might – then it’s clear that we need to be explicit about that, and stop calling it a framework for enterprise-architecture.

    (From the developing discussions over the past couple of years, in the TOGAF community and elsewhere – e.g. in security-architecture and service-architecture – it’s also clear that enterprise IT-architecture also won’t succeed without a strong linkage into a true enterprise-architecture, but that’s another question entirely from the specific point you’re making about TOGAF’s own role.)

    I agree that IT-architecture appears to be a distinct specialist discipline in its own right, focussed primarily on the detail-layer and on integration of heterogeneous information-systems. It operates primarily in a rule-based context, and in that sense is somewhat amenable to certification via a multiple-choice exam, with such certification indicating sufficient familiarity with the knowledge-base to have memorised some of the basic terminology and descriptions of best-practice. Real IT-architecture gets real complicated real fast, but that core knowledge is still of real use as a starting-point: I’ll agree with that. As long as we say TOGAF is _only_ for IT-architecture, and does not move out of the IT-architecture space, we can get probably carry on for quite a while with what we already have.

    But it breaks down as soon as technical complexity hits social complexity – which is exactly what happens when we add security-architecture or service-architecture into the IT-architecture mix. _That’s_ why there’s been so much difficulty with service / security-architectures in TOGAF – it’s not just that it’s complicated (which it is) but it’s also genuinely complex, in the Cynefin sense. And rules alone will not help there: in fact reliance on rules alone in such contexts is a recipe for disaster. _We cannot get IT-architecture to work reliably by focussing only on the IT_: that’s been the lesson that’s been becoming steadily more and more evident ever since the TAFIM days.

    So in that sense, it’s arguable whether there actually _is_ a separate discipline of EITA: there’s IT _solution_architecture, always working within a defined set of constraints and a defined scope; but at the enterprise scope ‘EITA’ can never be other than a selective view into the whole enterprise, always with awareness that the whole is always there. In that sense, TOGAF seems to be facing a choice: either withdraw back to a solution-oriented IT-only space, and forget about anything broader such as security-architecture, service-architecture or business-architecture; or else expand outward into a true enterprise-architecture space. What we have right now doesn’t really fit either of those requirements – which is exactly what’s reflected in the certification problem.

    ITIL made exactly this type of jump between version 2 and version 3. Version 2 was a classic ‘them and us’, literally with business on one side and IT on the other. Version 3 is a generic service-management model which uses IT service-management as its detailed worked example: like TOGAF, it starts out from IT, but extends out cleanly and consistently into the whole-of-enterprise space. And ITIL certification reflects that fact, too – which is why there are distinct ITIL certification levels which actually _mean_ something in terms of practice and competence. Yes, agreed, EA may be “a still very immature profession”: but so is IT service-management. If they can do it, why can’t we?

  7. On the certificate

    All this seems a storm in a tea cup to me. Anybody who thinks a TOGAF certificate makes them an architect needs their head examining. It shows you understand TOGAF terms and concepts – that is all.

    On training

    Thank you for the apology. But didn’t you report your collleage came back disappointed and anti-TOGAF from a training course? They clearly went on the wrong course.

  8. MC says:

    Wear the shoes of someone wanting/trying to enter the professional field of EA with no prior work experience in EA

    If the certification should not be used by the recruiters to evaluate (the only) qualification that the candidate has in EA then how will the candidate ever get the necessary experience to get the job? This is a catch 22.

    In my opinion, certification should surely be considered in the interview process but if there is no work experience then that candidature gets lesser value than someone who has work experience (and certification) Or in case of employers who have their own EA framework based off of TOGAF/FEA/Gartner Combo, might value someone with just certification because the candidate needs to learn and implement the company’s local framework and not what he/she might have learned on previous jobs. Another advantage of the hiring the ones with just certification and no work experience is that they are cheaper.

    • Tom G says:

      MC – This is fairly specific to TOGAF and other certifications which rely only on simplistic multiple-choice exams for their certification. My point is that such certification is worse than meaningless as a means to describe competence in a complex-domain skill.

      Since writing the post above, Open Group have introduced a lower-level ‘TOGAF 9 Foundation’ certification, which in essence does not claim to test anything more than familiarity with TOGAF terminology – which _is_ useful for anyone applying for an EA role, because it means that you don’t have to brought up to speed on the language.

      If full TOGAF certification is meaningless, TOGAF training is not: it’s about how TOGAF works in practice rather than solely in theory, and the better trainers really do know the ‘gotchas’ and workarounds that need to be used in the real world. If I was a recruiter considering you as a ‘new unknown’, I would look to see if you’d done a good training-course rather than solely the certificate exam.

      Once you _do_ have some practice behind you, go for a practice-based certification such as ITAC. From my own perspective, ITAC is not much help to me, because it assumes that the only path to EA is via IT solution-architecture: I come from a business/information path, so whilst I could easily do the EA exam (level-3?), I wouldn’t be allowed to take that exam without first passing the previous levels, which are IT-specific and which I know I wouldn’t pass. But if you _do_ come from an IT background, it’s probably a good way to go.

      “Another advantage of hiring the ones with just certification and no work experience is that they are cheaper.” The disadvantage is that they won’t know what to do. :-) What far too many people forget is that architecture is a generalist skill, not a specialist one: it takes a heck of a long time to go across all of the different skill-bases. (And whilst doing all of that you’ll never have time to develop any one skill to the point where you’ll get specialist-level pay: a huge disincentive for most people against heading out on an architecture career-path.) Blunt fact is that it takes not merely months but many years to collect together enough skills to become competent as an architect: probably a minimum of five years for enterprise-wide IT-architecture, and more like fifteen or twenty for true whole-of-enterprise EA. Hence “hiring the ones with just certification and no experience” may seem cheaper at first, but may be darned expensive if you have to wait five or ten years before you can trust them to be any good at what you want them to do! I agree that hiring people at ‘apprentice’ level means there’s less to unlearn: but again, they’re going to be spending a long time on the bench before they’re going to be able to contribute much value, so the organisation will need to take a strong long-term view – which far too few seem to be able to manage these days, unfortunately.

      My own problem is that I’m working right at the forefront of EA, pushing hard not only to break it out of the IT-centric box (as in classic TOGAF) but also make sure it doesn’t then get equally stuck in business-architecture rather than IT-architecture. There’s no certification for EA at that level: to be blunt, I’m probably one of the few people who could write one at present. But I’m constantly being dragged back by the dead weight of the industry’s obsessive IT-centrism, and the inability of too many people – recruiters especially – to understand the real complexities of real-world enterprise-level architecture. And as more EAs do start to wake up to the full scope that we have deal with in architecture, it’s not just me any more: a lot more people are being affected by this fundamentally-flawed approach to skills-assessment. That’s really what this post was about.

  9. Amit R says:

    A fresh engineer like me who has will to enter this field should follow which path ??
    I thought certification would enhance knowledge & not just let me get acquainted with terminology. Can you suggest any masters degree in this field anywhere in the world ??

    • Tom G says:

      Hi Amit – On its own, the TOGAF certification doesn’t really provide or prove much more than a knowledge of terminology. But a good TOGAF training will give you a solid practical background for real IT-’EA’ knowledge, and real examples on which to test that knowledge.

      There are many good TOGAF training-courses just about everywhere worldwide. From your name I would guess that you’re Indian? If you’re in the US, like many of your compatriots, just look around for the adverts (I would recommend my colleague John Polgreen, who’s with Architecting the Enterprise, but there are plenty of others). If you’re in India, there would be fewer options at present, but Open Group now have a partner-organisation on the sub-continent – perhaps look at the Open Group website for further info?

  10. Christopher Lace says:

    I’m scheduled to take the test on TOGAF 9 this Saturday. I just wanted to get some idea of what some “experts” in the field are currently dealing with and how they utilize TOGAF 9 in modern practice. Some background: I have 10 years of IT/Engineering background, an undergrad in Psychology, an MS in IT Project Management, a PMP, and I’m currently a Doctoral candidate of Computer Science in Enterprise Information Systems. My ultimate goal is to be an enterprise architect and decide from there if I want to pursue becoming a future CIO.
    As you can see, I’ve never held an official title of ‘enterprise systems/solutions architect’. However, because that is the next step in my career path, I strongly felt getting TOGAF 9 certified was the next logical step. I’ve actually done an extensive two-month study on TOGAF 9 and passing the exam can be something that says you know terminology, or for someone in my case, I can actually get into an organization, learn their current practices and identify deltas with the TOGAF methodology and make suggestions.

    @Tom – You need to reread TOGAF 9 Foundations. If you actually look closely at what the document is trying to preach, it’s saying that it’s a flexible model that goes through a cradle to grave process addressing Business (addresses service-architecture), Data, Application, and Technology (addresses your security-architecture). From which point the process aims to do continual gap analysis until the scope of the IT approach matches with the business objectives. TOGAF 9 is designed to inherit other architectures, not be the architecture for all required architectures that an organization needs. Seriously, old man, do your homework and stop griping about how everything’s broken and blaming TOGAF for your current architecture’s short-comings. As an architect you’re supposed to use TOGAF 9 as a springboard to create case specific solutions. Hello… that’s what the Organizational Architecture is designed to accomplish in the Enterprise Continuum. YOU are the agent that is supposed to create the “differentiator” that makes your firm stand out from the rest.

    Be a solutionist. Not a complainer; lest your age really begin to show. (I’m 29.)

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Books by Tom Graves
Ebooks by Tom Graves
Categories
Archives