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 8.1

Last Updated: 2026-03-09

Effective: 2026-03-09

IEDDC Enterprise IT Standards

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 Applicability of IT Standards

2.2 IT Standards Development

2.3 Architecture Evaluation & Guidance

2.4 Commercial Third-Party Products and IT Standards

2.5 RFP/RFQs and IT Standards

2.6 Deviation from IT Standards

2.7 Information Technology Lifecycle Management

2.8 Application and Technology Inventory

3 Guiding Principles for Enterprise Architecture

3.1 Definition

3.2 Guiding Principles for Enterprise Architecture

4 Enterprise Reference Architecture

4.1 Definition

4.2 Enterprise Reference Architecture Diagram

4.3 Sub-domain Definitions

5 STANDARD: Application Development

5.1 Component Descriptions

5.2 Perspectives

5.2.1 .NET Application On-premises Perspective

5.2.2 Domino Application Perspective

5.2.3 Java Application On-premises Perspective

5.2.4 Java Application Azure Perspective

5.2.5 Mobile Application On-Premises Perspective

5.2.6 Mobile Application Cloud-based Perspective

5.2.7 SharePoint Application Perspective

5.2.8 Single Page Application/Progressive Web Application Perspective

5.3 Technical Architecture Guidelines (TAGs)

5.4 Using SaaS in Your Solution

6 STANDARD: Identity and Access Management

6.1 Component Descriptions

6.2 Perspectives

6.3 Technical Architecture Guidelines (TAGs)

7 STANDARD: Geospatial Services

7.1 Component Descriptions

7.2 Perspectives

7.2.1 Geospatial Services On-Prem Perspective

7.2.2 Geospatial Services Cloud Perspective

7.3 Technical Architecture Guidelines (TAGs)

8 STANDARD: Support Services

8.1 Component Descriptions

8.2 Perspectives

8.2.1 reCAPTCHA Perspective

8.2.2 Enterprise Payment Perspective

8.3 Technical Architecture Guidelines (TAGs)

9 STANDARD: Content Services

9.1 Component Descriptions

9.2 Perspectives

9.3 Technical Architecture Guidelines (TAGs)

10 STANDARD: Analytics and Reporting

10.1 Component Descriptions

10.2 Perspectives

10.3 Technical Architecture Guidelines (TAGs)

11 STANDARD: Integration Services

11.1 Component Descriptions

11.2 Perspectives

11.3 Technical Architecture Guidelines (TAGs)

11.4 Integration Services and Transition to Cloud

12 STANDARD: Database Services

12.1 Component Descriptions

12.2 Perspectives

12.3 Technical Architecture Guidelines (TAGs)

12.4 Highway Reference Database (HRD)

12.4.1 Highway Reference Data (HRD) Perspective

13 STANDARD: Infrastructure Services

13.1 Component Descriptions

13.2 Perspectives

13.3 Technical Architecture Guidelines (TAGs)

14 STANDARD: Batch Services

14.1 Component Descriptions

14.2 Perspectives

14.3 Technical Architecture Guidelines (TAGs)

15 STANDARD: System Monitoring

15.1 Component Descriptions

15.2 Perspectives

15.3 Technical Architecture Guidelines (TAGs)

16 STANDARD: DevSecOps

16.1 Component Descriptions

16.2 Perspectives

16.3 Technical Architecture Guidelines (TAGs)

17 STANDARD: Enterprise Solutions

17.1 Definition

17.2 Enterprise Solutions

18 STANDARD: Enterprise Infrastructure

18.1 Definition

18.2 Enterprise Servers

18.3 Hosting Facilities

18.4 Network Components

18.5 URL Branding – Application Web Site Naming Convention (DNS)

18.6 Standard Workstation

19 STANDARD: Enterprise Technologies

19.1 Definition

19.2 List of Enterprise Technologies

19.3 Technologies Expressly Not Supported

19.4 Artificial Intelligence (AI)

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, i.e., infrastructure and application architects, server engineers and administrators, developers, 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, tool selection, product evaluation, 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)

• 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 describes processes for applying these standards to ensure optimal technical architecture for our IT solutions.

Sections 3 Guiding Principles for Enterprise Architecture offers key foundational guideposts upon which our EA strategy and approach are built.

Section 4 Enterprise Reference Architecture attempts to break down the larger enterprise into logically related groupings of technology components or “sub-domains”. Each sub-domain will then be broken down to describe its constituent components in subsequent sections of the document.

