Deliverables versus Outcomesby Roger Evernden

The TOGAF® documentation places a great deal of emphasis on various deliverables that are produced at different stages in the Architecture Development Method (ADM).

For example, Chapter 36. Architecture Deliverables, provides descriptions of the deliverables referenced in the ADM; it explains where they are typically produced and consumed, and outlines the purpose and content of each deliverable.

These deliverables are referred to again and again – in the overview of the ADM (Section 5.2.2 Basic Structure), and in the details for each Phase of the ADM.

So it is hardly surprising that many students who are new to TOGAF see these deliverables as the most important result from using TOGAF and the ADM.

But there is a very important distinction between a “deliverable” and an “outcome” – which sometimes gets lost when TOGAF is followed too literally and rigidly.

A “deliverable” is something tangible and physical that architects produce as part of their work. It is a work product or output. TOGAF provides a formal definition of a deliverable in Section 3.33 Deliverable:

“An architectural work product that is contractually specified and in turn formally

reviewed, agreed, and signed off by the stakeholders. Deliverables represent the output

of projects and those deliverables that are in documentation form will typically be archived

at completion of a project, or transitioned into an Architecture Repository as a reference

model, standard, or snapshot of the Architecture Landscape at a point in time.”

TOGAF Series #58 | ATL002:58

© 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

If you follow TOGAF to the letter, then a deliverable takes on huge importance – it is the thing that you are contractually bound to produce – and if you don’t get it produced, accepted, or signed off, then your stakeholders might get upset and annoyed.

But deliverables aren’t what really matters – to enterprise architects, and more importantly to stakeholders. Deliverables are only ever a means to an end.

Which is where outcomes fit in. Now the word “outcome” doesn’t get a formal definition in TOGAF, and this word isn’t used as frequently as deliverable. But outcomes are what EA is really all about. What matters is that we make the necessary, relevant, or appropriate changes to the architecture in order to address stakeholder concerns and requirements. And this point is made several times in the TOGAF documentation, so it might be useful to emphasise that here:

• “The purpose of the Architecture Vision is to provide key stakeholders with a formally agreed outcome.” [Section 36.2.8 Architecture Vision]

• Governance is “the discipline of monitoring, managing, and steering a business (or IS/IT landscape) to deliver the business outcome required.” [Section 3.39]

• A stakeholders is “an individual, team, or organization (or classes thereof ) with interests in, or concerns relative to, the outcome of the architecture.” [Section 3.68}

• “The business imperatives behind the enterprise architecture work drive the requirements and performance metrics for the architecture work. They should be sufficiently clear so that [the Preliminary Phase] may scope the business outcomes and resource requirements, and define the outline enterprise business information requirements and associated strategies of the enterprise architecture work to be done.” [Section 6.2.3]

• “Identified Transition Architectures and work packages should have a clear set of outcomes.” [Section 13.4.11 Create the Architecture Roadmap & Implementation and Migration Plan, in Phase E: Opportunities and Solutions]

• “Finally [the last step in Phase E], update the Architecture Vision, Architecture Definition Document, and Architecture Requirements Specification with any additional relevant outcomes from this phase.” [Section 13.4.11 Create the Architecture Roadmap & Implementation and Migration Plan]

• In Phase F: Migration Planning the first step is pretty much all about outcomes! It mentions business outcomes as part of business planning, enterprise architecture, portfolio/project management, and operations management. [Section 14.4.1 Confirm Management Framework Interactions for the Implementation and Migration Plan]

• The second step in Phase F says that “Business Value has to be defined as well as techniques, such as the value chain, which are to be used to illustrate the role in achieving tangible business outcomes.” [Section 14.4.2 Assign a Business Value to Each Work Package]

It’s also important to emphasize that the key point of capability-based planning, as discussed in Chapter 32, is as “a business planning technique that focuses on business outcomes.”

So please remember – TOGAF recommends contractually defined deliverables, but you would not be doing your work as an architect unless you deliver the desired outcomes!