Appendix G –TechnicalMethodologyand ApproachDocument

Technical Methodology andApproach DocumentCWS/CMS TechnicalArchitecture AlternativesAnalysis (TAAA)California Health and HumanServices Agency Data CenterEclipse Solutions, Inc. 2151 River Plaza Drive, Suite 320, Sacramento, California 95833Phone: (916) 565-8090 Email: [email protected] Fax: (916) 565-5126

This page intentionally left blank.

Technical Methodology and Approach DocumentApprovalsProject Name: CWS / CMS Technical Architecture Alternatives Analysis (TAAA)Purchase Order Number: 0000014360Document Name: CWS / CMS TAAA Technical Methodology and Approach DocumentApproval Signatures:HHSDC – Lauren Barton, CWS / CMS Deputy DirectorDate:HHSDC – Ceciley Snook, CWS / CMS Contracts AnalystDate:Eclipse – Jim Brown, Project ManagerDate:Revision HistoryDateDescriptionCreatorInitial Version 1.0Version 2.0November 23, 2004December 10, 2004EclipseEclipseVersion 3.0December 23, 2004Version 4March 1, 2005Initial SubmittalUpdate to include State ProjectManager and Quality Assurancecomments.Update to include additional QAcomments.Update to incorporate FunctionPoint Analysis MethodologyCWS/CMS Technical ArchitectureAlternatives AnalysisPage iEclipseEclipse3/23/2005

Technical Methodology and Approach DocumentTable of Contents1Document Overview . 11.1Background . 12Approach and Methodology . 32.1Approach to Statement of Work . 32.1.1Task 1 – Project Management, Quality Assurance and Risk Management. 42.1.2Task 2 – Systems Engineering Analysis/Alternatives Analysis . 62.1.3Tasks 3 and 4 – FSR, APDU, and Request for Proposal Requirements. 223Project Work Plan – Task Level Description . 234Interview and Workshop Schedule . 385Project Schedule. 39Appendix A List of Acronyms . 40Appendix B Interview and Workshop Schedule . 42CWS/CMS Technical ArchitectureAlternatives AnalysisPage ii3/23/2005

Technical Methodology and Approach DocumentList of Figures and TablesFigure 1. Project Management and Systems Engineering Analysis / Alternatives AnalysisApproach. 3Figure 2. Scalable Project Management Framework. 4Figure 3. QA Methodology. 5Figure 8 - Function Point Application Boundary . 13Figure 4. Preparation Assistance Support and Acquisition Support Approach . 22Figure 5. TAAA Project Gantt Chart. 39CWS/CMS Technical ArchitectureAlternatives AnalysisPage iii3/23/2005

Technical Methodology and Approach Document1 Document OverviewThe Technical Methodology and Approach Document describes the methodology that theEclipse / Gartner team will be using to conduct the Child Welfare Services (CWS) / CaseManagement System (CMS) Technical Architecture Alternatives Analysis (TAAA) and themethod to be used for soliciting and capturing the business, technical and financial requirements.This document will serve as the basis of understanding the work to be performed under theTAAA Statement of Work (SOW).1.1 BackgroundThe CWS / CMS was originally implemented in 1997 and has moved into the Maintenance andOperations (M&O) phase. The system supports all 58 California counties, the Department ofSocial Services and has over 19,000 users identified. Since its implementation, the system hasincorporated all but four (4) of the most significant and critical SACWIS functionality requiredby federal requirements. The system’s current technical architecture is comprised oftechnologies and concepts that were common for large mission critical systems in the mid 1990s.The limitations of the current system include: Depends significantly on legacy application technologies that are expensive to maintainand restricts strategies to meet program goals; Does not lend itself to enhancement using emerging technologies; Does not satisfactorily meet the changing business and technical needs of the system’send users.The State has outlined an approach for analyzing the costs and benefits of alternativearchitectures that will address the limitations of the current system and the outstanding SACWISrequirements. The State believes that re-architecting the system may reduce maintenance costs,reduce the time and costs required for system upgrades, provide improved functionality and useraccess, allow the use of commercial off the shelf software, permit incorporation of web servicecomponents, and produce an open system architecture that is significantly easier to support thanthe existing system.The State decided to conduct an independent analysis of the best approach to solving theproblems and challenges faced by the existing CWS / CMS technical architecture. This analysiswill be performed by the Eclipse / Gartner team, which possesses expertise in large systemtechnical architecture alternatives analysis. The primary objective of the Eclipse/Gartner teamwill be to provide a Total Cost of Ownership (TCO) comparison between each of the three (3)alternatives defined by the State in the SOW, which include:1. Continue with the Current CWS / CMS Technical Architecture2. Evolve the Current CWS / CMS Technical Architecture to a Web Services BasedTechnical Architecture Over Time3. Continue M&O of the Current CWS / CMS and Simultaneously Build a New SystemUsing a Web Services Based technical ArchitectureCWS/CMS Technical ArchitectureAlternatives AnalysisPage 13/23/2005

