Commonwealth of Pennsylvania Infrastructure and Economic Development Delivery Center

Enterprise Information Technology Standards Guiding Principles, Technical Architecture Guidelines, Reference Architectures, Enterprise Solutions, Enterprise Infrastructure, Standard Technologies & Hosting Requirements

Version 6.0 Effective: August 26, 2020 pennsylvania

EMERGENCY MANAGEMENT AGENCY

~ pennsylvania ._i ~ OFFICE OF ADMINISTRATION pennsylvania

DEPARTMENT OF COMMUNITY

AND ECONOMIC DEVaOPMENT •

DEPARTMENT OF TRANSPORTATION

Enterprise Information Technology Standards Page: 2

Table of Contents

TABLE OF CONTENTS

1 DOCUMENT INFORMATION

1.1 PURPOSE

1.2 INTENDED AUDIENCE

1.3 INTENDED USE

1.4 CONTENTS OF THIS DOCUMENT

1.5 REVISION HISTORY

2 IT STANDARDS IN PRACTICE

2.1 TYPES OF IT STANDARDS

2.2 APPLICABILITY OF IT STANDARDS

2.3 IT STANDARDS DEVELOPMENT

2.4 ARCHITECTURE EVALUATION & GUIDANCE

2.5 COTS AND IT STANDARDS

2.6 RFP/RFQ’S AND IT STANDARDS

2.7 DEVIATION FROM IT STANDARDS

2.8 INFORMATION TECHNOLOGY LIFECYCLE MANAGEMENT

2.9 APPLICATION AND TECHNOLOGY INVENTORY

3 STANDARD: GUIDING PRINCIPLES FOR ENTERPRISE ARCHITECTURE

3.1 DEFINITION

3.2 GUIDING PRINCIPLES FOR ENTERPRISE ARCHITECTURE

4 STANDARD: TECHNICAL ARCHITECTURE GUIDELINES

4.1 DEFINITION

4.2 GENERAL TECHNICAL ARCHITECTURE

4.3 COMMERCIAL‐OFF‐THE‐SHELF SOFTWARE (COTS)

4.4 DATA ARCHITECTURE & MANAGEMENT

4.5 ENTERPRISE APPLICATION INTEGRATION

4.6 IDENTITY & ACCESS MANAGEMENT

5 STANDARD: REFERENCE ARCHITECTURES

5.1 DEFINITION

5.2 PRESENT VS. FUTURE STATE REFERENCE ARCHITECTURE

5.3 ENTERPRISE REFERENCE ARCHITECTURE ‐ DIAGRAM

5.4 ENTERPRISE REFERENCE ARCHITECTURE ‐ OVERVIEW

5.4.1 Consumer Components

5.4.2 DMZ/Gateway Components

5.4.3 Intranet Components

5.5 BI AND REPORTING PERSPECTIVE

5.6 DATA INTEGRATION PERSPECTIVE

5.7 ENTERPRISE APPLICATION INTEGRATION PERSPECTIVE

5.8 MOBILE APPLICATIONS PERSPECTIVE

5.9 IDENTITY AND ACCESS MANAGEMENT PERSPECTIVE

5.10 AUTOMATION & ORCHESTRATION PERSPECTIVE

EASM

Enterpri~ Architecture & Service Management

Enterprise Information Technology Standards Page: 3

5.11 ENTERPRISE CONTENT SERVICES PERSPECTIVE

5.12 SYSTEM MONITORING PERSPECTIVE

6 STANDARD: ENTERPRISE SOLUTIONS

6.1 DEFINITION

6.2 ENTERPRISE SOLUTIONS

7 STANDARD: ENTERPRISE INFRASTRUCTURE

7.1 DEFINITION

7.2 ENTERPRISE SERVERS

7.3 HOSTING FACILITIES

7.4 NETWORK COMPONENTS

7.5 URL BRANDING – APPLICATION WEB SITE NAMING CONVENTION (DNS)

7.6 STANDARD WORKSTATION

8 STANDARD: ENTERPRISE TECHNOLOGIES

8.1 DEFINITION

8.2 LIST OF ENTERPRISE TECHNOLOGIES

8.3 TECHNOLOGIES EXPRESSLY NOT SUPPORTED

9 STANDARD: HOSTING REQUIREMENTS

EASM

Enterprise Information Technology Standards Page: 4

1 Document Information

1.1 Purpose

This document has been developed by Infrastructure and Economic Development Delivery Center’s, (IEDDC) Enterprise Architecture and Service Management (EASM) program to document, achieve consensus and communicate the organization’s Enterprise IT Standards.

1.2 Intended Audience

This document is to be used by technical professionals (e.g. infrastructure and application architects, server engineers and administrators, etc.) who participate in the design, development, maintenance and support of IT solutions for IEDDC. IT managers, project managers, business analysts and others in the broader IT community will also find this document useful for a wide range of activities, including: portfolio and project planning, requirements analysis, etc.

This document is made available to IEDDC and other Commonwealth employees, contractors, business partners and prospective contractors.

1.3 Intended Use

IEDDC’s EASM program will facilitate the use of this document in promoting technology, solution and architecture standardization and rationalization. The intended uses for this document include but are not limited to the following:

Communicating enterprise standard technologies, solutions and architectures to IT stakeholders, Evaluating proposed technical architectures, Providing guidance for the technical architecture of new and significantly updated IT solutions, Providing guidance to potential vendors regarding requirements and standards when creating responses to requests for proposals and quotations (RFPs and RFQs), and Providing guidance to IEDDC staff when evaluating RFPs and RFQs and other procurement related documents.

