Agile Enterprise Architecture - The Open an agile enterprise architecture program without some tooling very difficult yManually maintaining “less rigorous” assets in Word, Excel,

Download Agile Enterprise Architecture - The Open   an agile enterprise architecture program without some tooling very difficult yManually maintaining “less rigorous” assets in Word, Excel,

Post on 12-Mar-2018

214 views

Category:

Documents

2 download

TRANSCRIPT

Armstrong Process Group, Inc.www.aprocessgroup.comCopyright 1998-2008, Armstrong Process Group, Inc., All rights reservedAgile Enterprise ArchitectureEnterprise Architecture Practitioners Conference 2009San Diego, CAEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved2ObjectivesReview TOGAF ADM lifecycleTypical EA pitfalls and challengesReview Agile Manifesto for software developmentAgile EA principlesAlignment of EA program with business strategyIntroduce agile planning conceptsAgile EA modeling when enoughs enoughValidate target architectures through continual solution delivery engagementSupport with traceability and toolsEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved3TOGAF Architecture Development Method (ADM)The ADM is iterative, over the whole process, between phases, and within phases.For each iteration of the ADM, a fresh decision must be taken as toBreadth of coverageArchitecture domainsLevel of detailExtent of the time horizonArchitectural assets to be leveragedEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved4Typical EA PitfallsPerception of EA an academic exerciseThe Ivory Tower syndromeBuilding abstract models that are not actionableUnclear relationship of EA to other business and IT lifecyclesDuplicative, potentially conflicting, activities in different places in the IT landscapeMissed handoffs and lack of process integrationPracticing EA as a linear or serial set of activitiesMust completely finish business architecture before starting on application architectureGetting lost in the pastUnbounded archeological excavations of the current stateDelivering value later versus soonerEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved5Estimation and Sizing ParadoxQ: Has anyone ever asked you, Could you please tell me how many people, how much money, and how much time it will take to build this thing that we dont really know much about?A: How much money do you want to spend and how long do you want us to take?A development effort will consume all of the people, time, and money resources that are committed to itIn fact, according to the CHAOS Report, usually about twice as much!Agile, iterative development is about optimizing the use of constrained resources to get the biggest return on investment to the businessEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved6Just-In-Time DevelopmentAgile, iterative development is like just-in-time (JIT) manufacturing Principle is to have less overheadReduce likelihood of significant reworkThe right number of work products produced at just the right time using the right amount of resourcesDo as little as possible to reach milestonesWhich does not mean not doing anythingDelay critical decisions and actions to last possible momentStop performing activities when they are done enoughDoing too much work too early, increases the likelihood that you will have to do most of it over againWant to avoid accidentally creating any more rework than necessaryEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved7Manifesto for Agile Software DevelopmentWe are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:Agile Principle Traditional PrincipleIndividuals and interactions Processes and toolsWorking software Comprehensive documentationCustomer collaboration Contract negotiationResponding to change Following a planThat is, while there is value in the items on the right, we value the items on the left more.http://www.agilemanifesto.orgEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved8Agile Enterprise Architecture PrinciplesSustain continual stakeholder interactionBuild useful plans based on sufficient and relevant modelsProve suitability of target architectures and migration plansAnticipate continual changeEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reservedEA Alignment with Business StrategyBusiness ArchitectureBusiness services, processes, eventsBusiness systems, capabilities, functionsData ArchitectureBusiness domains, entities, data elements Data requirements, relationshipsApplication ArchitecturePortfolios, applications, subsystemsInterfaces, integrationTechnology ArchitectureHardware and software platformsNetwork and communications infrastructureContext: Business drivers, regulations, security, service levelsEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved10Deliver Increasing Business AgilityNeed to move from current state (less effective) to future state (more agile)Need strategic plan for transforming organization Establish stable, transition milestonesCurrent BaselineEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved11ATPL Plus Agile EA LifecycleInitiation Stabilization Production TransitionPhasesI1IterationsI2 I3 I4 I5 I6 I7 I8DisciplinesBusiness ArchitectureData ArchitectureApplication ArchitectureSecurity ArchitectureTechnology ArchitectureDeploymentGovernance and Change ManagementProject ManagementEnvironmentEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved12Project Time ElementsTime element related to programs complete lifetime; includes previous and future versions; possibly eventually retired; an enterprise has many programsProgramTime element resulting in specific version of program released into operational environment; one program has many releasesReleaseTime element related to achieving specific business milestones within a release; one release has four phasesabstraction# of elementslevels of abstraction# of elementsmore specificmoregeneralPhaseTime element related to achieving measurable objectives related to requirements and risk; one phase has one or many iterationsIterationEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved13Sample ReleasesRelease Start Date# of Weeks End DateRelease 1.0 8/1/2003 39 4/29/2004Release 1.1 4/1/2004 12 6/23/2004Release 2.0 6/1/2004 26 11/29/2004Release 3.0 1/1/2005 33 8/19/2005I S P T Release 1.0I S P T Release 1.1I S P T Release 2.0Release 3.0 I TS PEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved14Four Phases of Iterative LifecyclePhase MilestoneInitiation Lifecycle Objectives (LCO)Understand the problemStabilization Lifecycle Architecture (LCA)Understand the solutionProduction Initial Operational Capability (IOC)Build the solutionTransition Operational ReleaseDeliver the solutionAnchoring the Software Process, 1995, Barry BoehmEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved15How Done Is It? Work Product StatesIdentified(Level 1)Described(Level 2)Outlined(Level 3)Detailed(Level 4)Identified with nameDescribed with sentence or twoBasic flow steps identified; alternate flows identified by nameBasic and alternate flows detailed; special requirementsEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved16Sample Work Product SelectionWork ProductLevel / PhaseReview Specification ToolI S P TBusiness Architecture 5 10 14 14 HighBusiness driver 1 1 1 1 High BMM::Assessment RM tool w/profileBusiness goal 1 1 1 1 High BMM::Goal RM tool w/profileBusiness objective 1 2 2 2 High BMM::Objective RM tool w/profileBusiness service 1 3 4 4 High UML::Use Case UML tool w/profileBusiness process 1 2 4 4 Medium BPMN::Process BPMN toolBusiness function 0 1 2 2 Medium BPMN::Process BPMN toolBusiness worker None n/a n/aData Architecture 2 4 7 10 MediumBusiness domain 1 1 1 1 Low UML::Package UML tool w/profileBusiness entity 0 1 3 3 Medium UML::Class UML tool w/profileData security requirement 1 2 3 4 High SysML::Requirement RM tool w/profileEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved17Business Service Gap AnalysisEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved18Trimming Frivolous IT ProjectsIdeally, an organization would like the enterprise architecture enterprise architecture function to engage all projectsHowever, this is initially often not very realistic feasible for most many organizations due to overloaded portfolios and limited EA resource allocation bandwidthIn todays world, many organizations need to seriously examine the risks of continuing to execute projects without EA supportOften some sort of risk analysis or triage process is required to identify those projects that demand architecture engagementIt is also important crucial to make sure that projects that areperceived as being simple with limited scope do not become architecturally-significant because of poor decision making due to lack of appropriate architecture guidanceEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved19Business-IT Integration Enterprise LifecyclesStrategic PlanningPortfolio/Program ManagementGovernanceService ManagementEnterprise ArchitectureSolution DeliverySystems EngineeringProject ManagementRequirements ManagementEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved20ATPL+ Govern Solution Architectures (GSA) PluginAPG refinements of Phase G: Implementation Governance of TOGAF ADMMajor deliverablesSolution Delivery RecommendationsSolution Architecture ContractArchitecture Review ReportNew rolesSolution ArchitectArchitecture Review LeadEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved21Enterprise Architecture Tool SituationSustaining an agile enterprise architecture program without some tooling very difficultManually maintaining less rigorous assets in Word, Excel, and PowerPoint is not very scalableNo single tool implements all requirements for capturing enterprise architecture assetsUsually requires an integrated tool set (not usually all from the same vendor)Understand difference between what organizationsWant to doShould doCan doEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved22EA Tool RequirementsSupport industry frameworks (such as TOGAF) and specifications (such as MDA)Customizable to organizations business and technical processes and environmentsAbility to integrate tools in a useful wayEffort to maintain integration must have ROI that is meaningful to usersEasy accessibilityEffort to get to relevant content needs to be easy and quickIntegration with repositories and configuration management systemsEnterprise Architecture Practitioners Conference 2009 San Diego Agile Enterprise ArchitectureCopyright 1998-2009, Armstrong Process Group, Inc., All rights reserved23Q&AThanks for your attention and participation!Agile Enterprise ArchitectureObjectivesTOGAF Architecture Development Method (ADM)Typical EA PitfallsEstimation and Sizing ParadoxJust-In-Time DevelopmentManifesto for Agile Software DevelopmentAgile Enterprise Architecture PrinciplesEA Alignment with Business StrategyDeliver Increasing Business AgilityATPL Plus Agile EA LifecycleProject Time ElementsSample ReleasesFour Phases of Iterative LifecycleHow Done Is It? Work Product StatesSample Work Product SelectionBusiness Service Gap AnalysisTrimming Frivolous IT ProjectsBusiness-IT Integration Enterprise LifecyclesATPL+ Govern Solution Architectures (GSA) PluginEnterprise Architecture Tool SituationEA Tool RequirementsQ&A

Recommended

View more >