Technical Methodology and Approach DocumentThe Eclipse/Gartner team will document their analysis and provide their recommendations to theState in the form of several key deliverables that include: Technical Methodology and Approach Document Annotated Outline of the Analysis Report Draft Section of the TAAA Report for Alternative #1 Draft Section of the TAAA Report for Alternative #2 Draft Section of the TAAA Report for Alternative #3 Draft and Final Versions of the TAAA Report.In addition to the TAAA tasks and deliverables, the Eclipse/Gartner team will also provide CWSCMS with support for State and Federal Approval and Acquisition Support Documents thatinclude: State Feasibility Study Report As-Needed Advance Planning Document Update Technical Requirements Document for a Request for Proposal.CWS/CMS Technical ArchitectureAlternatives AnalysisPage 23/23/2005

Technical Methodology and Approach Document2 Approach and Methodology2.1 Approach to Statement of WorkThe Eclipse/Gartner team will follow a structured approach to defining the TAAA forCWS/CMS (see Figure 1 below). We will work closely with the State to clearly understand thecurrent and future business and IT direction of the CWS/CMS program. Utilizing a well-definedand proven architecture analysis process, the team will assess the scope of the SACWISfunctional requirements and conduct a detailed analysis of the supporting application architecturealternatives, including a total cost of ownership based on these alternatives. Each of the three (3)alternatives identified in the SOW will be analyzed to determine the technical and businessbenefits, limitations, and risks associated with implementing required remaining SACWISfunctionality within the alternative, including cost comparisons that document the total cost ofownership over the expected life of the system for each associated alternative. TheEclipse/Gartner team will establish a decision-making process and criteria to aid stakeholders inselecting the most viable alternative; thereby, enabling the State to move forward in the approvaland acquisition phases of the overall project. Further definition of the actual architecturedefinition approach is provided in Section 2.1.2.Project planning and management are core functions throughout all lifecycle activities to ensureissues, risks, and resources are managed appropriately. Successful project planning andmanagement will also ensure the identification and communication of work activities andschedules relating to the TAAA development, internal and external approvals, coordination withstakeholders, and the transition to the procurement phase of the project.Figure 1. Project Management and Systems Engineering Analysis / Alternatives AnalysisApproachOngoing Project ManagementBusiness and IT AlignmentTechnologyTrendsGap Analysis and ent/TargetStateAssessmentDevelopCWS/CMS ITDirectionCreate BaselineAnalysis(functional andtechnical)Conduct GapAnalysisDevelopProposedSolutionDevelop TCOAnalysisTarget BusinessModel(SACWIS)CWS/CMS Technical ArchitectureAlternatives AnalysisPage 33/23/2005

