OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap

State of New Mexico

Office of State Engineer Interstate Stream Commission WATERS SOA Re-Engineering Project Solution Roadmap Jan. 05, 2011

CONFIDENTIAL – Not for distribution – – For discussion purposes only –

1

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Agenda    

WATERS Change Rationale Future State Architecture Highlights Roadmap Overview Roadmap Milestone Details

CONFIDENTIAL 2 Jan 05, 2011

– Not for distribution – – For discussion purposes only –

2

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Why Change WATERS?      

Current system unable to meet changing laws and regulations in time  single biggest reason Desired improvements in agency personnel utilization Improved employee morale Reduce costs in new feature development and existing feature maintenance Better business process transparency Increased general public satisfaction with State’s services

CONFIDENTIAL 3 Jan 05, 2011

– Not for distribution – – For discussion purposes only –

How To Judge Success? 

FY 2011 Targets



 Match pace of regulatory changes  Achieve 95% readiness to implement active water resource management in 7 key basins  Abstract 65% of water right application transactions 

5-Year Targets  Reduce Recurring Costs by $374K ($874K-$500K)  Provide Operating Savings of $874K (staff labor reduction + IT labor reduction + data quality improvements)

FY 2012 Targets  Process 22K water rights applications

CONFIDENTIAL 4 Jan 05, 2011

– Not for distribution – – For discussion purposes only –

3

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap WATERS Architecture Uses Layering 

Web 2.0 Rich Client (Workflow steps + Process Reports)  Easy to learn, customize and use



Business Process Orchestrations  Business Rule Engine

Process Monitoring



Legacy System Connectivity Files, Databases, Web Services, API etc. 





Existing Applications and Databases CONFIDENTIAL

5 Jan 05, 2011

– Not for distribution – – For discussion purposes only –

4

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap BPM Engine – The Heart of WATERS Future State

CONFIDENTIAL 6 Jan 05, 2011

– Not for distribution – – For discussion purposes only –

Business Process Orchestrations contain implementations of various Domestic and Non-Domestic business processes involving UI, web portal-based screens for system-to-human interactions and orchestrated access to legacy computing assets (databases, applications, business services etc.) via EAI adaptors. Business Rule Engine (BRE) supports definition, deployment and run-time execution of business rules used to drive business processes through various decision points and to perform necessary calculations. Enterprise Service Bus (ESB) hosts business service contacts and allows for their dynamic discovery and invocation. Business Activity Monitor (BAM) maintains process workflow state database and monitors both process orchestrations and service implementations at run-time. BAM serves as data repository supporting operational transactional and analytical reports. Shared Service Orchestrations are select elements of overall business process orchestrations that have been selected for re-use in various processes and to be exposed to various systems via service oriented façades. Service-Oriented orchestrations use process orchestration architecture augmented with necessary amount of custom programming logic as necessary to implement service interface contracts. Enterprise Application Integration (EAI) Adaptors are used by orchestrations to invoke functionality and obtain data contained in external systems (files, databases, web services, APIs etc.) 5

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Why Is BPM-Based Architecture Good for WATERS? Current system unable to meet changing laws and regulations in time





 Quick process and rule reconfiguration with minimal downtime

 Shift from programmer to technical BA resources  Re-use of existing application assets  Industry-standard I&O procedures  Possibility of development and I&O partnerships/outsourcing

Desired improvements in agency personnel utilization



 Intuitive, easy to learn and use, Web-based User Interfaces

Improved employee morale



 Increased job satisfaction resulting from improved productivity

Better business process transparency



 Real-time workflow state reporting 7 Jan 05, 2011

Reduce costs in new feature development and existing feature maintenance



Increased general public satisfaction with State’s services

 Self-service options with intuitive, easy to learn and use, Web-based User Interfaces  Up-to-date information CONFIDENTIAL availability – Not for distribution –

– For discussion purposes only –

6

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Roadmap Overview Vision

Technology POC

Architecture POC

RI

R II

R III

R IV

CONFIDENTIAL 8 Jan 05, 2011

– Not for distribution – – For discussion purposes only –