1.4 Contents of This Document

Section 1 Document Information provides basic document information, including the purpose, intended audience and intended use as well as a brief description of the contents. Section 2 IT Standards in Practice provides information about the different types of IT standards defined at IEDDC and the processes for applying these standards to ensure optimal technical architecture for our IT solutions. Sections 3 through 9 define IEDDC’s actual Enterprise IT Standards in the form of Guiding Principles, Technical Architecture Guidelines (TAG’s), Reference Architectures, Enterprise Solutions, Enterprise Infrastructure, Enterprise Technologies and Hosting Requirements.

1.5 Revision History

Date Version Author Description of Change

11/28/2012 1.0 Don Kirschman Initial draft of the document

12/10/2012 1.1 Don Kirschman Added Section for Reference Architectures. Also, minor edits throughout document based on EASM feedback.

12/12/2012 1.2 Don Kirschman Added section for Enterprise Solutions. Formatting and minor content changes throughout the document.

EASM

Enterprise Architecture & Suvice Management

Enterprise Information Technology Standards Page: 5

Date Version Author Description of Change

12/18/2012 1.3 Don Kirschman, Gautam Ray

Content and formatting edits to all sections of the document. Added section on Changing Standards.

1/7/2013 1.4 Don Kirschman Removed references to Platform Technologies and adopted the term Enterprise Technology for consistency with ITLM. Added content to Reference Architectures. Made various other changes throughout the document.

1/10/2013 1.5 Don Kirschman Added content to: Section 1.6 Architecture Evaluation, Section 1.7 Waivers from Standards and Section 2.2 Standard Enterprise Solutions. Changed cover page, headers, footer, etc. Formatted all tables consistently and other minor format and content changes throughout the document.

1/22/2013 1.6 Don Kirschman Broke Section 2 into Sections 2, 3 and 4. Added content from IT Infrastructure Guidelines and BIO Systems Environment documents as Sections 5 and 6 respectively. Added “Contents of This Document” to Section 1. Updated EASM logo.

2/11/2013 1.7 Don Kirschman Added section on COTS and IT Standards. Changed IT Infrastructure Guidelines to Guiding Principles for Technical Architecture. Added Guiding Principles regarding Java/.NET and relational databases. Other minor changes.

3/6/2013 2.0 Don Kirschman Removed Appendix B and Appendix C the IT Solution Architecture Evaluation form and the IT Standards Waiver Request form, respectively.

3/26/2013 2.1 Don Kirschman Gautam Ray

Moved Guiding Principles upfront immediately following General Information. Added new Guiding Principles.

Modified some of the existing Guiding Principles.

3/27/2013 2.2 Don Kirschman Renamed Section 1.9 to “Deviations from Standards” and removed all verbiage concerning waivers.

4/22/2013 2.3 Don Kirschman Incorporated suggestion regarding timing of COTS evaluation and accepted changes on several minor typographical edits throughout the document.

5/10/2013 2.4 Don Kirschman Incorporated changes to align with ITLM process as well as dozens of minor grammar, spelling and content changes throughout the document.

8/11/2013 3.0 Doreen Wallen Added Section 5.5 reference architecture for mobile applications.

10/9/2013 3.1 Don Kirschman Added Section 5.6 reference architecture for Domino applications and Section 5.7 reference architecture for SharePoint applications.

6/10/2014 3.2 Don Kirschman Changed 3.1 to indicate Enterprise Technology Inventory report from ITLM is report ITLM008.

Expanded some descriptions of Enterprise Solutions.

Various grammar, spelling and format corrections/changes.

EASM

Enterprise Information Technology Standards Page: 6

7/21/2014 4.0 EASM Team Updated to incorporate external documents and strengthen wording to reflect standards concept.

12/11/2014 4.1 EASM Team Edits made based on Joyce B., comments. See document outlining questions and comments. In addition, hosting requirements section has been entirely updated.

05/11/2015 4.2 EASM Team Changed Section 6 to remove versions for technologies listed in Standard Enterprise Technologies section.

Updated Section 3 with newest PennDOT Enterprise Software Inventory.

6/16/2015 4.3 ITLM Process Owner Updated Section 3 Standard Enterprise Technologies with current Enterprise Software Inventory

8/12/2015 4.4 ITLM Process Owner Updated Section 3 Standard Enterprise Technologies with current Enterprise Software Inventory

9/10/2015 4.5 ITLM Process Owner Updated Section 3 Standard Enterprise Technologies with a newly renamed PennDOT Enterprise Technology Standard report (ITLM008). Changed references to old report name Enterprise Software Inventory.

4/27/2016 4.6 ITLM Process Owner Updated Section 3 Standard Enterprise Technologies with current PennDOT Enterprise Technology Standard report (ITLM008).

6/3/2016 5.0 Don Kirschman In Section 2, edited and expanded material concerning the types of Enterprise IT Standards, adding the concept of Technical Architecture Guidelines (TAG’s) and Enterprise Infrastructure as types of standards.

In Section 2, consolidated and expanded material that defines how standards are developed and how they are used/applied on IT projects to effect a more optimal EA.

Added a new section (Section 3) exclusively for the Guiding Principles for Enterprise Architecture.

Added a new section (Section 4) for TAG’s and added new TAG’s for General Technical Architecture (ARCH), Enterprise Application Integration (EAI), Data Architecture (DATA) and Identity & Access Management (IAM).