Technical Methodology and Approach Document2.1.1 Task 1 – Project Management, Quality Assurance and Risk ManagementProject Management MethodologyThe following overview of our strategy for successfully managing this engagement is illustratedbelow.Figure 2. Scalable Project Management FrameworkProject Management Methodology Framework1. Project Initiation 2. Project PlanningProject Activities Project Champion Project Sponsor Business Case Project DefinitionIT ProjectGovernanceRolesProject Activities Project Manager Project Plan3. Project Execution4. Project CloseoutProject Activities Project Plan Execution Status Reviews Phase Reviews Data Gathering AnalysisProject Activities Project Acceptance Contract Review Knowledge Transfer Post ImplementationReviewAgency Project Management For Agency Specific ProjectsPMO Oversight or Project Management ProjectsQuality AssurancePotential Independent Verification and Validation for Larger ProjectsQuality Assurance MethodologyThe issue resolution and quality assurance (QA) approach and methodology is designed to meetour clients’ diverse and demanding needs. Our QA services serve to mitigate potential issues tohelp ensure the quality of IT projects by providing, for example: A Quality Master plan for each assignment that details the work products, reviews,methodology, time frames, resources, and expected outcomes Recommendations for QA best practices, tools, and techniques Project plan input as it relates to building in QA best practicesThe intent of the QA process is to verify and validate the interim work products of each majorphase of the project. Typical of most large-scale efforts, it is assumed that agencies will rely on aformalized approach to monitor and review the quality of its own interim work products. QA isCWS/CMS Technical ArchitectureAlternatives AnalysisPage 43/23/2005

Technical Methodology and Approach Documentintended to provide “another set of eyes” to review deliverables of all kinds, to ensure that theyconform as closely as possible to best practices.The Eclipse/Gartner team has adopted a proven, structured approach for performing QA servicesthat is consistent with standards established by the Institute of Electrical and ElectronicsEngineers, Inc. (IEEE) and the Project Management Institute (PMI). Our QA methodology istightly integrated with overall Project Management objectives. This methodology includesunderstanding and managing customer satisfaction and requirements; providing risk mitigationstrategies that focus on avoiding problems rather than correcting them; clearly communicatingresponsibilities; and ensuring that the project has appropriate resources to succeed in a timelyand cost-effective manner.Figure 3. QA ntIndependentQAQA htOversight/ /MonthlyMonthlyQAQAReportsReportsSource: Gartner 2004Risk Management and Issue Resolution Approach and MethodologyIn addition to project management and quality assurance, risk management methods areintegrated into our overall project management methodology. Risk identification, monitoring andresolution are key tools for successfully completing a project. Part of controlling a project is tohave an established risk management process. This process is a primary part of project planningand management activities and is kept current until project closeout. The Eclipse/Gartner teamwill manage project risks on an ongoing basis throughout the engagement.The key to risk management is having an understanding of all the potential risks to the project,and ensuring that these potential risks and risk mitigation strategies are communicated to keyproject stakeholders on an ongoing basis. An example checklist of action plan for riskmanagement is included below.Table 1. Risk Management Action Plan ChecklistAction Plan Checklist:1. Create a central repository for risk information and associated documentation of riskitems and resolution strategies2. Summarize information on a risk form3. Assign a risk manager, who should be either the project manager or a member of thestatus tracking/reviewing team (this assignment should have been done at projectbaseline, but definitely by the early days of performance)CWS/CMS Technical ArchitectureAlternatives AnalysisPage 53/23/2005

