Link: http://weblog.tetradian.com/2012/11/01/showing-my-age-i-guess/
Am I really showing my age, as an enterprise-architect? Or perhaps I should do even more? Dunno, quite…
I had a blog-comment this morning from Christopher Lace, in response to a TOGAF-related blog-post of mine from back in May 2009: ‘More on TOGAF and certification‘. Chris didn’t give a website, but LinkedIn suggests he’s with Honeywell Aerospace in Colorado Springs. Anyway, here’s his comment:
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.)
I’ll admit I was was, uh, a teensy bit miffed at the tone: I mean, how well would you react to a phrase such as “Seriously, old man”? (Well, if you’re not still living in 1920s upper-class-twit Britain, anyway. 
). The “do your homework” and “stop griping” and “Hello…” remarks do kinda feel like he’s pushing his luck just that leeetle bit too far, given that I’d already been doing world-leading software-development for more than half a decade when this guy was still in his diapers. And of course he’s so far studied TOGAF from the book for two months and hasn’t yet done his Foundation exam, whereas I’m an ‘old man’ who’s only used it (or, more often, attempted to fight my way past its severe limitations) in real-world practice for some fifty times as long: so obviously he knows it all much, much better than I do…
Sigh. (Yeah, this happens a lot: try LinkedIn sometime… 
)
But let’s make allowances for the know-it-all exuberance of the over-qualified-and-under-experienced, and take it all at face-value, because there are some useful points here that are worth sharing more broadly than buried down in the comments-section of an all-but-forgotten blog-post.
Anyway, here’s my reply, that I started in the comments-section back there, and thought it’d be better instead to bring out here.
—
Hi Christopher
First, good luck with your TOGAF exam!
And yep, no doubt my age is really beginning to show (I’m 61). One side-aspect of that age is that whilst you’ve studied TOGAF for two months and are looking forward to your TOGAF Foundation exam, I’ve studied TOGAF and used it in real-world practice for almost a decade now. That includes detailed analysis of its anatomy from before version 8 (when they finally realised that ‘the business’ might be relevant to IT-architecture, and added it in 8.1 ‘Enterprise Edition’), through to the detailed discussions around TOGAF Next (the upcoming TOGAF 10). I also know personally quite a few of the key people involved in the writing of TOGAF, right from the beginning to the present day; and my rewrite of the ADM, to make it less IT-specific, is in daily use by at least one of the major TOGAF training-organisations. In short, it might be polite if you were to give me a little bit more benefit of the doubt, and consider that it might just possible that I do know what I’m talking about here?
Perhaps the key here is a recent blog-post of mine, ‘Two Enterprise-Architectures‘. (My web-stats show that almost 2000 people have read it from a link in someone else’s article on CIOIndex.com, so presumably it is relevant to CIOs?) The point in that post is that there are two fundamentally-different meanings of ‘enterprise-architecture’:
- ‘enterprise-architecture’ as a contraction of ‘enterprise-wide IT-architecture’
- ‘enterprise-architecture’ as the literal ‘architecture of the enterprise’
Both meanings are valid, but it’s very important not to mix them up. From everything you’ve said, your focus would seem to be on the former variant; mine is on the latter variant – in which, incidentally, the IT-architecture is viewed as merely one amongst a whole myriad of enterprise-scope architectures.
In much the same way, TOGAF is designed around the ‘enterprise IT-architecture’ variant – which is what we’d expect, given that The Open Group is an IT-standards body. In my opinion, TOGAF is probably an excellent fit for the present stage of your chosen career, in Computer Science and enterprise-scale IT-architecture. It is not, however, a good fit for the literal ‘architecture of the enterprise’, because, to be blunt, even in the present version it is still too IT-centric for anything other than a quite narrow IT-architecture. (This isn’t just my opinion, by the way: for an Open Group opinion, see Len Fehskens’ classic blog-post ‘Enterprise Architecture’s Quest For Its Identity‘). TOGAF is an IT-architecture framework, hence it should be no surprise that it makes no real attempt to understand business as business: in effect, its concept of ‘Business Architecture’ is ‘anything not-IT that might affect IT’. Above the strictly IT-specific architecture, TOGAF can be made to work for the more general architectures of a specific sub-class of strongly IT-oriented industries – in essence, banks, finance, insurance, tax. But it’s often awkwardly constrained even there, and far too constrained for most aspects of any other industry.
Since you ask me to “do [my] homework” and re-read the TOGAF Foundation materials, I’ll ask you to do much the same. Re-read the full TOGAF 9.1 specification, and show me where in TOGAF it describes manual fallbacks at the same level as ‘Application’, such as you’d need when the power is out and your data-centre is under ten feet of water. (If you think that’ll never happen, ask the folks on the US East Coast right now…). Show me where in TOGAF it describes the part of the roadmap about the physical realities of your data-centre, such as the physical building, cable-access, maintenance-access, power-supply, cooling or switchover for the primary and secondary back-up generators. Show me where in TOGAF it describes how to track the relationship between a physical object and a data-reference to that object – or, more to the point, how to work out what the heck happened when that relationship fails, such as when your shiny new laptop fails to turn up from Amazon.
To save you the effort, I can tell you right now that it isn’t there: it’s considered ‘somebody else’s problem‘. Which is perhaps true, for IT-architecture; but not for whole-enterprise architecture, which by definition must cover everything that happens in the enterprise space. That’s the difference. Kind of an important difference, that: several-orders-of-magnitude difference, in fact. (And, by the way, that’s why there tend to be a lot of ‘old folks’ in this space, because whether we like it or not, it really does take decades to gather that scope of experience…)
This isn’t a fault of TOGAF that it won’t and can’t cover a true whole-enterprise scope, because it was never designed to do that job. The only problem with TOGAF is that people too often tend to misuse it beyond its designed capability and scope, and either claim that they’re doing whole-enterprise architecture – which they’re not – or that IT-architecture is all that there is – which it isn’t.
So let’s briefly revisit one section of your comment above:
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.
We’ve covered the ‘do your homework’ bit (I’ve done it, lots, thanks), and the ‘blaming TOGAF’ bit (I don’t – if I blame anything or anyone, it’s the people who fail to recognise TOGAF’s limits and limitations). The next point is “you’re supposed to use TOGAF as a springboard”. To which the answer is, No, I’m not: I’m supposed to use what works as a springboard – exactly as with any other architecture-analysis, I don’t assume a single predefined ‘solution’ as my starting-point. And long experience has shown me that, for the enterprise-architecture work I do – whole-enterprise-architectures – TOGAF is too limited, and the ‘layers’ too misleading, to be a valid springboard for that type of work in real-world practice. As for the “Organizational Architecture … in the Enterprise Continuum”, where is ’Organizational Architecture’ described in the TOGAF spec? – other than perhaps a one-line statement that says that it’s, uh, supposed to be done by, uh, someone, somehow, possibly, perhaps? Short answer, again, is that it ain’t there: you might not need it for an IT-architecture, but we do definitely do need it for a whole-enterprise architecture. Which means that we must look beyond TOGAF alone to resolve that need.
In short, what you’re about to discover, as you head towards the pinnacle of the CIO, is that the real world is a lot broader than just the IT. In fact, it turns out much of that real world barely touches IT at all; that whilst real-world IT is a lot harder than the books make out, if anything it’s the easy part of any whole-enterprise architecture; and that the really hard part of an enterprise-architect’s work (and a CIO’s work, too), is all the ‘people-stuff’ – which barely gets any mention in the TOGAF manual. (There’s a brief section on ‘Stakeholder Management’ – ch.24, to be precise – but otherwise that’s about it.) You’ll also discover, as a CIO, that the business’ most important information resides not in computers, but in people’s heads, hearts and souls – a place that TOGAF alone somehow doesn’t quite reach? So let’s just say that by the time you reach that CIO role, your undergrad studies in psychology are likely to prove a lot more useful than all of your technical-studies put together…
“Be a solutionist”, you say. Right, sure, agreed. So let’s give you some practical solutions here.
– I won’t suggest my own books, because, to be blunt, you’re nowhere near ready for them yet. You’ll need at least a couple of years of real-world practice at enterprise-scope architecture before they’ll make much sense to you;, and until you do have that experience, it’s probable you’ll continue to dismiss me as just another maundering ‘old man’. Oh well.
– But I’d strongly recommend Chris Potts’ ‘fruITion’ trilogy: fruITion, recrEAtion and defrICtion. All of them use fiction as a way to illustrate real-world architecture practice. The last has only just been published, and I haven’t had a chance to read it yet, but the other two respectively deal with the role of the CIO and the enterprise-architect.
– I’d also strongly recommend Matthew Frederick’s ‘101 Things I Learned In Architecture School‘. It’s primarily about building-architecture, but most of it is also directly applicable to enterprise-architecture – or any other form of architectures, including software-architecture and the like. It’s also a nice mini-book to use to show other people what architectures are about.
– On the software-architecture side, I’d recommend Simon Brown’s ebook Software Architecture for Developers. Not only is he great on software-architecture, he understands enterprise-architecture a lot better than many supposed ‘enterprise-architects’ do.
– On business-architecture, the obvious place to start would be Alex Osterwalder’s Business Model Generation. Definitely the best ‘coffee-table’ book to leave lying around on your desk at work, as a really useful ‘conversation-starter’ on architectures in general, it covers a very broad subset of the business-architecture space, and even includes a brief section on (IT-oriented) enterprise-architecture near the end of the book.
– Once you’ve completed your TOGAF Foundation, probably the next course you must do – if you’re aiming for a CIO role – is ITIL Foundation. ITIL (IT Infrastructure Library) is the standard at the operations level: you’ll need to know and understand all of that, if you’re going to be able, as a CIO, to reconcile the very real difference between CompSci theory and real-world practice.
– You definitely need to learn some other enterprise-architecture frameworks, too. At the very least, for US government and defence-industry, you need to know FEAF and DoDAF respectively. See TRAK for a ‘de-militarised’ version of DoDAF/MoDAF, originally developed for London Underground; I’d also suggest NGOSS/Frameworx as an excellent example of a broad-scope yet comprehensive architecture-framework aimed at the needs of telecoms and media industries. There are at least a couple of hundred other EA-related frameworks to choose from, too: look around and see what you can find. Study, compare and contrast the scope, applications and limitations of all of these frameworks, together with TOGAF: doing so will give you a much better idea of what frameworks can and can’t do, and how to hack and switch between them for different architecture-tasks.
– And perhaps I might even recommend that you take a rather longer and more in-depth wander around this site for a while. Excluding the now-gone ‘A Week In Tweets’ series, there are more than 500 posts on enterprise-architecture themes here now, totalling well over a million words: you may find it a lot more useful in practice than you perhaps seem to think right now. Your choice of course.
Anyway, more than enough for now, I’d guess – hope it helps?