Sections 5 through 16 define standards related to each technology sub-domain. Each section is comprised of:

• Definitions of each component, including what it does, how it is typically deployed within IEDDC which Agencies currently support it, and where it falls in the technology lifecycle.

• Technical reference architecture diagrams, or “Perspectives”, that give examples of how components in the sub-domain are typically integrated into solutions.

• Technical Architecture Guidelines (TAGs) that define how components shall or shall not be used or chosen

Section 17 Enterprise Solutions focuses on custom developed and internally maintained components that should be used to fulfill specific business functionality whenever possible.

Section 18 Enterprise Infrastructure describes IEDDC- and Commonwealth-managed environments - data centers and cloud providers available to host both custom-built and commercial solutions.

Section 19 Enterprise Technologies a further breakdown of specific technologies (including tools, products, and frameworks that may not rise to the level of enterprise component), their minimum supported version, which Agencies currently use them, and their place in the technology lifecycle.

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.

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.

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.

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/2017 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

8/21/2024 7.0 AMS SAS Team and Subject Matter Experts

Revamped and reorganized the document to include:

• New on-prem and cloud-based hosting environments

• Application components and frameworks

• Standard development and DevOps tools

10/23/2025 8.0 AMS SAS Team • CUCR to IT VRA (Section 2.4) o Updated IT policy naming and references (various)

• Updated "placemat" diagram (4.2) o New components

▪ Python (see section 5.1)

▪ Okta, CyberArk, Azure Key

Vault (6.1)

▪ EPP (Section 8.1 and 8.2)

▪ Informatica Intelligent Data

Management Cloud (IDMC) (11.1)

▪ Cosmos DB (12.1)

▪ Azure Functions/Azure

Function Apps (13.1)

▪ Log Analytics Workspaces, Oracle Enterprise Manager, Redgate Monitor, New Relic (15.1)

▪ JMeter (Load Testing) (16.1)

• Additional perspectives to differentiate on-premises deployments from those in Azure (section 5.2)

• Added links to infrastructure Reference Architectures (RADDs) developed by AMS APS (section 5.2)

• New guidance/TAGS o Unit Testing (5.3) o Programmatic Printing (5.3) o Document uploads (5.3)

• Added GIS Cloud Perspective (7.2)

• Added Integration options for cloud migration (11.4)

• Added Highway Reference Data (12.4)

• Added Infrastructure patterns (13.2)

• Significant cleanup of the Enterprise Technology Report (Section 19.2)

• Added initial section on AI (19.4)

3/9/2026 8.1 AMS SAS Team • Updated Azure DevOps Pipelines description.

• Updated BMC Remedy references to BMC Helix.

• Updated APDV.038 with changes proposed by SDLC team.

• Updated/added SM.001-SM.003 to align with enterprise system monitoring best practices.

2 IT Standards in Practice

2.1 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, including:

o Pennsylvania Emergency Management Agency (PEMA) o Department of Community and Economic Development (DCED) o Pennsylvania Department of Transportation (PennDOT)

• Is hosted in IEDDC or Commonwealth environments, whether they be on-premises data centers or sanctioned cloud providers

• 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) Information Technology Policies (ITPs). Where applicable, ITPs will be referenced specifically in context throughout this document.

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-managed 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, 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-managed 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 shall be considered preferred but not mandatory.

Commercial Off-The-Shelf (COTS), IEDDC Hosted:

IEDDC procures a generally available COTS product with minimal or no customization and hosts the application in IEDDC and/or Commonwealth-managed 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.

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.

https://www.pa.gov/agencies/oa/policies/it-policies

2.2 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, 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 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.3 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 Design Document (IADD): Defines the logical infrastructure architecture for the IT solution, including servers, network connectivity, communication protocols, security, etc. Please note that an updated IADD (architecture diagram) is required prior to any changes to infrastructure (cloud or on-prem).

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.

2.4 Commercial Third-Party Products and IT Standards

Solutions based on Commercial Off-The-Shelf (COTS), Software-as-a-Service (SaaS), and Platform-as-a-

Service (PaaS) products 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 product 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.

All software procurements must go through our ServiceNow which includes an initial review by the GRC

(Governance, Risk, and Compliance). This initial review may lead to a request for an IT Vendor Risk

Assessment. Both the initial review and IT Vendor Risk Assessment are defined in the IT Risk

Management Policy.