Technical Methodology and Approach DocumentAction Plan Checklist:4. Include a risk summary in the regular status meetings5. Provide a consistent and ongoing evaluation of risk items and development of riskstrategies6. Identify new risks (e.g., risk assessment)7. Evaluate new and existing risks8. Define/refine risk response strategies9. Select and obtain approval (from steering committee) for selected risk responsestrategies10. Implement approved risk response strategy11. Revise any related or impacted planning documents12. Conduct regular follow-up risk assessments based on magnitude of the projectSource: Gartner 20042.1.2 Task 2 – Systems Engineering Analysis/Alternatives AnalysisArchitecture ApproachOur approach to IT architecture is to begin with a baseline analysis and work through theenvironmental trends and business drivers down into the requirements for the architecture. In thisway, architectural discussions are tied directly to the business issues of the organization. In April2003, the CWS/CMS Project completed a Technical Architecture Strategic Plan (TASP) thatoutlined a broad conceptual model for evolving the current CWS/CMS technical architecture to aweb services based infrastructure over time. The TAAA will address the need to compare thebusiness, technical, and cost implications of implementing new SACWIS functionality andaddressing the business problems identified in the RFO and SOW (e.g., security, system access,system changes, etc.). Each alternative identified by the State will be compared in order todetermine the best solution to resolve unmet needs in the CWS/CMS environment. Given thatthe three alternatives have only been defined in very broad terms, the Eclipse/Gartner team willdevelop more robust scenarios for each alternative that will be validated during the alternativeanalysis workshops. These validated scenarios will then form the basis for the TCO modelingand analysis.The key principles of the Eclipse/Gartner approach are as follows:1The starting point must be to first define principles or strategy. The IT strategy clearlymust support the overall business strategy, including resolution of business problemscurrently being experienced by CWS/CMS. Business and technology drivers provide abasis for determining the non-functional needs that are currently unmet by the existingapplication (i.e., remote access, mobile support, etc.)CWS/CMS Technical ArchitectureAlternatives AnalysisPage 63/23/2005

Technical Methodology and Approach Document2The functional architecture is derived from the strategy (e.g., meeting SACWISrequirements). These functions become the focus of the assessment process, andprovide a starting point for defining the scope and cost of each of the three alternativearchitectures. Federal SACWIS requirements and function point analysis for bothSACWIS and Non-SACWIS requirements will be utilized.3The application architecture is comprised of the set of IT applications (bought or built)that deliver the functionality (plus a defined integration technology) that links thevarious applications and a coherent data model. For CWS/CMS, this includes relevantcomponents of the logical and physical layers as illustrated in Figure 4 below (theenabling layer is discussed as the technical architecture). For example, in the physicallayer we will discuss the original design principals and the rationale for constructing theapplication and allocating application logic, business rules, communication gatewaysand transactions, etc. In the physical architecture we will define the scope of SACWISand Non-SACWIS in terms of function points, discuss location of where key processesand transactions occur (i.e., desktop, middle-tier, host tier) and the allocation ofsoftware components across the tiers. We will first define the baseline CWS/CMSapplication then validate the target state design principals and application logic that willcomprise the Technical Architecture Alternatives Analysis 2 (TAAA2) and TechnicalArchitecture Alternatives Analysis 3 (TAAA3) alternatives. We will describe thechanges required for these alternative architectures in order to determine the TCOramifications of the change.4The technical architecture is the foundation upon which the application architecture isbuilt. The analytical process is similar to that defined for the application architecture.Since the current CWS/CMS system has implemented a very robust infrastructure, weanticipate that the significant change will occur in this layer among the alternatives.The Eclipse/Gartner team will develop a detailed inventory of the major infrastructurecomponents in order to determine the TCO implications of change under the TAAA2and TAAA3 alternatives.5The organizational architecture refers to the set of management processes or governancerules by which the needs of the user constituencies are identified, analyzed, prioritizedand satisfied by the IT delivery organizations (for this engagement, the Eclipse/Gartnerteam will address organizational architecture insofar as it applies to the decision-makingprocess among architecture alternatives).The Eclipse/Gartner team understands that the focus area for this effort is centered on thefunctional, application and technical architecture layers.For each of the TAAA alternatives, the Eclipse/Gartner team will develop a taxonomy thatsubdivides the technologies into individual technology components. The figure below is anexample of a taxonomy:CWS/CMS Technical ArchitectureAlternatives AnalysisPage 73/23/2005

Technical Methodology and Approach DocumentFigure 4. Application TaxonomyApplication Architecture FrameworkLayersSub-LayersLogical ArchitectureBusiness driversWhat IT does toApplication requirementssupport the business(site-specific)High level architecturePhysical ArchitectureSite-specific CommonServicesHow it does it(site-specific)Function PointsADE and RepositoryFundamental Design PrinciplesPlatform Allocation of ModulesEnabling TechnologyMiddlewareThe stuff it is made of(provided by vendors)Hardware and OperatingSystemsThe Eclipse/Gartner team of Technical Architects will then develop conceptual models of thearchitectural alternatives under consideration in order to develop a roadmap for the evolution ofthe environment. A high level illustration of TAAA2 is represented below:CWS/CMS Technical ArchitectureAlternatives AnalysisPage 83/23/2005

