I can read the website blurb and be impressed by the alleged benefits, but I haven't worked anywhere or with anyone who followed the TOGAF (or any alternative) architecture framework.

Our organisation has declared itself dedicated to moving from what is currently a fairly shambolic design & development model towards something approaching a modern structured process.

Things like TOGAF have been mentioned as helping achieve a world-class enterprise development environment (!) but I'm convinced that no-one here really understands the real-world benefits that wholesale adoption might bring and, perhaps more importantly, the effort/pain required to achieve the same.

Do you have experience in using TOGAF or similar to wrestle control in an organisation? Do you think that use of the framework brought any benefit?

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

3

I don't have any TOGAF experience, so I'll answer in this comment instead. After reading the link, TOGAF looks very complex and highly academic. I suspect you'll never make it through the change. You are in a "shambolic development model" and that is bad, but why go to the other extreme opposite (which is just as bad)? Aim a little lower. Find a nice middle ground instead which works for you.
–
Martin WickmanDec 17 '10 at 12:14

Thanks to @Jon_Hopkins for the TOGAF definition
–
LunatikDec 20 '10 at 9:08

1

Lookingatthe TOGAF website for 10 seconds reminds me too much of stuff like HL7, CDA and other absurd specifications that are an enormous hassle.
–
whatsisnameDec 5 '12 at 4:09

"Things like TOGAF have been mentioned as helping achieve a world-class enterprise development environment" as have hundreds of other things...
–
jwentingAug 28 '14 at 8:26

4 Answers
4

The main thrust of TOGAF is about standardizing terminology and the various architecture diagrams. Which is in itself a good thing BUT its very vague about what should go into the diagrams and what practical use can be made of them.

Also I find it difficult to take seriously any standard which comes from the organisation responsible for the CORBA fiasco.

I would seriously recommend the TOGAF course book to anyone who has trouble sleeping. The repetitive style with pages full of the same statement re-worded five different ways make it impossible for me to keep my eyes open for more than four pages. :-)

As far as Enterprise Architecture is concerned Zachman is still king of the heap.

I suppose usage of TOGAF or similar becomes useful when the company and especially its ICT landscape hits some big size. One really big company (employs +25k people and has stack of +100 various IT systems) where I was doing my internship is using TOGAF. And it's concepts and approaches are referenced in architecture defining papers throughout projects they do.

One of the benefits that I could really feel - is that they have common language for numerous stakeholders that are involved on development-architecture-business layers.

Another point that is stated in TOGAF is that you will need to adapt things TOGAF has (like ADM) for your company's scope - then you will get "our organization's architectural framework" which will have good genes so to say.

Well, I have seen a couple of companies that were trying to adopt methodologies/frameworks similar to TOGAF (but not TOGAF) and in all of these cases I just witnessed failures.

As long as I have seen, there are at least three reasons for such failures:

These metodologies/frameworks were so complicated that required a team by themself to be managed/adopted/implemented. The company ended up in doing only that. No time/people left for the real job. Even worse: this stuff interfered heavily with the day-to-day work.

These metodologies/frameworks do not actually try to make the enterprise architecture and its business processes more manageable or more reliable. They just try to organize them (in a very academic way). This makes the whole thing more understandable/palatable from the (external) point of view of the management/business people but do not make it any better for the people who do the real work.

These metodologies/frameworks take for granted that the management/business people know what they want to produce/provide beforehand. This is often not true. Making a marketable product/service is often a matter of experimenting and changing. The real nature of the product/service being produced/provided is really known only at the end of a long R&D process, not at the beginning. Trying to formalize/organize such an explorative process is just plain unrealistic.

As jkhollhepp said, If you have to re-organize a complicated architecture, it could be very hard to start from a blank page. In this case, using TOGAF or a similar framework as a starting point can be helpful. Despite this, I have the feeling that you should use TOGAF as a theoretical/conceptual model only. Any attempt to actually use it should be avoided until someone is able to demonstrate that it is actally required or unavoidable.

I've looked at TOGAF and my company uses other architectural frameworks but I haven't seen that one in use. I would say that these don't give you much "out of the box". But, if you use them to help structure your thinking around your system architectures, and adapt it to the particulars of your organization, it can be helpful.

Think about it like this. It is really hard to start from a blank page and say "let's write up our organization's architectural framework". Starting from TOGAF might be easier than starting from a blank page.