The approach to roadmap definition includes 2 dimensions: time and skill. Horizontal axis represents time and is broken down into 7 phases, each culminating with a milestone meant to assess phase outcomes against specified objectives. Envisioning phase concluded in the first week of January 2011 and has resulted in creation of the roadmap as part of Vision milestone. Technology Selection phase is intended to conduct RFP activities and to select a single core BPM technology vendor. In addition to technology selection, Technology POC milestone includes having selected the solution delivery and I&O approaches as well as having picked delivery/operations partners as may be required. Risk Reduction phase will demonstrate a viable executable architecture addressing key risks in all applicable risk categories. Architecture POC milestone will demonstrate organizational capability to build, run and govern the intended future state solution. Domestic process automation phase will result in the first production release of the re-engineered WATERS application and will cover all Domestic processes. This will be the first opportunity to realize efficiencies of the future state architecture in real life. Non-Domestic processes will be broken down into 3 releases, each aligned with one of the 3 defined document families. Each release will introduce additional core system capabilities and will tackle business processes of increasing complexity.

7

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Skill dimension of the roadmap is represented on the vertical axis. The following “disciplines” are identified and each will have a role to play in WATERS re-engineering. Business and Systems Requirements will cover business architecture definition (processes, rules, goals, KPIs etc.) as well as translate business needs into system requirements (use cases, supplementary specifications). System requirements will undergo further analysis steps and identified boundary objects (UIs, reports, files and services) will be specified in detail using appropriate templates. Software Development will include all resources necessary to create and demonstrate system architecture, provide detailed solution designs based on system requirements, build the necessary software components and orchestrations, test the resulting solution and turn it over to I&O for deployment. Infrastructure and Operations (I&O) has the responsibility to run the built solution in production environment as well as to provide necessary systems upgrades and enhancements as may be necessitated by end-user volumes. Business Operations represents all internal application users and is responsible for day-to-day interactions with WATERS. By functioning as the voice of the customer and representing interests of public constituents, business operations ensures optimal coverage of end-user needs in the future state solution. Enterprise Architecture (EA) Governance work stream ensures that all architectural assets (various executable frameworks, process orchestrations, services, databases, reports, UIs, legacy systems etc.) are developed according to chosen best practices, that all assets have clearly-defined organizational ownership and that changes to assets are only made after careful impact analysis and in accordance with organizational priorities. The blue “humps” in the middle of the roadmap chart represent relative levels of activity within each discipline and how these levels change with time.

8

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Milestone 1 – Formulating the Future-State Vision  

Envisioning Phase: Nov – Dec 2010 (completed) Objectives  To assess current application asset reuse as part of future state solutions  To analyze future state solution approaches – –

Custom-built application with COTS BRE BPM-based application

 To assess solution impact on organizational units… – – –

Business Operations Software Engineering I&O

 To formulate a multi-disciplinary approach to solution development – – –

Business process modeling and system requirements definition Systems architecture EA governance

 To build this roadmap CONFIDENTIAL 9 Jan 05, 2011

– Not for distribution – – For discussion purposes only –

9

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Milestone 2 – Selecting COTS Platform Technology Selection Phase: Jan – Feb 2011 Objectives

 

 To select BPM platform vendor from likely candidates – – – –

Progress Software IBM Oracle Microsoft

 To make an informed platform decision based on vendor-provided demonstrations –

Tailored technology POC

 To determine solution delivery approach based on selected technology – – –

100% in-house In-house with staff augmentation 100% outsourced

 To determine I&O approach based on selected technology – – –

Self-hosted, self-monitored Self-hosted, vendor-monitored Vendor-hosted, vendor-monitored

 To create staffing model andCONFIDENTIAL training plans

10

Jan 05, 2011

– Not for distribution – – For discussion purposes only –