Added a new section for Reference Architectures (Section 5) for the architectures that were defined as part of the Legacy Modernization project.

In Section 5, updated the “placemat” Reference Architecture diagram to have less technical granularity and more high-level classification and clarification information.

Renumbered sections as needed due to new sections that were added.

Relocated Enterprise Technologies towards the back of document (now Section 8).

Changed the document template formatting.

EASM

Enterprise Information Technology Standards Page: 7

7/20/2016 5.1 Don Kirschman, Gautam Ray, and Nathan Balagopal

Updated Reference Architecture (Section 5) to add bullet points to further define the placemat reference architecture diagram.

Incorporated additional perspective diagrams provided by BIO/Nathan B. into the Reference Architecture (Section 5).

8/5/2016 5.2 Don Kirschman Rob Mohler

In Section 8.2, incorporated latest version of Enterprise Technologies from ITLM008 report to reflect updates made to ITLM technology inventory.

2/2/2017 5.3 Paul Joseph Inserted to section 7 Enterprise Infrastructure, section 7.5 URL Branding – Application Web Site Naming Convention (DNS)

3/21/2017 5.4 Don Kirschman, ITLM Process

Updated Runtime Reference Architecture diagram (WMB changed to IIB).

Updated Section 8.2 with the latest technology standard listing with updated ITLM008 report.

9/26/17 5.5 Nathan Balagopal Updated the Reference architecture in section 5.9

9/28/2017 5.6 Don Kirschman In Enterprise Solutions Section 6.2, consolidated various EDMS solutions into one and marked EDMS as Contain. Added ECS and ESEC as Enterprise Solutions. Also, enhanced the description of PDJF.

12/12/2017 5.7 ITLM Process Updated Section 8.2 with the latest technology standard listing with updated ITLM008 report. Report name changed to reflect Standard and Emerging technologies.

12/10/2019 5.8 ITLM Process Updated Section 8.2 with the latest technology standard listing.

01/24/2020 5.9 Robert Mohler Corrected grammatical and spelling errors.

08/31/2020 6.0 Brian M. Nobile

IT Infrastructure Architecture Team

Changed PennDOT References to IEDDC where appropriate.

Updated Reference Architecture Documentation Sections 5.8-5.12

Enterprise Information Technology Standards Page: 8

2 IT Standards in Practice

2.1 Types of IT Standards

IEDDC’s EASM program has established a set of Enterprise IT Standards to ensure a business-driven EA from the top-down and an optimized, responsive and flexible EA from the bottom-up. The seven types of Enterprise IT Standards are:

1. Guiding Principles for Enterprise Architecture – Defined in Section 3,

2. Technical Architecture Guidelines – Defined in Section 4,

3. Reference Architectures – Defined in Section 5,

4. Enterprise Solutions – Defined in Section 6,

5. Enterprise Infrastructure – Defined in Section 7,

6. Enterprise Technologies – Defined in Section 8, and

7. Hosting Requirements – Defined in Section 9.

2.2 Applicability of IT Standards

These Enterprise IT Standards are generally and broadly applicable to any IT solution that:

