HomeApp Dev Methodologies

Bailing on TOGAF

Like Tweet Pin it Share Share Email

Your resolutions for 2018:

Resolution #1: Send me ManagementSpeaks. Keeping an ear open for these is an excellent way to keep yourself grounded. Also, my supply is getting low.

Resolution #2: Send KJRs you like to your friends, family, colleagues, and especially people you don’t like and want to irritate. They’ll thank you. Except for the ones who won’t.

Resolution #3: Let me know how I’m doing … not only on the subjects I write about, but also on whether I’m writing about the right subjects.

Resolution #4: Give up on TOGAF.

This one might need a bit more explanation …

For those unlettered in the arcana of enterprise architecture, TOGAF stands for The Open Group Architecture Framework. According to the Open Group, TOGAF®, an Open Group Standard, is a proven enterprise architecture methodology and framework used by the world’s leading organizations to improve business efficiency.

Before diving into the important reasons to abandon TOGAF, a question: In what way is TOGAF proven? I Googled “TOGAF SUCCESS RATE” and came up dry. So far as I can tell neither the Open Group nor anyone else has even defined a TOGAF success metric, let alone tracked improvement against a baseline.

And a quibble: According to the above explanation, TOGAF’s goal is business efficiency. But … efficient with respect to what? Cost? Electrical consumption? Weight loss per hour of exercise? “Efficient” is meaningless without this information. And anyway, efficiency isn’t always what’s most desirable in a business. Effectiveness is the better goal; efficiency is one form of effectiveness among many. Target the wrong goal and the rest really doesn’t matter.

More important (but not most important) is a TOGAF intrinsic: It’s a high overhead approach to business and technical architecture management that ends up fostering rigidity rather than agility.

Documenting the current state is labor intensive. Designing the desired future state is labor intensive. Maintaining the documentation for both as projects finish and IT deploys new or changed information technology is labor intensive.

Meanwhile, attempts to secure funding for architecture remediation generally fail in the competition for budget and staffing with projects whose purpose is delivering direct business value.

But we’ve covered this ground before in KJR. What’s new that makes TOGAF abandonment a 2018 imperative?

TOGAF’s foundation contains a fundamental flaw. We’ve been able to wallpaper over it so far, but won’t be able to ignore it much longer. The flaw: its fixed-layer model.

In the world according to TOGAF, which to be fair has, until today, been quite similar to the world according to KJR, architecture has four layers with well-defined boundaries: the Business layer, Application layer, Data layer, and Technology layer.

But their boundaries are increasingly blurry.

Start with the technology layer. It’s really two distinct layers, infrastructure and platforms.

Infrastructure includes everything applications run on and data are stored in and managed by: facilities; networks; virtualization technology; servers, both physical and virtual; and so on.

Platforms are the tools IT uses to build applications. Except that in many cases the tool IT uses to build an application is an application, not a platform. IT organizations create new capabilities using tools or APIs built into ERP packages, Salesforce, and, for that matter, SharePoint all the time.

And it’s even messier than that, because increasingly, IT doesn’t build applications using just one underlying application as a platform. IT uses an enterprise service bus (ESB) or some equivalent integration technology to create a virtual “source of truth” service out of a collection of “systems of record.”

It builds applications out of these services rather than making direct use of application APIs.

Unless they’re expert systems built out of business rules … and it isn’t remotely clear whether business rules are code or data.

Then there’s intersystem integration, something TOGAF has never represented well. Too bad, because in my experience, integration is where most of the architecture improvement opportunities lie.

Somehow, most companies have still failed to replace their tangle of custom, point-to-point, largely batch, poorly documented and increasingly fragile inter-system interfaces with well-engineered integration. And yet even depicting systems interfaces and integration is pretty much an afterthought for TOGAF and its brethren.

SOA (service oriented architecture) with an ESB provides tools for building engineered integration, but not a methodology for designing it. Documenting the current mess? Even less.

So stop trying to implement TOGAF. Instead, clean up your interface tangle while waiting for the Open Group to address TOGAF’s deficiencies.

And finally …

Resolution #5: Stop making resolutions. Resolutions motivate people to be better than they are by making them feel guilty when they don’t live up to them. But really, don’t you have enough people in your life trying to make you feel guilty without piling on yourself?

# # #

Elsewhere in the news: Check out Bob’s latest in CIO magazine: “How to kill a dead project.” Okay, that isn’t really a resolution. Check it out anyway.

Comments (4)

  • Thanks for this.

    First came Zachman. followed, somewhere in time by TOGAF. And other “frameworks”.
    They’re all good… if you use them well.

    I’ve heard people say “Let’s do Zachman” and “We’ve adopted TOGAF”. Silly.

    Zachman offers an effective way to think and organize stuff. Very good. TOGAF offers a few good ideas (BADT is a good starting point, before considering the complexities you outline) layered in thousands of pages of fairly incomprehensible money-making tutorials. Which are rarely (ever?) put into practice.

    Frameworks are not the means, the method, the end goal. They should simply act to help your brain to put some order over the chaos. For me, Zachman works for that. TOGAF really doesn’t as much.

  • I retired from IT management a few years ago, but still faithfully read your work. I think it makes me better at what I’m doing in retirement. I stopped doing resolutions a few years back. Now I schedule tasks for myself instead.

  • Wow! Two fine articles for the price of one. Keep up the good work – I certainly have learned good things from it.

    I would like to see columns like the sexual attraction piece with a bit more frequency. They speak to the deeper dynamics every good manager has to be able to better address, even though society itself is still trying to figure things out. Like a bear stirring up the bees’ nest to get the honey of truth and better understanding from us all.

    I’ll disagree with you, in a way, when you say the problem with TOGAF is that the boundaries are blurry. I think the boundaries are actually clear, but few users like to acknowledge them because with those boundaries comes accountability for technology few sufficiently understand. Which breeds covert fear and anxiety for any aspect beyond the use of the tool. But then, how many organizational cultures really support the reality of distributed and flexible information and computing power, all in service to the organization they work for?

    And, without the support culture, how can management implement the policies to make something like TOGAF be of real value to the organization? Now, what that culture should like? Beyond speculating that at least part of the answer could lay in applied diversity, I have no idea.

    But, whether I agree with you on all points or not, simply posing the question, I believe, makes me and your other readers the wiser.

  • You had me at “It’s a high overhead approach…” I hope you made a resolution to keep writing! You are often a bright spot in a week filled with poorly written stories about the state of the world.

Comments are closed.