For SaaS and PaaS-centric solutions, risk of creating unsupported orphan versions through customization is all but alleviated, as product maintenance is ceded entirely to the vendor; however, control of

Commonwealth data and processes are also handed to the vendor. Before implementing any solution not hosted in a Commonwealth-managed data center or cloud instance - whether that be in a public cloud provider or a vendor-owned data center – the solution must be subject to an initial review by the

GRC (Governance, Risk, and Compliance).

The GRC does not focus on the internal technical stack used to implement the product. Rather, it is intended to help ensure that the vendor will be a good steward of Commonwealth data by reviewing the offering’s security posture. The GRC, after an initial review, may request an IT Vendor Risk Assessment.

This assessment is focused on the vendor’s SOC 2 Type II report. This assessment also includes a review of the vendor’s Information Security Policy, Penetration Tests, Accessibility reports, and any StateRAMP or FedRAMP certificates.

Please refer to Commonwealth IT Policy IT Risk Management Policy for additional information about the

IT Vendor Risk Assessment.

2.5 RFP/RFQs 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-https://www.pa.gov/content/dam/copapwp-pagov/en/oa/documents/policies/it-policies/it%20risk%20management%20policy.pdf https://www.pa.gov/content/dam/copapwp-pagov/en/oa/documents/policies/it-policies/it%20risk%20management%20policy.pdf https://www.pa.gov/content/dam/copapwp-pagov/en/oa/documents/policies/it-policies/it%20risk%20management%20policy.pdf alignment. As noted in Section 2.4 above, vendor solutions relying on SaaS or PaaS offerings will need to be approved through the CUCR after award and prior to production implementation.

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.6 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 Sections 5 through 16 of this document. Waiver required.

• Non-Standard Architecture: This is the use of an architecture that is inconsistent with the

Enterprise Reference Architecture or Perspectives identified in Sections 4 through 16 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 17 of this document. Waiver required.

• 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 18 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 19 of this document. Waiver required.

2.7 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 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. At this time, 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 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.8 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, technologies, and the relationships between them.

ITAM also identifies application and technology stakeholders. ITAM can be accessed from within the

Commonwealth network 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

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.

https://itam.penndot.gov/#/home

3 Guiding Principles for Enterprise Architecture

3.1 Definition

A successful Enterprise Architecture program must be driven by business needs, with solution architecture applying technology in its best form to meet those needs. IEDDC’s Enterprise Architecture and Service Management (EASM) program has created the set of four Guiding Principles for Enterprise

Architecture below to ground this business-centric approach. These principles define our EA strategy and govern our EA decisions, standards, and processes from the top-down.

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 and iterative roadmaps, and implemented via agile project management strategies avoiding high-risk, “big bang”, waterfall projects.

4 Enterprise Reference Architecture

4.1 Definition

Generally, an Enterprise Reference Architecture defines the high-level logical architecture and supported technology stack for the entire IT environment for an organization. The Enterprise Reference

Architecture that follows here attempts to decompose IEDDD’s broad array of enterprise technologies and solutions, generally referred to as “components”, into functional areas or “sub-domains” for easier consumption and rationalization.

Any given solution architecture will draw components from one or more of the sub-domains as building blocks to develop a business application. New IT solutions being designed will be directed to reuse established component combinations and integration patterns to the greatest extent possible. Most sub-domains have contextual reference architecture or “perspective” diagrams that visualize these established patterns. This reuse reduces design effort, time, and cost while also ensuring that existing technologies, solutions, and physical infrastructures are rationalized and standardized.

4.2 Enterprise Reference Architecture Diagram

4.3 Sub-domain Definitions

As the IEDDC enterprise was broken down into more manageable functional areas, the following sub-domains emerged. These are expected to evolve over time as technologies and the relationships between them change.

• Application Development – standard tools, products, languages, frameworks, platforms, etc.

used to construct and implement business applications, foundational services, and enterprise solutions.

• Identity and Access Management – component sub-domain that provides user authentication and authorization (auth/authz), registration, and management services to most of the other enterprise sub-domains.

• Geospatial Services – components related to the generation, management, storage, and graphical representation of location and mapping data, and geographic presentation of business and analytical data.

• Support Services – Miscellaneous services supporting various business functions, such as

CAPTCHA, payment processing, electronic communications, etc.

• Content Services – services related to the capture, generation, storage, and management of electronic documents and images.