As part of selecting COTS BPM platform, OSE has to decide on how the future state solution is going to be developed and operated by IT & Operations personnel from the staffing model perspective. 100% in-house delivery approach would entail scaling up full-time technology department workforce with individuals responsible for solution architecture, design, coding and testing. This does not mean all “developer”-type resources since a large portion of BPM engine-based process automation lies with Technical BAs, whose job it is to configure orchestration steps, business rules and skeletal UI pages. The team may be augmented to any extent with external consulting resources on Time and Materials (T&M) basis. Such external resources may include technology SMEs with in-depth platform knowledge and will function in architectural thought leadership capacity. Conversely, lower-end programmers and testers may be obtained on a vastly reduce cost basis, especially if involving delivery partner organizations with proven offshore presence. OSE may find it viable to completely outsource design and development activities for at least some of the modules and may rely on 100% outsourced system testing efforts to be performed entirely offsite and possibly offshore.

10

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap BMP engine and other supporting technologies (web portal, ESB, BRE etc.) may prove too much of a challenge to OSE I&O organization to handle on its own. Should the organization decide to keep I&O 100% in-house, substantial investments in personnel acquisition and training will be made in order to cover day-to-day operating needs and future system upgrades. Outsourcing or partnering decisions related to WATERS I&O split along the lines of hosting vs. monitoring. Both functions may be performed in-house as it is done with current state applications. The organization may choose to own the hardware but let an outsourcing partner perform remote monitoring and take care of necessary upgrades. Moving further in the outsourcing continuum would place both the system ownership and monitoring responsibilities with an external partner entity. Public cloud-based computing infrastructure should be considered as a viable option to reduce systems ownership costs for WATERS. Special attention should be paid to the need to replicate workflow state across various virtual computing nodes, as it is not a trivially simple endeavor. On the other hand, placing of stateless service implementation into Cloud environments is a proven best practice and should not present significant challenges.

11

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Milestone 2 – COTS Platform Selection RFP 

Business + System Requirements  1/10/11 – 1/14/11: Define technology POC scope (business processes, system use cases, NFRs)



Software Development 1/17/11 – 1/28/11: Prepare the RFP 1/31/11 – 2/11/11: Wait for vendor responses 2/14/11 – 2/18/11: Conduct orals/demos 2/21/11 – 2/25/11: Facilitate vendor decision involving Business and I&O  2/28/11: Begin procurement process    

CONFIDENTIAL 11 Jan 05, 2011

– Not for distribution – – For discussion purposes only –

The requirements provided as part of the RFP should guide the technology selection decision. From the system functionality view point, OSE should ask the potential vendors to demonstrate what the following capabilities would look like on their BPM platforms: •

• •

• • •

Creating a process orchestration consisting of performing a search for a business entity using a simple set of criteria and filtering out results based on a set of business rules related to user’s geographical location. This represents system implementation-time functionality. Performing a run-time search based on the above implementation. Modifying the search with additional criteria attributes, adding an intermediate step of notifying the “administrator” or search performance via email and changing business rules governing presentation of results. Re-executing the search with updated process and rules. Executing operational reports. Executing analytical reports. 12

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap In addition to the functionality demonstrations listed above the vendor will be required to provide system sizing recommendations and proposed software deployment options (and costs) to accommodate the performance requirements related to transaction volume and execution timing.

13

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Milestone 2 – Solution Delivery and I&O Approaches 

Software Development + I&O  Select suitable approaches  Negotiate with professional services vendors  Execute vendor agreements

CONFIDENTIAL 12 Jan 05, 2011

– Not for distribution – – For discussion purposes only –

14

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Milestone 3 – Adopting the MO Mindset  

Risk Reduction Phase: Mar – May 2011 Objectives To identify and mitigate RISKS To construct software frameworks for quick solution delivery To catalogue acceptable solution design patterns To demonstrate Development and I&O capabilities To form EA governance organization To set in motion staffing plans (acquisition, augmentation, training etc.)  To prepare detailed business and system requirements for R I      

CONFIDENTIAL 13 Jan 05, 2011

– Not for distribution – – For discussion purposes only –

15

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Milestone 3 – You can’t spell WATERS without RISK Business



 Not meeting complex business process requirements correctly resulting in diminished personnel effectiveness, increased operating costs, reduced constituent satisfaction etc.

Regulatory



 Inability to meet legally-binding laws and regulations resulting is severe penalties.

Technological



 Inability to implement key functional or architecturally significant performance (or other non-functional) requirements.

Technology organizational



 Lack of availability of skilled resources needed to carry forward the solution based on the architectural approach.

