Public vs Private Sector Architecture

Ade Odusote, Senior IT Architect

October 15, 2018

As in the building construction industry, the scope of IT Architecture is broad; Private vs Public, High Level vs Detailed, and Technology vs Business are just a few examples. From a functional perspective, today’s organization applies this Architecture in different areas, including data, application, and technical areas, to start with. 

Similarities

These Technology Architectures, i.e. Data, Application, and Technical Architectures, are typically distinct and discrete, with some cross over in their interactions with other Architectures. As an example, the Application Architecture needs insight into the Data tier for a complete understanding of the business requirements. However, given the similarities in business processes across sectors, these Architectures are usually sector-agnostic, e.g. the Application Architecture of a Cloud-Based Time Tracking System can be easily replicated from the private to public sector, and vice versa.

Solution Architecture, on the other hand, is primarily concerned with the design and delivery of business solutions to meet well-defined business and/or technical requirements. In doing this, the Practitioner requires technical skills, and significant insight into the other Architectures, to enable collaboration with all domains of the Architecture continuum. Usually overlooked are the leadership skills, which the Practitioner requires to provide technical leadership of project deliverables in concert with the PM, Enterprise Architect, Developers, Business Analyst, etc.

Solution Architecture artefacts and skills are also largely transferrable from one sector to the other. As an example, a Solution Architect delivering a site mapping solution in the oil industry and one doing the same for a municipality will apply similar amounts of rigor, discipline, and collaboration to come up with a solution pertinent to their respective business domains. The most important differences will be in the management of the triple constraints of Schedule, Cost and Scope, which have an impact on Architecture deliverables, but are the accountabilities of the PM, with the Solution Architect as a significant stakeholder.

Differences

The main difference in IT Architecture development between the public and private sector is in the area of Enterprise Architecture (EA). The public sector’s primary stakeholder are the Citizens, who are concerned with transparency and accountability in a Government that can provide quality service delivery with less resources. Doing more with less requires a high level of operational efficiency, and a main limitation to attaining this in IT delivery is organizational silos, which IT Executives in the public sector are continually seeking to breakdown, for obvious reasons. The siloed organization is rife with redundancies: multiple systems being used for the same function across different business units, disconnected systems of records with their underlying support infrastructure and cost, little communication between these different systems with an attendant brittle workflow and inefficiencies in knowledge sharing, little accountability and stewardship in data management leading to security lapses and breaches, and other ailments that keep the CIO up at night!

For the public sector, the role of IT Architecture, especially Enterprise Architecture, would thus focus on integration and consolidation of disparate systems, establishment of end-to-end business process flows, definition of systems of records, reduction in cost and complexity of business processes via application rationalization, and consolidation of this diverse environment by focusing on better governance and more rigorous standards.

The business case for Enterprise Architecture in the public sector would illustrate the need for consolidation, integrations, portfolio management, and business reengineering, any of which would carry a significant price tag. To alleviate this, the Enterprise Architecture function would need to work with the business domains to develop a roadmap that gradually and incrementally aligns the government strategies, plan and resources to their technology assets, most probably standardizing technology by functions rather than by departments. Target deliverables of this roadmap will include the establishment of system and data governance practices, the definition and adoption of architecture principles (such as cloud-1st or buy before build) to manage payback and ROI, as well as the provision of management artefacts that show alignment of strategic business plans to technology investments.

Summary

The benefits derived from applying Enterprise Architecture (EA) at the public sector are easily realizable in the private sector. Although efficiencies can be derived by EA in both, we should remember that the private sector is largely profit driven. Thus, while EA efficiencies will drive cost down, they will not necessarily increase revenue. For the private sector, one of the primary functions of EA in driving revenue growth will thus be to “shepherd” the adoption of new and emerging technologies (e.g. Cloud Analytics, Mobility, AI, etc.) without compromising the security and integrity of existing business flows and systems. EA in this capacity will serve as one of several strategic planning tools available to the business executive that will align business drivers with technology.

After practicing in both the public and private sectors for two decades, our findings are that with the exception of EA, the Architecture practice is mostly transferable across sectors. In the public sector, EA is largely concerned with increasing efficiencies, i.e. doing more with less, while in the private sector, EA strives to do more with less AND additionally enable the enterprise to take advantage of emerging technologies without compromising the integrity of the enterprise. For those public sector organizations that are crossing the boundaries from being just cost centers to being profit centers, Enterprise Architecture and the other domains of the Architecture continuum provide more or less the same benefits: increase operational and system efficiencies, while taking advantage of new and emerging technologies to drive sustainable growth.

Mr. Ade Odusote is a Senior Domain Architect with IT Architects in Calgary, Alberta, and Mr. Bob Ivkovic is a Principal with IT Architects. IT Architects (www.itarchitects.ca) is an information consulting firm specializing in business process optimization, system evolution planning, and the deployment of leading-edge technologies. If you require further information, Ade and Bob can be reached at info@itarchitects.ca or 403-630-1126.

Leave a Reply

Your email address will not be published.