Guideline: How to Deconstruct TOGAF to Meet Your Specific Needsby Roger Evernden

Decomposition and deconstruction are both useful techniques in enterprise architecture, but of the two, deconstruction is less well known or understood. Which is a pity, because of the two, deconstruction is probably the more useful technique.

In this guideline I’ll explain what deconstruction is, and then show how you can use it to help you customize and adapt the TOGAF documentation to meet your specific needs.

• In a similar way, you might also fail to adequately separate architectural concerns. It would be too obvious if you failed to separate Data from Application, because that is now a standard EA practice, but you could easily design an architecture in which Business Rules were deeply embodied in Products and Processes – making it difficult to make simple changes to either Products, Processes or Business Rules!

• Another trick is to make sure that you don’t translate stakeholder concerns into architectural explanations and constraints. You can impress stakeholders by listening carefully and sympathetically to their concerns, without ever explaining exactly how the architecture causes the problem. Stakeholders like architects who appear to listen to them; they’ll never realise how you avoided providing a genuinely architectural solution.

• And you can stunt the sustainable evolution of an enterprise architecture by only thinking about immediate needs, instead of also including a longer-term direction. Only think about the next step, not any future options it might enable. This is a great tactic – in some cases you might even need to totally undo some of the work that you’ve previously done at a later stage.

TOGAF Series #54 | ATL002:54

© Copyright 2016 Good e-Learning. All rights reserved. No part of this publication may be reproduced, resold, stored in a retrieval system, or distributed in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner. Such requests for permission or any other comments relating to the material contained in this document may be submitted to: marketing@goodelearning.com. Good e-Learning is a trading name used by

Educational Systems Ltd. The Open Group® and TOGAF® are registered trademarks of the Open Group in the United States and other countries

© Copyright 2016 Good e-Learning. All rights reserved. No part of this publication may be reproduced, resold, stored in a retrieval system, or distributed in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner. Such requests for permission or any other comments relating to the material contained in this document may be submitted to: marketing@goodelearning.com. Good e-Learning is a trading name used by

Educational Systems Ltd. The Open Group® and TOGAF® are registered trademarks of the Open Group in the United States and other countries

• In a similar way, you might also fail to adequately separate architectural concerns. It would be too obvious if you failed to separate Data from Application, because that is now a standard EA practice, but you could easily design an architecture in which Business Rules were deeply embodied in Products and Processes – making it difficult to make simple changes to either Products, Processes or Business Rules!

• Another trick is to make sure that you don’t translate stakeholder concerns into architectural explanations and constraints. You can impress stakeholders by listening carefully and sympathetically to their concerns, without ever explaining exactly how the architecture causes the problem. Stakeholders like architects who appear to listen to them; they’ll never realise how you avoided providing a genuinely architectural solution.

• And you can stunt the sustainable evolution of an enterprise architecture by only thinking about immediate needs, instead of also including a longer-term direction. Only think about the next step, not any future options it might enable. This is a great tactic – in some cases you might even need to totally undo some of the work that you’ve previously done at a later stage.

• If you only partially define building blocks and their interfaces it will be difficult to compose and configure any target architecture effectively. For example, you might define a building block, but leave out an interface to a key data element, which renders a calculation meaningless.

• Related to this, if you fail to describe architecture states (current, intermediate or target) as patterns, then it is much harder for anyone to fully understand the composition and configuration of that architecture. You can simply create lovely colourful graphics that look great, but without showing the underlying patterns.

• And if you tightly bind the architecture to a particular solution or technology, instead of separating architectural and solution understanding, then it will be much harder to move on to new or emerging solutions in the future.

• As your “architectural” plans develop, you can cause no end of unmanageability by ignoring governance and contractual agreements altogether, thus allowing implementations to introduce exceptions, waivers, and divergence from any architectural roadmap without them having to worry about principles, guidelines, directives, or formal reviews.

• I’ll finish with two big tips. In many organizations it’s possible to develop new architectures without even taking stakeholder concerns into account! If you want to you can still hold meetings with stakeholders, but don’t bother taking notes or listening. But often you can get away without even meeting many of the key stakeholders. This gives you free reign to develop your ideas without having to think about genuine needs.

• And here’s the big one: make sure you spend hours developed detailed artefacts that are difficult to understand, unnecessarily detailed, or irrelevant. You can quickly “document” all sorts of things that are apparently necessary to architectural understanding; anyone following in your footsteps will waste even more time trying to make sense of this information jungle!

I hope you enjoyed reading these “tips” – and maybe you recognised some of them from your own experiences. But most of all I hope that this humorous approach will help you avoid these traps, and develop architectures that are easier to manage!