Technical Methodology and Approach DocumentFigure 5. Illustrative Conceptual Architecture DiagramSACWIS Alternative AnalysisAlternative 2: Incremental Migration to Web ServicesService-Oriented ArchitecturePseudo-Service-Oriented ArchitectureConsolidated DatabaseRedundant DatabasesCSESACWISSACWISNormalized ServicesBPM &RulesEngineWrapped Legacy Systems(e.g. Case Mgmnt, EligibilityDetermination, Fin. Mgmnt, etc.))Web Services I/FWeb Services I/FTANFWeb Services I/FWeb Services I/FWeb Services I/FWeb Services I/FWeb ServicesProvider EnvironmentWeb Services ProtocolsWeb ServicesConsumer EnvironmentThin Client Browser WindowsconsultingHHSDCSACWIS Migration Options and StrategyEngagement: 220629390 January 2005Entire contents 2004 Gartner, Inc.Page 13The Eclipse/Gartner team will then develop an evaluation framework to thoroughly review eachalternative. The objective will be to develop a consensus model that will result in the selection ofa proposed alternative. An illustrative example of such a framework is provided below:CWS/CMS Technical ArchitectureAlternatives AnalysisPage 93/23/2005

Technical Methodology and Approach DocumentFigure 6. Illustrative Alternative Evaluation FrameworkRiskTimeTCOBenefitsEvaluation CriteriaALT XALT YALT ZBusiness Alignment (1 low, 5 high)142Functionality (1 low, 5 high)Flexibility (1 low, 5 high)Maintainability (1 low, 5 high)Technology Architecture Coherence(1 low, 5 high)221344233243Implementation Costs (5 low, 1 high)523Maintenance Costs (5 low, 1 high)Time to Benefit Realization (5 short,1 long)Incremental Benefit Delivery(5 Frequent, 1 lengthy)Financial Risk (5 low, 1 high)Technical Risk (5 low, 1 high)Operational Risk (5 low, 1 high)Schedule Risk (5 low, 1 high)Implementation Risk (5 low, 1 high)152133253424451435334313Total365038The Eclipse/Gartner team will work closely with the State project team members to identify theappropriate evaluation criteria and the associated weighting for the framework. The project teamwill also identify and document the benefits, risks, limitations, total cost of ownership (includingthe unfulfilled SACWIS functional requirements), and any assumptions for each of thealternatives. Cost estimates for each alternative will be derived by triangulating a number ofestimation techniques, including function point analysis focused on sizing, for estimatingsoftware development costs and time frames.Function Point AnalysisThe Function Point Analysis (FPA) methodology utilized for the TAAA project is an internallyrecognized methodology for determining the overall size of a software application. Functionpoint analysis centers around seven basic steps: 1) Determining the type of function point count;2) Identifying the counting scope or boundary; 3) Identifying data functions; 4) Identifying thetransactional functions; 5) Determining the unadjusted count; 6) Determining the adjustment forcomplexity; and 7) Calculating the adjusted function point count. We used these results to sizethe current CWS/CMS application and then to develop estimates for the software developmentCWS/CMS Technical ArchitectureAlternatives AnalysisPage 103/23/2005