I&O organizational



 Inability to deploy, maintain and upgrade the system due to technological novelty. Tested executable software is the ONLY proof of risk mitigation! CONFIDENTIAL 14 Jan 05, 2011

– Not for distribution – – For discussion purposes only –

16

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Milestone 3 – Architecture POC, Ultimate “Show Me” 

Web Portal Framework      



Navigation Look and feel Common controls Customization Security Side-by-side Legacy and Future State operation

Services Framework  Use of ESB  Service-enabled orchestrations  Security



BPM Framework  Common diagnostics  EAI adaptor enhancements  Security



Applied to key functional requirements and NFRs + Encapsulated in solution design patterns

Reporting Framework  Operational and analytical reports CONFIDENTIAL

15 Jan 05, 2011

– Not for distribution – – For discussion purposes only –

Architecture POC is different from Technology Selection POC it that the former addresses actual system requirements by creating software components that end-up as part of the future-state solution, while the latter demonstrates how various technology platform would handle requirements from various categories (process creation, process execution, reporting etc.) in general and without building any reusable architectural assets. Architecture POC yields tested, executable code which addresses common functional and non-functional needs and is proven to be working by being incorporated as part of specific functional flows. For example, a diagnostic architectural complement responsible fro message tracing and logging would be re-used throughout the system eventually, but will start out its life as part of water right transaction search use case implementation.

17

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Milestone 3 – Skeletal EA Governance Model



Enterprise Architecture Review Board



 Meets weekly (1 hour)  Venue for discussion and approval of proposed architectural approaches  Forum to suggest EA Asset changes

EA Assets  Are… – – – – –

COTS components Frameworks Services Processes/Orchestrations Adaptors

 Each has an accountable owner and a clear change protocol

CONFIDENTIAL 16 Jan 05, 2011

– Not for distribution – – For discussion purposes only –

18

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Milestone 4 – Investments Begin To Pay Off with R I  

Domestic Process Automation Phase: Jun – Objectives  To use EA assets to automate Domestic water rights management processes – – –

Self-service and agent-assisted application entry Automated decisioning Meter data submission

 To maintain dual system operation with legacy WATERS serving Non-Domestic and future state WATERS Domestic transactions  To expand EA assets with additional features  To regularly exercise Governance mechanisms – –

EARB Change Management

 To institute production I&O policies and procedures  To prepare detailed business and system requirements for R II

CONFIDENTIAL 17 Jan 05, 2011

– Not for distribution – – For discussion purposes only –

19

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Milestone 4 – What Happens to Legacy Applications? 



  

Prioritize WATERS Non-Domestic improvements and only implement most pressing ones. Wait for R II – IV to implement the rest. Sunset WRATS2WATERS features related to Domestic transactions. The new architecture will serve as WRATS to WATERS integration platform. Enhance only most critical NonDomestic integration areas. Keep Document Management unchanged. Adaptor-based WATERS components will bring FEITH updates into BPM world. Integrate GIS with WATERS future-state only. Expose Domestic Transaction Details through NMWRRS web site and keep Non-Domestic data in legacy application. What about projects “in-flight” or “ready-for-takeoff” Like Enterprise Reporting Architecture? CONFIDENTIAL

18 Jan 05, 2011

– Not for distribution – – For discussion purposes only –

In addition to impact on existing systems, special attention should be paid to technology decisions affecting projects which have not yet been undertaken or made substantial progress towards completion. An example of such a project is development of Enterprise Reporting Architecture. It is understood that such architecture will rely on technologies which will have to work synergistically with WATERS. Enterprise reporting requires a combination of transactional and analytical databases, ETL engine to implement data file-based integration needs, reporting framework to generate transaction al and analytical reports, and, finally, a web portal to enable on-demand report execution and display of results to end-users. The obvious overlap with WATERS occurs in the area of database engine, reporting framework and web portal. Decisions made for WATERS application re-engineering should be weighed against other enterprise initiative needs so that technological overlap and the resulting cost increases and other inefficiencies can be minimized.

20

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Milestone 4 – Old and New Running Side-by-Side 

