This is AdrianGrigoriu's Typepad Profile.
Join Typepad and start following AdrianGrigoriu's activity
Join Now!
Already a member? Sign In
AdrianGrigoriu
Recent Activity
Hi Mike, I hope you are not going to re-open the discussion on TOGAF we had some time ago. Indeed, some will indeed say that they already know and discussed these issues long ago. Apologies to them. Nonetheless, I can see merit in uncovering TOGAF issues for those who still struggle to employ it. That being said, ADM Phases B, C and D are part of an Architecture Development Method indeed. But the rest of the phases like F,G and H are rather part of an Enterprise Transformation process which is not the responsibility of an Enterprise Architect, except perhaps in an advisory role. ADM should perhaps clearly state that for these phases there is latitude to employ proper business methods. The name ADM (Architecture Development Method) is a misnomer as such, not suitable for this phases, because the focus of the whole process is not to design or even implement the architecture itself but to transform the enterprise, eventually employing an architecture. Moreover, for some reason, I don't think that any business would like to use ADM as the enterprise transformation process. What do you think? The current architecture development process in phases B, C and D does not use requirements. I think we would all agree with that because the only task in these phases is to discover and document the current EA, no matter what requirements or modeling method one uses. The Architecture Vision in phase A should be essentially based on the Enterprise Vision. The enterprise strategy and goals are the starting point for that. These constitute, if you like, the requirements for the target enterprise and its architecture. Besides, in practice, the EA team has been never known or asked to collect all the requirements for the transformation of an enterprise. That is matter for individual solution projects to document, analyse and implement them. The transformation roadmap, strategy, planning and target architecture would consider the outcomes of these programs rather than their requirements. By the way, there cannot be an Architecture Vision in phase A before one discovers and documents the current architecture in the phases B, C and D. One has to follow an evolutionary approach, rather than revolutionary, that starts from where you are and then build on it. The business management and stakeholders would be appalled to learn that the EA wishes to start from "tabula rasa" to re-design the enterprise from scratch. ADM is indeed more of a solution development process as it was also stated in one of the early TOGAF releases because: * any solution starts with the requirements collection and analysis and takes into account their changes at each iteration * a solution development process includes indeed phases like F, G and H - that is implementation... Besides, as above, there is nothing in the ADM that makes it applicable at the enterprise level. On the contrary, phases F,G and H do not apply as explained above. Since TOGAF does not do modeling either, as it was stated by you before, how to design and join these artifacts is your problem. One does TOGAF and not EA because the architect attempts to deliver according to TOGAF's list of deliverables - which is in fact a small and prescriptive subset out of an unlimited number of potential EA artifacts. When asked to come with an EA, an architecture blueprint, TOGAFers would deliver just a few views, according to methodology, which would satisfy just a small number of stakeholders. In any case, the outcome of TOGAF, is not an integrated EA but a number of independent and disjoint enterprise artifacts listed in a table. These, may enterprises had long before the advent of TOGAF or the EA for that matter. Besides, who in this world, would issue the EA team with a formal "Request for Architecture Work" as specified in the TOGAF ADM? To my knowledge, Archimate and TOGAF still have, after a long time, different if not conflicting metamodels. One reason is because TOGAF has different and even variable definitions for concepts such as for Functions, never mind a plethora of alternative concepts such as building blocks, capabilities, services which are not sufficiently differentiated to be properly modeled. But I think I am not the only one to observe this state of affairs. On top, TOGAF is said to be a set of tools. What tools, can we specify what they are? Isn't ADM a process though? Then it is stated that you may add any tool you like. Yet again, what tools, for what and when to use them? What is missing in TOGAF that we have to come up with? "Mintzburgh's Organigraphic, Osterwalder's Business Model Canvas & the OMG's Business Motivation Model... daveML" only to quote a few of them from you. What about Value Chains, Streams, Operating Models etc? But then how much does TOGAF cover out of this plethora of methods, taking into account, at least in my opinion, that it is not a proper architecture development or enterprise transformation process? Now, if anyone wishes to join the Open Group to attempt to derail TOGAF from its path, please do that. There is just the small matter of cost and time spent to render TOGAF usable, since you are not paid to do theoretical framework work but the EA of your Enterprise. Then, in my experience, it's easier to move a mountain than an organization which owns such a legacy cash cow and people of various companies in this world who have their own vested interests, sometimes to preserve the status quo. Honestly, try my FFLV-GODS. Everything you need is in there. No set of tools, no eternal discussions on the meaning of concepts. There is a clear differentiation between functions and processes (flows), capabilities and services that can be explained on the three-dimensional framework (that comes with proper metamodel). There is an architecture development process, an enterprise transformation process, a governance framework (principles, maturity measurement, roles, best practices, team organisation...), business modeling guidelines and GODS - a generic business architecture based on value chains, functions and flows that you may use to jump start your business architecture -, IT architecture templates, a strategy design framework etc. You would dare then look into the eyes of your customers. I am also just publishing a book of blogs posted over the past seven years which selects and groups my own EA posts from several sites (such as ebizq and ITToolbox).
Mike, you asked "If TOGAF sucks, aren't we to blame?" You have not proved that TOGAF does not suck. That we are to blame for accepting something that sucks is a different matter. There are explanations. People usually, prefer to use the frameworks coming from reputed firms or open fora because they believe that there are less chances to suck. And they would readily adopt them because not everybody wants to define own EA and its framework, again and again. They just need to deliver EA not to re-invent it. Besides people claim they do TOGAF because employers demand it now. And TOGAF does not easily vanish because it makes profit for too many today. TOGAF has not acknowledged or integrated frameworks like Zachman, concepts like business and operating models... So much about its openness to change. that "TOGAF is incomplete" TOGAF ADM is a solution rather than EA development process. It just tell us the phases of a process that those with experience know better. That's why it talks endlessly about requirements rather than strategy, roadmaps... and business or operating models for that matter. TOGAF is not the modeling framework we all need, either because it does not tell us how to put the parts together in the whole. On top, TOGAF is IT. And is not even integrated with Archimate. I would say that "incomplete" is not strong enough. that "TOGAF is not complex". Its content is not, the form is though. It's simply a too large, unstructured, not integrated collection of views coming from various work groups. How do you find an item when you need it? The only thing hard to understand is what to use, how and where is it in that tome. And how does one reconcile all those conflicting or overlapping definitions? They did not even bother to align definitions. There are surely, good bits but how do you find them in that lot? The reality is that most of us do the training and certification but don't use TOGAF in practice if you watch what they say in discussion groups. Except bits and pieces. To me you either do TOGAF or EA. At the end of the day, the firms lose though. See this too: http://www.ebizq.net/blogs/ea_matters/2011/06/togaf.php http://www.ebizq.net/blogs/ea_matters/2012/04/are-requirements-necessary-for-ea.php http://www.ebizq.net/blogs/ea_matters/2012/10/can-togaf-be-extended-to-deliver-ea.php http://www.ebizq.net/blogs/ea_matters/2012/04/are-requirements-necessary-for-ea.php
AdrianGrigoriu is now following The Typepad Team
Aug 12, 2010