14
 2/17/2015 Busi ness Scenar i os http://webcache.go ogleusercontent.com/search?q=cache:- tcj fr64f6QJ:pubs.open group.org/archi tecture/togaf8-doc/arch/chap34.html+ &cd=2&hl =en&ct= cl 1/14 Text-only version This is Google's cache of http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap34.html . It is a snapshot of the page as it appeared on 15 Feb 2015 05:53:06 GMT. The current page could have changed in the meantime. Learn more Tip: To quickly find your search term on this page, press Ctrl+F or -F (Mac) and use the find bar.   You are here: TOGAF 8.1.1 Online > Part IV: Resource Base > Business Scenarios <<< Previ ous Home Next >>> Business Scenarios Introduction | Benefits of Business Scenarios | Creating the Business Scenario  | Contents of a Business Scenario | Contributions to the Business Scenario | Business Scenarios and the TOGAF ADM | Guidelines on Developing Business Scenarios | Guidelines on Business Scenario Documentation  | Guidelines on Goals and Objectives | Summary This chapter describes a method for deriving business requirements for architecture and the implied technical requirements. Introduction  A key fact or in the suc cess of an enterpr ise architect ure i s the extent to which it is linked to business requirements, and demonstrably supporting and enabling the enterprise to achieve its business objectives. Business scenarios are an important technique that may be used at various stages of the enterprise architecture, principally the Architecture Vision and the Business Architecture, but in other architecture domains as well, if required, to derive the characteristics of the architecture directly from the high-level requirements of the business. They are used to help identify and understand business needs, and thereby to derive the business requirements that the architecture development has to address.  A business sc enario describes:  A business process, application, or s et of applications that can be enab led by the architect ure The business and technology environment The people and computing components (called "actors") who execute the scenario The desired outcome of proper execution  A good business scenar io is representative of a significant business need or problem, and enables vendors to understand the value to the customer organization of a developed solution.  A good business sc enar io is also "SMA RT": Specific, by defining what needs to be done in the busin ess Measurable, through clear metrics for success Actionable, by: Clearly segmenting the problem Providing the basis for determining elements and plans for the solution Realistic, in that the problem can be solved within the bounds of physical reality, time, and cost constraints Time-bound, in that there is a clear statement of when the solution opportunity expires Guidelines on Goals and Objectives provides detailed examples on objectives that could be considered. Whatever objectives you use, the idea is to make those objectives SMART. Benefits of Business Scenarios

Business Scenarios

Embed Size (px)

DESCRIPTION

Business Scenarios