• Analytics and Reporting – components supporting real-time and automated report generation and presentation of business analytical data

• Integration Services – tools enabling data and process integrations, translations, transformations, etc., between disparate systems and sub-domains, including middleware, asynchronous messaging, service gateways, data extract/transform/load (ETL), change data capture (CDC), and secure file transfer (FTP)

• Database Services – supported database management platforms

• Infrastructure Services – supported operating systems and application servers available to host web applications, batch process, and COTS products.

• Batch Services – Orchestration and management components specifically supporting batch processes.

• System Monitoring – foundational components used to monitor health, performance, and uptime of component across most other sub-domains.

• DevSecOps – cross-cutting sub-domain providing continuous integration/continuous delivery

(CI/CD) orchestration, software configuration management (SCM), change/release management, automated application scanning (code quality, security, software composition, accessibility, etc.), and automated testing services.

5 STANDARD: Application Development

5.1 Component Descriptions

PROGRAMMING LANGUAGES

.NET (Current) (DCED, PEMA, PennDOT): .NET is one of the primary programming languages in use here at the IEDDC. The .NET ecosystem is a collection of tools, frameworks, libraries, and languages that are built on top of the .NET platform, providing a rich set of tools and frameworks for building modern web applications, services, APIs, and supporting components. With its cross-platform capabilities, support for multiple languages, and extensive library of third-party packages, the .NET ecosystem offers a powerful and flexible platform for building applications that can run anywhere.

IEDDC infrastructure and DevSecOps support the .NET ecosystem on-prem on IIS/Windows infrastructure and in the cloud on Azure App Services or Azure Kubernetes Services (AKS). .NET Core is used for building modern, cloud-native, microservices-based applications, and ASP.NET Web Forms and

API are used for existing enterprise applications, such as eCAMMS, Lab Applications, and PSAP Portal.

.NET is used in most of the sub-domains at various integration levels on the IEDDC Enterprise Reference

Architecture Diagram from Section 4.

Java (Current) (PennDOT): Java is one of the standard programming languages used at the IEDDC. Java is a general-purpose programming language used to develop a wide range of applications, from mobile and web apps to enterprise-level, cloud-native, microservices-based software systems. Some of the largest, most complex, and highest user volume systems for both Driver & Vehicle Services (DVS) and

Highway Administration (HA) are built in Java.

Most Java applications are currently deployed in-house onto JBoss or WebSphere servers running on

RedHat Enterprise Linux (RHEL) or Windows, with recent modern cloud-native applications using Java

Spring Boot deployed to containers running on Azure App Service or Azure Kubernetes Services (AKS).

The IEDDC has built its own enterprise frameworks (PDJF, PDFramework, ENTSS, etc.) to facilitate building enterprise applications, though most of these have been Contained in favor of more standards-based frameworks and patterns. Java is used in most of the sub-domains at various integration levels on the IEDDC Enterprise Reference Architecture Diagram from Section 4.

JavaScript/Typescript (Current) (DCED, PEMA, PennDOT): JavaScript has a vast ecosystem of frameworks and libraries like React, Angular*, and Vue.js, which provide powerful tools and abstractions to simplify development of complex, responsive, and accessible web and mobile applications.

JavaScript/Typescript frameworks are mainly used for building single-page applications (SPA) and GIS

MapCore applications. Vue.js SPA with Java Spring Boot or .NET API backend has emerged as the

IEDDC’s preferred pattern to build scalable cloud-native applications. GIS services and ArcGIS-based geospatial applications are built using JavaScript/Typescript frameworks like Angular and GraphQL.

IEDDC infrastructure and DevSecOps supports the JavaScript/TypeScript ecosystem on-prem and on

Azure; however, preferred hosting for newly developed enterprise solutions, such as Automated Permit

Routing and Analysis System (APRAS) and Modernized Vehicle Driver License Services (MVDLS), is Azure

Kubernetes Services (AKS) for microservices, or Azure App Service for simpler API layer implementations.

*PLEASE NOTE: This is specifically Angular, not AngularJS. AngularJS is out of support and is considered in Retire status.

Python (Emerging) (PennDOT): Python is a dynamically typed and garbage-collected programming language. It supports multiple programming paradigms, including structured (particularly procedural), object-oriented, and functional programming. Python is widely used for scripting, process automation in

DevOps, and across various domains such as web development, data science, and machine learning. The language is platform-agnostic, running natively on Mac OS X, Windows, Linux, and Unix, with unofficial builds available for Android and iOS.