Use Citrix MetaFrame construct to expose new and legacy WATERS function in the web portal  Let end-users decide which interface to invoke within the portal  Direct users to web pages fronting future state processes for migrated/enhanced/new workflows  Frame legacy application screen and expose them “as-is”



Direct NMWRRS data enquiries to the new system for migrated data and processes. Keep old queries for the rest (nondomestic)

Develop temporary integration routines to enable parallel system operation

CONFIDENTIAL 19 Jan 05, 2011

– Not for distribution – – For discussion purposes only –

21

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Milestones 5-7 – Incremental Non-Domestic Releases  

Non-Domestic Process Automation Phase: – Overall Objectives  To gradually sunset legacy WATERS application  To enable processing of different document types on legacy vs. future state WATERS  To expand EA assets with additional features  To refine Governance mechanisms – –

EARB Change Management

 To streamline I&O policies and procedures R II – Documents with no review/action



   

HS NOIAP OOJ ORDER

20 Jan 05, 2011

R III – Documents with review and/or action but no publication 



      

COWNF DCL COWNP EXPL LIC REPAR RFP

CONFIDENTIAL

       

– Not for distribution – – For discussion purposes only –



R IV – Documents with review, action and publication

APPRO ALTD CLW CLWPL CLWPP CLWPU COMB CPD CPDPL

        

CPDPP CPDPU CPLA CPLAS CPPSW CPPU CPUR CPURS DED

      

ENLRG FCDAM GTSPP GWTSW SUPPL STGPP SWTGW

22

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Milestones 5-7 – Sequential vs. Overlapped Delivery

Sequential delivery



 Lower burn rate  Fewer bodies, less project management overhead  Longer time to market 

Overlapped Delivery  Higher burn rate  More bodies, more project management overhead  Shorter time to market

Either model will work: The RISKS are gone by this time! CONFIDENTIAL 21 Jan 05, 2011

– Not for distribution – – For discussion purposes only –

23

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Methodology Needs Envisioning Phase – Selecting Methodology Approach



 Business + Systems Requirements – –

Select modeling tool Demonstrate tool usage for business/system requirement modeling

 Software Development – –

Select modeling tool Demonstrate tool usage for software architecture modeling

Risk Reduction Phase – Learning The Ropes



 Business + Systems Requirements –

Requirement Specification Training - Business Process Definition (2 days classroom + 1 month on-the-job) - Use Case Specifications (1 day classroom + 2 weeks on-the-job) - System Analysis Element Specifications (1 day classroom + 2 weeks onthe-job)

–

BPM + BRE (4-5 days classroom + 2 month on-the-job)

 Software Development – – 23 Jan 05, 2011

Solution Architecture Modeling (2 days classroom + 1 month on-thejob) Technology-specific trailing (classroom and on-the-job, durations CONFIDENTIAL TBD) – Not for distribution – – For discussion purposes only –

24

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap Methodology Needs (contd.) Risk Reduction Phase – Learning The Ropes



 I&O –

Operations Management Package-specific trailing (TBD)

CONFIDENTIAL 24 Jan 05, 2011

– Not for distribution – – For discussion purposes only –

25

OSE/ISC - Water Rights Systems Modernization Project – Architecture Solution Roadmap From Novice to Independent Worker in ~3 Months Classroom Training



 1-5 day sessions depending on subject  Case-based method with hands-on tool/concept usage  Real-time instructor feedback

On-the-job Training



 Step 1 – Side-by-side Mentoring – – –

Mentor sits with trainee and performs most assigned tasks. Trainee mostly watches and contributes to deliverables occasionally 1 week to 1 month, depending on task/concept complexity 1 mentor : ~5 trainees max

 Step 2 – Semi-Independent Assignment – – –

Trainee does most of the assigned work. Mentor watches progress and provides timely corrections/improvement suggestions 2 weeks to 2 months, depending on task/concept complexity 1 mentor : ~7 trainees max

 Step 3 – Independent Assignment with Mentor Validation – – 25

–

Jan 05, 2011

Trainee works independently. Mentor verifies quality and progress in regular intervals (1-2 weeks) ~1 month CONFIDENTIAL Not for distribution – 1 mentor : ~10 trainees –max – For discussion purposes only –

26