Commentary: For Public-Sector Solutions, Hybrid May Be the Future

With the advancement of technology solutions into cloud operations, many questions arise. These questions have to be asked in order to choose the best option — cloud or on-premise solution.

I see a hybrid model coming into play in the public sector, depending on answers to solution requirements — for instance, performance, security, data accessibility or interface requirements. When data warehouses and applications were housed on-prem, many of these questions never came up before, or answers were assumed by knowledge of the local environment.

The role of “System Architect” is rising to the front line again, with a need to design solutions and their ecosystems. Determining whether or not a system should reside in the cloud will largely be based on the architectural requirements of a solution that make implementation successful. The system architect must analyze these questions: Who, What, When and Where? The “How?” comes after these W’s are answered:

— Who are the system users?

— What are users going to be doing — reporting, access, integrations, etc.?

— When will these users perform these tasks, and what load requirements will they have?

— Where are these users or targets of interfaces?

Another major part is physical security, the loss of which changes the game and requires a higher level of both software technology and trust in a solution or cloud provider(s).

Most agencies require security checklists to ensure that citizen data is protected to the best of standards (see the NIST Cybersecurity Framework). One major requirement is that most government solutions require the host to reside in the United States. This usually includes any support staff for the host provider as well as any contractors used by the vendors involved, with a few written exceptions and sole-source contracts.

Other concerns are how to embed local security and authentication. Newer standards using Security Assertion Markup Language (SAML) or OpenID Connect allow for Identity Providers (IdPs) to synchronize with directory solutions, such as Microsoft Active Directory. Using Okta as an IdP with an OpenID Connect implementation, one can inject data from Active Directory custom attributes into Microsoft Core applications, built in Microsoft Identity Framework, where Active Directory libraries have been removed. These are extremely important methodologies as they take the old-school LDAP persistent connectivity away, translating authentication into transactions.

One big issue when deciding to recommend a product or solution is what accessibility the agency has to the data. For the longest time, in computing, it was all about moving away from proprietary ways. With cloud solutions, unless APIs or other integrations are provided, I see software and solutions moving back into this proprietary, locked-down realm. APIs or programmatic accessibility to the data should be, in my mind, a contractual requirement. Standards should be developed and enforced to ensure portability and similar data payloads, typically in JSON format.

APIs, or other programmatic means, provide ways for a system to remain flexible to scope changes and easier to integrate with other solutions. These scope changes or integration requirements are questions not of “if” but of “when!”

This is how reporting integrations across multiple solutions can be accomplished: gathering better metrics and analytics with other systems. Point, requirements and scope will always be moving targets. Architectural agility becomes a new environment mandate.