Enterprise Architecture Workgroup Kickoff

Transcription

Enterprise ArchitectureWorkgroup KickoffDecember 11, 2014 Thursday 3:00-4:00 p.m. 8 Story Street #6016

Agenda The EA Vision Milestones for EA at Harvard Governance EA Program Approach Definition of Terms Architecture Maturity EA Focus Areas2

The EA VisionOur Vision for Enterprise ArchitectureProvide a technology framework and a set of standards to enable acquisition, development,and deployment of IT services that maximize interoperation, minimize duplication, and simplifythe IT environment across all of Harvard.Strategic ObjectivesGuiding Principles Deliver an enterprise architectureframework that drives technologyand development standardsacross Harvard Ensure that EA provides activedirection and delivers value to theorganization Provide common approaches forintegration across enterpriseapplications, processes, and data Align and rationalize technologydecisions and investments Identify redundant or conflictingprocesses and data acrossorganizations Counter complexity with commonsolutions Enable sharing of data acrossorganizations Preference for open-source,COTS, and programmaticinterfaces — both in what weobtain and what is producedKey Performance Indicators Decrease in project deliverytimeframes to production Increase in the number ofintegrated applications usingprogrammatic interfaces Increase in the number of fundedprojects that conform to an EAChecklist Decrease in ad-hoc data sharing Increase in automated dataexchange Encourage, define, and ultimatelyprovide best-practice solutions Increase in the number of knownauthoritative data sources Evolve framework and solutionswith advances in technology Decrease in the number of copiesof data3

Milestones for EA at HarvardHUIT Top 40 GoalEA MilestonesOct 2014: Launch EA strategic initiative, includingvision and strategic plan20. Establish anIT enterprise architectureDec 2014: Define a Harvard EA framework toincorporate key elements in principles, data, integration,and technology architectureMarch 2015: Conduct a current state analysison integration to identify data passed betweenenterprise applications and the means of exchangeSept 2014: Identify a set of technical architects who canundertake architectural reviews21. Implement anarchitecture review processOct 2014: Review and refresh PRC technical reviewprocessDec 2014: Review and refresh ITCRB technical reviewprocess4

GovernanceEnterprise Architecture Executive CommitteeIT executives who ensure that the vision and plan are addressed by the working group. Also providesconsistent direction and problem-solving approaches for the working group and the EA program at large.Meets monthly.Co-Chairs: Anne Margulies and Stephen GallagherMembers: Scott Bradner, Ben Gaucherin, Stephen Ervin, Gabriele Fariello, Praneeth Machettira,Pratike Patel, Jason Shaffner, Jason Snyder, Jim Waldo, Bob WittsteinEnterprise Architecture Working Group Technical members of HUIT, Harvard Schools, and other IT departments thatmeet on a regular basis Defines the Enterprise Architecture framework for review by Steering Committee Defines sub-groups to detail layers Builds and reviews other EA components as per vision Publishes a monthly report on enterprise architecture progress, issues, and direction for the organizationChair: Jason SnyderMembers: Scott Bradner, Bill Brickman, Dan Kaplan, Arnold Paul, Robert Piscitello, Jon Saperia,Raoul Sevier, Michael Thomas5

EA Program ApproachRe-Evaluate: Identify Places Where EA Can Make an ImpactLayersSecurityRequirementsand NeedsUser ExperienceCommunication & EducationAdvisories,Methodologies,and PrinciplesApplications and Software ArchitectureImplementationPlanArchitectsUX ConsultationInteroperationDataPatterns andReferenceArchitectureAd-Hoc ConsultationMiddlewareITCRB and PRC ReviewsInfrastructure and IaaSTechnologyTrends andBest PracticesNetworkingOutreach andTrainingEvaluate Skills &Organizational Needs6

Definition of Terms: EA er look-and-feel and navigationstyle of an application or serviceThe appearance of the Harvard brand, color schemes, use of breadcrumbs, positionand appearance of navigation bars.Applications,services, SaaSAlgorithms and code that providetechnical or business valueLarge-scale applications such as the Student Information System (SIS), smallapplications such as Electronic Submission Tracking and Reporting (ESTR),services such as Informatica for data transfers, and Software-as-a-Service solutionssuch as Office365.InteroperationExchanges of information andprovisioning of business transactionsbetween different applications andservicesExamples of information exchanges include transfers of student registration fromSIS systems to central directories and transfer of account balance values fromfinancial systems to CRM systems. An example of a remote service is the Identityand Access Management service for Authentication.DataInformation represented in formats thatare managed by applications andservicesData includes structured information such as student records and general ledgerfinancial data. Examples of unstructured data include electronic books, the contentof wikis, and most of the information available from the Internet.MiddlewareCommon business or technicalservices that are implementedseparately from applications andservicesDatabase technologies are the most common example of middleware, but this layercan also include reporting ‘engines’, rules ‘engines’, application servers, datatransfer applications, and other common shared services.InfrastructureHardware and virtualized platforms that Servers, associated storage components, operating systems, and other computingoperate applications, services, anddevices are the common examples of infrastructure, more recently joined by cloudtheir componentsbased infrastructures of Platform-as-a-Service and Infrastructure-as-a-Service.NetworksCommunications technologies that joininfrastructures in disparate locationsTechnologies that allow computing devices to communicate with each other includewired and wireless communications supported by devices such as routers, switches,and naming services.SecurityUse of resources by authorizedindividuals and computing services toinformation, business functions, andcomputing servicesExamples of security mechanisms include door locks, user IDs and passwords, andintrusion detection/prevention tools. These mechanisms are supported byapplications and services that manage user and systemic authentication,authorization, access to functionality, and access to data.7

