Guidebook for Standards and Methods Level 0 (VEAF)
State of Vermont Enterprise Architecture Framework (VEAF) Guidebook for Standards and Methods Level 0 Version 2.1 May 2014 VEAF Guidebook State of Vermont Revision History Version Date Organization / Point of Contact Description of Changes 1.0 2/4/2014 J. Hunt Initial Version 2.0 4/7/2014 c. Bradley Formatting and reworking content 2.1 5/6/2014 C. Bradley Editing Formatting consistent with other VEAF documents. Aligned components with HSE VEAF HSEP Strategy Documents. CONTENTS Executive Summary....................................................................................................................................... 6 Value of the Enterprise Architecture Office ........................................................................................... 6 Introduction .................................................................................................................................................. 8 Chapter 1 - Background ................................................................................................................................ 8 Enterprise Architecture Definition ......................................................................................................... 9 Scope .................................................................................................................................................... 10 In Scope .......................................................................................................................................... 10 Out of Scope................................................................................................................................... 10 Approach .............................................................................................................................................. 10 Governance .................................................................................................................................... 11 Business ......................................................................................................................................... 11 Application ..................................................................................................................................... 11 Information .................................................................................................................................... 11 Technology ..................................................................................................................................... 12 EA Strategy ..................................................................................................................................... 12 Domain Levels of Understanding ................................................................................................... 12 Focus..................................................................................................................................................... 12 Benefits of VEAF ................................................................................................................................... 13 Chapter 2 - VEAF Organization and Administration ................................................................................... 13 Organizational Roles & Management Responsibilities ........................................................................ 13 Architecture Owner ....................................................................................................................... 13 2|Page VEAF Guidebook State of Vermont Enterprise Architecture Office ....................................................................................................... 14 Enterprise Architect ....................................................................................................................... 15 Communications Plan ........................................................................................................................... 15 Chapter 3 - Enterprise Architecture Office as a Center of Excellence ........................................................ 17 Architecture Governance Processes .................................................................................................... 18 Identification of Stakeholders across the organization ................................................................. 18 Manage Best Practices ................................................................................................................... 19 Architecture Documentation Process ............................................................................................ 19 Architecture Review Process ......................................................................................................... 19 Architecture Communication Process ........................................................................................... 19 Architecture Compliance Process .................................................................................................. 19 Architecture Sustainability Management ...................................................................................... 20 Architecture Change Management Process .................................................................................. 20 Chapter 4 - Business Drivers ....................................................................................................................... 20 Background........................................................................................................................................... 20 Enterprise Business Drivers .................................................................................................................. 21 Chapter 5 - Technology Trends ................................................................................................................... 22 Enterprise Information Technology Trends.......................................................................................... 22 Chapter 6 - Principles .................................................................................................................................. 24 Guiding Principles of an Agency ........................................................................................................... 26 Chapter 7 - Enterprise Best Practices.......................................................................................................... 27 Enterprise Architecture must be an in-sourced effort ......................................................................... 27 IT resources must be focused on the agency’s mission ....................................................................... 27 The State will use a standard set of proven technologies.................................................................... 27 Technology selection will consider the ability to support systems ...................................................... 28 Governance of enterprise architecture will be centralized.................................................................. 28 The State will balance the needs of privacy and accessibly ................................................................. 28 Chapter 8 - Business Unit Considerations and the Importance of Non-Functional Requirements ............ 28 The NON-Functional Requirements Document.................................................................................... 29 Operational Considerations.................................................................................................................. 29 Business problem as articulated by the Business Lead ........................................................................ 30 Chapter 9 - Adapting the Architecture Development Method (ADM) for Business Units within the State of Vermont .................................................................................................................................................. 31 Preliminary Framework and Principles ................................................................................................ 32 3|Page VEAF Guidebook State of Vermont Sustainability Management Model ...................................................................................................... 33 Project Design and Implementation..................................................................................................... 33 Demonstrable Effectiveness ................................................................................................................. 33 Financial Resources .............................................................................................................................. 34 Business Earned Value Technique ........................................................................................................ 34 Components ......................................................................................................................................... 35 BU Architecture Assessments (ADM Phases A through E) ................................................................... 36 BU Migration Planning into the EA....................................................................................................... 36 BU / EA Governance and Principles...................................................................................................... 37 BU / EA Change Management Communication Methods .................................................................... 37 Chapter 10 - BU Requirements Management and the Requirements Repository. .................................... 40 Special Note on the Oracle SOA Repository. ........................................................................................ 42 BU Architecture Model Conclusion ...................................................................................................... 43 Chapter 11 - EA Documentation Requirements (Artifacts) for Architecture Models ................................. 44 Application of Views and Viewpoints ................................................................................................... 44 Documentation Requirements ............................................................................................................. 44 ISO/IEC/IEEE 42010 Architecture Description Template for collecting Artifacts ................................. 46 Chapter 12 - Conclusion .............................................................................................................................. 47 Supplemental .............................................................................................................................................. 48 Appendix A – State of Vermont HSEP Liscenced Products ................................................................... 48 4|Page VEAF Guidebook State of Vermont Table of Figures Figure 1- B-A-I-T, Governance and Strategy ............................................................................................... 11 Figure 3- EA Center of Excellence for SOA .................................................................................................. 18 Figure 5- Business Domain Principle Map................................................................................................... 26 Figure 6- Technology Domain Principle Map .............................................................................................. 27 Figure 9 Phases for Vermont Architecture Development Process Based on ADM from Open Group ....... 32 Figure 10 Change Control Method for Vermont EA and BU ....................................................................... 39 Figure 11 Architecture Repository .............................................................................................................. 41 Figure 12 Content of the Architecture Description .................................................................................... 46 5|Page VEAF Guidebook State of Vermont EXECUTIVE SUMMARY This is a guidebook, as such it is meant to guide readers through an overview of the State of Vermont Architecture Framework (VEAF). It presents a brief method for directing the guidance, development, and best practices for the administration of the State of VEAF platform. The purpose of this document is to foster an appreciation of why Enterprise Architecture is needed, the sphere of technical influence it governs and how the framework is used by the business to meets meet and satisfies their mission. VALUE OF THE ENTERPRISE ARCHITECTURE OFFICE The nature of data processing has changed greatly in recent years. Today’s system users have more computing power at their desktops than mainframes had just a decade ago. Each year, new and better applications, software, hardware and peripherals are being developed. Each advance offers new opportunities to increase processing capability and improve service to constituents of the State of Vermont. Every change state agencies or departments make to parts of a system, whether to take advantage of new technologies or to respond to business changes, potentially affects many other parts of the statewide IT portfolio. Furthermore, the systems built today must be capable of integrating with those that are built tomorrow. VEAF is adaptable to such change yet it demands detailed plans, processes and the commitment of all stakeholders across the organization. VEAF is a complete expression of the enterprise; a master plan which acts as a collaboration force between aspects of business and technology -- unifying both into a single goal. All the individual components of the architecture to be used in the development of systems and must also ensure that those components work together for the benefit of the whole. The standards and guidelines governing VEAF will serve to support those who are making technologybased decisions for the State of Vermont. Rather than resorting to out-of-context, ad-hoc studies to facilitate strategic IT decision making, IT Managers can look to the VEAF for guidance and direction to capitalize on the technologies of the future while preserving today's investments. The goal is to enable the State of Vermont to optimize its systems and make the whole greater than the sum of its parts. By encouraging standardization of products and processes that are compatible with the architecture and by providing guidance to planners, designers and implementers, VEAF represents a major step toward optimal, cost-effective resource utilization. 6|Page VEAF Guidebook State of Vermont Figure 1 VEAF Enterprise Architecture 7|Page VEAF Guidebook State of Vermont INTRODUCTION State of Vermont Enterprise Architecture Framework (VEAF) is an approach to Enterprise Architecture based on The Open Group Architecture Framework (TOGAF) and Oracle Enterprise Architecture Framework (OEAF). This chapter identifies the background and business case for architecture as well as an architecture definition, scope of the architecture effort, approach to the architecture program, a definition of program deliverables, and the focus of the effort. CHAPTER 1 - BACKGROUND In January of 2013, the State of Vermont Information Technology Strategic Plan 2013-2018 was published. This plan outlines Vermont’s IT vision for the next five years. The opening executive summary, called out Department of Information and Innovation’s (DII) mission, goals and resources required, and strategic principles which are listed below: The goal of state-wide Enterprise Architecture is to enhance coordination, simplify integration, and build a consistent infrastructure. Department of Information and Innovation’s Mission: To improve state government effectiveness and productivity, the Department of Information and Innovation provides expertise, standards and shared services for the state enterprise and supports agency and/or department-specific IT. Department of Innovation’s Goals and Resources Required (estimates for 2013 – 2018): Modernize critical technologies (IT) - $430M (roughly 90% non-state funding) over 5 years Ensure sustainability of IT capabilities - $ 13M over 5 years Operate IT effectively - estimated $350M - $500M 2over 5 years Enable productivity improvement throughout government - $ 35M over 5 years Department of Innovation’s Strategic Principles: Leverage IT successes in other States Leverage shared services and cloud-based IT Leverage modern IT delivery frameworks Align the technology workforce to adapt to IT trends Couple IT with business process optimization Optimize IT investments via Enterprise Architecture (EA), Project Management (PM), and Project Portfolio Management (PPM) methodologies. Strategic principle six specifically calls for the optimization of IT Investments via enterprise architecture methodologies and as such legitimizes the VEAF endeavor. The goals of VEAF focus on the business first, enhancing coordination of efforts between the business and IT, simplifying integration, building a consistent infrastructure, and generally allowing for greater efficiencies in the development of technology solutions. The intent of VEAF is to realize these goals while ensuring the effective use of 8|Page VEAF Guidebook State of Vermont state resources, thereby enabling consistent, effective delivery of services to Vermonters, State of Vermont employees, vendors, and the businesses of Vermont. Enterprise Architecture covers the broad spectrum of the strategic and operational capabilities of an organization. This includes business, application, information, and technology domains. Technology environments include networks, applications, databases, messaging, interfacing, middleware, security, operations and other relevant architecture disciplines. Guidelines will be developed to facilitate access and consolidation, provide security, eliminate duplication and help ensure that solutions are extensible, scalable, and more easily integrated. The pervasive use of the Internet is the primary driver of Enterprise Architecture. Citizens have come to expect services to be provided through the Internet and the state must be capable of responding to those demands. There are currently several departmental websites that provide information or services. However, there is a broader need to provide integrated statewide services. The current state egovernment initiative will provide the first opportunities to establish architectural standards. Future egovernment initiatives will be developed in conjunction with standards that will become part of the Enterprise Architecture. Adopting Enterprise Architectural standards will require an ongoing commitment by the state. But with the evolution of new products, technology trends, business trends, and user demands will require a consistent architectural standards to ensure ongoing system stability. Compliance with architectural standards will continue to evolve over time. The result of adopting consistent EA standards will allow for more effective use of state resources and a more efficient delivery of services. ENTERPRISE ARCHITECTURE DEFINITION In order to develop Enterprise Architecture (EA), there must be a common understanding of the term “EA”. EA is a strategic information asset base, which defines the mission, the information necessary to perform the mission, the technologies necessary to perform the mission, and the transformational processes for implementing new technologies in response to changing mission needs (Schekkerman). 1 An EA includes baseline enterprise architecture, target enterprise architecture and a transition plan. The EA is managed by governance and principle methodologies documented and introduced as guidelines for the support of the business mission. The need for sustainable business and IT operations is one of the primary drivers of Enterprise Architecture. EA encompasses functional and operational aspects of the organization it describes. A complete enterprise architecture description serves multiple purposes, among them: Understanding, rationalizing, and mapping key business capabilities to their supporting technology components. These technology components may change over time. 1 Schekkerman, Jaap. Enterprise Architecture Good Practices Guide. Trafford: Vancouver BC, 2008 9|Page VEAF Guidebook State of Vermont Breaking down the complexity of the supporting IT systems so that developers can analyze and design components that are relatively isolated from one another without compromising their ability to integrate them Analyzing the functionality so that required technical components (or infrastructure) can be identified Assisting in the analysis of service-level requirements so that the means of delivering them can be designed Providing a basis for the specifications of the physical computer systems on which the IT system will execute, and providing the basis for the mapping of components onto these computer systems The architecture efforts within the State of Vermont are intended to identify and document existing systems, infrastructure, and components, as well as the blueprint for the development of new systems, components, applications, and major modifications to existing systems. SCOPE Managing the scope of the VEAF is essential to its success. The scope of the VEAF is defined by the business operations and processes organizations most impacted by technology and where the adoption of the architecture is most influential. In Scope Information technology architecture is a strategic issue that must be addressed. The VEAF encompasses the Executive, Legislative and Judicial branches of state government. Out of Scope Vermont Higher Education and local governmental entities are outside the scope of this Enterprise Architecture program. However, where these other government entities are impacted, along with those organizations that do business with the State, compliance to VEAF definitions, drivers, governance and principles are enacted and enforced. APPROACH Over the past few years, business demands have caused the State information technology divisions and State government leaders to consider information technology architecture for both current and future technologies. A framework needed to be adopted that would allow business units within the State to turn to VEAF for assistance in achieving their respective mission statements and goals. Using The Open Group Architectural Framework (TOGAF) and Oracle Enterprise Architecture Framework (OEAF) as a baseline, VEAF follows industry standards and principles. These standards and principles guide all activities of VEAF and its strategic IT plan. DII also developed organizational roles, management responsibilities, to complement VEAF. The organizational roles and responsibilities define how the Enterprise Architecture is maintained and managed. The processes define how the architecture’s vitality is maintained and how governance determines what part of the architecture becomes accepted, revised or rejected. 10 | P a g e VEAF Guidebook State of Vermont The following key architecture domains drive the VEAF program: Business, Application, Information, and Technology. These domains are embraced by Governance and the Enterprise Architecture Strategy. For the purposes of the Vermont Health Connect, The Agency of Human Services primarily drives the business side. As designs, decisions, and other details are gathered and documented; the resulting artifacts are captured and stored in the EA repository for future use and modification as needed. In our current implementation, Business, Application, Information, and Technology (B-A-I-T) domains are managed by Governance and EA Strategy. Figure 2- B-A-I-T, Governance and Strategy Governance Indicates the overall enterprise governance that is required across all domains. It includes a Center of Excellence (CoE) and Change Control Board (CCB). The function of Governance is to review and approve any potential exceptions to the enterprise within the guidelines of the overall strategy of the State. Business Has ownership of components and processes is related to the VEAF Development, Security and Management. Governance guides the relationship among all domains. The Business domain is responsible for the following: Mission and Goals, Critical Success Factors, Business Capabilities, Business Process and Design, Requirements, Rules and Organization. Application The Application Domain involves the following: EA Integration, Custom Application Development, Service Definitions, Process alignments, and Services Architectures. Information As its name suggests, is data centric. This domain involves the following: Data Integration, Data Architecture, Master Data Management (MDM), Metadata Management, Data Delivery, Business Intelligence (BI) and Analytics, Enterprise Reporting and Performance Management, Data Quality and Modeling, and Content Management. 11 | P a g e VEAF Guidebook State of Vermont Technology Focuses on hardware and Operating System (OS). This domain covers servers, network and network appliances, telephony, OS, computers (desktop, laptop, and virtual), middleware, Database(s), Security applications or devices, Storage systems, mobile portability and, Cloud Services. EA Strategy Concerns itself with the enterprise strategy that the State of Vermont is employing to leverage best practices, provide reusable business services and guidance to vendors during implementation according to the enterprise architecture standards adopted by the state. Domain Levels of Understanding The capabilities of the business, application, information, and technology domains can be understood on multiple levels. This document is meant to function at level 0 and 1, providing a high level overview of VEAF, without concerning itself with the details of individual systems or applications. Level 0 – Capability Mapping for Business , Application , Information , and Technology Architectures Level 0 Business Capabilities Application Capabilities Information Capabilities Technology Capabilities Level 1 – Map Business Processes to Application, Information, and Technology Support Models Level 1 Business Processes, Business Sub-Processes Business Services & Generic Application Services mapping App Diagrams, Capability Model, Tech Support Model, & Product Mapping Data Object Support Mapping Data Integration Model Data Context Technical Capability Model & Product Mapping Level 2 – Component View Level 2 Application Component View ERD Diagram Integration Support Model Technology Component View & Logical Operational Reference Architecture Level 3 – Functional Requirements Level 3 Product Application Services Level 4 – Technical Requirements Level 4 Product Technical Architecture Figure 3 The Five Levels of Understanding FOCUS The State of Vermont recognizes that the development of Enterprise Architecture is a long term, ongoing process. The approach taken by the State of Vermont describes architecture as an adaptable, and 12 | P a g e VEAF Guidebook State of Vermont evolving process providing continuous alignment between the business of state government and technology. The current focus of VEAF is the Agency for Human Services. Nonetheless, VEAF functions with a view to adaptability and vitality by engaging with other business units within the State, offering high level technical expertise as to the suitability of a Business Domain’s functionality within the EA. BENEFITS OF VEAF Fundamentally, the framework of EA provides a “generic problem space and common vocabulary within which individuals can cooperate to solve a specific business problem.” (Schekkerman, p. 59). Frameworks are guidance tools. As mentioned in the Approach above the framework for VEAF is based on TOGAF and OEAF. The specific benefits of VEAF are listed below. VEAF provides an enterprise-wide IT vision that supports business objectives. It implements best practices and principles resulting in efficient, rapid responses to emerging business needs. It reduces expenditures by lower development, support and maintenance costs. VEAF creates reusable pattern of architecture which minimize costs. Provides an Enterprise Architecture with a clear strategy for procurement and migration. VEAF offers a consistent framework providing for better return on existing investment and supports future technology decisions. CHAPTER 2 - VEAF ORGANIZATION AND ADMINISTRATION This chapter identifies the administration aspects of VEAF. They include architecture governance, roles and responsibilities, and the governance processes. These, in conjunction with strategic plans, project management, and risk assessment requirements, will ensure the architecture remains viable and supports the business of the State. ORGANIZATIONAL ROLES & MANAGEMENT RESPONSIBILITIES The support of Enterprise Architecture requires the involvement of personnel in a variety of roles and responsibilities. The VEAF has identified the roles and organizational duties at both the State and departmental level. The following provides a narrative description of the identified roles and responsibilities. Architecture Owner The Architecture Owner is an executive manager with the authority and responsibility for the State’s technology direction and owns the Enterprise Architecture. This position exists on two levels; The State of Vermont CIO acts as the manager of technology and architecture from a statewide perspective. The State of Vermont Chief Technology Officer (CTO) acts as the Architecture Owner at the department level. 13 | P a g e VEAF Guidebook State of Vermont ARCHITECTURE OWNER RESPONSIBILITIES Supporting Enterprise Architecture requires the involvement of personnel in a variety of roles and responsibilities across the entire organization. Champions the value and effectiveness of the Enterprise Architecture Ensures that the on-going implementation of architecture is successful Continuously demonstrates the benefits of the Enterprise Architecture Ensures applications and services conform to the Enterprise Architecture Promotes understanding and acceptance of the Enterprise Architecture Assures appropriate resources are available and assigned to architecture roles Ensures quality and currency of the architecture Appoints an Architecture Office to oversee the use, maintenance and communication of the architecture Maintains particular focus on managing the architecture principles Enterprise Architecture Office The Enterprise Architecture Office is managed by the State CTO. The office oversees the development of the VEAF, and is responsible for the use, maintenance and communication of the CAP at the enterprise level. The CTO has been appointed by the CIO to chair and operate the Enterprise Architecture Office. ARCHITECTURE OFFICE RESPONSIBILITIES Maintains a focus on managing the Architecture Governance processes Implements and manages a compliance process to ensure the conformance of IT deployment projects to the Enterprise Architecture Implements and manages a vitality process to ensure the currency and accuracy of the Enterprise Architecture Implements and manages a communication plan Educates application developers, users, and management on Enterprise Architecture Ensures all committees function appropriately and effectively and with a consistent methodology Educates facilitators and domain committee members on the methodology Establishes and manages architecture targets and measurements Establishes and manages the architecture implementation plan Develops and maintains the architecture templates used by each domain Acts as a liaison to other governmental entities and coordinates efforts with external standardssetting bodies 14 | P a g e VEAF Guidebook State of Vermont Enterprise Architect The Enterprise Architect, as a member of the Enterprise Architecture Office, is responsible for the use and communication of the Enterprise Architecture (e.g. principles, processes, components) on behalf of the Architecture Owner at the department level. The CTO will assign Enterprise Architects to work with departments on assessing needs, offering assistance in communication and education as to what the VEAF offers, while adhering to the governance and principles guiding VEAF. Agencies have the latitude to refine the components within their domain, and the EA will incorporate into the architecture. As authorized an EA may reject or require enhancements to components from the Agency in order to adhere to the governance and principles of the Architecture. ENTERPRISE ARCHITECT RESPONSIBILITIES WITH RESPECT TO AN AGENCY The Enterprise Architecture Office provides a central focal point for ensuring the vitality of the IT architecture, overseeing architecture management processes at the statewide level. Establishes and manages a departmental compliance process to ensure the conformance of IT deployment projects to the Enterprise Architecture Establishes and manages a communication plan within the department Provides education on the Enterprise Architecture to application developers, users and management Establishes and manages architecture targets and measurements Establishes and manages the architecture implementation plan Manages the physical storage and dissemination of the departmental architecture contents Maintains a focus on managing the department’s integration with the VAEA governance processes. Maintains a liaison relationship with the Architecture Office Participates as a technical member of the Center of Excellence (CoE) along with the business members ENTERPRISE ARCHITECT DOMAIN RESPONSIBILITIES Develops and maintains domain content in the Architecture Blueprint Assist statewide Architecture Review Committee with compliance studies, product reviews, and architecture change/help requests Provide guidance to departments on domain-specific architecture issues Provide technical assistance and recommendations on architecture issues COMMUNICATIONS PLAN Enterprise Architecture contains large volumes of complex and inter-dependent information. Effective communication of information to the right stakeholders a critical to success. An agreed upon 15 | P a g e VEAF Guidebook State of Vermont communication plan with a well-defined set of roles, responsibilities and processes needs to be outlined at the beginning of any project involving the Enterprise. The Enterprise Architect and the Business Unit are responsible for approving the initial target architecture of a project. The EA, using the guidance of the architecture principles, seeks to move the business toward their solution through a managed and deliberative process using a communication plan. The typical contents of a communication plan are: 1. Stakeholder identification 2. Organization of communication needs and mechanisms such as meetings, repositories, and access to shared documents. 3. Identification and creation of foundational business documents such as charters, business drivers, business goals, and business strategies. 4. Identification of KPIs (Key Performance Indicators) 5. Identification of upfront risks Once a communication plan is established, the Enterprise Architect and the Business Unit are able to more effectively act as a team, engaging areas of the business impacted by the project. The team acts with authority to commit resources and make and enforce decisions within their respective organizations. The State of Vermont Enterprise Architecture is governed by a welldefined set of roles, As with the architecture, communication must be well managed to ensure the effectiveness of the overall architecture. responsibilities, and The EA Governance process is used as the guide for the communication processes. plan. Governance is identified as an integral part of the overall strategy used to implement technology solutions within the state. EA Governance is closely aligned with Business Strategic Planning, IT Strategic Planning, IT deployment, Project Management and Risk Assessment. (3) The State of Vermont has identified these specific principles that govern the development of a communication plan between the Enterprise Architecture group and the Business. 1. Wide Participation – wide participation by stakeholders throughout the business unit ensures that the Enterprise Architecture will meet the optimal requirements of the line of business 2. Common Data Definitions and Vocabulary – Having a common taxonomy across the business with respect to the Enterprise Architecture will ease the ability to integrate new technologies into the business 3. Strategic Focus – EA Governance strives to fulfill the strategic requirements of individual agencies and the state as a whole. This is achieved through the identification of metrics that align the EA with the business strategy. 16 | P a g e VEAF Guidebook State of Vermont Commissioner Commissioner Dotted lines show communication lines between EA and Business Units Business Units (Agencies and Departments) Business Drivers, Business Objectives, Business Processes, Business Rules. SLA to Providers, Vermonters, business entities, functional and non-functional business requirements Business UAT Business Practices and Policies CIO CTO Enterprise Architects Lead Governance, Enterprise Principles, Monitoring, Education and Compliance E-PMO EA OFFICE Functions as a team: Comprised of CTO and Enterprise Architects Business Analysts Figure 4- EA and Business Communication Flow and Responsibilities CHAPTER 3 - ENTERPRISE ARCHITECTURE OFFICE AS A CENTER OF EXCELLENCE The Enterprise Architecture Office by reason of its commission from the State and the talent contained therein, is a Center of Excellence (CoE) for Technology for the State of Vermont. The Enterprise Architecture CoE is in place not only to help develop EA strategy, but to build awareness for, evangelize, and implement best practices for enterprise architecture. The AE CoE identifies gaps and training needs, offering a baseline for building governance and structure. This is critical for the maturity of the Enterprise Architecture as it expands with time. The objective of this EA CoE is to build a user community of EA subject matter experts (SMEs) and IT strategists that share enterprise architecture information and knowledge throughout State Agencies. The Enterprise Architecture Office’s mission is to support methodologies, standards, governance processes, manage a service registry, and document repository. The main goal of this core group is to establish best practices at design time that maximizes the reusability of applications and services. The CoE includes a vision statement, domain goals, best practices, technology trends, and technology standards. These documents expand and contract on an as needed basis with respect to the Business 17 | P a g e VEAF Guidebook State of Vermont Domain and it relation to the Enterprise Domains. In the example of Service Oriented Architecture (SOA) for the HBE, the CoE shows how the relations among the CTO and the EAs interact with the Business Domains, fostering clear lines of communication and activities. This model exemplifies an EA CoE for SOA. (Figure 54) Figure 5- EA Center of Excellence for SOA ARCHITECTURE GOVERNANCE PROCESSES The Architecture Governance processes are an integral part of the overall IT management processes. The Architecture Governance processes are an integral part of the overall IT management processes used to implement technology solutions within the State. Good Enterprise Architecture is required for successfully implementing, developing, and managing the State’s Enterprise Architecture. Governance is the rapt attention to the detail, principles, and standards of Enterprise Architecture. Governance guides the organization to a realization of its Goals and to ultimately success. Below are the primary processes necessary to govern the Enterprise Architecture Center of Excellence. Identification of Stakeholders across the organization In any architecture process, it is important to identify stakeholders at all parts of the organization in order to ensure that all applicable views and viewpoint are represented. This will provide a more holistic view of the architecture. 18 | P a g e VEAF Guidebook State of Vermont Manage Best Practices Best practices are discussed in depth in Chapter 7 of this document. As a center of excellence it is necessary for the Enterprise Architecture Office to maintain and update best practices on an ongoing basis. Architecture Documentation Process The goal of the Architecture Documentation Process is to produce the Architecture Blueprint. The Architecture Blueprint articulates the State’s architecture, showing classifications for products and compliances as emerging, current, twilight, and sunset. Products and compliances are also denoted as accepted or rejected during the creation and review of the Architecture Blueprint. This documentation process produces a wealth of information can be drawn to aid agencies in determining technology solutions. The Architecture Blueprint articulates the State’s architecture, showing classifications for products and compliances as emerging, current, twilight, and sunset. Architecture Review Process The review process allows the Enterprise Architecture Office to review, debate, discuss, and decide on the various additions and changes to the Architecture Blueprint. It is also the process that determines which variances will be accepted into the State’s technology portfolio. Architecture Communication Process The purpose of this process is to ensure that all users of the architecture understand the objectives of the architecture blueprint and its significance to the State of Vermont. All users must have access to the latest version of the architecture document in order to make educated decisions about future business and technology. This requires that a mechanism must exist to communicate to all users in order to ensure that their activities will be synchronized with the blueprint. The document must also be available to contractors and vendors who expect to do business with the state. In many instances they will be required to conform to the state’s architecture. Architecture Compliance Process The State of Vermont IT community has undertaken the development of Enterprise Architecture with the understanding that it is tactically sound approach to managing information technology from a statewide perspective. With general consensus achieved, it is assumed that compliance will be a voluntary process. Agencies will adhere to defined architectural strategies because it is an expedient, efficient and globally accepted. However, there will exist circumstances that will preclude the use of the documented standards. A formal compliance process exists to allow for the review and acceptance of variances from statewide architecture. Agencies will be allowed to submit deviations. These deviations should be presented with an appropriate business case stating the reasons for the variance. Business cases will be reviewed and approved variances will be documented. The approval process includes a variety of interests and community perspectives including business needs, IT strategies, budgetary views, and legislative activities. Agencies should either work toward making their initiatives compliant, or work towards refining standards. The architecture is not intended to restrict organizations, but rather to enhance coordination and integration, to simplify 19 | P a g e VEAF Guidebook State of Vermont implementation, to build a consistent infrastructure, and to promote interoperability providing for greater efficiencies. Architecture Sustainability Management Architecture sustainability management describes the The architecture is not intended process by which new business strategies and requirements to restrict organizations but are incorporated into the organization. Through this process rather to enhance coordination architecture is enhanced and updated, bringing in new and integration. technologies, solutions, and designs. These developments need to be incorporated into the enterprise architecture, and the architecture governance process needs to ensure that project innovations are appropriate and suitable for the enterprise architecture context. Sustainability management is not concerned specifically with the design and delivery of solutions in itself. At a minimum, sustainability reviews should occur every four to six months as a best practice. Architecture Change Management Process Change Management addresses the impacts of the processes, organizational structure, relationships and responsibilities associated with the creation of an enterprise-wide technology architecture. It does not address changes to the Architecture Blueprint itself. The Change Management Process defines how changes to the architecture are addressed and how the VEAF will be kept. The Change Management Process is defined and controlled by the Enterprise Architecture Office and may initiate change management actions. CHAPTER 4 - BUSINESS DRIVERS A key factor in developing an adaptive statewide Enterprise Architecture is the understanding of the enterprise business drivers of Vermont state government. The enterprise business drivers document the direction of the enterprise in order to help to ensure that the application of information technology supports the business of the State. A successful Adaptive Enterprise Architecture will include both business and technical architecture components. Both are equally important and define the roles and processes utilized to document the specific architecture. BACKGROUND To expedite the definition of the technical architecture, one of the initial tasks undertaken by the State in its effort to define Enterprise Architecture was to streamline the development of the enterprise business drivers that guide information technology projects. The State utilized existing business strategic plans and working groups with government leaders to document these business drivers. The initial set of business drivers were documented in 2002. In January of 2004, the Architecture Review Committee updated the business drivers, as well as the principles, best practices, and technology trends for the State. Follow-on efforts to the development of the technical architecture will likely include documentation of the business architecture including the roles, processes, and schedules that ensure the accuracy and vitality of the business perspective of the State. 20 | P a g e VEAF Guidebook State of Vermont ENTERPRISE BUSINESS DRIVERS The Enterprise Business Drivers describe the business strategies of Vermont state government, and documents the business direction of the enterprise. They help to ensure that the application of IT support the business of the State. The following list identifies a sample of enterprise business drivers as developed and documented by the state. Enterprise business drivers document the business direction of the enterprise 1. The State of Vermont will make information easily accessible and readily available as needed and wherever needed, for both the citizens of Vermont and the employees. Citizens currently expect to get direct access to government services. In particular, the high availability of information is becoming more and more necessary. 2. The State will deliver services in a fiscally accountable fashion. Vermont is a balanced budget government with a constitutional limit on the collecting of taxes and the spending of taxes collected. 3. Citizens of Vermont are becoming increasingly aware of new service delivery models. As citizens demand for “faster, better, cheaper” service increases, it will be necessary for the State to provide those services in innovative ways to produce maximum benefit. 4. In order to provide expanded services, the State of Vermont must collect increasing amounts of personal information. As a result, it will be necessary for the State to put in place a means to respect and protect the privacy of its citizens. 5. All state agencies must cooperate and collaborate in delivering their services. The citizens of Vermont have increased expectations as to the sharing and availability of their personal data. In other words, once it is given to an agency, they expect all agencies to have ready access to it this providing them faster and better services. 6. The State will develop processes that allow its services to be delivered as closely as possible to the citizen. Wide varieties of services are available and must be delivered to the citizens in a manner that doesn’t impose inconvenience nor require the citizen’s presence at the central seat of the government. 7. The State must continually provide high quality services quicker. As business models for service delivery continue to mature through all categories of industry and government, the levels of citizen expectations continue to rise. 8. As government services become increasingly available, it will be necessary for the state to communicate and market those services throughout the entire state, so that all citizens receive the benefits to which they are entitled. 9. As Vermont government moves from older process models to 21st century process models, information technology will be a critical success factor in the creation, maintenance and delivery of services to all citizens. 10. The current business model under which Vermont State Government functions was adopted in the mid-1970’s. Reorganization of this model to better arrange and provide services is highly probable under future administrations. This newer model is speculated to coordinate business 21 | P a g e VEAF Guidebook State of Vermont units through similar “Pillars of Government”, such as Benefits Based, Justice & Public Safety, Education, Regulatory & Administration, and Transportation & Engineering. 11. Homeland Security efforts require the State of Vermont to take a proactive approach in protecting Vermont’s citizens and securing the State's IT assets and data. This will ensure Vermont Government will continue after a natural or man-made disaster. CHAPTER 5 - TECHNOLOGY TRENDS Technology trends within the industry may have a significant impact on business, architecture, and the deployment of information technology within state government. Identifying and tracking the progress of these trends coupled with an awareness of their impact will allow IT decision makers to develop more informed, effective decisions. Some key questions that should be asked include the following: Technology trends can have a significant impact on the business and architecture requirements of state government. What trends and events will drive new business investment in IT? What technology advances or changes will impact IT deployment decision? How can the State exploit IT while facing a complex and volatile environment? The technology trends identified apply to the enterprise view of architecture. Each individual domain should have technology trends identified that are specific to that domain. These trends should be continually assessed for potential impacts to both the business and architecture. ENTERPRISE INFORMATION TECHNOLOGY TRENDS The following is a list that groups together a sample of trends coupled with potential decisions that could potentially mitigate the impact of these trends. 1. Government will still experience a shortfall in obtaining highly skilled, motivated staff due to budget constraints and out-sourcing options. Successful agencies will focus in retaining, training, retooling, and uplifting existing staff. Government will establish an increased emphasis on human capital management (HCM). Leading-edge jurisdictions will replace initial recruitment, retention, and training efforts with a holistic approach to human capital management, ultimately affecting sourcing and recruitment strategies. 22 | P a g e VEAF Guidebook State of Vermont 2. The increasing failure of traditional software development methods and financial and resource constraints combined with “time-to-market flexibility”, is producing fundamentally new techniques for the execution of IT projects. Buy vs. Build o Turnkey or tailored commercial off-the-shelf (COTS) solutions are increasing. Component-based Development o Planned Reuse & COTS subcomponents o Emphasis on consolidation and uniformity for common business practices o Rather than customize applications, governments will focus greater attention on standardizing traditional government business processes. o Object-Oriented Methods and Technologies 3. Enterprises are using new technologies to reduce administration costs and establish a unified system management approach for corporate computing. Return to Centrally Administered Computing Network and System Management Tools Server-centric Business Operations Enterprise desire to reassert centralized control of IT Mainframe mindset exploiting latest client/server technology 4. Unified management and governed evolution of the Enterprise Architecture will become a dominant best practice even where asset ownership is federated. Federated architectures will focus on supporting common business infrastructure initiatives across semi-autonomous business units. The state must leverage buying power. Collaboration between business units is imperative. 5. Tension between citizens’ security and right to privacy will become increasingly significant. Securing IT assets and developing a comprehensive security and privacy architecture are required by 80%+ of public sector CIOs. Privacy/security mandates will require CIOs to re-evaluate existing practices in light of the physical and digital security requirements for federal, state, local, and international government interfaces. 6. Evolution from Vendor Contracting to Vendor Partnerships will evolve. Those vendors who develop true partnerships with the public sector during a down economy will emerge as the winners. Savvy vendors will sacrifice short-term profits for long-term, enterprise contractual agreements. Vendors will gain ground by bundling product offerings. 23 | P a g e VEAF Guidebook State of Vermont 7. E-Government Slows E-government” will be refocused on e-employees, where more immediate returns can be realized. The “re-facing” of e-government will allow time for establishing the foundation. The “e” in e-government will be downsized, as reflected in the downsizing of government budgets. Minimal expansion of e-government services will occur Focus will be on rationalizing and improving existing transactions (and their ease of use) across each jurisdiction. Data sharing, ERP investments, and consolidation rationalization will provide a foundation for reinvigorating e-government service offerings. 8. A service-oriented architecture is emerging due to the enablement of web-services and increased accessibility and usage of all access channels. 9. The portal will be a cost of doing business, with frameworks broaching G2E, G2B, G2G, and G2C requirements and providing content, process automation, integration, development, knowledge, and collaboration management capabilities. Portal frameworks will provide comprehensive facilities for interfaces (personalization, visualization, navigation) and application delivery (e.g., Web services location, development, integration). CHAPTER 6 - PRINCIPLES The Enterprise Architecture Principles are general rules and guidelines, intended to be enduring and seldom amended. Principles inform and support the way in which an organization sets about fulfilling its mission. Principles are the general rules which hold true across the architecture. Likewise, Domain Principles are the underlying general rules that hold true across a specific domain Principles define the spirit of the architecture by capturing the thinking behind it. Domain Principles form the core values of architectural decision making for an organization. These principles are derived from The Open Group Architecture Framework (TOGAF) principle catalog as well as the Oracle Enterprise Architecture Framework (OEAF). In their turn, principles may be just one element in a structured set of ideas that collectively define and guide the organization, from values through to actions and results. Every Enterprise Architecture Principle follows a template based on TOGAF. This ensures a high degree of quality and adaptation regardless of Agency business domain. Enterprise Architecture principles have been identified along with the motivation and implication for each. These statements provide rationale for adhering to the principles, serve as a starting point for difficult evaluations and decisions, and guide the design and selection of technology components. 24 | P a g e VEAF Guidebook State of Vermont The format of a principle should follow the example below. Name <Name of Principle> Reference <Unique identifier for the principle> Statement The Statement should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar from one organization to the next. It is vital that the principles statement be unambiguous. Rationale The Rationale should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of information and technology principles to the principles governing business operations. Also describe the relationship to other principles, and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision. Implications The Implications should highlight the requirements, both for the business and IT, for carrying out the principle – in terms of resources, costs, and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to: “How does this affect me?” It is important not to oversimplify, trivialize, or judge the merit of the impact. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analyzed. Principles have been grouped into related categories. These principles apply across the enterprise. As domains are developed, references to these overarching principles should be made where appropriate and conflicts with these principles should be addressed. Currently the Enterprise Architecture Group manages 85 named principles listed below. (Details provided in XLS Workbook EAGOV-009 EA Principles) Design for Reusability (Common Use Applications) Focus on User Needs Implement Security Compliance (Security & Regulatory Compliance) Service Oriented Architecture Aligned and Comprehensive Enhance Decisionsupport Accountability and Transparency Information Asset Management Compliance to Enterprise Architecture Master Data Management (Authoritative Information Sources) Effectiveness Just Enough, Just in Time Comply with EA Service Abstraction Service Autonomy Service Description Service Discoverability Service Harvesting Standard Data Exchange Formats Service Loose Coupling Utilize Advanced Data Analytics Service policy enforcement Service re-use Service monitoring Control Technical Diversity Open Process Cost Optimization Simplicity and Consistency Done is Better than Perfect Strategic Focus Value & Risk Classification Wide Participation Data Security Common Data Definition & Vocabulary Data Stewardship Standard Service Contract Information Accessibility Access via Services Maximize Benefit to Enterprise Optimize for Sustainability Optimize Process and Increase Accountability Primacy of Principles Compliance with Laws and Regulations Data Quality Measurement for Quality Metadata Driven Service security "Automate SOA governance processes" Avoid Point-to-Point Integrations 25 | P a g e VEAF Guidebook Business-level Services Concurrent Service Versions Conform to organization's governance Event Processing Graceful Service Migration "Identified governance stakeholders" State of Vermont Opaque Service Implementation Adhere to Open Standards Platform Independence Availability "Provider & consumer contracts" Ensure Architectural Quality Attributes (Performance & Scalability) Service Contract Service metadata SOA governance must promote the alignment of business and IT Location Transparency SOA Reference Architecture is required Logical Data Representation "Tailor SOA governance processes" Normalized Data Formats Technical Orchestration Management Automation Virtualization & Cloud Computing Configuration over Customization Interoperability Security as a Service SSO and Identity Federation across Domains Secure Web Services Secure Management of Security Information Active Threat Detection & Analysis Secure, Complete Audit Trail Data Security System Availability Defense in Depth Least Privilege GUIDING PRINCIPLES OF AN AGENCY Guiding Principles govern the business, agency and the entire organization. EA Guiding Principles govern the implementation of how business principles are mapped and aligned with the CIO, CTO and other business managers. Using HBE as an example, EA Guiding Principles identify how a principle is mapped to 2013 Technology Goals, the Governor’s Vision, and long term Department of Information and Innovation (DII) Strategic Principles for 2013-2018. For instance, Cost Optimization is a Business Principle from the Business Domain. It is defined as the government and its agencies shall provide applicants with the lowest total cost for services rendered by improving efficiencies and streamlining core operational processes. Yet, when mapped to the core EA Principles for 2013 Technology goals Cost Optimization allows for the modernization and effective sustainable technology to support the business. The Business Domain Principle Map in relation to Technology Strategic Principles for 2013-2018 follows the pattern in Figure 65. Figure 6- Business Domain Principle Map 26 | P a g e VEAF Guidebook State of Vermont Likewise the Technology Domain Principle Map shows technology specific principles as related to the 2013-2018 strategy. Figure 6 Figure 7- Technology Domain Principle Map CHAPTER 7 - ENTERPRISE BEST PRACTICES Best Practices identify industry processes related to the implementation of the architecture that will assist in the maintenance and expansion of an adaptive statewide technical architecture. They apply to the enterprise-wide concept of architecture. Each domain should identify and document best practices relevant to that specific domain. ENTERPRISE ARCHITECTURE MUST BE AN IN-SOURCED EFFORT Architecture should be a core function of IT within the State as it comprises principles based on the business needs of the enterprise and should guide the deployment of IT resources within the enterprise. The State must protect the Architecture from undue influence by external partners. It may accept external assistance, but ultimately architecture decisions should be led by the Architecture Office. Even when outsourcing operations, the architectural direction must be set internally. Enterprise Architecture governance will require significant commitment of resources. IT RESOURCES MUST BE FOCUSED ON THE AGENCY’S MISSION When resources are focused, it maximizes their value. New IT skills are often expensive to obtain and difficult to acquire, because of this IT must be responsive to changing technologies and core business processes. These must be a process to insure alignment between IT and business goals. Non-core areas are candidates for outsourcing and decisions on specialization in cross functional systems must have collaboration between agencies. THE STATE WILL USE A STANDARD SET OF PROVEN TECHNOLOGIES IT efforts need to focus on the business enterprise, improving interoperability and eliminating technology silos. The goal of this is to ensure a stable long term technology and application environment. 27 | P a g e VEAF Guidebook State of Vermont In order to facilitate long term stability, IT must ensure compliance via a rigorous selection criteria and utilize a standards process during procurement. This will limit choices via the architecture blueprint by taking into consideration an enterprise-wide view when selecting technologies. By considering the impacts to the enterprise to individual operations, and avoiding the undue proliferation of technologies, IT will be able to ensure long term stability against short term efficiency. TECHNOLOGY SELECTION WILL CONSIDER THE ABILITY TO SUPPORT SYSTEMS By building in systems management into technology evaluation, IT will be able to help reduce the risk to the business presented by new applications and technologies. By selecting supportable technologies IT can better protect existing technology investments and ensure the effective deployment of technology resources. Considering systems management my limit the choice of IT solutions, and will require a champion in senior management, as it will involve investment in systems management processes and technologies. In return, this investment will increase system consistency, share ability and accessibility, providing effective IT solutions that achieve desired public policy outcomes. GOVERNANCE OF ENTERPRISE ARCHITECTURE WILL BE CENTRALIZED The Enterprise Architecture Office will support common business infrastructure initiatives across business units. This will require clear lines of communication with EAs and the business as the public sector experiences above-average difficulty with EA governance. Governance will play a huge role as e-government programs grow due to citizen demand. THE STATE WILL BALANCE THE NEEDS OF PRIVACY AND ACCESSIBLY Security implementations have bypassed the assessment of privacy policies, which must serve as their foundation. Tensions between citizen’s security and right to privacy will become increasingly important. Privacy and security mandates will require CIO’s to regularly re-evaluate existing practices in light of digital and physical security requirements. It will be necessary to enhance and in some cases re-write applications to ensure security of personal information and the state’s assets. CHAPTER 8 - BUSINESS UNIT CONSIDERATIONS AND THE IMPORTANCE OF NONFUNCTIONAL REQUIREMENTS Systems and technology vary widely throughout the Agencies and Divisions within the State of Vermont. SOA (Service Oriented Architecture) is an architecture style for creating business solutions while fostering business agility. The goal is to continuously improve business results, enable flexibility and cost-effectiveness with existing business practices. There are general principles which govern SOA. They are listed here as a guideline for business leaders. These principles are used during the RFP process, but should be followed throughout the entire Enterprise Architecture project. 1. Well defined Service Contract 2. Define Services with Appropriate Granularity. These items will appear in a Non-Functional Requirements Catalog during the RFP process. The Enterprise Architecture Program hosts all current NFRs used for the Enterprise. 28 | P a g e VEAF Guidebook State of Vermont 3. Service Statelessness should be a goal. 4. Services have appropriate Security and Enforcement Standards 5. Adoption of SOA Vocabulary – will facilitate communication between the Architecture Office and the Business Unit. THE NON-FUNCTIONAL REQUIREMENTS DOCUMENT Functionality is important, of course. But if you don't consider non-functional requirements, then the solution could very well be practically useless. Non-functional requirements are those that don't necessarily address "I want my system to do this," but instead address "How do I make this system work in the real world". NFRs generally follow the ISO/IEC 9126 definitions for software quality. They are specific or implied properties. An NFR should outline with some detail the suitability of the service being requested by the business and how the enterprise attains that goal. Issues related to reliability, usability, efficiency, maintainability, and portability. The NFR is a way to show how the architecture, practically and realistically, addresses the services performed by the business through the Enterprise. OPERATIONAL CONSIDERATIONS2 It is critical to Define Metrics (including Key Business Performance Indicators) at the commencement of mapping any business process to the Enterprise Architecture. Metrics are essential for the continuous communication and justification of SOA engagement. What starts with a baseline measurement (which might be put in a business case), will be measured at appropriate intervals and reported. Here a few metrics are suggested. Most, if not all, of these are outlined in the NFR Document during the RFP Process. As a best-practice, it is wise to continually refer to these metrics during the development, implementation and deployment of each service. Application Usage: What is the actual usage of an application, before and after implementation of SOA on the business. SOA can lead to a service which can be used by many more consumers than in the current state. This change can be measured if there is a baseline. Cost Reduction: Define various cost factors; e.g., maintenance, license, energy, etc. The ratio between relevant cost factors also need to be taken in to consideration; e.g., the ratio in IT budget between the projects supporting business growth initiatives and the projects for (legacy) maintenance. Functional Re-use: Define and measure functional re-use before and after the evolution of service-enabling business functionality. The metrics need to be measured and reported across business silos. Quality of Service: Quality of Service (e.g., service up/downtime, message throughput) is part of Service-Level Agreement (SLA) monitoring and should include appropriate performance-related key performance indicators 2 http://www.opengroup.org/soa/source-book/l2soa/best-practices.htm 29 | P a g e VEAF Guidebook State of Vermont Revenue-generated: Creation of services can lead to additional revenue by exposing internal processes/functionality externally. Time-to-Market: Using SOA to enable re-usable and standardized services to access legacy systems should reduce time-to-market of certain functionality. Security Key Performance Indicators (data protection-related KPIs): Especially concerning the key SOA principle: “Ensure services have appropriate security enforcement standards”, this metric helps to monitor frequency and severity of security incidents after modernization. BUSINESS PROBLEM AS ARTICULATED BY THE BUSINESS LEAD In 2009, Gartner, Inc., identified “Not Engaging the Business People” as one of the top ten Enterprise Architecture pitfalls. “When IT and business goals are not aligned, resultant problems include nontechnical people trying to make technical decisions while enterprise architects become too reactionary and tactical in response to projects. To overcome this, Gartner recommends that enterprise architects get involved in the development of the business context and engage jointly with other employees in the business architecture.”3 Successful Enterprise Architecture is linked to the business requirements. The Business Lead is the best person to help articulate the problem EA is helping to resolve. She/he understands the environment, the business goals and objectives, human capital, roles and responsibilities. The Enterprise Architect (EA) can assist the Business lead in creating a business scenario that captures the problem in a concise informative way. Thus, the scenario creates the primary roadmap for the project. The Open Group suggests the following process for creating a Business Scenario divided among three phases. Identifying the problem, identify the technical environment used by the business, document business objectives, list business actors, list of enterprise actors, and documenting roles per actor.4 Error! Reference source not found. shows the gathering, analysis and review phases for developing business scenarios. 3 4 http://www.gartner.com/newsroom/id/1159617 http://www.opengroup.org/public/arch/p4/bus_scen/bus_scen.htm 30 | P a g e VEAF Guidebook State of Vermont CHAPTER 9 - ADAPTING THE ARCHITECTURE DEVELOPMENT METHOD (ADM) FOR BUSINESS UNITS WITHIN THE STATE OF VERMONT This Part of the VEAF Guidebook offers some instructional guidelines and principles to be used when working with Agencies and Departments within the State of Vermont. These Agencies and Departments are called Business Units (BU). ADM is a method used within the TOGAF Framework for Enterprise Architecture. ADM is iterative (a specific BU), over the whole process (Statewide), between phases (e.g., deployments, upgrades and migrations), and within phases such as applying a specific phase to flesh out a BU problem. ADM phases are flexible enough to allow an Agency or a Department within the State of Vermont to offer insight as to how the BU applies its current architecture in relation to its business models. Some or all of these phases might apply. For the purposes of this Guidebook, the State of Vermont EA Office recognizes Phase A-F as BU Architecture Assessments. A complete list of all TOGAF ADM Phases and Sub-Phases are located on the Open Group Web Site.5 During the process the Business Unit learns the breadth of coverage offered by the enterprise architecture and how it functions as a service back to the business. Details concerning the BU’s goals are defined, architectural assets are leveraged, practices and principles are honed for clarity; information and knowledge are shared and exchanged between the EA Office and the BU. ADM is always collaborative; it is NOT a top down. Using inductive reasoning, the EA and BU move from specific observations about their respective technologies to a broader general understanding of how Enterprise Architecture solves not only specific business problems but fosters the achievement of the statewide goals and principles.6 Care should be taken by the EA Office as to not insist on too much technical detail upfront as the business unit might not have full knowledge of all assets or procedures. ADM Phases can be applied in different business units, they are not hard-and-fast rules to be applied but used as a guideline. The following illustration shows the different phases of ADM and how they interact with the Requirements for the BU. (Figure 8) 5 6 http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap03.html http://www.socialresearchmethods.net/kb/dedind.php 31 | P a g e VEAF Guidebook State of Vermont Figure 8 Phases for Vermont Architecture Development Process Based on ADM from Open Group PRELIMINARY FRAMEWORK7 AND PRINCIPLES As the Preliminary Phase of the architecture process for the Business Unit, the principles managed by the EA Office will inform the constraints on any architecture work. The goal of this phase is to define the scope and assumptions of the BU in relation to the EA. The framework phase can be adapted from a previous successful pilot project. This phase answers the question posed by the business, “why do we need to do this, since my entire technology processes work fine?” and “We have a staff that handles our technology services, so what are you offering?” and finally, “how we do architecture?” Care should be used to avoid overwhelming the business with technical jargon, and “lessons learned” from previous enterprise architecture project. Adapt and formulate a common vocabulary during this phase so time is not wasted on education concerning the framework. The Business knows their processes and functions; the EA Office functions as a service to the business as a customer. EA gathers the following information from the business as a guideline. A few observations on Customer Experience will help during all conversations, meetings and formal presentations to the Business. Dissatisfaction with how technology impacts and disrupts the comfort level of employees using antiquated systems and processes must be considered. The EA Office engages Business Units by employing coaching, mentoring and above all empathy for how the Business sees them in relation to changing technology 7 http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap04.html 32 | P a g e VEAF Guidebook State of Vermont The EA Office is interested in how the BU “does” its own Architecture. Attention to some detail at the BU level is important. An EA Architect will gather the following technical information: Applications Middleware Code Requirements: Java, VB, etc. Data: Business Object, MDM, Data Connectivity (ODBC, etc.), SQL, Oracle, DB2, SQL Server, ECM (Electronic Content Management), Reporting tools SOA IDM Architecture Integration: How do BU Components fit into the EA Framework? Do BU components fit in to maturity and compliance models consistent with EA Office? SUSTAINABILITY MANAGEMENT MODEL A large number of factors affect project sustainability. These factors include some of the following: Project Design and Implementation Demonstrable Effectiveness Financial Resources PROJECT DESIGN AND IMPLEMENTATION The Architecture Vision document is a great tool to put forward, in an informal way, the business case for an enterprise architecture project. It informs the business as to the key benefits of the proposal to decision-makers. The AV document articulates the business goals and how they are mapped to key enterprise architecture principles. The AV document includes a high-level description of the baseline and target architectures as envisioned by the business. This phase of the sustainability plan is essentially the “elevator-pitch” for the project. DEMONSTRABLE EFFECTIVENESS The Architecture project must be able to document its success. The ADM from TOGAF is particularly helpful in showing, advertising and measuring the effectiveness of a program. Once an architecture project has been defined, the lead stakeholders should develop an Implementation Governance Model uniquely adapted for the project. The governance model will guide the project toward a demonstrable, measurable and sustainable architecture that can easily be communicated to the organization. A key aspect of Phase G, Implementation and Governance, is ensuring compliance with governing strategies, project scope, budget constraints and vision. The EA and business leads may offer these types of artifacts as a method to demonstrate the effective sustainability of the architecture project: Recommendations for Service Requirements and enhancements Performance Metrics Service Level Agreements (SLAs) Updated Architecture Vision 33 | P a g e VEAF Guidebook State of Vermont Review of budget requirements Repository (SOA, BPM, Business Services) inventories and reviews for re-use Implementation Governance Models Contract reviews FINANCIAL RESOURCES The sustainability of a project is enhanced and increased when project have multiple sources of funding. Cost containment practices such as distributing labor costs across multiple Agencies, out-sourcing labor intensive activities, and use of shared technology services will also add to sustainability. Once the funding is sourced, an Enterprise Architecture Assessment (EAA) can be utilized to help establish cost modeling for the project. (See Appendix XXXX for EAA) The EAA creates a gap analysis for existing and target architecture needs. This analysis will provide the business with costs models for software, hardware, services, licensing, storage, cloud services for the foreseeable future. The EAA identifies the funding sources, Enterprise Architecture Principles in use, costs for oversight, and cost projects for five years. The Figures below X show some of the information gathered for the EAA. BUSINESS EARNED VALUE TECHNIQUE Earned value (EV) is a Project Management Institute definition. As such, it is a technique to measure performance of a project as it moves from project initiation to project closure. It also provides a means to forecast future performance based on past performance. EV is a process based on a structured approach to planning, cost collection and performance measurement. EV provides objective measurement of a project status, basis for estimating final costs, predictions as to when the project will be completed and a means of managing change. Enterprise architecture methods strongly suggest that the EV be managed by the project manager within the scope of the architecture project. MS-Project 2010 support EV calculations and models. 34 | P a g e VEAF Guidebook State of Vermont COMPONENTS A component is defined as “an enterprise applications and infrastructure turned into specific, reliable and modular services"8 The identification of components helps the business understand IT architecture standardizations for their operational models. A business says, I need a payment system, or a rebate system. They don’t say I need that software or this software. Which is what a vendor would tell the business. VEAF Architecture is composed of thirteen identified architecture components, each with their own governing theme. These components are listed below. EA Component Identity Management Consent Management Portal Enterprise Information Exchange Master Data Management Rules Engine Eligibility Automation Foundation Major Theme Ensure individuals are identified across the range of roles that they play and human services programs that they interact with, and have access only to information and functionality for which they are authorized Ensure that appropriate information is shared with only individuals that are authorized and have a need for access by providing explicit authorizations. Provide a consistent user interface and access to information and functionality Also referred to as a gateway, or service bus, which provides a standards based mechanism for integrating with and sharing information among the full range of human services and administrative applications Includes Master Person Index, and Master Provider Index to ensure a common view and single version of the “truth” across Vermont’s HHS programs Define and manage the business rules that will drive eligibility assessments across human services programs Provide HSE Platform shared functionality for eligibility screening, application and determinations services for Vermont HHS programs Content Management Allow management of and access to a wide range of information and media Analytics and Business Intelligence Tools and Repositories Create reports and dashboards to shed light on and manage current operations, and to develop analytical and predictive analyses for future planning and policy development 8 Peter Weill and Jeanne W. Ross, IT Governance. (Boston: Harvard Business Review Press, 2004) 34. 35 | P a g e VEAF Guidebook State of Vermont EA Component Major Theme Collaboration Capabilities These capabilities are part of the UCM component. These capabilities include: Service Coordination (Secure Messaging and Shared Case Notes), Client and Provider Look-Up and Query, Referral Management (Create Referral and Manage Referral), and Alerts and Notifications Service-Oriented Architecture (SOA) Universal Customer Management (UCM) Enterprise Content Management (ECM) and Customer Communication Management Architected services that are composed of discrete software agents that are loosely coupled to other enterprise components. These services are re-usable for the construction of additional applications. Ensure individual (member) data is managed holistically. This is generally serviced by CRM applications that touch multiple areas of a customer (member) activity. Services to be used include CRM 2.0 capabilities thus offering bidirectional communications and exchanges. This is backbone of any Care management system. Allow for the management of structured and un-structured data across the enterprise. The customer communication management part refers to notifications constructed by the business to formally communicate with members by way of the enterprise. BU ARCHITECTURE ASSESSMENTS (ADM PHASES A THROUGH E) Gathering information on a BU’s architecture is needed in order for a clear baseline for growth, migration, deployments, change management and governance. The BU and EA Architect can used the specific phase definitions listed in this document to pick and choose which data are necessary for moving forward. Together, the BU and the EA Architect perform the following: BU identifies baseline Architecture BU identifies technology leads, analysts, programmers, vendors or other resources associated with BU Architecture EA Architect formulates base architecture BU MIGRATION PLANNING INTO THE EA The Migration Planning phase is critical. It is not optional. This phase moves the business goals into a target architectural system that explains back to the business how the targeted architecture is tailored specifically for the business goals. 36 | P a g e VEAF Guidebook State of Vermont By the start of this phase the BU and EA have clearly and concisely identified the areas of compatibility, gaps in architecture that need to be closed, and possible decommissioning of the business’ existing technology. At this phase meeting minutes and/or notes generated during the Architecture Assessments phases should be reviewed, updated, and entered into the Architecture Repository. The work package, actors needed for deployments are identified during this phase. The following outlines some of the activities during this phase. Confirm Management Framework Interactions for the Implementation and Migration Plan For each work package in the plan, assign a business value Estimates for Resource Requirements: Project Timings, Availability and Delivery methods Prioritize Migration work packages based on Cost / Benefit and Risk Validation. Write EA Roadmap for Migration Plan Business and EA Architect Generate Collaborative Implementation Migration Plan for Deployment Complete the ADM and Document Lessons Learned BU / EA GOVERNANCE AND PRINCIPLES The practice of Governance with principles adds value to the business. As with all activities of the EA Office, the focus on Governance and Principles within the Architecture framework is paramount. The following Business specific principles show how goals are achieved. As an example, if a principle of the AHS business is “Cost Optimization”, a rationale and its implications within technology must be identified up front in order for the Governance of the EA to be effective. Cost Optimization is a State directive, and as such, the Business needs to attenuate costs without impacting services to the citizens of Vermont. The Business identifies areas where EA can introduce optimization and effectiveness with respect to the Business’ technology. EA thus assists the Business in achieving their goals. Governance is applied during all phases. However, during this phase, the BU and EA pause to assess and monitor necessary resources, compliance checks on the target architecture against the existing EA, setup post deployment review process and set specific deadlines. Current EA Principles are found in Part 1 of the Guidelines. BU / EA CHANGE MANAGEMENT COMMUNICATION METHODS9 The rate of customization and change needs to be constantly measured against the Enterprise Architecture. Streamlining and avoiding administrative complexity in the CM method allows for rapid, process driven methods for change within the architecture. CM Criteria Evaluation 9 http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap14.html 37 | P a g e VEAF Guidebook State of Vermont Is the change request against a wide-range of applications, devices, components, data objects? Does the change affect the usability of the enterprise? Does the change affect other Bus? Are there operational modifications to be considered? Considerations might include but not limited to: new monitors, additional 2-tier backups for production, educational materials required from the business for users Are the CM Actors identified and their roles clearly identified? The Change Management process governs modifications to an established technical infrastructure and associated information systems. Modifications to the Enterprise Architecture are made in a controlled way and managed using a standardized change control procedure as outlined Change Control Process document.10 A change control method ensures efficient and prompt handling of changes - from inception to implementation and allows the Enterprise Architecture group to consider the benefits and risks associated with a proposed change ( Figure 9). This policy is intended to provide best practice and procedural guidelines that should be used when making changes to EA Infrastructure. The EA change control process should satisfy the following requirements: 10 \\inside.vermont.gov@SSL\DavWWWRoot\sov\cto\info\Documents\Change Control\Draft EA Change Control Process.docx 38 | P a g e VEAF Guidebook State of Vermont Change Management for Business Unit: Business Unit Identified Change with COST Approval Business Units Phase UAT Change testing on Staging Platform ONLY Review: Approve move on to Impact Vendor Vendor Identifies Costs and Resources Enterprise Architecture Office Change Control Board (midmanagement level) Business Unit Identifies Change Release to Production Cost Identified and Approval Granted to move forward. Multiple Reviews and Impact Studies Change Development prepared, iterations outlined. Vendor / Enterprise Office Study Impact Study Modifications requests against Existing Architecture Update Change in the Architecture Iterations Repository. Catalog Operational Changes. Technology Review Based on UAT results: GO no GO Decisions made. Showstoppers identified, modifications for future iterations identified, release notes and modifications to documents finalized. Change Advisory Board (Director Level) Artifacts for Architecture Repository RISK Assessment then move forward to PMO PMO Prioritizes and Schedules Figure 9 Change Control Method for Vermont EA and BU Defines the roles, processes, and procedures to be used to manage submission, recording, analysis and approval of changes. Provides a mechanism for requesting a change. Provides detailed information concerning the changes. Provides a formal review and approval process for changes. Provides notification to groups potentially affected by the change where appropriate. Provides a historical record of all requested changes for review and audit purposes. Establishes and defines one or more suitable maintenance windows during which planned outages can be expected for major, non-routine EA infrastructure changes. Since Agencies and Departments within the State of Vermont use various vendors for development, testing and management of production systems; attention to vendor CM methods need to be outline as part of the Architecture Model. In the example below, AHS business and EA Office interact with the vendor’s CM. Architects are encouraged to seek out and understand the CM methods for the vendor whenever possible. Figure 9 illustrates the CM process for a BU that has achieved cost approval. Note: the swim 39 | P a g e VEAF Guidebook State of Vermont line for EA Office in Figure 9 shows how EA Architects straddle the CCB, Vendor and EA Office during the CM process. EA and BU catalog current change management methods employed by the agency or department EA looks carefully for opportunities for flexibility within the BU’s methods that will allow the BU to rapidly evolve within the EA Change Management BU Drivers: Note EA’s apply Governance and Principles for CM here. Here are some considerations. 1. Does BU have current technology reports? 2. Does BU manage existing technology? If so, report carefully on what is in place. 3. What methods will be employed to decommission existing technology within the BU? 4. What are the business-as-usual development needs? Who, What, How and When? CHAPTER 10 - BU REQUIREMENTS MANAGEMENT AND THE REQUIREMENTS REPOSITORY.11 All phases of ADM lead to the Requirements Management Phase. As indicated by the "Requirements Management" circle at the center of the ADM graphic, the ADM is continuously driven by the requirements management process. (Figure 8 9) It is important to note that the Requirements Management circle denotes not a static set of requirements, but a dynamic process whereby requirements for enterprise architecture and subsequent changes to those requirements are identified, stored, and fed into and out of the relevant ADM phases, and also between cycles of the ADM. The ability to deal with changes in requirements is crucial. “Architecture is an activity that by its very nature deals with uncertainty and change - the "grey area" between what stakeholders aspires to and what can be specified and engineered as a solution.”12 Architecture requirements are subject to changes in practice. Moreover, architecture often deals with drivers and constraints, many of which by their very nature are beyond the control of the enterprise (disasters, changing market conditions, new legislation, etc.), and which can produce changes in requirements in an unforeseen manner. 11 Note: A Requirements Repository is currently under construction on the State of Vermont SharePoint Site. It will be managed by the EA Office. 12 http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap17.html 40 | P a g e VEAF Guidebook State of Vermont The Requirements Repository is used to record and manage all information relevant to the BU requirements for the EA. These data are derived from the BU Drivers and the enterprise components used to implement the requirement. Requirements are constantly checked against the Solutions Repository for compatibility.13 Figure 10 Architecture Repository 13 http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap41.html 41 | P a g e VEAF Guidebook State of Vermont SPECIAL NOTE ON THE ORACLE SOA REPOSITORY.14 The Oracle SOA Repository is a critical building block in the Enterprise Architecture managed by the State of Vermont. For our purposes this Repository and its supporting documents will be considered a mandatory subset in the Solutions Repository. The Oracle Enterprise Repository provides the features Visibility into all SOA assets and their relationships Automatically collects and populates the Oracle Enterprise Repository and Registry with existing services and other assets through introspection and synchronization with developer tools Provides a flexible and extensible model for categorizing SOA assets. Provides visibility of assets that currently exist, are planned, or are in development to reduce duplication of effort Automatically discovers, maps, and manages new dependencies to support impact analysis End-to-end governance throughout the lifecycle Automates the depicted governance processes Communicates architectural standards and tracks architectural compliance Harvest the operational metrics from Oracle Enterprise Manager (OEM). Analytics i. Tracks and reports on reuse throughout the entire service lifecycle, including development reuse, runtime service reuse statistics and data on consumption and compliance through scorecards ii. Collects and communicates vital information on service performance, quality, and compliance with corporate standards iii. Supports critical decisions with feedback on SOA compliance, performance, and ROI Activities of Requirements Management: 1. BU Business Drivers. EA Office manages Business Drivers for the Enterprise Architecture. See VEAF Manual Part 1 for information on those drivers. Each BU might have their own drivers that might meet the same operational principles used by the EA Office. For instance, an Agency or Department might be driven by a need for a more simplified organization due to budgetary considerations. The EA Architect is positioned to help assess the alignment of Business Drivers. 14 http://www.oracle.com/us/technologies/soa/enterprise-repository-ds-1953749.pdf 42 | P a g e VEAF Guidebook State of Vermont 2. BU Business Analyst Inputs a. BA Communication Plan with EA Office (see CAP in Part 1) b. Organizational Process Assets, Organizational Process Assets are “any or all process related assets, from any or all of the organizations involved in the project that can be used to influence the project’s success.” Examples include: plans, procedures, lessons learned, historical information, schedules, risk data and earned value data. Organizational Process Assets fall into two broad categories, Processes and Procedures and the Corporate Knowledge Base. The key concept is that these are assets a project manager may use for the benefit of the project. 15 c. Requirements Compatibility, do they support the resolution of the business problem and are compatible with the Solutions offered by the EA Office? d. Requirements Plan (rules and policies) e. Requirements Structures f. Scope and Goals g. Stakeholder list and Responsibilities 3. BU Business Outputs a. Application within EA per TOGAF 9 b. Future initiatives: Do they fall in line with the strategic IT Initiatives as outlined by CIO and CTO? BU ARCHITECTURE MODEL CONCLUSION The State of Vermont Enterprise Program (VEAF) uses ADM for Architecture Development across business units. It will guide the BU and EA on the design for a target Architecture acceptable by the BU. There are a few reasons ADM might need to be tailored to specific BU circumstances. ADM is flexible enough to handle this through phase modifications. As an example, a business case might arise where a BU does not have any defined Architecture Vision. The EA Office can assist in offering a planning method that focuses on identifying that Vision for the BU without the need to implement of migrate any Architecture. Phases A-F, would serve the needs for that business case. The ADM process can also be adapted to deal with a number of different use scenarios, such as security improvements and the decommissioning of antiquated technology. 15 Project Management Institute. A Guide to the Project Management Body of Knowledge: PMBOK Guide 4th Edition 43 | P a g e VEAF Guidebook State of Vermont CHAPTER 11 - EA DOCUMENTATION REQUIREMENTS (ARTIFACTS) FOR ARCHITECTURE MODELS As the BU and EA begin the process of outlining a target architecture for the business, many artifacts will be collected and deposited into the Architecture Repository. The EA is responsible for necessary artifacts required for all Enterprise Architecture projects. Artifacts should be posted onto the CTO SharePoint Site until an Enterprise Architecture Repository is available. No single document can offer a complete view of the existing enterprise or the target enterprise as required by the business. To understand this approach to documentation, think of a plane landing at an airport. Both the airtraffic controller and the pilot have the same goal of landing a plane, however both only have one view of the system. The pilot’s view of the airport makes up only part of the whole and contains some elements not viewed by the air-traffic controller and vice versa. Together both views are needed need to understand how the airport functions as a whole. In order to understand how the entire airport works cohesively, multiple views are required. APPLICATION OF VIEWS AND VIEWPOINTS Artifacts are documented views. A view is what you see when looking at a system from a chosen viewpoint. A viewpoint is a way of looking at a system. So in the example of the air-traffic controller and the pilot, each sees the systems of the airport differently based on a viewpoint. Yet, the specific view is unique to each. For the purposes of understanding how a BU view’s its business, an Architecture Description (AD) is necessary. The Architecture Description will include the Stakeholders and their concerns, various Viewpoints, Views, Consistencies, In-Consistencies and data model descriptions. It is best to start with the Architecture Description and then add the artifacts to the AD. DOCUMENTATION REQUIREMENTS The following table describes the supporting artifacts used in documenting enterprise, segment, or solution architecture for the EA and BU. These artifacts will feed into the work captured in the Architecture Vision, Architecture Description Document (aka, System Design Document & Interface Control Document), and Architecture Roadmap deliverables. Templates for each are available on SharePoint. 44 | P a g e VEAF Guidebook State of Vermont ADM Phase Artifacts Architecture Domain and EA Governance Principles Catalog VEAF Guidebook Component Strategy Documents Agency Strategy Documents Business Architecture Organization/Actor Catalog Role Catalog Business Service/Function Catalog Business Interaction Matrix Actor/Role Matrix Business Footprint Diagram Business Service/Information Diagram Functional Decomposition Diagram Product Lifecycle Diagram Application Architecture Application Portfolio Catalog Interface Catalog Application/Organization Matrix Role/Application Matrix Application/Function Matrix Application Interaction Matrix Application Communication Diagram Application and User Location Diagram Application Use-Case Diagram Information Architecture Data Entity/Data Component Catalog Data Entity/Business Function Matrix Application/Data Matrix Conceptual Data Diagram Logical Data Diagram Data Dissemination Diagram Technology Architecture Technology Standards Catalog Technology Portfolio Catalog Application/Technology Matrix Environments and Locations Diagram Platform Decomposition Diagram 45 | P a g e VEAF Guidebook State of Vermont ISO/IEC/IEEE 42010 ARCHITECTURE DESCRIPTION TEMPLATE FOR COLLECTING ARTIFACTS16 The purpose of documenting the Architecture Description is communication. Shared documentation enumerating the stakeholders, systems, data models, connectors, capabilities, architecture decision points, and architecture in/consistencies; will allow EAs and various BUs to use a common singular language for reuse within the Enterprise. In Figure 11, the relationship among rules, correspondences, Views, Viewpoints, Stakeholders is outlined and shows how information, when documented correctly feeds an accurate sustainable description of the Enterprise Architecture. Figure 11 Content of the Architecture Description17 16 The template is licensed under a Creative Commons Attribution 3.0 Unported License http://creativecommons.org/licenses/by/3.0/ Contact the author Rich Hilliard ⟨[email protected]⟩ with comments, suggestions, improvements or questions. For more information on ISO/IEC/IEEE 42010, visit the website: http://www.iso-architecture.org/42010/. 17 46 | P a g e VEAF Guidebook State of Vermont CHAPTER 12 - CONCLUSION The VEAF is, by definition, a model of the The VEAF is the model of the organization’s enterprise and its future direction. Its organization’s enterprise and its value to agencies and departments implies more than simply IT investment and IT management. The future direction. dynamic changes in technology and business practices impose greater pressure on an organization to respond more rapidly. VEAF is uniquely positioned to respond to these pressures and demands. By outlining, defining and publishing VEAF’s processes and mechanisms, a long-range view of how the enterprise-wide use of IT will align with and enhance the achievement of the State of Vermont's business strategies. VEAF offers the framework, governance, and guidelines through its principles that will with the state’s organizational needs 47 | P a g e VEAF Guidebook State of Vermont SUPPLEMENTAL APPENDIX A – STATE OF VERMONT HSEP LISCENCED PRODUCTS The SoV licensed the following products on an enterprise/unlimited basis Pillar Database Products Products Oracle Database Enterprise Edition Real Application Clusters Partitioning Advanced Security Database Vault Oracle Advanced Compression Oracle Active Data Guard Diagnostics Pack Tuning Pack Change Management Pack Provisioning and Patch Automation Pack for Database Configuration Management Pack for Oracle Database Oracle Datamasking Pack Business Intelligence Publisher Case Management Products Siebel Public Sector CRM, Siebel Base CRM, Siebel Public Sector Partner Portal, Siebel Public Sector eService, Siebel Partner Manager, Rule Engine Products Oracle Policy Automation, Oracle Policy Modeling, Oracle Policy Automation Connectors for Siebel Reporting and Business Intelligence Oracle Business Intelligence Suite Enterprise Edition Plus Oracle Business Intelligence Management Pack: Informatica PowerCenter and Power Connect Adapters Partner Analytics Fusion Edition Contact Center Telephony Analytics Fusion Edition Service Analytics Fusion Edition 48 | P a g e VEAF Guidebook State of Vermont The SoV licensed the following products on an enterprise/unlimited basis Pillar Products Case Management Analytics Fusion Edition Oracle Data Integrator Oracle BI Publisher Identity and Access Management Identity Analytics Identity and Access Management Suite Plus Oracle Virtual Directory Identity Manager Oracle Internet Directory Oracle Identity Manager Oracle Access Manager Oracle Internet Directory Oracle Adaptive Access Manager Identity Manager Connector - Database Applications Table Identify Manager Connector - Database User Management Identify Manager Connector - Microsoft Active Directory Identify Manager Connector - Microsoft Exchange Identify Manager Connector - PeopleSoft Enterprise Applications Identify Manager Connector - Database Microsoft Windows Identify Manager Connector - UNIX Identify Manager Connector - RSA Authentication Manager Identify Manager Connector - Siebel Enterprise Applications Identify Manager Connector - IBM RACF Management Pack Plus for Identity Management Portal Products Liferay Enterprise (One gate) Management Pack for WebCenter Suite 49 | P a g e VEAF Guidebook State of Vermont The SoV licensed the following products on an enterprise/unlimited basis Pillar Products WebCenter Suite (does not include Content Management) WebCenter Suite Plus upgrade Enterprise Content Management Products Oracle Web Center Capture v 10.1.3.5.1 aka 10gR3 Oracle Recognition and Content v11.1.1.7 Thunderhead Now v5.1 WCP/WLS (notices) Service Orientation Platform Products / BPM WebLogic Suite SOA Management Pack Enterprise Edition WebLogic Server Management Pack Enterprise Edition SOA Suite for Oracle Middleware Includes Oracle BPEL Includes Oracle Mediator Includes Oracle Rules Includes Oracle Human Workflow Includes Oracle Service Bus Includes Oracles Business Activity Monitoring Unified Business Process Management Suite Enterprise Repository Service Registry Healthcare Adaptor Application Integration Architecture MDM-CRM Integration PIP Oracle Application Management Suite for Siebel Master Data Management and Data Quality Products Oracle Customer Hub Data Steward Oracle Customer Hub B2B Oracle Customer Hub B2C Oracle Activity Hub B2B for Oracle Customer Hub B2B Oracle Activity Hub B2C for Oracle Customer Hub 50 | P a g e VEAF Guidebook State of Vermont The SoV licensed the following products on an enterprise/unlimited basis Pillar Products B2C Oracle Customer Master Data Management Integration Base Pack Oracle Data Quality Matching Server - limited to 4 Processors Oracle Data Quality Address Validation Server limited to 4 Processors – Oracle Data Quality Parsing and Standardization Server (Informatica) - limited to 4 Processors. OEDQ is implemented instead of Informatica though it is licensed for any data quality Oracle Data Quality Profiling Server (Informatica) limited to 4 Processors. OEDQ is implemented instead of Informatica though it is licensed for any data quality Misc.…. Oracle Governance, Risk, and Compliance Manager UPK Secure Enterprise Search 51 | P a g e
© Copyright 2024