Citation preview

  • 2/17/2015 BusinessScenarios

    http://webcache.googleusercontent.com/search?q=cache:tcjfr64f6QJ:pubs.opengroup.org/architecture/togaf8doc/arch/chap34.html+&cd=2&hl=en&ct=cl 1/14

    Textonlyversion

    ThisisGoogle'scacheofhttp://pubs.opengroup.org/architecture/togaf8doc/arch/chap34.html.Itisasnapshotofthepageasitappearedon15Feb201505:53:06GMT.Thecurrentpagecouldhavechangedinthemeantime.LearnmoreTip:Toquicklyfindyoursearchtermonthispage,pressCtrl+ForF(Mac)andusethefindbar.

    Youarehere:TOGAF8.1.1Online>PartIV:ResourceBase>BusinessScenarios

    BusinessScenarios

    Introduction|BenefitsofBusinessScenarios|CreatingtheBusinessScenario|ContentsofaBusinessScenario|ContributionstotheBusinessScenario|BusinessScenariosandtheTOGAFADM|GuidelinesonDevelopingBusinessScenarios|GuidelinesonBusinessScenarioDocumentation|GuidelinesonGoalsandObjectives|

    Summary

    Thischapterdescribesamethodforderivingbusinessrequirementsforarchitectureandtheimpliedtechnicalrequirements.

    Introduction

    Akeyfactorinthesuccessofanenterprisearchitectureistheextenttowhichitislinkedtobusinessrequirements,anddemonstrablysupportingandenablingtheenterprisetoachieveitsbusinessobjectives.

    Businessscenariosareanimportanttechniquethatmaybeusedatvariousstagesoftheenterprisearchitecture,principallytheArchitectureVisionandtheBusinessArchitecture,butinotherarchitecturedomainsaswell,ifrequired,toderivethecharacteristicsofthearchitecturedirectlyfromthehighlevelrequirementsofthebusiness.Theyareusedtohelpidentifyandunderstandbusinessneeds,andtherebytoderivethebusinessrequirementsthatthearchitecturedevelopmenthastoaddress.

    Abusinessscenariodescribes:

    Abusinessprocess,application,orsetofapplicationsthatcanbeenabledbythearchitectureThebusinessandtechnologyenvironmentThepeopleandcomputingcomponents(called"actors")whoexecutethescenarioThedesiredoutcomeofproperexecution

    Agoodbusinessscenarioisrepresentativeofasignificantbusinessneedorproblem,andenablesvendorstounderstandthevaluetothecustomerorganizationofadevelopedsolution.

    Agoodbusinessscenarioisalso"SMART":

    Specific,bydefiningwhatneedstobedoneinthebusinessMeasurable,throughclearmetricsforsuccessActionable,by:

    ClearlysegmentingtheproblemProvidingthebasisfordeterminingelementsandplansforthesolution

    Realistic,inthattheproblemcanbesolvedwithintheboundsofphysicalreality,time,andcostconstraints

    Timebound,inthatthereisaclearstatementofwhenthesolutionopportunityexpires

    GuidelinesonGoalsandObjectivesprovidesdetailedexamplesonobjectivesthatcouldbeconsidered.Whateverobjectivesyouuse,theideaistomakethoseobjectivesSMART.

    BenefitsofBusinessScenarios

  • 2/17/2015 BusinessScenarios

    http://webcache.googleusercontent.com/search?q=cache:tcjfr64f6QJ:pubs.opengroup.org/architecture/togaf8doc/arch/chap34.html+&cd=2&hl=en&ct=cl 2/14

    Abusinessscenarioisessentiallyacompletedescriptionofabusinessproblem,bothinbusinessandinarchitecturalterms,whichenablesindividualrequirementstobeviewedinrelationtooneanotherinthecontextoftheoverallproblem.Withoutsuchacompletedescriptiontoserveascontext:

    Thereisadangerofthearchitecturebeingbasedonanincompletesetofrequirementsthatdonotadduptoawholeproblemdescription,andthatcanthereforemisguidearchitecturework.

    Thebusinessvalueofsolvingtheproblemisunclear.Therelevanceofpotentialsolutionsisunclear.

    Also,becausethetechniquerequirestheinvolvementofbusinesslinemanagementandotherstakeholdersatanearlystageinthearchitectureproject,italsoplaysanimportantroleingainingthebuyinofthesekeypersonneltotheoverallprojectanditsendproducttheenterprisearchitecture.

    Anadditionaladvantageofbusinessscenariosisincommunicationwithvendors.MostarchitecturenowadaysisimplementedbymakingmaximumuseofCommercialOffTheShelf(COTS)softwaresolutions,oftenfrommultiplevendors,procuredintheopenmarket.TheuseofbusinessscenariosbyanITcustomercanbeanimportantaidtoITvendorsindeliveringappropriatesolutions.Vendorsneedtoensurethattheirsolutioncomponentsaddvaluetoanopensolutionandaremarketable.Businessscenariosprovidealanguagewithwhichthevendorcommunitycanlinkcustomerproblemsandtechnicalsolutions.Besidesmakingobviouswhatisneeded,andwhy,theyallowvendorstosolveproblemsoptimally,usingopenstandardsandleveragingeachother'sskills.

    CreatingtheBusinessScenario

    TheOverallProcess

    Creatingabusinessscenarioinvolvesthefollowing,asillustratedinCreatingaBusinessScenario:

    1.Identifying,documenting,andrankingtheproblemdrivingthescenario2.Identifyingthebusinessandtechnicalenvironmentofthescenarioanddocumentingitinscenariomodels3.Identifyinganddocumentingdesiredobjectives(theresultsofhandlingtheproblemssuccessfully)get"SMART"4.Identifyingthehumanactors(participants)andtheirplaceinthebusinessmodel5.Identifyingcomputeractors(computingelements)andtheirplaceinthetechnologymodel6.Identifyinganddocumentingroles,responsibilities,andmeasuresofsuccessperactordocumentingtherequiredscriptsperactor,andtheresultsofhandlingthesituation7.Checkingfor"fitnessforpurpose"andrefiningonlyifnecessary

    Figure:CreatingaBusinessScenario

    AbusinessscenarioisdevelopedoveranumberofiterativephasesofGathering,Analyzing,and

  • 2/17/2015 BusinessScenarios

    http://webcache.googleusercontent.com/search?q=cache:tcjfr64f6QJ:pubs.opengroup.org/architecture/togaf8doc/arch/chap34.html+&cd=2&hl=en&ct=cl 3/14

    Reviewingtheinformationinthebusinessscenario.

    Ineachphase,eachoftheareasaboveissuccessivelyimproved.Therefinementstepinvolvesdecidingwhethertoconsiderthescenariocompleteandgotothenextphase,orwhetherfurtherrefinementisnecessary.Thisisaccomplishedbyaskingwhetherthecurrentstateofthebusinessscenarioisfitforthepurposeofcarryingrequirementsdownstreaminthearchitectureprocess.

    Thethreephasesofdevelopingabusinessscenarioaredescribedindetailbelow,anddepictedinPhasesofDevelopingBusinessScenarios.

    Figure:PhasesofDevelopingBusinessScenarios

    Gathering

    TheGatheringphaseiswhereinformationiscollectedoneachoftheareasinCreatingaBusinessScenario.Ifinformationgatheringproceduresandpracticesarealreadyinplaceinanorganizationforexample,togatherinformationforstrategicplanningtheyshouldbeusedasappropriate,eitherduringbusinessscenarioworkshopsorinplaceofbusinessscenarioworkshops.

    Multipletechniquesmaybeusedinthisphase,suchasinformationresearch,qualitativeanalysis,quantitativeanalysis,surveys,requestsforinformation,etc.Asmuchinformationaspossibleshouldbegatheredandpreprocessed"offline"priortoanyfacetofaceworkshops(describedbelow).Forexample,arequestforinformationmayincludearequestforstrategicandoperationalplans.Suchdocumentstypicallyprovidegreatinsights,buttheinformationthattheycontainusuallyrequiressignificantpreprocessing.Theinformationmaybeusedtogenerateaninitialdraftofthebusinessscenariopriortotheworkshop,ifpossible.Thiswillincreasetheunderstandingandconfidenceofthearchitect,andthevalueoftheworkshoptoitsparticipants.

    Averyusefulwaytogatherinformationistoholdbusinessscenarioworkshops,wherebyabusinessscenarioconsultantleadsaselectandsmallgroupofbusinessrepresentativesthroughanumberofquestionstoelicittheinformationsurroundingtheproblembeingaddressedbythearchitectureeffort.Theworkshopattendeesmustbecarefullyselectedfromhighlevelsinthebusinessandtechnicalsidesoftheorganization.Itisimportanttogetpeoplethatcanandwillprovideinformationopenlyandhonestly.Whereadraftofthebusinessscenarioalreadyexistsforexample,asaresultofpreprocessinginformationgatheredduringthisphase,asdescribedabovetheworkshopmayalsobeusedtoreviewthestateofthebusinessscenariodraft.

    Sometimesitisnecessarytohavemultipleworkshops:insomecases,toseparatethegatheringofinformationonthebusinesssidefromthegatheringofinformationonthetechnicalsideandinothercasessimplytogetmoreinformationfrommorepeople.

    Whengatheringinformation,thearchitectcangreatlystrengthenthebusinessscenariobyobtaining"realworldexamples"i.e.,casestudiestowhichthereadercaneasilyrelate.Whencitingrealworldexamples,itisimportanttomaintainalevelofanonymityofthepartiesinvolved,toavoidblame.

  • 2/17/2015 BusinessScenarios

    http://webcache.googleusercontent.com/search?q=cache:tcjfr64f6QJ:pubs.opengroup.org/architecture/togaf8doc/arch/chap34.html+&cd=2&hl=en&ct=cl 4/14

    Analyzing

    TheAnalyzingphaseiswhereagreatdealofrealBusinessArchitectureworkisactuallydone.Thisiswheretheinformationthatisgatheredisprocessedanddocumented,andwherethemodelsarecreatedtorepresentthatinformation,typicallyvisually.

    TheAnalyzingphasetakesadvantageoftheknowledgeandexperienceofthebusinessscenarioconsultantusingpastworkandexperiencetodevelopthemodelsnecessarytodepicttheinformationcaptured.Notethatthemodelsanddocumentationproducedarenotnecessarilyreproducedverbatimfrominterviews,butratherfilteredandtranslatedaccordingtotherealunderlyingneeds.

    IntheAnalyzingphaseitisimportanttomaintainlinkagesbetweenthekeyelementsofthebusinessscenario.Onetechniquethatassistsinmaintainingsuchlinkagesisthecreationofmatricesthatareusedtorelatebusinessprocessestoeachof:

    ConstituenciesHumanActorsComputerActorsIssuesObjectives

    Inthisway,thebusinessprocessbecomesthebindingfocalpoint,whichmakesagreatdealofsense,sinceinmostcasesitisbusinessprocessimprovementthatisbeingsought.

    Reviewing

    TheReviewingphaseiswheretheresultsarefedbacktothesponsorsoftheprojecttoensurethatthereisasharedunderstandingofthefullscopeoftheproblem,andthepotentialdepthofthetechnicalimpact.

    Multiplebusinessscenarioworkshopsor"readout"meetingswiththesponsorsandinvolvedpartiesarerecommended.Themeetingsshouldbesetuptobeopenandinteractive.Itisrecommendedtohaveexercisesbuiltintomeetingagendas,inordertotestattendees'understandingandinterestlevels,aswellastotestthearchitect'sownassumptionsandresults.

    Thisphaseisextremelyimportant,astheabsenceofsharedexpectationsisinmanycasestherootcauseofprojectfailures.

    ContentsofaBusinessScenario

    Thedocumentationofabusinessscenarioshouldcontainalltheimportantdetailsaboutthescenario.Itshouldcapture,andsequence,thecriticalstepsandinteractionsbetweenactorsthataddressthesituation.Itshouldalsodeclarealltherelevantinformationaboutallactors,specifically:thedifferentresponsibilitiesoftheactorsthekeypreconditionsthathavetobemetpriortopropersystemfunctionalityandthetechnicalrequirementsfortheservicetobeofacceptablequality.

    Therearetwomaintypesofcontent:graphics(models),anddescriptivetext.Bothhaveaparttoplay.

    BusinessScenarioModelscapturebusinessandtechnologyviewsinagraphicalform,toaidcomprehension.Specifically,theyrelateactorsandinteractions,andgiveastartingpointtoconfirmspecificrequirements.

    BusinessScenarioDescriptionscapturedetailsinatextualform.Atypicalcontentslistforabusinessscenarioisgivenbelow.

    TableofContents

    PREFACE

    EXECUTIVESUMMARY

    DOCUMENTROADMAP

    BUSINESSSCENARIO

    BUSINESSSCENARIOOVERVIEW

  • 2/17/2015 BusinessScenarios

    http://webcache.googleusercontent.com/search?q=cache:tcjfr64f6QJ:pubs.opengroup.org/architecture/togaf8doc/arch/chap34.html+&cd=2&hl=en&ct=cl 5/14

    BACKGROUNDOFSCENARIO

    PURPOSEOFSCENARIO

    DEFINITIONS/DESCRIPTIONSOFTERMSUSED

    VIEWSOFENVIRONMENTSANDPROCESSES

    BUSINESSENVIRONMENT

    Constituencies

    PROCESSDESCRIPTIONS

    Process"a"

    etc....

    TECHNICALENVIRONMENT

    Technicalenvironment"a"

    etc....

    ACTORSANDTHEIRROLESANDRESPONSIBILITIES

    COMPUTERACTORSANDROLES

    RELATIONSHIPOFCOMPONENTSANDPROCESSES

    HUMANACTORSANDROLES

    RELATIONSHIPOFHUMANSANDPROCESSES

    INFORMATIONFLOWANALYSIS

    PRINCIPLESANDCONSTRAINTS

    ITPrinciples

    Constraints

    REQUIREMENTS

    BUSINESSSCENARIOANALYSIS

    PROBLEMSUMMARY

    Issues

    Objectives

    SUMMARY

    APPENDIXES

    APPENDIXA:BUSINESSSCENARIOSADDITIONALINFORMATION

    APPENDIXBn:BUSINESSSCENARIOWORKSHOPNOTES

    ContributionstotheBusinessScenario

    Itisimportanttorealizethatthecreationofabusinessscenarioisnotsolelytheprovinceofthearchitect.Asmentionedpreviously,businesslinemanagementandotherstakeholdersintheenterpriseareinvolved,toensurethatthebusinessgoalsareaccuratelycaptured.Inaddition,dependingontherelationshipthatanorganizationhaswithitsITvendors,thelatteralsomaybeinvolved,toensurethattherolesoftechnicalsolutionsarealsoaccuratelycaptured,andtoensurecommunicationwiththevendors.

    Typically,theinvolvementofthebusinessmanagementisgreatestintheearlystages,whilethebusinessproblemsarebeingexploredandcaptured,whiletheinvolvementofthearchitectisgreatestinthelaterstages,andwhenarchitecturalsolutionsarebeingdescribed.Similarly,ifvendorsare

  • 2/17/2015 BusinessScenarios

    http://webcache.googleusercontent.com/search?q=cache:tcjfr64f6QJ:pubs.opengroup.org/architecture/togaf8doc/arch/chap34.html+&cd=2&hl=en&ct=cl 6/14

    involvedinthebusinessscenarioprocess,theinvolvementofthecustomerside(businessmanagementplusenterprisearchitects)isgreatestintheearlystages,whilethatofthevendorsisgreatestinthelaterstages,whentheroleofspecifictechnicalsolutionsisbeingexploredandcaptured.ThisconceptisillustratedinRelativeContributionstoaBusinessScenario.

    Figure:RelativeContributionstoaBusinessScenario

    VendorITarchitectsmightbeabletoassistenterpriseITarchitectswithintegrationofthevendors'productsintotheenterprisearchitecture.ThisassistancemostprobablyfallsinthemiddleofthetimelineinRelativeContributionstoaBusinessScenario.

    BusinessScenariosandtheTOGAFADM

    BusinessscenariosfiguremostprominentlyintheinitialphaseoftheArchitectureDevelopmentMethod(ADM),ArchitectureVision,whentheyareusedtodefinerelevantbusinessrequirements,andtobuildconsensuswithbusinessmanagementandotherstakeholders.

    However,thebusinessrequirementsarereferredtothroughoutallphasesoftheADMlifecycle,asillustratedinRelevanceofRequirementsThroughouttheADM.

  • 2/17/2015 BusinessScenarios

    http://webcache.googleusercontent.com/search?q=cache:tcjfr64f6QJ:pubs.opengroup.org/architecture/togaf8doc/arch/chap34.html+&cd=2&hl=en&ct=cl 7/14

    Figure:RelevanceofRequirementsThroughouttheADM

    BecausebusinessrequirementsareimportantthroughoutallphasesoftheADMlifecycle,thebusinessscenariotechniquehasanimportantroletoplayintheTOGAFADM,byensuringthatthebusinessrequirementsthemselvesarecompleteandcorrect.

    GuidelinesonDevelopingBusinessScenarios

    GeneralGuidelines

    Thestakeholders(e.g.,businessmanagers,endusers)willtellyouwhattheywant,butasanarchitectyoumuststillgainanunderstandingofthebusiness,soyoumustknowthemostimportantactorsinthesystem.Ifthestakeholdersdonotknowwhattheywant:

    Taketime,observe,andrecordhowtheyareworkingtodayStructureinformationinsuchawaythatitcanbeusedlaterUncovercriticalbusinessrulesfromdomainexpertsStayfocusedonwhatneedstobeaccomplished,andhowitistobeaccomplished

    Thiseffortprovidestheanchorforachainofreasonfrombusinessrequirementsthroughtotechnicalsolutions.Itwillpayofflatertobediligentandcriticalatthestart.

    QuestionstoAskforEachArea

    ThebusinessscenarioworkshopsmentionedaboveintheGatheringphasearereallystructuredinterviews.Whilethereisnosinglesetofappropriatequestionstoaskinallsituations,thefollowingprovidessomeguidancetohelpbusinessscenarioconsultantsinaskingquestions.

    Identifying,Documenting,andRankingtheProblem

  • 2/17/2015 BusinessScenarios

    http://webcache.googleusercontent.com/search?q=cache:tcjfr64f6QJ:pubs.opengroup.org/architecture/togaf8doc/arch/chap34.html+&cd=2&hl=en&ct=cl 8/14

    Istheproblemdescribedasastatementofwhatneedstobeaccomplished,likestepsinaprocess,andnothow(withtechnology"push")?

    Iftheproblemistoospecificora"how":

    RaisearedflagAsk"Whydoyouneedtodoitthatway?"questions

    Iftheproblemistoovagueorunactionable:

    RaisearedflagAsk"Whatisityouneedtodo,orwillbeabletodoifthisproblemissolved?"questions

    Askquestionsthathelptoidentifywhereandwhentheproblemexists:

    Whereareyouexperiencingthisparticularproblem?Inwhatbusinessprocess?Whendoyouencountertheseissues?Duringthebeginningoftheprocess,themiddle,theend?

    Askquestionsthathelptoidentifythecostsoftheproblem:

    Doyouaccountforthecostsassociatedwiththisproblem?Ifso,whatarethey?Aretherehiddencosts?Ifso,whatarethey?Isthecostofthisproblemcoveredinthecostofsomethingelse?Ifso,whatandhowmuch?Istheproblemmanifestedintermsofpoorqualityoraperceptionofanineffectiveorganization?

    IdentifyingtheBusiness&TechnicalEnvironment,andDocumentinginModels

    Questionstoaskaboutthebusinessenvironment:

    Whatkeyprocesssuffersfromtheissues?Whatarethemajorstepsthatneedtobeprocessed?Location/scaleofinternalbusinessdepartments?Location/scaleofexternalbusinesspartners?Anyspecificbusinessrulesandregulationsrelatedtothesituation?

    Questionstoaskaboutthecurrenttechnologyenvironment:

    Whattechnologycomponentsarealreadypresupposedtoberelatedtothisproblem?Arethereanytechnologyconstraints?Arethereanytechnologyprinciplesthatapply?

    IdentifyingandDocumentingObjectives

    Isthe"what"sufficientlybackedupwiththerationalefor"why"?Ifnot,askformeasurablerationaleinthefollowingareas:

    ReturnoninvestmentScalabilityPerformanceneedsCompliancetostandardsEaseofusemeasures

    IdentifyingHumanActorsandtheirPlaceintheBusinessModel

    Anactorrepresentsanythingthatinteractswithorwithinthesystem.Thiscanbeahuman,oramachine,oracomputerprogram.Actorsinitiateactivitywiththesystem,forexample:

    ComputeruserwiththecomputerPhoneuserwiththetelephonePayrollclerkwiththepayrollsystemInternetsubscriberwiththewebbrowser

    Anactorrepresentsarolethatauserplaysi.e.,auserissomeoneplayingarolewhileusingthesystem(e.g.,John(user)isadispatcher(actor)).Eachactorusesthesystemindifferentways

  • 2/17/2015 BusinessScenarios

    http://webcache.googleusercontent.com/search?q=cache:tcjfr64f6QJ:pubs.opengroup.org/architecture/togaf8doc/arch/chap34.html+&cd=2&hl=en&ct=cl 9/14

    (otherwisetheyshouldbethesameactor).Askaboutthehumansthatwillbeinvolved,fromdifferentviewpoints,suchas:

    DeveloperMaintainerOperatorAdministratorUser

    IdentifyingComputerActorsandtheirPlaceintheTechnologyModel

    Askaboutthecomputercomponentslikelytobeinvolved,againfromdifferentpointsofview.Whatmusttheydo?

    DocumentingRoles,Responsibilities,MeasuresofSuccess,RequiredScripts

    Whendefiningroles,askquestionslike:

    Whatarethemaintasksoftheactor?Willtheactorhavetoread/write/changeanyinformation?Willtheactorhavetoinformthesystemaboutoutsidechanges?Doestheactorwishtobeinformedaboutunexpectedchanges?

    CheckingforFitnessforPurpose,andrefiningifnecessary

    Isthereenoughinformationtoidentifywho/whatcouldfulfilltherequirement?Ifnot,probemoredeeply.

    Isthereadescriptionofwhen,andhowoften,therequirementneedstobeaddressed?Ifnot,askabouttiming.

    GuidelinesonBusinessScenarioDocumentation

    TextualDocumentation

    Effectivebusinessscenariodocumentationrequiresabalancebetweenensuringthatthedetailisaccessible,andpreventingitfromovershadowingtheresultsandoverwhelmingthereader.Tothisend,thebusinessscenariodocumentshouldhavethemainfindingsinthebodyofthedocumentandthedetailsinappendices.

    Intheappendices:

    Capturealltheimportantdetailsaboutabusinessscenario:SituationdescriptionandrationaleAllmeasurementsAllactorrolesandsubmeasurementsAllservicesrequired

    Capturethecriticalstepsbetweenactorsthataddressthesituation,andsequencetheinteractionsDeclarerelevantinformationaboutallactors:

    PartitiontheresponsibilityoftheactorsListpreconditionsthathavetobemetpriortopropersystemfunctionalityProvidetechnicalrequirementsfortheservicetobeofacceptablequality

    Inthemainbodyofthebusinessscenario:

    Generalizealltherelevantdatafromthedetailintheappendices

    BusinessScenarioModels

    Rememberthepurposeofusingmodels:Capturebusinessandtechnologyviewsinagraphicalform

  • 2/17/2015 BusinessScenarios

    http://webcache.googleusercontent.com/search?q=cache:tcjfr64f6QJ:pubs.opengroup.org/architecture/togaf8doc/arch/chap34.html+&cd=2&hl=en&ct=c 10/14

    HelpcomprehensionGiveastartingpointtoconfirmrequirementsRelateactorsandinteractions

    Keepdrawingsclearandneat:DonotputtoomuchintoonediagramSimplerdiagramsareeasiertounderstand

    Numberdiagramsforeasyreference:Maintainacatalogofthenumberstoavoidduplicates

    GuidelinesonGoalsandObjectives

    TheImportanceofGoals

    Oneofthefirststepsinthedevelopmentofanarchitectureistodefinetheoverallgoalsandobjectivesforthedevelopment.Theobjectivesshouldbederivedfromthebusinessgoalsoftheorganization,andthewayinwhichITisseentocontributetomeetingthosegoals.

    Everyorganizationbehavesdifferentlyinthisrespect,someseeingITasthedrivingforcefortheenterpriseandothersseeingITinasupportingrole,simplyautomatingthebusinessprocesseswhichalreadyexist.Theessentialthingisthatthearchitecturalobjectivesshouldbeverycloselyalignedwiththebusinessgoalsandobjectivesoftheorganization.

    TheImportanceofSMARTObjectives

    Notonlymustgoalsbestatedingeneralterms,butalsospecificmeasuresneedtobeattachedtothemtomakethemSMART,asdescribedabove.

    Theamountofeffortspentindoingthiswillleadtogreaterclarityforthesponsorsofthearchitectureevolutioncycle.Itwillpaybackbydrivingproposedsolutionsmuchmorecloselytowardthegoalsateachstepofthecycle.Itisextremelyhelpfulforthedifferentstakeholdersinsidetheorganization,aswellasforsuppliersandconsultants,tohaveaclearyardstickformeasuringfitnessforpurpose.Ifdonewell,theADMcanbeusedtotracespecificdecisionsbacktocriteria,andthusyieldtheirjustification.

    ThegoalsbelowhavebeenadaptedfromthosegiveninpreviousversionsofTOGAF.Thesearecategoriesofgoals,eachwithalistofpossibleobjectives.EachoftheseobjectivesshouldbemadeSMARTwithspecificmeasuresandmetricsforthetask.However,sincetheactualworktobedonewillbespecifictothearchitectureprojectconcerned,itisnotpossibletoprovidealistofgenericSMARTobjectivesthatwillrelatetoanyproject.

    Instead,weprovideheresomeexampleSMARTobjectives.

    ExampleofMakingObjectivesSMART

    Underthegeneralgoalheading"ImproveUserProductivity"below,thereisanobjectivetoprovidea"ConsistentUserInterface"anditisdescribedasfollows:

    "Aconsistentuserinterfacewillensurethatalluseraccessiblefunctionsandserviceswillappearandbehaveinasimilar,predictablefashionregardlessofapplicationorsite.Thiswillleadtobetterefficiencyandfewerusererrors,whichinturnmayresultinlowerrecoverycosts."

    TomakethisobjectiveSMART,weaskwhethertheobjectiveisspecific,measurable,actionable,realistic,andtimebound,andthenaugmenttheobjectiveappropriately.

    Thefollowingcapturesananalysisofthesecriteriaforthestatedobjective:

    Specific:Theobjectiveofproviding"aconsistentuserinterfacethatwillensurealluseraccessiblefunctionsandserviceswillappearandbehaveinasimilar,predictablefashionregardlessofapplicationorsite".isprettyspecific.However,themeasureslistedinthesecondsentencecouldbemorespecific...

    Measurable:Asstatedabove,theobjectiveismeasurable,butcouldbemorespecific.Thesecondsentencecouldbeamendedtoread(forexample):"Thiswillleadto10%greateruserefficiencyand20%fewerorderentryusererrors,whichinturnmayresultin5%lowerorderentrycosts".

    Actionable:Theobjectivedoesappeartobeactionable.Itseemsclearthatconsistencyoftheuser

  • 2/17/2015 BusinessScenarios

    http://webcache.googleusercontent.com/search?q=cache:tcjfr64f6QJ:pubs.opengroup.org/architecture/togaf8doc/arch/chap34.html+&cd=2&hl=en&ct=c 11/14

    interfacemustbeprovided,andthatcouldbehandledbywhoeverisresponsibleforprovidingtheuserinterfacetotheuserdevice.

    Realistic:Theobjectiveofproviding"aconsistentuserinterfacethatwillensurealluseraccessiblefunctionsandserviceswillappearandbehaveinasimilar,predictablefashionregardlessofapplicationorsite"mightnotberealistic.ConsideringtheusetodayofPDAsattheuserendmightleadustoaugmentthisobjectivetoassurethatthedownstreamdevelopersdon'tundulycreatedesignsthathindertheuseofnewtechnologies.Theobjectivecouldberestatedas"aconsistentuserinterface,acrossuserinterfacedevicesthatprovidesimilarfunctionality,thatwillensure..."etc.

    Timebound:Theobjectiveasstatedisnottimebound.Tobetimeboundtheobjectivecouldberestatedas"BytheendofQ3,provideaconsistent...".

    TheaboveresultsinaSMARTobjectivethatlooksmorelikethis(againrememberthisisanexample):

    "BytheendofQ3,provideaconsistentuserinterfaceacrossuserinterfacedevicesthatprovidesimilarfunctionalitytoensurealluseraccessiblefunctionsandservicesappearandbehaveinasimilarwaywhenusingthosedevicesinapredictablefashionregardlessofapplicationorsite.Thiswillleadto10%greateruserefficiencyand20%fewerorderentryusererrors,whichinturnmayresultin5%lowerorderentrycosts."

    CategoriesofGoalsandObjectives

    Althougheveryorganizationwillhaveitsownsetofgoals,someexamplesmayhelpinthedevelopmentofanorganizationspecificlist.Thegoalsgivenbelowarecategoriesofgoals,eachwithalistofpossibleobjectives,whichhavebeenadaptedfromthegoalsgiveninpreviousversionsofTOGAF.

    EachoftheobjectivesgivenbelowshouldbemadeSMARTwithspecificmeasuresandmetricsforthetaskinvolved,asillustratedintheexampleabove.However,theactualworktobedonewillbespecifictothearchitectureprojectconcerned,anditisnotpossibletoprovidealistofgenericSMARTobjectivesthatwillrelatetoanyproject.

    Goal:ImproveBusinessProcessPerformance

    Businessprocessimprovementscanberealizedthroughthefollowingobjectives:

    IncreasedprocessthroughputConsistentoutputqualityPredictableprocesscostsIncreasedreuseofexistingprocessesReducedtimeofsendingbusinessinformationfromoneprocesstoanotherprocess

    Goal:DecreaseCosts

    Costimprovementscanberealizedthroughthefollowingobjectives:

    LowerlevelsofredundancyandduplicationinassetsthroughouttheenterpriseDecreasedrelianceonexternalITserviceprovidersforintegrationandcustomizationLowercostsofmaintenance

    Goal:ImproveBusinessOperations

    Businessoperationsimprovementscanberealizedthroughthefollowingobjectives:

    IncreasedbudgetavailabletonewbusinessfeaturesDecreasedcostsofrunningthebusinessDecreasedtimetomarketforproductsorservicesIncreasedqualityofservicestocustomersImprovedqualityofbusinessinformation

    Goal:ImproveManagementEfficacy

  • 2/17/2015 BusinessScenarios

    http://webcache.googleusercontent.com/search?q=cache:tcjfr64f6QJ:pubs.opengroup.org/architecture/togaf8doc/arch/chap34.html+&cd=2&hl=en&ct=c 12/14

    Managementefficacyimprovementscanberealizedthroughthefollowingobjectives:

    IncreasedflexibilityofbusinessShortertimetomakedecisionsHigherqualitydecisions

    Goal:ReduceRisk

    Riskimprovementscanberealizedthroughthefollowingobjectives:

    EaseofimplementingnewprocessesDecreasederrorsintroducedintobusinessprocessesthroughcomplexandfaultysystemsDecreasedrealworldsafetyhazards(includinghazardsthatcauselossoflife)

    Goal:ImproveEffectivenessofITOrganization

    ITorganizationeffectivenesscanberealizedthroughthefollowingobjectives:

    IncreasedrolloutofnewprojectsDecreasedtimetorolloutnewprojectsLowercostinrollingoutnewprojectsDecreasedlossofservicecontinuitywhenrollingoutnewprojectsCommondevelopment:applicationsthatarecommontomultiplebusinessareaswillbedevelopedor

    acquiredonceandreusedratherthanseparatelydevelopedbyeachbusinessarea.Opensystemsenvironment:astandardsbasedcommonoperatingenvironment,whichaccommodates

    theinjectionofnewstandards,technologies,andapplicationsonanorganizationwidebasis,willbeestablished.Thisstandardsbasedenvironmentwillprovidethebasisfordevelopmentofcommonapplicationsandfacilitatesoftwarereuse.

    Useofproducts:asfaraspossible,hardwareindependent,offtheshelfitemsshouldbeusedtosatisfyrequirementsinordertoreducedependenceoncustomdevelopmentsandtoreducedevelopmentandmaintenancecosts.

    Softwarereuse:forthoseapplicationsthatmustbecustomdeveloped,developmentofportableapplicationswillreducetheamountofsoftwaredevelopedandaddtotheinventoryofsoftwaresuitableforreusebyothersystems.

    Resourcesharing:dataprocessingresources(hardware,software,anddata)willbesharedbyallusersrequiringtheservicesofthoseresources.Resourcesharingwillbeaccomplishedinthecontextofsecurityandoperationalconsiderations.

    Goal:ImproveUserProductivity

    Userproductivityimprovementscanberealizedthroughthefollowingobjectives:

    Consistentuserinterface:aconsistentuserinterfacewillensurethatalluseraccessiblefunctionsandserviceswillappearandbehaveinasimilar,predictablefashionregardlessofapplicationorsite.Thiswillleadtobetterefficiencyandfewerusererrors,whichinturnmayresultinlowerrecoverycosts.

    Integratedapplications:applicationsavailabletotheuserwillbehaveinalogicallyconsistentmanneracrossuserenvironments,whichwillleadtothesamebenefitsasaconsistentuserinterface.

    Datasharing:databaseswillbesharedacrosstheorganizationinthecontextofsecurityandoperationalconsiderations,leadingtoincreasedeaseofaccesstorequireddata.

    Goal:ImprovePortabilityandScalability

    Theportabilityandscalabilityofapplicationswillbethroughthefollowingobjectives:

    Portability:applicationsthatadheretoopensystemsstandardswillbeportable,leadingtoincreasedeaseofmovementacrossheterogeneouscomputingplatforms.Portableapplicationscanallowsitestoupgradetheirplatformsastechnologicalimprovementsoccur,withminimalimpactonoperations.

    Scalability:applicationsthatconformtothemodelwillbeconfigurable,allowingoperationonthefullspectrumofplatformsrequired.

  • 2/17/2015 BusinessScenarios

    http://webcache.googleusercontent.com/search?q=cache:tcjfr64f6QJ:pubs.opengroup.org/architecture/togaf8doc/arch/chap34.html+&cd=2&hl=en&ct=c 13/14

    Goal:ImproveInteroperability

    Interoperabilityimprovementsacrossapplicationsandbusinessareascanberealizedthroughthefollowingobjectives:

    Commoninfrastructure:thearchitectureshouldpromoteacommunicationsandcomputinginfrastructurebasedonopensystemsandsystemstransparencyincluding,butnotlimitedto,operatingsystems,databasemanagement,datainterchange,networkservices,networkmanagement,anduserinterfaces.

    Standardization:byimplementingstandardsbasedplatforms,applicationswillbeprovidedwithandwillbeabletouseacommonsetofservicesthatimprovetheopportunitiesforinteroperability.

    Goal:IncreaseVendorIndependence

    Vendorindependencewillbeincreasedthroughthefollowingobjectives:

    Interchangeablecomponents:onlyhardwareandsoftwarethathavestandardsbasedinterfaceswillbeselected,sothatupgradesortheinsertionofnewproductswillresultinminimaldisruptiontotheuser'senvironment.

    Nonproprietaryspecifications:capabilitieswillbedefinedintermsofnonproprietaryspecificationsthatsupportfullandopencompetitionandareavailabletoanyvendorforuseindevelopingcommercialproducts.

    Goal:ReduceLifecycleCosts

    Lifecyclecostscanbereducedthroughmostoftheobjectivesdiscussedabove.Inaddition,thefollowingobjectivesdirectlyaddressreductionoflifecyclecosts:

    Reducedduplication:replacementofisolatedsystemsandislandsofautomationwithinterconnectedopensystemswillleadtoreductionsinoverlappingfunctionality,dataduplication,andunneededredundancybecauseopensystemscansharedataandotherresources.

    Reducedsoftwaremaintenancecosts:reductionsinthequantityandvarietyofsoftwareusedintheorganizationwillleadtoreductionsintheamountandcostofsoftwaremaintenance.Useofstandardofftheshelfsoftwarewillleadtofurtherreductionsincostssincevendorsofsuchsoftwaredistributetheirproductmaintenancecostsacrossamuchlargeruserbase.

    Incrementalreplacement:commoninterfacestosharedinfrastructurecomponentsallowforphasedreplacementorupgradewithminimaloperationaldisturbance.

    Reducedtrainingcosts:commonsystemsandconsistentHumanComputerInterfaces(HCIs)willleadtoreducedtrainingcosts.

    Goal:ImproveSecurity

    Securitycanbeimprovedintheorganization'sinformationthroughthefollowingobjectives:

    Consistentsecurityinterfacesforapplications:consistentsecurityinterfacesandprocedureswillleadtofewererrorswhendevelopingapplicationsandincreasedapplicationportability.Notallapplicationswillneedthesamesuiteofsecurityfeatures,butanyfeaturesusedwillbeconsistentacrossapplications.

    Consistentsecurityinterfacesforusers:acommonuserinterfacetosecurityfeatureswillleadtoreducedlearningtimewhenmovingfromsystemtosystem.

    Securityindependence:applicationdeploymentcanusethesecuritypolicyandmechanismsappropriatetotheparticularenvironmentifthereisgoodlayeringinthearchitecture.

    A25%reductionincallstothehelpdeskrelatingtosecurityissues.A20%reductionin"falsepositives"detectedinthenetwork(afalsepositiveisaneventthatappears

    tobeanactionablesecurityevent,butinfactisafalsealarm).

    Goal:ImproveManageability

    Managementimprovementcanberealizedthroughthefollowingobjectives:

    Consistentmanagementinterface:consistentmanagementpracticesandprocedureswillfacilitate

  • 2/17/2015 BusinessScenarios

    http://webcache.googleusercontent.com/search?q=cache:tcjfr64f6QJ:pubs.opengroup.org/architecture/togaf8doc/arch/chap34.html+&cd=2&hl=en&ct=c 14/14

    managementacrossallapplicationsandtheirunderlyingsupportstructures.Aconsistentinterfacecansimplifythemanagementburden,leadingtoincreaseduserefficiency.

    Reducedoperation,administration,andmaintenancecosts:operation,administration,andmaintenancecostsmaybereducedthroughtheavailabilityofimprovedmanagementproductsandincreasedstandardizationoftheobjectsbeingmanaged.

    Summary

    BusinessscenarioshelpaddressoneofthemostcommonissuesfacingITexecutives:aligningITwiththebusiness.

    ThesuccessofanymajorITprojectismeasuredbytheextenttowhichitislinkedtobusinessrequirements,anddemonstrablysupportsandenablestheenterprisetoachieveitsbusinessobjectives.Businessscenariosareanimportanttechniquethatmaybeusedatvariousstagesofdefiningenterprisearchitecture,oranyothermajorITproject,toderivethecharacteristicsofthearchitecturedirectlyfromthehighlevelrequirementsofthebusiness.Businessscenariosareusedtohelpidentifyandunderstandbusinessneeds,andtherebytoderivethebusinessrequirementsthatthearchitecturedevelopment,andultimatelytheIT,hastoaddress.

    However,itisimportanttorememberthatbusinessscenariosarejustatool,nottheobjective.Theyareapartof,andenable,thelargerprocessofarchitecturedevelopment.Thearchitectshouldusethem,butnotgetlostinthem.Thekeyistostayfocusedwatchoutfor"featurecreep",andaddressthemostimportantissuesthattendtoreturnthegreatestvalue.

    returntotopofpage

    Navigation

    TheTOGAFdocumentsetisdesignedforusewithframes.Tonavigatearoundthedocument:

    InthemainContentsframeatthetopofthepage,clicktherelevanthyperlink(PartI,PartII,etc.)toloadtheContentsListforthatPartoftheTOGAFdocumentintotheSecondaryIndexframeintheleftmargin.

    ThenclickinthatContentsListtoloadapageintothismainframe.

    returntotopofpage

    Downloads

    DownloadsoftheTOGAFdocumentation,areavailableunderlicensefromtheTOGAFinformationwebsite.ThelicenseisfreetoanyorganizationwishingtouseTOGAFentirelyforinternalpurposes(forexample,todevelopaninformationsystemarchitectureforusewithinthatorganization).AhardcopybookisalsoavailablefromTheOpenGroupBookstoreasdocumentG063.

    Copyright19992006TheOpenGroup,AllRightsReservedTOGAFisatrademarkofTheOpenGroup