TOGAF Certified
Finally got round to doing my TOGAF Certified Practitioner exam for IT-architecture (I will not call what they do ‘enterprise architecture…). And happy to report that I did indeed pass, and quite well, too (84%), despite a bunch of highly ambiguous questions about which I duly complained. ::wrygrin::
So now I’s a real IT-architect – look, I got the piece o’ paper ter prove it, ain’t I? 🙂 🙂
And I’m also taking it that I now have the right to start seriously putting the boot into the shambles that is the Open Group’s pretence that TOGAF is an enterprise-architecture methodology, ‘cos it ain’t. Sorry, folks. It has a lot of very good ideas, and some proven approaches and practices, but as it stands it’s so IT-centric as to be nearly unusable for anything else. (I gather it’s marginally usable even for much of current IT-architecture, but I’ll leave the IT-centric types to hammer that one out.) TOGAF is a good start: but for enterprise-architecture we need something that covers the whole of the enterprise scope – not just the IT.
So I’m setting myself a target of rewriting the thing, together with the rework I’ve been doing on Zachman’s similarly-shambolic taxonomy, and putting it out there as another mini-book, before the end of November. (Provisional title: Bridging the Silos: Enterprise Architecture for IT Architects.)
Watch This Space, perhaps?
Tom,
I am very grateful you are getting the word out about this problem. I run a professional association for IT architects called IASA and we are continually hearing from members that a framework doesnt cut it. Further it is actually such a small portion of what we do as architects. The issue that we’ve had as architects (whether software, infrastructure, or other) has been our approach to creating rigor. By that I mean that we have approached this the way we do a large IT problem. Invent a framework and that will solve it…
The IASA is built around a different approach, not just what architects have to know (the nouns if you will) but what we do to be successful. We have broken down the problem from a professional angle. That is, how do we create an architect? What skills do they need and how do we ensure that they have them? While initially daunting we must consider that architecture is by no means more complicated than medicine, yet new doctors (most of which are extremely competent) are create everyday all over the world. So our approach is similar.
I would be thrilled to discuss your views at some point and describe what we currently have and where we are headed. The primary point of the IASA is that architects themselves should be in control of there profession. Thus your direction can have a massive impact.
Totally agree about frameworks – any standard framework not just TOGAF. My experience has been that a one-size-fits-all approach just doesn’t cut it and that different organizations need frameworks that address the concerns of different communities of stakeholders. The selection of viewpoints depends on the organisation, level of ‘architectural maturity’ and culture of the enterprise. That also means that an architecture framework will change and evolve over time.
Having said that, a framework is just that – it’s the content that really matters.
However I’m a little concerned about the idea that Enterprise Architecture is somehow bigger than IT Architecture. Who are we kidding here? Just try going in to an organization and telling them, from within the IT department, you’re going to re-architect their business processes and see what kind of reception you get. Some of us have to put in some effort to try to avoid giving the impression that IT are trying to take over the world.
Talk about scope creep.
I, too, agree that the notion that a framework somehow equates to an architecture, is rather absurd. I do challenge the notion, however, that to re-architect a business process is somehow out-of-scope for IT Architects. I suppose that it really depends on the organization. While it is often true that you will run into challenges should you make such a suggestion up front as suggested, It’s often up to the architect to allow the organization to see the inefficiencies of their current process. I’ve had to to this numerous times. Under the guise of modeling/documenting the current business process in order to better design an IT solution, I’ve been able to ask questions and help lead the organizations management to see for themselves the problems that exist in a process, and how a better process could help them.
Thanks, Joe
I agree entirely that we need to “challenge the notion … that to re-architect a business process is somehow out-of-scope for IT Architects”. The catch is that the business is usually very wary about any attempt to do so “from within IT”, as David Deighton put it earlier. So yes, we either have to do a kind of ‘stealth architecture’, analogous to the ‘stealth foresight’ I described in another post; or else break away from the TOGAF-style delusion that IT is the centre of the business world, and start doing proper enterprise-architecture, in which we start from a whole-of-enterprise perspective, and demote IT to what it really is, which is just one more service-strand within the overall enterprise.
The hard part is gaining the respect of the business: in most organisation’s I’ve dealt with, it’s not so much been an ‘IT/business divide’ as a gaping chasm of mutual distrust. As you suggest, asking the right questions is a good place to start! Yet we also need to have a good grasp of the human sides of the process equation – treating people as people, not machines or ‘service units’. And for many IT folks, who may well have gone into engineering specifically so that they didn’t have to deal with people, that can be a large ask…
All I’m doing here, I guess, is raising a flag on this as a genuine issue that we must address if we want enterprise-architecture to mature into a valid whole-of-enterprise discipline.
Further comments / experiences / suggestions much appreciated!
I feel the IASA skill set and TOGAF (and other) frameworks are essential.
IASA skill set do prepare an individual to become an architect.
Frameworks tells us how to architect a system
The important point here is, you need to learn the skill sets and you also need to understand some matured frameworks and then design (or redesign) your enterprise architecture.
Can you design a system without having the basic skill sets (like IASA), by only mastering an architecture framework (like TOGAF)? Yes, but then you are lucky. Lucky that the methods, tools and patterns specified suited your organization.
Can you design a system only by learning the basic skillsets and not even looking into matured frameworks, Hmm yes, then you are a genius. How many organizations HR will know that you are a real genius?
Your comments are highly appreciated.
Hi Stanly – thanks for the comments. Because this is a fairly old post, and the answer’s quite long, I’ve created a new post: http://weblog.tomgraves.org/index.php/2008/07/02/togaf-iasa/ . Hope it makes sense, anyway? – and over to you there for further comments, if you wish.