Technical Methodology and Approach Documentprojects in terms of effort, scheduling, and costs. The following paragraphs provide adescription of the function point analysis background and process. BackgroundIn the mid-1970s, IBM commissioned an engineer, Allan Albrecht and his colleagues toexplore software measurements and metrics. At the time, the main metric used for measuringsoftware was the “lines of code” metric. The technique was exactly as it sounds; it counts thelines of source code to determine software sizing, programmer productivity, anddevelopment project progress.The limitations inherent in the lines of code metric were quickly uncovered:o Individual programmer’s style greatly alter the countso Difficulties in agreeing on “what” constitutes a line of codeo Implementation choices in hardware and architecture greatly influence the source linecountsAs a result of these limitations, the function point metric was intended to be independent ofthe amount of code in software applications. In October of 1979, Albrecht presented thepaper “Measuring Application Development Productivity”. The paper described how thefunction point metric could be useful for analyzing the full lifecycle of software projects –from requirements development through delivery, maintenance and enhancement. By 1984,the International Function Point User Group (IFPUG) was created.In its simplest terms, function points count the externally visible aspects of softwareproducts: inputs to an application, outputs from an application, user inquiries, the data filesupdated by the application, and the number of interfaces to other applications. These itemsare then weighted by their complexity – the relative difficulty of implementing each. Onceadjusted by their complexity factors, the total of all these represent the function point countof the application. We used these results to provide estimated project effort, scheduling, andcosts. Function Point Counting ProcessSteps in function point counting:o Determine type of function point count (application)o Identify counting scope (application) and application boundaryo Identify data functions (ILF, EIF)o Identify transactional functions (EI, EO, EQ)o Determine unadjusted function point counto Determine value adjustment factoro Calculate adjusted function point countCWS/CMS Technical ArchitectureAlternatives AnalysisPage 113/23/2005

Technical Methodology and Approach Document Types of Function Point CountsThere are three possible types of function point counts:o Development project countso Enhancement project countso Application countsA development project count measures the end user functionality present at an application’sfirst installation. This includes the application’s basic functionality as well as thefunctionality needed for data conversion. An enhancement project count measures anymodifications made to the existing application by adding new functions, deleting oldfunctions, and modifying current functions. These counts are taken in context with thecurrent application function point count and the new count reflects all these changes. Anapplication count measures an existing application. The application count evaluates thecurrent functionality provided to end users by the application. The application count is thetype used for the CWS/CMS TAAA project. Determining Counting Scope and Application BoundaryAs noted above, the counting scope encompassed CWS/CMS as an application count. Thenext step in the process was to determine the application boundary. As with all aspects offunction point analysis, the application boundary is defined by the end user’s perspective ofthe system. Implementation choices or technical architecture do not influence the analysis.According to the Counting Practices Manual (IFPUG):o The application boundary for a client-server application includes the functionality of boththe client and the server.o A function point count of the application should be conducted from the perspective of thebusiness solution versus the technical solution.o The client-server environment and the various layers of the application are part of thephysical environment and are not part of the functional requirements.o All components need not reside on the same hardware platform.o From a business perspective, the application boundary of a client-server applicationconsists of all components that collectively meet the business requirements, regardless ofphysical implementation or platform.Based on these criteria, we have defined the CWS/CMS application boundary as shown.CWS/CMS Technical ArchitectureAlternatives AnalysisPage 123/23/2005

Technical Methodology and Approach DocumentFigure 4 - Function Point Application Boundary Identify Data Functions (ILF, EIF)Data functions refer to those logical data stored and available to the application. Theapplication can update, reference, or retrieve this logical data. The data functions are furtherdefined below.Internal Logical File (ILF)An internal logical file (ILF) is a user-identifiable group of logically related data orcontrol information maintained within the boundary of the application. The primaryintent of an ILF is to hold data maintained through one or more elementary processesof the application being counted.External Interface File (EIF)An external interface file (EIF) is a user-identifiable group of logically related dataor control information referenced by the application but maintained within theboundary of a different application. The primary intent of an EIF is to hold datareferenced through one or more elementary processes within the boundary of theapplication counted. An EIF counted for an application must be in an ILF in anotherapplication. Identify Transactional Functions (EI, EO, EQ)Transactional functions perform the processes of an application: updating, retrieving,outputting, and receiving input from the user. External inputs (EI) process the incoming dataof the application. External o

The Eclipse/Gartner team has adopted a proven, structured approach for performing QA services that is consistent with standards established by the Institute of Electrical and Electronics Engineers, Inc. (IEEE) and the Project Management Institute (PMI). Our QA methodology is tightly integrated wit