Swift (Current) (DCED, PEMA, PennDOT): Swift is a powerful, general purpose, object-oriented language for iOS, iPadOS, macOS, tvOS, and watchOS and is the primary language used to develop native mobile applications in the Delivery Center. Mobile applications developed using Swift will integrate with a variety of services or microservices hosted both on-premises or in the cloud.

IMS (Contain) (PennDOT): IMS is the primary language used to build mainframe user interfaces and transactions handling data stored in IMS database. IMS and related tools are still supported to continue maintenance on legacy mainframe applications, but new development has moved toward replacing these applications with a combination of custom developed web and mobile applications, and COTS or

SaaS products, where applicable. To facilitate this modernization, IMS transactions can provide the basis for services supporting web and mobile applications, exposing legacy IMS business logic and data access through MQSeries messaging, IBM ACE, and IMS Connect Integration Services.

COBOL (Contain) (PennDOT): COBOL is the primary programming language underpinning IMS applications and JCL batch programs. COBOL and related tools are supported to continue maintenance of legacy systems. New business batch development has moved to Java, .NET, and other more modern platforms on-prem and in the cloud.

JCL (Contain) (PennDOT): Job Control Language (JCL) is the primary control language for mainframe-based business and code promotion batch programs. While JCL and related tools are supported to continue maintenance of legacy systems, new business batch development has moved to Java, .NET, and other more modern platforms on-prem and in the cloud, or to ETL programs such as Informatica or

Azure Data Factory. JCL-based routines are used to move data from or to IMS DB, DB2, and files and handle FTP of files between other internal systems and external partners. Tivoli Workload Scheduler

(TWS) is used to schedule, orchestrate, and monitor the results of JCL routines.

LOW CODE/NO CODE PLATFORMS

Technologies with limited stacks that enable faster code to delivery for customers by using pre-built templates and use cases.

Domino (Contain) (PennDOT): The Domino platform is currently supporting enterprise-level business critical operations with complex workflow, notification processes, and reporting. These solutions contain data classifications that include PII and sensitive employee data, and can support public, anonymous users and IAM through Active Directory.

SharePoint (Current) (DCED, PEMA, PennDOT): SharePoint is used for collaboration based, low code needs with minimal workflow and reporting. It can be used to implement enterprise-level business critical operations but may not contain data classifications that would include PII, credit cards, or sensitive employee data. Public, anonymous access is not supported, but IAM implementing proprietary

SharePoint user lists integrated with Active Directory is supported.

A decision tree for when to use SharePoint can be found here (available for Internal users): SharePoint

Decision Tree IED DC.pdf (pa.gov)

Power Apps (Emerging) (DCED, PEMA, PennDOT): Microsoft Power Apps or Power Platform is a suite of apps, services, connectors, and a data platform (Microsoft Dataverse) that can be used to build custom business apps with minimal code. This platform is approved for use by the Enterprise but is not currently in widespread use in the IEDDC. It is not currently recommended for public-facing, high volume apps; rather, it seems best for relatively simple internal or back-office workflows or business processes that connect to SharePoint or other existing data stores.

PATTERNS

SPA (Current) (DCED, PEMA, PennDOT): Single-Page Applications (SPA) - web applications that load a single document and then update the body content of that single document via JavaScript APIs such as

Vue – have emerged as the preferred pattern for developing web applications at the IEDDC, replacing traditional server applications implementing JEE or .NET UI functionality. These applications, while supported on-prem, are now typically deployed along with a Java Spring Boot or .NET service layer hosted in Azure.

PWA (Current) (DCED, PEMA, PennDOT): Progressive Web Applications (PWA) - applications built on the same web technologies as SPAs, but that can also be installed and run locally on all desktop and mobile devices that have a browser - have been developed when both online and offline functionality is being implemented from a single codebase. Progressive Web Applications may strike an appropriate balance between traditional web applications and native mobile applications when seeking cross-platform support. These applications, while supported on-prem, are now typically deployed along with Java

Spring Boot or .NET service layer hosted in Azure.

MPA (Current) (DCED, PEMA, PennDOT): Multi-Page Applications (MPA) – Traditional web applications comprised of many web pages. Specific patterns used include MVC (Model-View-Controller), MVP

(Model-View-Presenter), MVVM (Model-View-Viewmodel), etc. This is often used for moderately sized applications rapidly developed with a need for session state maintenance. Currently these are primarily developed as JEE or .NET Applications hosted on-premises in JBoss and IIS, respectively.

