Defining a 'GaaP' architecture - Government as a Platform, is considerably easier when you explore a possible real-world implementation, making many of the somewhat esoteric design principles much more tangible.
A great example is the Cloud Foundry offering from Pivotal, where Cloud Foundry is the PaaS implemented to build the Australian digital strategy and also Cloud.gov, enabling USA public sector development teams to build Digital Government systems faster and via standardized best practices, and where Pivotal offer a managed service for others wishing to build a similar 'Cloud Native' approach to business system development.
DevOps: Transforming Procurement for the Composable Enterprise
Although GaaP is naturally a technology heavy conversation it's actually non-technical aspects that offer the most illumination on the topic, especially for senior executives, most notably the overall organizational transformation in particular Procurement.
You might not have thought Procurement would be relevant to the software engineering scenario, but consider the broader context of IT they exist within and how much of the resource they use is bought in by the organization. When you consider the RFP (Request for Proposal) bidding process is the most common technique used for sourcing business applications for government, and that these can take months and years to conclude you can see how the two begin to relate, how one can act as a throughput bottleneck on the other.
In a Linkedin blog David Callner begins to explore how DevOps might be adopted in the public sector, noting how RFPs increasingly now feature a call for the use of Agile rather than Waterfall methods.
In particular he describes how RFPs act to collate large volumes of user requirements, a process which can take months, followed by months of supplier engagement to bid the RFP and then further months for contracts and implementation, stretching out over years beginning to end and unsurprisingly resulting in large failure rates.
In short it's a process of trying to consume a large elephant and so instead the better approach is to break up the challenge into 'bite size chunks'. David also describes how in some scenarios they instead work more collaboratively with agencies, to capture requirements into Agile Product Backlogs and organize these into Epic work streams, that can be worked on continuously from beginning through end.
The PaaS approach compliments and accelerates this approach by baking the procurement into the technology, empowering developers to self-serve their own requirements, and critically, employ the use of pre-developed templates and module integrations. The future of enterprise business systems is no longer buying one monolith app from a single vendor, but instead composing together modular solutions that span across internal legacy apps as well as across the XaaS spectrum.
DevOps: Teams and Roles
The reason Pivotal is such a good example of this scenario is not just that they offer a managed implementation of the PaaS, but also bring considerable expertise in the surrounding Cloud Native practices, such as DevOps, Microservices and containers et al.
A great example is this Medium article which explores the dynamics of new team models for DevOps, defining a number of specific roles and how they interoperate, such as:
- Product Owner/Product Manager
- Data scientists
The article also goes on to describe a detailed PaaS architecture:
Integrated Architecture for Digital Government
Governments can adopt wholesale this Cloud Native approach off the shelf, as it is a common, generic model for increasing the agility and throughput of any software team.
It can then be further tailored for the public sector scenario through defining a second 'Value Line' as shown in the diagram, from the top upwards above the apps, to represent a further layer of government-specific modules and tailorings. For example integration of federated identity services such as the Gov.UK Verify Identity service.
This will offer government agencies an entirely new paradigm for addressing the most fundamental of their enterprise IT challenges: Joined up, integrated working and sharing of data across multiple agencies and systems. Rather than hard-coding yet another citizen authentication process into another application, this approach instead calls upon shared, component services such as Identity Authentication.
For example one scenario might modernize a legacy CICS platform, that includes it's own proprietary CICS-based identity authentication mechanism, to a new Java platform using the Spring framework. As part of this they could isolate out this function and made it instead accessible to SAML WS-Security open standards-based methods, via the Spring Acegi security system.
This would also provide the foundations for web enabled 'Rich Web Applications', built via an AJAX-enabled widget set such as Dojo, where they can establish a trust relationship via a "Secure SOAP Proxy", enabling secure sign-on via new web applications.
iPaaS and Microservices
This is a complimentary and accelerating architecture for the overall Cloud Native approach. For example in this Slideshare presentation Microsoft describe how the PaaS layer will evolve to become an 'Integration PaaS', ideally suited to integrating business systems via microservices.