Dave Hornford Addresses Misconceptions Surrounding TOGAF

 Mike The Architect Blog

I have gotten a surprising (or maybe not so surprising) discussion on the TOGAF Demystification Series. In one of the posts entitled, “TOGAF Demystification Series: TOGAF Sucks, Incomplete And Overly Complex” there were many comments made about this one in particular. All of the comments made for an interesting conversation but I did like the thoroughness of one in particular. I thought Dave Hornford made some extremely salient points and provided a bit of context from the perspective of the Chair of the TOGAF standard.

Since these great responses were buried in a comment thread I decided that it would be beneficial to all of you to promote this to a post as well given the meaningful content.

Note: For extended context click on the link above to see the full context of the responses. I have left comments unedited. 

 

Mike The Architect Blog: Dave HornfordDave Hornford Addresses Misconceptions Surrounding TOGAF

Dave Hornford is a Managing Partner for Conexiam as well as the Chair for the Open Group Architecture Forum (TOGAF)

 

Addressing comments about the quality of TOGAF

Is it as good as I want it to be, not a chance. Can I change it? Of course, all I have to do is obtain a consensus of a project team. The Architecture Forum then reviews this consensus, and then the member companies of the Open Group review it. At every point comments, concerns, objections & improvements must be addressed by consensus. I live Mike’s challenge.

In response to a misunderstanding of how TOGAF is applied and the meaning behind Requirements Phase in TOGAF

I do not understand the charge that TOGAF fails because it focuses on requirements? All I can assume is that special meaning is carried into TOGAF. Wherever possible in TOGAF we try to use a concept that can carry a range of specific detail – requirements is one of my favorite examples. TOGAF defines requirement as “a statement of need that must be met by a particular architecture or work package”.

TOGAF’s requirements are a nice broad concept – a statement of need that must be met by the architecture. What else an I going to find in the strategy, goals, objectives, hopes, fears, dreams, courses of action, and constraints other than requirements? The set of needs that must be met by the architecture.

Further, no weaseling in TOGAF. If we follow the thread in requirements & stakeholders, TOGAF highlights that best practice is provide a name. No hiding behind vague assertions like ‘shareholder value’, or ‘the strategy’. Instead we take those requirements and trace them back to a stakeholder. Show me who wants something and then I can perform trade-off between that stakeholder’s requirements and the requirements of the other stakeholders. I can weigh, assess, rank, and refine. And following best practice: review with my stakeholders and use the governance process to provide assurance. My only escape from this tyranny is to get one-or-more stakeholder’s to change the requirement, at which point I have a different set that must be met. No wonder TOGAF talks about iteration.

Doing real architecture is hard because of this point – it must address the complete set of requirements. No hiding. Get out in the open and show your work. Describe a target that best addresses the complete set of requirements and deliver a roadmap that will move the organization from where it is to where it wants to be within the capability of the organization to change. (Phase A, B, C, D, E & Requirements Management)

Second, I cannot see how TOGAF’s ADM can be considered a solution approach. If I’m doing solution architecture why would I develop an Architecture Vision (Phase A), develop a Roadmap (Phase E) then integrate the Implementation & Migration Plan into the organization’s portfolio (Phase F) and manage the lifecycle of my architecture (Phase H). I’ve heard many ways people wrap a solution approach, complete with proof-of-concept and RFPs into the ADM. But, in my opinion it’s a stretch.

 

Dave’s usage of TOGAF in his engagements

Do TOGAF or do EA? Sorry I don’t do TOGAF. I get paid to either deliver useful architecture or improve the capability of an EA team. TOGAF is a tool, not a goal. It is an EA Framework that provides scaffolding for capability, content & method. To quote TOGAF Part I, “the purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy”

In my opinion, too many words. In essence darned good – optimize across the enterprise the activity of the enterprise to create an integrated environment that is agile and supports current strategy… That’s worth getting out of bed for.

 

Addressing TOGAF and ArchiMate linkages

Lastly, you contend TOGAF fails because it isn’t hand-in-glove with Archimate. Here, I may run into trouble at the next set of member meetings. Archimate is a subset of the concepts required to completely describe an enterprise architecture.

This is not a slur on Archimate, by being a subset it allows me to use a reasonable set of entities, perform traceability between the entities and have a graphical notation I can learn quickly. Beautiful. Truly beautiful.

But, if I need to describe organizational culture, fully map strategy, associate capital allocation, participation of multiple third parties, return on equity and taxation, identify information entities by provenance & usage restriction, clouds and account for last mile connectivity to a specific restricted platform – I may find Archimate limited. When I pull out the complete set of modeling techniques to describe these entities I may have the richness of a 1/2 dozen domain specific modeling techniques and have to perform acrobatics to link them. There never is a free lunch. Don’t forget, I enjoy aerobatics.

When I do EA I need the freedom to describe what I need to describe to address the problem at hand – I will never let the toolset be constrained to a general-purpose saw. Sometimes a spoke shave, or coping saw or Mintzburg’s Organigraphs are needed. By the same token, I am very glad that I have a general-purpose tool that works reasonably well most of the time.

TOGAF aligns to my need for freedom and my expectation for a comprehensive toolset – there is a reasonable content-meta-model that provides a reasonable set of entities. I can read the mapping papers to Archimate. Or, I can roll my own and use Mintzburgh’s Organigraphic, Osterwalder’s Business Model Canvas & the OMG’s Business Motivation Model: exquisite richness and an integration challenge. Clearly a job for daveML. Or, use Archimate, and have a reasonable set that provides pre-defined end-to-end traceability. TOGAF is clear, use the tool needed. Describe what is necessary to understand, create a target that meets the set of stakeholder requirements, create a roadmap to traverse the gap and govern the builders to keep them on the path of goodness.

Regardless of my tooling, if I have the elements of TOGAF calls for – governance, appropriate team, integration with corporate process, consistent method to develop an architecture & roadmap, stakeholders and requirements I have the underpinning to create a very good understanding of how the enterprise ‘works’. Then I can do my job and optimize the future against the complete set of requirements. Good thing TOGAF is general purpose and provides a scaffold so I can address the problem I have in a manner consistent with the guy in the next office. When we use a minimum set of consistent entities we can even use each other’s work – although the guy in the next office does look askance at Organigraphics and Goal Structuring Notation.

I’d be happier if TOGAF was crisp on the distinction between concept and instantiation. Today I sometimes read an instantiation and have to derive the concept so I can re-instantiate appropriate to my problem. Perhaps the next release will make me happier.

 

Call to Action

I’ll re-iterate Mike’s challenge. Want to make the EA world better, join us in the Architecture Forum. But, be prepared to work to consensus with many of the world’s leading practitioners. It’s a tough crowd. Specialist boutique consultants, global consulting practices and some of the most advanced in-house architects will review your work. You will be challenged to find what consistently works for a very broad set of problems. Not just mine, or yours, or Mike’s.

 

You can find out more about Dave Hornford at:

@davehornford
http://www.conexiam.com

 

Advertisements

0 thoughts on “Dave Hornford Addresses Misconceptions Surrounding TOGAF”

  1. 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).

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s