FRAMEWORKS

Vue/Angular/React (Current) (DCED, PEMA, PennDOT): Vue, Angular, and React are JavaScript or

TypeScript frameworks and libraries being used independently or in concert to build modern, reactive, and accessible user interfaces for web and mobile platforms. Specifically, Vue-based single-page or progressive web applications with Java Spring Boot or .NET microservices backend has emerged as the

IEDDC’s preferred pattern to build scalable cloud-native applications.

ENTSS (Contain) (PennDOT): ENTSS is a custom-developed, multipurpose Java library, included as a component in Java web applications to streamline implementation of Business Rules, General Purpose https://spportal.penndot.pa.gov/HelpDocuments/SiteRequisition/SharePoint%20Decision%20Tree%20IED%20DC.pdf https://spportal.penndot.pa.gov/HelpDocuments/SiteRequisition/SharePoint%20Decision%20Tree%20IED%20DC.pdf

Codes (GPCs)/configuration, Alerts, Authentication, and provides custom web page tags for common UI elements. This framework uses DB2 to house its supporting data.

MapKit (Current) (DCED, PEMA, PennDOT): MapKit is a native framework inside of Swift used for mobile applications. MapKit enables developers to display map or satellite imagery, show coordinates, and annotate locations with custom markers or pins.

PDFramework (Contain) (PennDOT): PDFramework is a custom-developed, multipurpose Java library, included as a component in Java web applications to streamline the implementation of user authentication and authorization, data access, and application configuration. This framework uses a DB2 database to house its supporting data.

PDJF (Contain) (PennDOT): PennDOT Java Framework (PDJF) is a custom-developed, multipurpose Java library, included as a component in Java web applications to streamline implementation and externalization of Application Configuration, General Purpose Codes (GPCs), Business Rules, User

Authorization, Error Handling/Logging, and more. This framework depends on an Oracle database to store its supporting data. It also provides its own administrative web application (PDJF Admin) to allow users and development staff to maintain this supporting data and configuration for all development environments.

SwiftUI (Emerging) (DCED, PEMA, PennDOT): SwiftUI is a framework used within Swift applications for building iOS user interfaces.

REUSABLE COMPONENTS

CASA (Current) (PennDOT): CASA is an on-prem Rest service developed to expose fundamental functions of the PDJF library as a service - including Expression Codes, Condition Codes, and

Authorization – allowing applications to use these functions independent of the UI implementation. It leverages the PDJF library itself and its associated Oracle database.

Shared Services (Current) (DCED, PEMA, PennDOT): Shared Services is a multifunctional SOAP service, offering such services as Business Rules, GPC codes, Email repository, Application Config maintainer, and

Municipality lookup. Shared Services is an on-prem service that leverages the ENTSS library itself and its associated DB2 database.

UNIT TESTING

Unit Testing Frameworks (Current) (DCED, PEMA, PennDOT): Unit testing frameworks are used such as

NUnit, XUnit, and MSTest for .NET applications, JUnit for Java applications, and JEST and Vitest for

JavaScript frameworks. For Angular, Jasmine is widely used. XE Framework and Swift Testing may be used for Swift applications.

SOLUTIONS

COTS (Current) (DCED, PEMA, PennDOT): Commercial Off-the-Shelf (COTS) in our context denotes publicly available, third-party developed, business software that is hosted and managed on

Commonwealth resources. IEDDC currently hosts and manages a variety of business solutions both on-premises and in the Commonwealth’s Azure instance, depending on the model best suited to the software and use case. COTS software can be both a consumer and provider of enterprise data and services through a variety of integration methods throughout the enterprise stack. COTS is preferred over custom development, where appropriate and without customization. Procurement of COTS software is managed through our ServiceNow system and includes a review by the GRC (Governance, Risk, and Compliance). The GRC’s initial review may lead to a request for an IT Vendor Risk Assessment.

SaaS (Current) (DCED, PEMA, PennDOT): Software-as-a-Service (SaaS) in our context denotes software that is not Commonwealth hosted and is managed – patches/upgrades, backups, availability/disaster recovery, etc. - primarily by the software provider. A SaaS solution can be both a consumer and provider of enterprise data and services through a variety of integration methods throughout the enterprise stack; however, please note that all SaaS or non-Commonwealth hosted solutions and their integrations…