Is developed by or for any agency covered under the IEDDC (Pennsylvania Emergency Management Agency (PEMA), Department of Community and Economic Development (DCED) and Pennsylvania Department of Transportation (PennDOT), Is hosted in IEDDCT or Commonwealth environments, or Is or will be supported by IEDDC IT resources.

In addition to IEDDC’s Enterprise IT Standards, solutions that meet the criteria above must also comply with all Commonwealth standards defined by the Office of Administration/Office for Information Technology (OA/OIT) in Information Technology Policies (ITP’s).

No comprehensive set of IT standards can be 100% applicable for all solutions or projects. The extent to which these standards apply varies depending on the scenario as defined by the development, hosting and support models for the solution. The table below presents some common scenarios and the corresponding level of applicability of the Enterprise IT Standards.

Scenario Applicability of IT Standards

IEDDC Developed and Supported: IEDDC resources (staff and internal consultants) develop a custom application, provide application maintenance and support, and host it in IEDDC and/or Commonwealth environments.

High: The solution shall comply with all relevant standards in all sections of this document.

3rd Party Developed, IEDDC Supported: IEDDC has a 3rd party develop a custom application (e.g.

RFP/RFQ, etc.), the application is or will be transitioned to IEDDC resources for application support and maintenance, and the application is hosted in IEDDC and/or Commonwealth environments.

High: The solution shall comply with all relevant standards in all sections of this document with the exception that use of enterprise application frameworks (e.g. PDJF) shall be considered preferred but not mandatory.

COTS IEDDC Hosted: IEDDC procures a generally-available COTS product with minimal or no customization and hosts the application in IEDDC and/or Commonwealth environments.

Medium: The solution shall comply with standards related to Operating System, hardware and infrastructure environments. Other standards shall be considered as preferred but not mandatory.

EASM

Enterprise Information Technology Standards Page: 9

Scenario Applicability of IT Standards

Software-as-a-Service (SaaS): IEDDC procures Software-as-a-Service from a vendor, and the solution is hosted in the vendor’s environments or with a public cloud provider.

Low: The solution shall comply with the standards related to hosting requirements. All other standards shall be considered as preferred but not mandatory.

2.3 IT Standards Development

IT standards are not developed in response to a new IT project. Rather, they are developed through a collaborative process managed by IEDDC’s Enterprise Architecture and Service Management (EASM) team.

The IT standards development process includes participation from all levels of the organization, including: IT executives, technical managers, team leads, architects and hands-on developers and technicians. The effort includes a cross-section of the organization to bring differing technical expertise and perspectives, including infrastructure, applications, database, operations and security.

IT standards are proposed, documented, presented, discussed and deliberated in an objective and professional manner. This process is managed by the EASM Workgroup, which is made up of a select group of Division Chiefs and Section Chiefs from ISTO and also includes senior-level consultants. As needed, the EASM Workgroup reaches out into the organization to enlist hands-on technical experts to gather research and provide feedback on proposed standards and architecture decisions.

Draft standards are presented to the EASM Workgroup for concurrence. After EASM Workgroup consideration and approval, IT standards are presented to the EASM Program Governance Committee (PGC), consisting of IEDDC’s IT Bureau Directors and the CIO. With EASM PGC approval, the proposed standards become official. Official IT standards are included in this document and distributed to the pertinent IT stakeholders within the organization.

2.4 Architecture Evaluation & Guidance

IEDDC will assign one or more enterprise architects to an IT project at the earliest point in the project lifecycle. The assigned architects specialize in infrastructure and application architecture, and they are familiar with IEDDC’s Enterprise IT Standards. These architects will work with the business community and business analysts and with the projects technical and project management team to gather high-level functional and solution architecture requirements. The architects will then translate those requirements into the most optimal solution architectures.

Documents and deliverables produced by the enterprise architects may include:

Application Profile Questionnaire (APQ): Collects the high-level functional and system requirements for new IT projects or solutions.

Solution Architecture: Illustrates and describes the key elements of the technical architecture for a new IT solution, including the specification of Enterprise Technologies, Enterprise Solutions, infrastructure environments, system interfaces, etc.

Infrastructure Architecture Document (IAD): Defines the logical infrastructure architecture for the IT solution, including servers, network connectivity, communication protocols, security, etc.

Enterprise architects will continue working with project teams throughout the project lifecycle to promote awareness of Enterprise IT Standards and to help ensure that the new solution architecture aligns with those standards while still meeting the needs of the business.

EASM

Enterprise Information Technology Standards Page: 10

2.5 COTS and IT Standards

Commercial Off-The-Shelf (COTS) solutions can offer a significant cost savings and a reduced time-to-market when compared with a custom-developed IT solution.

If a COTS solution is to be hosted in IEDDC or Commonwealth environments and is to be supported in any way by IEDDC IT resources, then the COTS is bound by certain elements of our Enterprise IT Standards. As with any IT solution, a COTS solution must be evaluated for alignment with our Enterprise IT Standards. The time for this evaluation is before the COTS is selected and certainly before a purchase contract or some other type of binding commitment has been established. Implications of COTS solutions that don’t align with Enterprise IT Standards and the potential for additional support costs must be weighed against any potential cost savings offered by the COTS.

COTS solutions are developed with a very specific set of technologies and with a target platform. While it may be technically possible to modify a COTS to bring it into closer alignment with our Enterprise IT Standards, caution must be taken, as these efforts are often very risky and may leave IEDDC with a solution that is orphaned by the COTS vendor and difficult to upgrade and maintain.

2.6 RFP/RFQ’s and IT Standards

Any IT solution being proposed as part of a procurement (RFP, RFQ, etc.) is also bound by our Enterprise IT Standards. As part of the RFP/RFQ process, prospective vendors must complete a IEDDC Offeror Technology List showing all required technologies for their proposed solution and include this form with their technical proposal. Prospective vendors must also indicate how their proposed technical architecture aligns with our Enterprise IT Standards and weigh the costs and benefits of any non-alignment.

A careful architecture evaluation of the proposed IT solution shall be conducted and any non-alignment with Enterprise IT Standards shall be carefully documented and presented to key selection team members in advance of proposal scoring and vendor selection. When evaluating potential vendor’s proposed IT solutions, those that align with IEDDC Enterprise IT Standards are preferable to those that do not.

2.7 Deviation from IT Standards

IEDDC recognizes that there may be strong business cases for IT solutions that deviate from our Enterprise IT standards. If a decision is made to proceed with an IT solution that does not align with our standards, a waiver request must be submitted and approved by IEDDC senior IT leadership. In some cases, in addition to approving the waiver, IEDDC’s Enterprise IT Standards may be updated so future IT solutions can incorporate similar architectures.

The following six situations illustrate a deviation from these Enterprise IT Standards:

Violation of Guiding Principles for Enterprise Architecture: This is a proposed architecture for an IT solution that is not in alignment with the Guiding Principles for Enterprise Architecture as identified in Section 3 of this document. Waiver required.

Violation of Technical Architecture Guidelines: This is an IT solution that is inconsistent with one or more of the Technical Architecture Guidelines (TAG’s) identified in Section 4 of this document.

Waiver required.

Non-Standard Architecture: This is the use of an architecture that is inconsistent with the standard Reference Architectures identified in Section 5 of this document. Waiver required.

Non-Use of Enterprise Solution: This is developing or acquiring new solution functionality that is the same or very similar to that which is already provided by a standard Enterprise Solution identified in Section 6 of this document. Waiver required.

EASM

Enterprise Information Technology Standards Page: 11

Non-Use of Shared Infrastructure: This is deploying or using a new infrastructure environment that is the same or very similar to that which is already provided by a standard Shared Infrastructure identified in Section 7 of this document. Waiver required.

Use of Non-Standard Technology: This is the use of any technology that is either not identified as an Enterprise Technology or that is prohibited for use in Section 8 of this document. Waiver required.

2.8 Information Technology Lifecycle Management

Information Technology Lifecycle Management (ITLM) is IEDDC’s formal process to tracking technologies in use to support our business. The ITLM process helps the organization identify and respond to change brought about by the interaction of interdependent technologies and the movement of those technologies through their natural lifecycle from release and early adoption through obsolescence and retirement.

A key element of the ITLM process is the assignment of a lifecycle classification or status to all critical Enterprise Technologies. The Commonwealth of Pennsylvania, Office of Administration, Office of Information Technology (OA/OIT) has established a standard set of lifecycle classification system for all agencies to use.

The standard technology lifecycle classifications are as follows:

Classification Description

Emerging Emerging technologies or products that have the potential to become current standards. Now, they are to be used only in pilot or test environments where they can be evaluated. Use of these technologies is restricted to a limited production mode and requires approval of a waiver request. Research technologies are less widely accepted, and time will determine if they will become a standard.

Current These technologies or products meet the requirements of the current architecture and are recommended for use.

Contain These technologies or products no longer meet the requirements of the current architecture and are not recommended for use. They are to be phased out over time.

No date has been set for their discontinuance.

Retire These technologies or products are being phased out. Plans are to be developed for their replacement, especially if there is risk involved, such as lack of vendor support. A date for retirement has been set.

2.9 Application and Technology Inventory

IEDDCs applications and technologies represent critical IT assets that support our business. A single, comprehensive and up-to-date inventory is essential to effectively manage and rationalize these assets. To that end, IEDDC maintains the IT Asset Management system (ITAM). ITAM is a central database and a web portal that tracks our business applications, and technologies and the relationships between them. ITAM also identifies application and technology stakeholders. ITAM can be accessed at https://itam.penndot.gov/#/home

ITAM supports the following processes that advance a sound IT ecosystem:

IT Lifecycle Management (ITLM) Technology Refresh Planning Technology Impact Analysis Application Portfolio Management Legacy Modernization Planning Knowledge Maintenance and Transfer IT Skills Assessment

EASM

Enterprise Information Technology Standards Page: 12

Keeping ITAM information up-to-date and accurate is critical to its usefulness. The ITLM process described above is used to ensure that the technology information is maintained. For our business applications, information is entered and maintained in ITAM as part of the IT project and Managed Maintenance processes.

Enterprise Information Technology Standards Page: 13

3 STANDARD: Guiding Principles for Enterprise Architecture

3.1 Definition

A successful Enterprise Architecture program must be business-driven. Technical architecture must follow from the needs of the business. To ensure this business-centric approach, IEDDC’s Enterprise Architecture and Service Management (EASM) program created a set of four Guiding Principles for Enterprise Architecture below. These principles define our EA strategy and govern our EA decisions, standards and processes from the top-down.

The remainder of this section defines IEDDC’s standard Guiding Principles for Enterprise Architecture.

3.2 Guiding Principles for Enterprise Architecture

IEDDC’s Guiding Principles for Enterprise Architecture are as follows:

Skills Availability: The skills necessary to maintain and enhance our systems must be available now and 15 years into the future.

Security: Data is protected from internal and external unauthorized access or disclosure.

System Agility: Our technology must enable flexibility and scalability, resulting in quick and efficient response to new and emerging business needs, including legislative mandates.

Systematic, Iterative Change: Change will be guided by systematic iterative road maps and agile project management strategies avoiding high risk “big bang” waterfall projects.

EASM

Enterprise Information Technology Standards Page: 14

4 STANDARD: Technical Architecture Guidelines

4.1 Definition

There is a tremendous gap between the business-centric strategy defined by Guiding Principles and the day-to-day technical decisions needed to implement IT solutions. More precise technical guidance is needed to guide architects, developers and infrastructure administrators. To fill this gap between strategy and operational needs, IEDDC defines Technical Architecture Guidelines or TAG’s. Technical Architecture Guidelines are set of technology-centric principles or precepts for IT architecture that guide the design of new IT solutions. To ensure business-centric EA and IT services, these Technical Architecture Guidelines must all align back to the Guiding Principles.

The remainder of this section defines IEDDC’s Technical Architecture Guidelines.

4.2 General Technical Architecture

The following are IEDDC’s Technical Architecture Guidelines for General Technical Architecture:

TAG# Guideline Statement Additional Explanation

ARCH.001 The solution shall comply with all Commonwealth standards defined by the Office of Administration/Office for Information Technology (OA/OIT) in Information Technology Policies (ITP’s) and IEDDC IT standards as defined in this document.

Reaffirms the intent and the authority of OA/OIT standards and IEDDC’s Enterprise IT Standards to affect a more standardized and optimal solution architecture.

ARCH.002 The solution shall comply with IEDDC’s standard Guiding Principles for Enterprise Architecture to the greatest extent possible.

Encourages the review and evaluation of the new solution architecture against the standard Guiding Principles for Enterprise Architecture defined in Section 3 of this document.

ARCH.003 The solution shall comply with IEDDC’s standard Technical Architecture Guidelines to the greatest extent possible.

Encourages the review and evaluation of the new solution architecture against the standard Technical Architecture Guidelines defined in Section 4 of this document.

ARCH.004 The solution shall align with IEDDC’s standard Reference Architectures to the greatest extent possible.

Encourages the review and evaluation of the new solution architecture against the standard Reference Architectures defined in Section 5 of this document.

ARCH.005 The solution shall leverage IEDDC’s standard Enterprise Solutions to the greatest extent possible.

Encourages the review and evaluation of the new solution architecture against the standard Enterprise Solutions as defined in Section 6 of this document.

ARCH.006 The solution shall leverage IEDDC’s standard Enterprise Infrastructure to the greatest extent possible.

Encourages the review and evaluation of the new solution architecture against the standard Enterprise Infrastructure as defined in Section 7 of this document.

EASM

Enterprise Information Technology Standards Page: 15

TAG# Guideline Statement Additional Explanation

ARCH.007 The solution shall leverage technologies in lifecycle classifications as defined by the Office of Administration/Office for Information Technology (OA/OIT) in Information Technology Policies (ITP’s) and IEDDC IT standards as defined in this document as follows:

Only technologies with a lifecycle classification of “Current” or “Emerging” shall be used for new or significantly modified IT solutions.

Technologies with a lifecycle classification of “Contain” or “Retire” shall not be used for new solutions or introduced into existing solutions.

If no applicable OA/OIT or IEDDC policy defines a lifecycle classification for a technology, a waiver must be submitted if the technology is to be used.

This is intended to promote the use of current and emerging technologies while also encouraging the gradual reduction in the use of older technologies.

ARCH.008 The solution shall ideally be architected as a series of distinct and loosely-coupled horizontal tiers.

If possible, separate IT solutions into horizontal tiers, such as presentation, business, middleware, persistence, etc. Loosely-couple these tiers to allow for flexibility and change in the future.

ARCH.009 The solution shall ideally be architected as a collection of loosely-coupled vertical components based on the business functionality each component provides.

At the enterprise level, this vertical separation may mean separate focused yet integrated solutions for HR, Budget, Inventory, etc.

Within a single solution, this may mean separate modules for functionality such as workflow, Customer Relationship Management-CRM, correspondence, administration/configuration, reporting, batch, etc. Loosely-couple these tiers to allow for flexibility and change in the future and perhaps for iterative delivery to the business customer.

ARCH.010 On-premises hosting is required for all IT solutions that manage confidential and/or PII data or are deemed mission-critical.

Applications that are mission-critical or that manage confidential data must be hosted in Commonwealth or IEDDC hosting facilities.

EASM

Enterprise Information Technology Standards Page: 16

ARCH.011 Public cloud hosting is appropriate for the following use cases:

Development, System and Performance Testing and Code & Configuration Management

Research and Innovation

Non-mission-critical applications

Vendor-hosted and SaaS applications

Applications that do not manage confidential and/or PII data

Backup and Disaster Recovery

Public-facing and content-only sites

IEDDC has very little experience with public cloud. IEDDC and CWOPA decision-makers are not yet able to embrace public cloud in all use-cases, particularly where confidential and citizen data is concerned. It is recognized that public cloud, particularly Platform-as-a- Service(PaaS) and Software-as-a- Service(SaaS), can offer operational efficiencies provided the use-case is appropriate.

ARCH.012 For cloud-hosted solutions, Software-as-a- Service (SaaS) and Platform-as-a-Service (PaaS) shall be considered before Infrastructure-as-a-Service (IaaS).

SaaS provides IT solutions to the business more quickly without the capital expenses for development or infrastructure. PaaS allows developers to deliver solutions without the capital and operating expenses of infrastructure. SaaS and PaaS allow infrastructure technicians to spend less time on hardware upgrades, OS and middleware patches and technology refreshes and spend more time in infrastructure design and optimization across the enterprise.

ARCH.013 The solution shall be scalable, with respect to infrastructure, technology and software architecture, to accommodate increases in system capacity and throughput without resulting in performance degradation.

Solution should run effectively in a clustered environment. Solution should respond well to horizontal and vertical scaling as demand for the solution grows.

ARCH.014 The solution shall encrypt sensitive data in motion and at rest as required in Commonwealth and IEDDC standards.

To protect confidential and PII data from unauthorized access.

ARCH.015 The solution shall be developed using Java EE or Microsoft C#.NET programming languages to the greatest extent possible.

Java and C#.NET are the two programming languages that IEDDC is best able to support for web applications and web services development.

ARCH.016 For solutions that primarily target desktop form factor devices, the solution shall be server-based to the greatest extent possible and be accessible with industry-leading web browsers.

Discourage the use of client-based applications (except for native mobile) and promote accessibility from multiple web browsers.

EASM

Enterprise Information Technology Standards Page: 17

ARCH.017 The solution shall be designed to be accessible via the internet unless there is a specific requirement to the contrary.

Promotes greater accessibility to enterprise applications for business users who are increasingly in the field or working from alternate locations.

ARCH.018 The solution shall have easily configurable parameters that do not require code modifications for such items as:

communication, infrastructure and component names and locations, database names and connections, environment-specific settings, etc.

Configuration items that can change often should be easily changed with no coding changes and with minimal or no effort for deployment of these changes.

ARCH.019 The solution shall support multiple environments, including production and multiple pre-production environments.

Environments as needed for Sandbox, Development, System Test, UAT, Performance Test and Production.

ARCH.020 The solution shall include enough technical documentation, and implementation plans must incorporate specific tasks and activities to facilitate knowledge transfer and transition to designated IEDDC technical resources.

To ensure a smooth transition from the project development/build team to a steady-state maintenance/support team.

4.3 Commercial-Off-The-Shelf Software (COTS)

The following are IEDDC’s Technical Architecture Guidelines for COTS solutions:

TAG# Guideline Statement Additional Explanation

COTS.001 The use of COTS middleware software is preferable to custom-development.

If there is a widely-used COTS technology to perform middleware functionality, it is most likely going to be more efficient to leverage that technology than custom coding in a general-purpose programming language like Java or C#.NET. Any efficiencies gained will have to be weighed against the cost of acquiring and supporting the COTS middleware technology.

COTS.002 The use of COTS business software is preferable to custom-development for providing business functionality that is common or non-unique to the organization.

Examples of such common business functionality include: HR, budget, service desk, etc. The more common the business function is, the better chance that a COTS is the way to go. COTS offering business functions that are common across a smaller number of organizations (e.g. 50 states or 67 counties) should be much more carefully evaluated for business fit before selection.

COTS.003 The COTS software shall not be customized such that the organization is supported by a unique code base for the core product.

At this point, the solution would be considered custom development and should be managed as such.

EASM

Enterprise Information Technology Standards Page: 18

COTS.004 The COTS software shall not be customized beyond 20% of the overall functionality.

As the level of customization increases, the advantages of the COTS vs. custom-development decreases. Beyond a certain level of customization, the COTS will be significantly costlier to develop, implement and maintain vs. custom-developed solutions.

COTS.005 The COTS software shall only be customized through configuration, configurable attributes, user exits, service interfaces or API integration with external solution components or services.

A leading issue with COTS is difficulty with upgrades and technology refreshes. Smart customization can substantially reduce the brittleness of the solution.

COTS.006 The COTS software must be recognized by independent technology-rating or industry groups as a leader for providing the intended functionality.

Recognition of COTS software by independent groups (e.g. Gartner, Forrester, etc.) or specific government or industry associations (e.g.

AASHTO, AAMVA, etc.) can greatly reduce the risk associated with COTS.

COTS.007 The COTS software must be widely adopted in the industry or very likely to be adopted in the future.

The more customers there are for COTS software, the more likely the product will remain viable in the long term.

COTS.008 The financial and existential variability of the software vendor shall be carefully considered when evaluating COTS software.

COTS software can be in production for 10 years or more. The possibility that the software vendor could cease operations should be carefully considered.

COTS.009 The COTS shall be widely supported by the IT labor force or the required technical skills shall be readily attainable.

Skilled IT labor must be readily available, or the skills must be easy to learn either on-the-job or through readily-available training.

COTS.010 The COTS software must include ongoing maintenance and support agreements with the software vendor so long as the COTS directly supports the business and/or is used in a production runtime environment.

The software vendor that develops the COTS must also offer maintenance and support agreements, and IEDDC must enter into these agreements to ensure the business is adequately protected. Maintenance and support agreements provide periodic fixes and enhancements as well as production support in the event of a defect or service interruption.

Maintenance and support for COTS cannot be “turned over” to IEDDC resources, as this would then be a custom-developed solution.

COTS.011 The cost of ongoing maintenance, COTS and technology upgrades and maintenance & support agreements must be considered when evaluating the costs of COTS software versus custom-development.

In addition to the upfront license costs, maintenance and support agreements cost typically range from 15% to 30% of the original license cost. These costs often increase each year based on some inflation index.

EASM

Enterprise Information Technology Standards Page: 19

COTS.012 If a COTS business solution is offered as Software-as-a-Service (SaaS), the SaaS deployment model shall be considered before on-premises hosting, provided the use case is appropriate for cloud hosting.

Vendors can generally provide more efficient and cost-effective support for their COTS business solutions if they are offered as SaaS.

The preference for SaaS does not apply for COTS middleware. Refer to TAG’s regarding cloud hosting for the appropriate use cases.

4.4 Data Architecture & Management

The following are IEDDC’s Technical Architecture Guidelines for Data Architecture & Management:

TAG# Guideline Statement Additional Explanation

DATA.001 Systems of record that must persist structured data for frequent querying or reporting shall do so using a relational database technology.

Even in an era of emerging technologies like no-SQL databases and Big Data, RDBMS are still the optimal choice for our transactional and operational systems of record.

DATA.002 Binary content, including: documents, images, videos, etc., shall be managed in a IEDDC-approved Content Management System and not in a relational database.

Documents/content shall be managed in a CMS, like EDMS (P8) or Microsoft SharePoint.

DATA.003 All confidential data, including: structured, unstructured and binary, shall be encrypted at rest.

Data must be encrypted at-rest and must only be accessible to authorized users.

DATA.004 All confidential data loaded, exported and exchanged among enterprise application databases shall be encrypted end-to-end.

Data must be encrypted in-transit and in intermediate resting locations.

DATA.005 Transactional (OLTP) and analytical (OLAP) data shall be managed in separate database environments, each being uniquely tuned for the required workloads.

Transactional databases must optimize transaction throughput and take extra measures to protect data integrity while analytical databases must optimize query performance. These disparate needs cannot efficiently be accommodated in a single environment.

DATA.006 The exchange of data in bulk to and from enterprise databases shall be through well-defined and documented interfaces.

Documented interfaces help in understanding dependency among enterprise applications and their databases.

DATA.007 Applications shall not have direct query access to other applications’ data.

Use ETL to move data from one application’s database to another or use an EAI solution if real-time integration is a business requirement.

EASM

Enterprise Information Technology Standards Page: 20

DATA.008 The use of COTS middleware tools for Extract, Transform and load (ETL) is preferable to custom coding.

COTS middleware is for more likely to deliver a better solution in less time and cost compared with custom coding. This is especially true for heterogeneous ETL (e.g. SQL Server to Oracle, ASCII text to Oracle).

DATA.009 Database code should not be used for routine CRUD operations; rather, dynamic SQL should be used instead.

Stored procedures can encapsulate business logic that may be best suited for the application tier, and they unnecessarily couple a frontend application to a specific database technology.

DATA.010 Database code should be reserved for long-running or highly-complex tasks involving data within a single database environment.

Database code (e.g. stored procedures, functions, etc.) is often the most performant option for such tasks but they should generally be avoided in all other cases.

DATA.011 Comprehensive, accurate and up-to-date data models shall be maintained for enterprise application databases using a COTS data modeling tool.

Ideally, this means logical and physical data modeling using the modeling tool, including the generation of DDL scripts for model-driven database development. At minimum, data models should be refreshed with each significant database change.

DATA.012 Databases for all enterprise applications shall be designed by a specially-trained and experienced data modeler.

Data modeling should not be left to individual developers except for the smallest of changes (e.g. adding or modifying the definition of a single column). An experience data modeler should take ownership and be responsible for the database design.

DATA.013 Technical and business definition metadata for all enterprise application databases shall be loaded to the enterprise metadata repository and refreshed on a regular basis.

The metadata repository makes metadata easy to search, explore and analyze by developers, DBA’s, BA’s and even the business user.

DATA.014 The solution shall document and implement an Information Lifecycle Management (ILM) strategy, including record retention and archiving/purge strategies, for all structured and unstructured data.

Promote sound ILM and efficient utilization of storage as well as maintain optimal query performance of mainline production transactional processing.

4.5 Enterprise Application Integration

The following are IEDDC’s Technical Architecture Guidelines for Enterprise Application Integration (EAI):

TAG# Guideline Statement Additional Explanation

EAI.001 A single enterprise inventory of all EAI services and interfaces shall be developed and kept current.

This is critical to understanding applicationdependencies, application and data governance and the impact of change on applications.

EASM

Enterprise Information Technology Standards Page: 21

EAI.002 All EAI services and interfaces must be secured with Authentication and Authorization of the service consumer in a manner consistent with OA/OIT policies.

This means Authentication and Authorization against the appropriate Commonwealth Active Directory domain.

EAI.003 All EAI services and interfaces shall be designed for security with the assumption that IEDDC and Commonwealth networks and IT environments are no more secure than the Internet.

The notion that a secure perimeter exists that insulates internal environments from security threats is no longer valid.

EAI.004 All confidential data exchanged via EAI services and interfaces must be encrypted in transit and at rest from end-to-end.

To protect confidential and PII data from unauthorized access.

EAI.005 EAI services and interfaces are the preferred architecture pattern to be used to satisfy business requirements for real-time access to data and services among systems.

Planned, designed, documented and managed SOA interfaces over firewall-friendly and easily-secured HTTP/HTTPS are far better than unrestricted direct query access.

EAI.006 EAI services and interfaces are only to be implemented when real-time or near real-time, access to data and services among systems is a business requirement; if not, a data integration approach should be used.

SOA services are preferable for real-time;

however, if latency (e.g. hourly, daily, etc.) is acceptable, data integration solutions (e.g.

ETL) are easier to implement and maintain, less tightly-coupled and more resilient.

EAI.007 The use of middleware for delivery of EAI solutions is preferable to writing custom application code.

Middleware generally results in better solutions that are built in less time, lower cost and with greater quality.

EAI.008 Existing middleware tools should be considered first for delivering EAI solutions.

EAI.009 A balanced, proactive and reactive approach shall be taken to evaluate EAI tools against changing technology and business needs, and additional tools will be considered, evaluated and adopted through a formal change management process governed by the EASM program.

Proactive approach based on changing and emerging technologies and business needs.

Reactive approach that responds to specific IT solution needs that cannot be addressed with existing tools.

EAI.010 Common EAI Patterns shall be developed that define how middleware and other common architectural components will be used, and these patterns shall be considered first for delivery of EAI solutions.

Identify the smallest number of pre-defined, preferred architectural patterns to optimally address known and expected EAI use cases, and encourage their use on IT projects.

EAI.011 A balanced, proactive and reactive approach shall be taken to evaluate EAI Patterns against current and emerging EAI Use Cases, and new patterns shall be developed in a formal change management process that is managed by the EASM program.

Proactive by considering changing and emerging use cases. Reactive in response to specific IT solution needs that cannot be addressed with existing patterns.

EAI.012 EAI mediation functionality and components should be confined to middleware tools and environments to the greatest extent possible.

Mediation (security, translation, transformation, etc.) should take place in middleware environments.

EASM

Enterprise Information Technology Standards Page: 22

EAI.013 Applications and application environments should be kept free from EAI mediation functionality and components to the greatest extent possible.

Applications and their environments should be free from mediation and middleware components, plugins, adaptors, etc.

EAI.014 EAI services and interfaces should use broadly-recognized standards, protocols and conventions when they are available.

Use of HTTP/HTTPS, SOAP, REST, XML and JSON for message format, and industry standards like CMIS for message content.

EAI.015 SOAP web services are the preferred architecture for EAI as more of the following conditions are met:

The service is a Common Service, A formal or contractual relationship exists between the service provider and the service consumer, The service has a small number of well-defined consumers, There is a need for standards-based security from end-to-end,…