Definition of Terms: EA esFoundational elements to drivedecision-making and alignmentPrinciples can be applied at many levels, from guiding principles that characterizestrategic, enterprise-wide systemic behavior to principles that help explain detailedtechnical behaviors of applications and services.MethodologiesMethodologies divide IT work intophases containing activities with theintent of better planning andmanagement; they help determinewhich methods or “best practices”should be applied to specific cases,and may include specific deliverablesand artifactsExamples of IT methodologies include waterfall, prototyping, iterative andincremental development, spiral development, rapid application development,extreme programming, and Agile.AdvisoriesRecommendations offered as a guideto specific actions or practicesCommon examples of advisories include security notifications of newly discoveredvulnerabilities with recommendations for patching systems or changing passwords,and announcements of changes to the features, forms, or functions of applications.PatternsGeneric models or descriptions fromwhich specific implementations can bebased or derivedIn the IT context, patterns include reusable approaches for connecting applicationsto databases, establishing user security within an application, and implementinguser experience in a solution.ReferenceArchitecturesA template solution, using multiplepatterns and a vocabulary thatpromotes commonality, defining anarchitecture for a particular domainExamples of business reference architectures include Insurance ApplicationArchitecture for the insurance domain, and 'HL7 V2.5' for the electronic healthrecord domain. An example of a technical reference architecture is the JavaEnterprise Edition for IT systems construction.OutreachElevating awareness of programs andinitiatives to affected populationsExamples of broadly-focused outreach include ABCD meetings on many IT topics,while more narrowly focused outreach include Big Group meetings regarding ITskills upgrades.TrainingThe acquisition of knowledge and skillsas a result of teaching that relates tospecific competencies, with the goalsof improving an individual’s productivityand performanceIT training of techniques could include database design, software coding in node.js,and process modeling with BPMN. Examples of vendor tool training include OracleFinancials, PeopleSoft, and Informatica ETL.8

