Dipa Birdi, Senior IT Consultant
November 18, 2019
Establishing a successful architecture practice in a government agency is a real challenge to say the least. Such agencies tend to operate a matrix environment and the focus on delivering IT change is directed towards a solution that meets immediate needs. Everything tends to be operational and tactical while strategic significance takes a backseat. The IT architecture team loses sight of defining enterprise guidelines, principles, and technology & application roadmaps to meet business goals. Thus, the Solution Architects are pigeon-holed to deliver a solution that meets the immediate needs of a project. All changes to the business application are left to the development teams while application roadmaps are ignored. This only ends up adding technical debt and high maintenance & support costs.
Being a government agency, IT is saddled with the responsibility of being compliant by considering all the rules and regulations of various regulatory bodies. Compliance based on regulatory requirements is a business rather than an IT responsibility and accountability. All regulations that need to be considered are primarily handled by the business units, which in turn are supported by the IT function. Many times, a project may be initiated to identify and make the necessary changes to the business applications. However, Subject Matter Experts who understand the impact of regulatory requirements are not always included. In a perfect world, resources from both the business and IT are expected to understand and consider regulatory requirements in the deployment of a solution. Unfortunately, the IT architecture team has poor understanding of regulatory requirements which leads to establishing duplicate controls and a lot of manual labour. This is especially detrimental in organizations where both business leadership and IT architecture are not proactive in meeting regulatory requirements as they change.
Organization Structure
One of the key factors responsible for these challenges is how the government agency is organized. By operating in a matrix environment, individuals perform their work within a very delineated organizational structure with little cohesiveness between them. Some people refer to this as a bureaucracy or bureaucratic structure. This means that communication and workflow across IT services is not always present. Thus, project management, architecture, development, application support, etc. are not aligned when it comes to deploying IT solutions and supporting the business.
With such a bureaucratic structure in place, each IT service focuses on creating its own practice objectives, accountabilities and responsibilities through the definition of respective processes, deliverables and engagement models with others. Each IT service defines its practice deliverable templates which may or may not include architecture-related information. This makes any IT architecture services and deliverables ineffective. And worse, the government agency ends up with multiple and unrelated IT architecture deployments resulting in an incompatible application environment. Process and system integration become a nightmare as different parts of the business operate in silos.
Being a government agency, all of IT is challenged when it comes to being compliant to different regulatory bodies. That’s the irony of the challenge itself as the government agency is not empowered to adhere to regulations across the enterprise. The business community may take it upon itself to handle the compliance needs that are impacting their immediate business requirements. Other business units may not be engaged at all leading to being compliant through omission or ignorance. The business community may primarily engage IT services such as Service Desk, Application Support and Security to assist in addressing compliance needs. In some cases, a project may be initiated to address changes to the business applications and infrastructure, which sends IT costs through the roof. The IT architecture team is often ignored, and incapable a lot of times, which leads to addressing the regulation needs independently. In this case, the holistic approach, which is often provided by the IT architecture team may not be used resulting in duplicate controls. The guiding principles established by the IT architecture team become ineffective and lack the governance to establish architecture standards and policies.
Project Delivery
All changes to the business applications are performed as a result of major initiatives or by the product teams focusing on backlog items. The product team tends to employ resources from PM, System Design, Development, BA, QA and Application Support groups when implementing changes in the backlog. When engaged on major initiatives, the Solution Architects are employed along with the above-mentioned teams. The Enterprise Architecture engagement to direct solution options and its compliance to architecture principles is usually at the discretion of the project managers or the business sponsor, which means that EA is rarely engaged.
Projects are pretty well left on their own and allowed to do their own thing. It’s almost like there’s no PMO, but that’s not the issue. The issue is that there is no architecture governance to guide solution deployment and ensure that the solution is aligned to the overall architecture landscape. During the project initiative, each IT services is responsible for creating the necessary artifacts which meet the immediate needs of the project without understanding architecture alignment or impacts to the rest of the business. Thus, the project team and its supporting IT services only deal with the individual requirements of a business area and the changes it has requested without emphasis on the overall architecture of business applications.
The more serious issue is that IT Governance is not established, and architecture controls enforced. Unfortunately, this ends up with other organization units assuming the accountabilities and responsibilities leading to substandard or incomplete solutions. In other words, they are “doing someone else’s job”.
Operational and Tactical Focus
As every change delivered by the IT service teams is to meet the immediate needs of the business, the focus is very much operational and tactical. This unfortunately leads the Architecture group to lose site of defining the guidelines, principles and technology and application roadmaps to meet the business goals at a strategic level. Thus, the Solution Architects are engaged to only deliver solutions that meet the immediate needs of major projects. All changes to the business applications and infrastructure are left to the project teams to define and application roadmaps are ignored since there is not strategic direction. Although the Solution Architects may be doing a good job of addressing the various aspects of architecture, which are related to the immediate needs, the overall holistic views which are normally maintained by Enterprise Architects are ignored or partially completed. Let’s face it, many government agencies don’t even have Enterprise Architects. What good are they if strategic direction and enterprise application alignment are not perceived as being important?
At the end of the day, each business unit looks after its own interests. They operate autonomously and views their IT needs as specialized, even in areas such as HR and finance where shared-services models are not considered best practice. The integration between business processes across business units is either not considered or missed due to not understanding the other’s business unit needs. In most cases, the business units work directly with IT vendors and do not involve the IT architecture team. This only leads to the proliferation of incompatible technologies and increased cost to support and maintain the overall application landscape of the organization. Bureaucracy and the sheer size of government agencies is at the root of the problem while bureaucracy is a culture that cannot easily be changed. And this is even more of a problem when the government agency operates within an uncontrolled corporate structure.
Mr. Dipa Birdi is a Senior IT Consultant affiliated with IT Architects in Calgary, Alberta, and has worked in various industries, including Energy, Banking, Payment Processing Finance, Telecommunications, and Retail. Dipa’s most recent assignments are Manager of IT Solution Services and Software Development at AESO, IT Advisory Manager at Price Waterhouse Coopers, Director of Software Development at Forzani Group, and Director of Enterprise Integration Architecture for Elavon Inc in Atlanta. 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, Dipa can be reached at info@itarchitects.ca or 403-829-3164.
