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?
I’d suggest working on the people skills above all else. Sheesh!
Tom,
It was a moment of pure pleasure to read your answer.
I am 52 years old.
Hear! Hear! A magnificent and magnanimous reply, Tom. TOGAF, and like-minded approaches, are indeed the easiest level of thought. It is abstract Peopleware (apologies to Neumann and DeMarco) which requires the major effort – and, then, attempting to pull the systems out of Peopleware so that processes like TOGAF can be applied to them is another major effort. Your comment about the handling of scope is so right-on (OK, I’m 64). I would say to Christopher (because I’m old): if you truly see with your eyes and truly hear with your ears and truly desire to learn and you “do not block the way of inquiry” (- Peirce, “First Rule of Logic”), then you will eventually arrive somewhere extremely close to Tom’s position. Tom, I want you to know that I hold your postings in the highest regard – they are deeply influential to my considerations. I, for one, am thankful you are old…
Thanks, Myron (and Jacques and Gene too)
Nice to know I’m not the only ‘old man’ here… 🙂
Tom,
Firstly, I’ll apologize for getting somewhat offensive on the last post. I get irate when people complain about “shortcomings” on things when they weren’t originally designed to do such. I get this a lot in my career where I should be expected to either know something or do something which is outside the original scope of what skills I agreed to come into the firm with or the duties I was told I was going to do. However, I digress…
The presence of the Business Architecture as being the mechanisms that drives Data, Application, and Technology makes complete sense and should address all of the organization’s requirements that build the Transition Architectures in order to reach the Target. The comment about “enterprise-architecture’ as the literal ‘architecture of the enterprise” goes beyond what TOGAF ever promised to do. Should TOGAF address janitorial elements of the enterprise as well? TO what level of granularity should the framework go? The framework essentially covers all of the bases I expected it to do and more from the moment I began studying its contents. As an enterprise architect, my main goal is to achieve Business Alignment (Business objectives drive IT infrastructures/solutions which enable business objectives, and so the cycle continues until the Target Architecture is realized).
“…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…).”
That’s not the enterprise architect’s role, you’re right. That’s building infrastructure’s/civil engineering’s role. It is however, the EA’s role to determine the data backup/migration solutions if such a situation were to take place; essentially, your standard enterprise contingency plans. Should I have a network database in place for redundancy while we order new hardware? All of a sudden you should see those building blocks in Data Architecture as well as Technology architecture. I’m sure that I seen an entire risk methodology (classification, identification, mitigation, residual, monitor/control) that was addressed in all of the TOGAF material. This is where the human element is incorporated as you mentioned (…heads, hearts, and souls).
“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.”
Since TOGAF says “TOGAF is a tool for assisting in the acceptance, production, use, and maintenance of enterprise architectures.” I assumed that we all understood the fundamental fact that it is a tool whether or not it is for a spring board or otherwise. The fact that “TOGAF is limited” probably only means that you want to use it for something beyond its intended use. If I bought a Ferrari, I don’t think I’m going to try and plow fields with it like a tractor, and then complain about what it can’t do despite how much I paid for it.
“As for the “Organizational Architecture … in the Enterprise Continuum”, where is ’Organizational Architecture’ described in the TOGAF spec?”
You’ve been an architect for so long (since I was in diapers) and I’m surprised you weren’t able to put two and two together. If you look at the enterprise continuum, it begins on the left with “generic architectures” and migrates to the other end of the spectrum of “specific architectures”. When I say “organizational architectures” it means that the “specific architectures” that address organization specific needs which I thought you’d get when I said “differentiators”; essentially the positive delta that gives organization XYZ a competitive edge against organization ABC. Also, by the way, the TOGAF document does have this phrase “ABBs evolve through their development lifecycle from abstract and generic entities to fully expressed Organization-Specific Architecture assets.” Yeah, I stand by the statement; “you need to reread the document“(which means more than Ctrl-F a .pdf when someone says something).
“your undergrad studies in psychology are likely to prove a lot more useful than all of your technical-studies put together…”
I don’t disagree. Truthfully, psychology is my true love. I just realized that the higher up you go in IT, the more business you encounter, and the more of that you encounter, the more people problems you deal with as opposed to just the on-switch not turning something on.
Bottom line: I truthfully think that we’re violently agreeing on about 90% of what we’re saying. You’re well versed and had a lot more time to get to know architecture. I understand that much. I’m just saying that we need to let TOGAF be TOGAF and identify other deltas about enterprises and classify them under a different role/title/job or whatever. If I was an enterprise architect, I don’t care about dealing with a flood in the comm. basement. I’m worried about the information loss, the hindrance of the business objectives being met due to a disaster and how I can design the IT infrastructure to mitigate those risks. Now, if this means that I need those specific resources to help me address those concerns (another TOGAF term) in the preliminary phase, then so be it! However, I don’t need those specific solutions in my enterprise continuum.
Hi Christopher
Thanks for the apology (and we’ll ignore the renewed insolence of “surprised you couldn’t put two and two together” and quite a few other items, shall we? 😐 ).
The core of this is that we have a fundamental difference in scope. It’s very clear that you view enterprise-architecture solely in terms of IT – an ‘inside-outward’ view centred around IT alone. The view I take of enterprise-architecture is that it’s the literal ‘architecture of the enterprise’ – in which everywhere and nowhere is ‘the centre’, and in which IT-architecture is merely one set of views into the overall space. I’d agree that both are ‘enterprise-architecture’, but the former is so only by dint of a very unwise term-hijack: the latter is actually the literal or ‘natural’ meaning of the term.
If the term-hijack does take place – i.e. IT-centric ‘EA’ purports to be ‘the architecture of the enterprise’ – then the consequences to the enterprise can be very severe indeed, because in effect the IT-centric view blocks everything else. For example, you say “I don’t care about dealing with a flood in the comm. basement” – but someone must do, otherwise you have no means to deal with “the information loss, the hindrance of the business objectives” and so on. And that ‘someone’ or ‘something’ must be included in the overall architecture of the enterprise – otherwise, again, we would have no means to prepare for and resolve disaster. Everything depends on everything else: if we have an architecture that’s arbitrarily constrained to IT, it may be easier to understand and to use, but by definition it cannot deal with the actual needs of the enterprise itself.
“The presence of the Business Architecture as being the mechanisms that drives Data, Application, and Technology makes complete sense and should address all of the organization’s requirements that build the Transition Architectures in order to reach the Target.”
Again, that’s IT-centrism. Turn it round: where are the people in all of that? Where is the awareness of the interdependencies between ‘anything-not-IT’ and everything else, that will impact even on IT as crucial second- or third- or whatever-order effects? I still don’t think you’re anywhere near grasping this point, so I won’t labour it too much. I’ll just re-iterate – as do all of those other commenters above – that there’s a necessarily larger picture that you’re just not getting as yet – and until you do, there’s really not much point in trying to converse about this.
One other very telling statement comes up early on in your comment above:
“I get irate when people complain about ‘shortcomings’ on things when they weren’t originally designed to do such. I get this a lot in my career where I should be expected to either know something or do something which is outside the original scope of what skills I agreed to come into the firm with or the duties I was told I was going to do. However, I digress…”
That’s not a digression: that’s actually the core of architecture, and the core point that you seem to have missed here. I don’t think I’ve ever done a consultancy-gig where I only did “the original scope of what skills I agreed to come into the firm with or the duties I was told I was going to do”. In quite a few gigs I didn’t do any of the nominal scope, because as soon as I got there, my first task was to find out what was actually needed – rather than what they’d thought they’d needed – and then do that.
Architecture is a generalist role. (There’s more on that here in the series on ‘No jobs for generalists‘, if you’re interested.) What you’ve quoted so far are all your specialist qualifications. Which, yes, you’ll need as an architect, if eventually only as foundation and background. Yet what you’ll need more is the architect’s attitude: a willingness to turn your hand to anything; to keep learning; to accept the frequent fact of “I don’t know” – and be willing to ask others who do know more than you do; a solid understanding of why the architect’s most common answer is “it depends…” – and yet able to give concrete, practical guidance around that ‘it depends’. Oh, and humility, too: that definitely helps…
If you’re not willing to do those things – if you’re not willing to let go of the certainty and status that you appear to seek – then that’s fine too. You’ll do very well as a specialist. Just don’t try to do enterprise-architecture – especially anything beyond IT – because you’ll do yourself and others a lot more harm than good if you do. Your choice, of course.
Best leave it at that for now, I guess.
Christopher,
Using TOGAF outside it’s intended use.
Hmmmm.
I absolutely accept and understand this point. Using a Hammer to glue china back together is probably not a good idea.
So Christopher, using TOGAF for EA is using it outside it’s intended use.
TOGAF is not an EA framework.
TOGAF is an EITA framework (that is to say is it IT centric but large scale – the word Enterprise meaning large rather than “The Enterprise”
So using TOGAF as an EA framework or as the basis for doing EA is therefore not a good idea.
TOGAF is not an EA framework. TOGAF is an EITA framework. The Open Group admits that. The Authors of TOGAF admit that.
OF course for a long time they didn’t and wouldn’t admit that, but in the last year or so they have.
By the way I am a TOGAF 8.1 Certified Practitioner – I couldn’t be bothered to take the 9 exams although I have been on the v9 4 day course and had read the entire specification. I can even say that most of it made sense – from an EITA point of view.
I can also tell you that I have worked at a number of organisations where TOGAF certification was a pre-requisite. When I arrived, after some digging, I found out that none actually used TOGAF at all. TOGAF has become a badge more than anything else “No one ever got sacked for paying for TOGAF training”. It feels very comfortable to senior people so it ticks their boxes. Unfortunately it doesn’t tick many EA boxes.
I would suggest you take a look at PEAF. It is not only an EA framework, but a pragmatic one too. I would love to hear your thoughts.
If you want to know more about what it takes to be an EA have a look at the Pragmatic Architects Creed here http://www.pragmaticea.com/pragmatic-architects-creed.asp. Which ones can you truthfully sign up to and which can you not? And if not, why not? What do you need to do, to be able to?
You could also look at the traits of an EA on pages 25 and 26 here http://www.pragmaticea.com/display-doc.asp?DocName=peaf-culture-relationships
You may have 10 years of IT/Engineering background but you need to start thinking and acting like an architect. That’s not a slur – My background is steeped in IT/Engineering but I made the transition to think like an architect although I have to say I believe that thinking like an architect was innate in me.
Everyone can learn and be taught how to be an architect, but like a piano player, some people will find it very hard and will never get past playing with a small band, whilst others will find that they just “have it” and will go on to become world class concert pianists. You need to know in yourself first, is being an architect in your heart or just something you like the sound of? Why do you want to be an architect? Think long and hard on that question.
By the way, pointing out your age to someone is a very strange thing to do.
Tom
Re: “ITIL (IT Infrastructure Library) is the standard at the operations level”. Love that put-down but whatever ITIL is, it is not a standard, it is a “framework of best practices”. There is ISO 20000 which is an actual standard.
Did you know that ITIL has also had versions. First there was just ITIL then appeared Version 3 and now we have Edition 2011. Beginning from V3, ITIL is “service lifecycle” oriented. According to it the IT people design a Service Portfolio which contains the current and future services. The seem to need zero input from the enterprise architects for deciding the future services. According to ITIL the IT people have a “Strategy Management Process” which generates the guidance for future services. Unfortunately the concept of IT service is very unclear in ITIL.
Aale, 61
Thanks, Aale – and yes, you’re right, of course: the distinction between the framework (ITIL) and the actual standard (ISO20000) is an important point that I’d missed there.
(This also reinforces the point that architects need to be willing to know and admit that they’re wrong, and know and turn to the people who do the deeper detail for further advice.)
(And, uh, my pointer to ITIL was in no way intended as a putdown: that’s something I really need people to note here! It’s just that people coming from a theory-background such as CompSci tend to have too little awareness of the practical realities of the respective discipline: I’ve commented on this elsewhere in the blog in terms of aero-engineering graduates and their relationship with turners and fitters in the engineering-workshop, for example. Familiarity with ITIL to at least the Foundation level – i.e. common language – is an essential counterpart to anyone wanting to move from software-engineering to IT-architecture practice.)
And yes, I’m familiar with the different versions of ITIL – though I always need to learn more! 🙂 The big shift was the transition between v2 and v3. V2 was a classic IT-oriented model, with a core-graphic that shows ‘the business’ on one side, IT on the other, and IT-service-management as an uncomfortable ‘pig-in-the-middle’. V3 is a generic service-management model, with IT-service-management as little more than a worked-example for that model. The upside is that it’s a framework that can be applied to any type of service-management; the downside, as you say, is that it now probably doesn’t provide enough support for the context-specific detail for IT-service-management.
There was a similar loss in TOGAF, by the way. V9 is more generic, in a not-very-successful attempt to move it towards a true ‘architecture of the enterprise’ – the insistence on holding on to the rigidly-IT-centric ‘BDAT’ layering is the key cause of continuing problems there. But in making it more generic, it dropped a lot of the old detail, if only for reasons of space – the TOGAF spec was impracticably large already, and something had to go to make room for all the new stuff. So if you do want to do IT-specific architecture, you’re probably better off with v8.1, which had much more detail about IT-infrastructure; and if all you want to work on is IT-infrastructure, you might be better off going all the way back to v7 (though it’s probably too far out of date these days?). There are trade-offs involved in all of these ‘standards’, and we need to know what they are before deciding on what to do: it’s not wise to just grab hold of a ‘standard’ because it claims that it is ‘the standard’, and assume that that’s all that there is.
I really like this thread. I’ll apologize again for the ‘renewed insolence’ ☺ despite what the tone may sound like on text, I really am saying much of this with a crooked grin for stimulating conversation.
@Tom — I certainly understand what you’re saying, Tom. Theirs is an inherent difference between an Enterprise Systems/Solutions Architect and an Enterprise Architect. In fact, I had a technical recruiter try to tell me that there are people that already do “enterprise architecture” with the firm when I asked about openings in that area. He described them in such that I had to response with the fact that they were indeed really Solutions Architects as opposed to Systems Architects. I know what you’re thinking. “What does this have to do with the price of tea in China?” I suppose my point is that when I think Enterprise Architecture, I use it in the context of achieving Business Alignment. Is there truly such a title that addresses all elements of an enterprise? Even the Zachman Framework, despite its “People” column, only deals with Scope, Business, Systems, Technology, and Detailed Representations (I know, it just reiterates another IT Architecture perspective). The fear in that is really the more you start to involve yourself with creating “an architect for the architect”, you start to lose that level of granularity that is designed to architect case specific elements that are designed to be more concentrated to a deliverable or a goal. My viewpoint on ‘the hierarchy” that I tread by is that the Chief Enterprise Architect gives direction to the > Enterprise Business Architect and Enterprise IT Architect who gives direction to > Enterprise Data Architects, Enterprise Infrastructure Architects, and the Enterprise Systems Architects. Where exactly does ‘the’ Enterprise Architect sit that encompasses the broadness that you’re looking for? For all intents and purposes, that ‘person’ is embodied in C-level management. Isn’t it?
@Kevin — Thanks for your insight. I’ll more than certainly look into expanding my knowledge from TOGAF and look toward what this mysterious ‘enterprise architect’ truly entails. From a ‘pragmatic enterprise architecture’ approach (not that I’ve actually gone and done the research on what PEA is) I might assume from the title that it’s an architecture framework built on the history of architecture and moving forward based on a ‘lessons learned’ ideology. If that’s the case, how then does the architect plan for the future in a sense that he must focus the objective on maintaining the competitive edge? I’d sooner utilize “Business Architecture” in TOGAF as the vehicle to achieve this. If I work for Apple, what can I do to ensure that Samsung and Nokia are on the back foot year after year? This is how I will design the Transition Architectures that paint the landscape. Is that a bad way to think?
@Christopher: “I really am saying much of this with a crooked grin for stimulating conversation.”
Okay, my turn to apologise for being over-defensive. Do be aware, though, that there are a lot of people around in this space (try some of the ‘EA’ groups on LinkedIn…) who are rabidly egotistic and who cover up their own incompetence and shallow-thinking with insolence and abuse. They’re a real pain to deal with, because they’re not there to learn, or to help anyone learn, they’re there solely to show off and to prop up their egos by putting others down, and they make genuine debate and discussion all but impossible on those threads. Unfortunately your ‘text with crooked grin’ looks and reads almost exactly the same as theirs: now that it’s clear your intent is different, it’s easier to deal with, but do be aware that a lot of us bear a lot of scars from dealing with dangerous fools*, and it’s all too easy to miss your intent when you write in that way.
(*’Dangerous fool’: someone who knows just enough to get others into serious trouble but not enough to get out of it again, too keen to leap into action, and too vain to acknowledge that there might be a problem there…)
@Christoper: “Theirs is an inherent difference between an Enterprise Systems/Solutions Architect and an Enterprise Architect.”
Yes, and then there are those two meanings of ‘Enterprise Architect’ as well. Do read Len Fehskens’ Open Group blog-post on this, via that link in the post above: it’ll really help on this. There are also a couple of related posts of mine, ‘Making sense of architecture roles‘ and ‘Business-architect and enterprise-architect‘, that may also be useful here.
@Christopher: “I suppose my point is that when I think Enterprise Architecture, I use it in the context of achieving Business Alignment.”
The catch there is on what’s meant by ‘Business Alignment’. Too many IT folks seem to think that it’s when the rest of the business lines up with what IT wants to do. Many business-folks – when they think of IT at all – would think of it as when IT actually delivers what they want it to do. In most organisations there’ll be a dozen or more different groups each expecting all the others to align with them. This is what’s known as a ‘wicked-problem‘, and with good reason…
@Christopher: “Is there truly such a title that addresses all elements of an enterprise?”
There’s a role that addresses all elements of an enterprise: it’s called ‘enterprise architect’. Unfortunately – courtesy of the way ‘the trade’ has been scrambled by ‘title-engineering’ and IT-centrism and the like – it’s now almost impossible to get a job with both that role and that title. Most of the the ‘real’-enterprise-architecture work in business is now forced to go under a different title such as ‘business transformation’.
@Christopher: “…you start to lose that level of granularity…”
Yes, that’s exactly the point: again, see that post about ‘Making sense of architecture roles’, about the ‘breadth versus depth’ dilemma. For any enterprise-scope architect, there’s a crucial trick called ‘Just Enough Detail‘, being able to drill-down right into the low-level granularity whilst still holding the whole of the big-picture: it’s not an easy trick to learn… and we’ll always need the help of others to get the balance right across the whole enterprise-scope. Learning how to do that trick fast and well takes a lot of time and experience: you’ll probably gain more than a few grey hairs before you get it right, too… 🙂
@Christopher: “My viewpoint on ‘the hierarchy” that I tread by”
It’s actually not a hierarchy – at least, not in the classic management sense. It’s much more an interweaving of services, focusing on different scopes and different granularities, all interweaving with each other. The interdependencies are such that if you frame it as a management-style hierarchy – each level issuing ‘orders’ to the levels ‘below’ – then the whole thing will break down into an unworkable mess. This is not unusual…
@Christopher: “…that ‘person’ is embodied in C-level management. Isn’t it?”
Yes, that’s Chris Potts’ position, in his book ‘recrEAtion‘ (see the link in the post above), and I’d strongly agree with him there: by definition, the CEO has the responsibility of ‘Chief Enterprise Architect’ for the organisation. In practice, in anything much larger than a startup, the CEO will need to delegate some aspects of that responsibility to others. That’s where and why the distinct discipline(s) and role(s) of ‘enterprise architect’ and the like come into play. But we should never forget that the actual responsibility and authority reside with the CEO and broader executive: we act on behalf of the CEO and suchlike, not as a would-be usurper!
@Christopher: “I’d sooner utilize “Business Architecture” in TOGAF as the vehicle to achieve this”
The catch there is that ‘Business Architecture’ in TOGAF is still solely focused on the parts of ‘the business’ that affect IT: at present, it doesn’t describe anything that won’t impact directly on IT. (That “directly” qualifier is important there: there are a lot of indirect impacts on IT that TOGAF doesn’t describe, yet turn out to be really important to IT, as you’ll soon discover to your cost in real-world practice if you follow TOGAF too closely as your only guide…) The Open Group itself is moving on somewhat from that position: for example, Alex Osterwalder did a keynote at a recent Open Group conference, and Business Model Canvas is probably supported by most EA-toolsets now. But it’s still not in TOGAF as such, and it’s still a long way from a business-architecture that anyone elsewhere in the business would recognise as an ‘architecture of the business’… Do remember that TOGAF doesn’t have all the answers: it’s just one framework amongst many, many others.
@Christopher: “must focus the objective on maintaining the competitive edge”
That’s an objective for enterprise-architecture, yes. Yet it’s an objective that barely applies in government or not-for-profit organisations, and it’s by no means the only object even for commercial organisations. For example, a lot of my current EA work revolves around values-architectures, the way that the organisation’s values pervade throughout every aspect of the organisation and its relationship with the broader shared-enterprise. If you think that that’s irrelevant to enterprise-architecture, consider the situation of a client of mine in Latin America: they’d suddenly plummeted from the most respected-bank in the region to the least-respected – with huge impacts on the bottom-line – yet had almost no idea of how or why it had happened. The reason was that they’d ignored the impact of a broken values-architecture: only when they started paying proper attention to it were they able to start rebuilding their business-position again. Note, too, that in that case the architectural challenges barely touched IT at all: if we’d stuck strictly to a TOGAF-style view of enterprise-architecture, we wouldn’t have been able to help, and the company would definitely have gone bust.
As for the rest, I think I’d best leave it to Kevin to answer that? 🙂
Hope this helps, anyway.
@Tom — I’ll certainly keep the broader view of ‘enterprise architecture’ when I practice ‘enterprise architecture’.
On a different note… I’M TOGAF 9 CERTIFIED!!! WOOHOOO!!!
Congratulations, Christopher – well done! 🙂
My 10c worth.
After not seeing him for > a year, I skyped Tom as he was prepaaring his original response to this. He was dealing with it with his usual proactive, philosphical and polite grace.
I’ve skimmed through all of the above but have this advice for all. The discussion reminds me of the operations of a highly effective village before it becomes a town.
MY ADVICE
While life is a fatal desease we all deal with, REVEL in the nuances listed, be PROUD of the community you are interacting with and ENJOY applying what you have learnt as we are ALL better for going through these interations together.
Last minute addition from my spouse. None of the above matters as 2012 is the last year for planet earth.
To be a CIO you dont need to have any quals, any idiot can get to this level, I’ve worked with plenty of maniacs.
IT people need a lesson in the common sence framework, since many techno boffins dont seem to be able to grasp its concepts.
TOGAF 9, yep, 900 pages of artefacts that never gets put to use.