Architecture MaturityFocus on Architecture as a ProcessEstablish EA outcomes on a maturity scale in order to deliver value at all stages of the program.Enterprise Architecture at Harvard: Maturing Architecture FrameworksDRAFT — For Discussion OnlyEA MaturityContinuously-ImprovedEA ProgramEA widely adopted; legacy portfolioreduced to agreed minimum. Metrics are used to measureprogress and effectiveness againstEA plansArchitecture contracts in placeRequirements impact assessmentsidentify need for updatesRisk assessments drive EA practiceand evolutionMonitoring tools watch for newtechnology and business trendsSolution Architecture Reference ModelsOn-PremiseUserCommunitiesApplications& ServicesIntegrationUserCommunitiesApplications& ServicesMiddlewareUserCommunitiesApplications& ServicesDataCloudWell Defined EA ProgramEnterprise-wide scope of EA agreed, butadoption and implementation is limited. Governance committees becomeformalArchitecture board reviews workArchitecture skills framework inplaceOrganizations use templates tocapture informationCross-organization referencelibrary in placeStandards information base inplaceArchitecture patterns, based onpast effective solutions, in placeEA compliance process is followedconsistently, with exception andchange processesInteroperability requirementsconsidered in strategic planningand budgeting tiesUserCommunitiesApplications& ServicesApplications& nMiddlewareOn-PremiseData Architecture activities andprocesses are informal andunstructuredArchitecture depends on individualcontributorsArchitecture vision inconsistent andfragmented across organizationsLack of consistent business,application, and technologyarchitectures across organizationsLittle communication or sharingacross organizationsApps, Services, SaaSInteroperationDataMiddleware & PaaSInfrastructure & IaaSNetworking Solutions focuson businessvalue-addingcapabilities Significant reusethrough leverageof commonservices Compositeapplications arethe norm Servicesdesigned forenterprise reuse Solutionsdesigned forcloudimplementation Data exchangeprocessstandardized Catalog ofinterchange datasets publishedand managed “Pub/sub” modelprovides wideenterprise access Web serviceswidely deployed Composite andworkflowmanagedsolutions routine Data elementsconform toenterprisedictionary Application andservice dataaccessible viainteroperationtools Solution data andinteroperationdata setsidentified inenterprise datacatalog Pub/sub andwarehousingwidely used Rationalizedmiddlewareportfolio Clearimplementationstandards Integratedmanagement andmonitoring Routine use ofPaaS On-premiseinfrastructureonly byagreement Infrastructureresources spanthe enterprise Clear operationalstandards andpractices Skills-managedworkforce SLO/SLAcontractsconsistentlydeployed acrossenterprise Unified on-premiseand cloudnetworkmanagement Clear operationalstandards andpractices Single identitymanagementauthenticationprocess andmechanism Integratedsecuritymonitoring,notification, andreporting Clearorganizationaland operationalstandards andpractices Clear and rapidresponses toattacks andbreaches UX standards arewell defined Shared andcommon servicesconform tostandards Adoption acrossportfolio inprocess Implementationstyle refactoredas part of solutionevolution Rationalizedsolution portfolioagreed Application andservice processstandards andpatterns agreed Application andservice technicalstandards andpatterns agreed IT skillsframeworkadopted SaaS and cloudsolutionsconsidered for allnew work ‘Key’ applicationsintegrated viacommon bus ‘Key’ interchangedata formatted tostandards ‘Key’ interchangedata setdefinitionspublished andavailable onrequest ‘Key’ servicespublished andavailable ‘Key’ elementmeanings andformats defined Systems ofrecord identifiedfor key data sets Emergingcatalogs of dataat rest and inmotion Data qualityinitiatives areunderway Productstandards formiddleware toolsdeclared Emergingimplementationstandards Multipleimplementationsand operationalsegmentation Inconsistentimplementationacross platformsand organizations Rationalizedinfrastructureportfolio IaaS becomingroutine Skills andpracticestransformationsunderway Contract-basedservice levels forkey applications Cross-organizationmanagement ofnetworkresources Uniformallocation ofnetwork addressresources VLANsegmentationconsistent acrossenterprise Networkoperationsincreasinglyaligned tostandards andpractices Cross-organizationmanagement oflower-levelsecurityresources Integratedidentityrepositories Segmentedapplication andservice securityoperations Emergingoperationalstandards andpractices UX at thediscretion ofdeveloper orprocured solution Standardsmarginally inplace but notenforced UX in servicesconforms to ‘firstimplementation’ Implementationembedded anddifficult to evolve Redundantapplicationsacrossorganizations Low consistencyin solutionprocessimplementation Technicalimplementationsvary widely Adoption ofreusable serviceslow Limited use ofSaaS solutions Point-to-pointintegration Implementationvia scripts andstandaloneapplications Interchange dataformatsembedded andopaque Some sharedservices, but withinconsistenttechniques Data definitionsand formatsprivate toapplications Incompletecross-applicationor crossorganization datainventories Few ‘systems ofrecord’ for data Access to data islimited and‘hand-crafted’ Datatransformationopaque duringinteroperation Redundantmiddleware tools ‘Stovepipe’implementations Lack ofimplementationstandards Inconsistentintegrationacross tools Limited use ofplatforms-as-aservice Redundantinfrastructureservices acrossorganizations Inconsistentoperationalstandards andpractices SLO/SLAcontracts rare Occasional use ofinfrastructure asa-service Network addressresourcessegmentedacross enterprise Network resourcemanagement bycommittee VLANimplementationsinconsistent Gateways closelymanaged Security servicesdeployed in‘islands’ Multiple identitymanagementsolutions No cross-domaincorrelation Multiple securityteams andorganizationsCloudIntegrationInformal EA ProgramEA agreed in principle,but impact is limited. SecurityUser Experience UX standards arein place UX is seamlessacross compositeand discretesolutions Implementationsuse externaldefinitions foreasy mmunitiesApplicationsDataIntegrationCloud9

EA Focus AreasEnterprise Architecture: InteroperabilityDeliver a plan outlining how we will deliver the following for interoperability:Current State Current-state integration analysis Identify data passed betweenenterprise applications Identify the means of exchangeRequirements & FrameworksFuture Action Principles, methodologies, andadvisories Building a place to publish theoutcomes Patterns, reference architectures,and standards Next steps Resource requirements, includingsoftware and services Timings Deliverables Identification of a repository andprocess for keeping theinformation gathered up to date10

Questions or comments?

Thank you!

Dec 10, 2014 · Defines the Enterprise Architecture framework for review by Steering Committee Defines sub-groups to detail layers Builds and reviews other EA components as per vision Publishes a monthly report on enterprise architecture progress, issue