Architecture Challenges in Government Agencies – Part II

Dipa Birdi, Senior IT Consultant

January 9, 2020

In Part I of this article Architecture Challenges in Government Agencies – Part I, we looked at the challenges of establishing a successful architecture practice within a government agency.  Part II of this article aims to examine solutions, approaches, and best practices to overcome common architecture challenges. Notably, the solutions may be broadly applicable to private enterprises and corporations, and not just to government agencies.  So, how do we resolve these challenges and overcome the traditional barriers to establishing a successful architecture practice?  Often, the fundamental causes of architecture issues within an organization stem from its outdated or inefficient IT practices, poor culture, and/or uninformed leadership. The inherent overlap between those classic issues means that these challenges cannot be addressed singularly and in a vacuum. Instead, a multidimensional approach ought to preferably be implemented to enable the organization to realize the benefits of an architecture team that can ultimately deliver optimized enterprise solutions.

For an organization to build and retain the IT support it needs, it is imperative that IT leaders are not only skilled in technology but are also adaptable and collaborative.  The organization expects IT to understand and appreciate its business operations and capabilities. It also expects IT to be accountable for the services it provides, often without appropriately communicating its requirements, if it communicates its requirements responsibly at all! Strangely enough, the business expects the world from IT, yet simultaneously will put up roadblocks so that IT and their architects can’t deliver optimized and enterprise solutions that align with the collective business requirements of the organization. This problem is better understood by dissecting it into the following discrete roadblock subtexts.

I. Erosion of Trust and Confidence in IT

Establishing business trust and confidence in IT and IT Architects should be a paramount priority on the list of any VP of IT/CIO.  It must be realized and accepted by VP of IT/CIO that this is an arduous task and may take several years to show value.  This is particularly important given the current challenges of our industry, which is modelled on past experiences of either undelivered and/or inconsistent architectural teams/practices.  In the distant past, IT used to be a trusted partner and respected by the business community as a valuable aid to improve business, both in public sector and private organizations. The concept of IT as a trusted business partner has weakened considerably, in part due to the now pervasive credibility issues both within IT Architecture and in the broader IT community.

Although IT Leaders have generally presumed that business expects everything from IT, the reality is that this is unlikely to be the case.  In fact, business users don’t expect much from IT and in many cases, IT has had a long leash over the years without delivering in the eyes of the business. Considering the growth of “shadow IT” groups and technically savvy business users, many times business has had to construct its own solutions (IT has no resources and/or higher priorities) … so eventually, they stop asking IT for help.  Of course, this results in technology sprawl, duplicate siloed applications, and increased technical debt.

The most obvious signs of the erosion of trust and confidence in IT include:

• • • Poor IT leadership, workplace culture, etc.;
    • IT outsourcing to make IT budgets look good while providing a lower standard of service;
    • Rapid and/or haphazard growth, and in many cases, the endorsement of “shadow IT” groups that don’t have to answer to IT, nor follow any of its standards and practices;
    • Failed historical attempts at Enterprise Architecture practices; and
    • Historical patterns of failure by IT to show their value and/or failure of architectural practices to evolve at the speed the business needs to.

It is critical that the VP of IT/CIO has a clear understanding of the business objectives and understand whether the company is innovative, dynamic, transformative or static.  This determines the role of IT within the company and allows the VP of IT/CIO to define an appropriate IT organization structure.  The VP of IT/CIO also needs to have a clear vision of each IT function and ensure that accountabilities are clearly defined and communicated to IT leaders. 

II. Role of Architecture Group

If the architecture group is reporting to the VP of IT/CIO, the VP of IT/CIO must understand that the architecture group is a pivotal cog in IT.  Then, the VP of IT/CIO must be committed to using the architecture group and believe in it as a value-added service.  The role of the architecture group must be clearly articulated to the IT Leaders as well as the CEO and other executives. The articulation of the role to leadership then enables the architecture group’s accountability and authority to be clearly defined and documented, which is another must. This will ensure that architecture group can address the business objectives and recommend the necessary guidance toward meeting business objectives. 

The IT industry has allowed the title of “architect” to be applied so broadly that it lacks definition and meaning, such that the responsibilities, expectations, and skills for the architect role are inconsistently defined and applied. Many job postings and positions that are described as architecture roles expect little by way of formal architectural training, practice and methodology, skill, strategic thinking, or holistic rationale.   We commonly hear tongue-in-cheek comments like “What does an architect do anyway?”, complete with the eye rolling for effect.

Agile, DevOps, and Emerging technology have also contributed toward challenges in establishing Architecture Practice within organizations. Consider the following:

• • • The trending popularity of Agile methods and the concurrently loose implementation of these methods.
    • Generalized approaches that encourage speed, low cost, and cut corners, at the expense of quality solutions, which often means excluding the actual architects due to the perception of “slowing down the process”. This is consistent with issues relating to (you know, with issues like holistic views, common approaches and patterns, reusability, sustainability, interoperability, evaluation of long-term operational costs of a solution, standardization, etc…)
    • Increasing awareness and technical skill in the general population, such as – low/no code platforms, automation platforms, wizards, cloud services (eg. O365 with all the related technical capabilities it offers). More people are interested and capable of defining solutions with a myriad of inexpensive technologies that are readily available.  Who needs to wait for an architect to design a solution anymore?

III. Lean Organization

A matrix management structure should be avoided to ensure that fewer leaders are held accountable to deliver IT services to the business in an effective and inexpensive manner.  Complex matrix organizational structures typically introduce duplicity, more bureaucracy leading to a lot of churn and missed opportunities for the business.

IV. Operational Funding

An inadequate budget for the architecture group invariably leads toward making the group superfluous and ineffective because they don’t have adequate resources to do their job. Organizations often fail to recognize or accept that the architecture group is primarily an operating expense. For that reason, the funding for the architectural group needs to be determined upfront using a discretionary funding model.  As the role of the architecture group is to provide their services for both operation and capital initiative, it is necessary to understand how their services will be funded for both.  All capital initiatives must include the necessary funding for their services by working with the architecture group leader.  The Architecture Group leader can assess the level of involvement on an ongoing basis. 

V. Clearly Defined Engagement Model

It is a key requirement that the organization defines how and when Enterprise Architects (EA) and Solution Architects (SA) interact with other organizational units. Lack of this definition is a frequent complaint of the many and ends up fueling the negative perception of the architecture group. For example, you’ve all heard the following: “Architects don’t know what they are doing; Architects live in an ivory tower; Architects are a bottleneck; I didn’t know I had to involve the architecture group”.  It’s no wonder other leaders or groups with insufficient knowledge and experience end up trying to fill the architect role. This leads to making incomplete decisions and providing solutions that end up costing the organization more in the long term.

VI. IT Governance

It is necessary to establish IT governance.  Many companies don’t have the determination, rigor, and staff (cost) to effectively define and govern architectural standards and patterns and then oversee the tactical side of solution delivery to ensure implementations stay on track to match architectural standards and align to IT and architectural strategies.

VII. Training

All EAs and SAs must be educated on the business operation and their capabilities, as well as the supporting technology stack. They should have a strong understanding of the business at an enterprise and unit level so that they can create and communicate the enterprise business capability model. This assists in obtaining trust within the business community and promotes the architecture group as a partner that understands their business, rather than as a lone wolf/outsider.  Inherently, EAs and SAs are generalists due to the wide scope of business and technology within the organization.  The EAs should be provided detailed training in more than one architectural domain.  They should also be provided the necessary training to understand financial models supporting Return on Investment (ROI) and Total Cost of Ownership (TCO) for transformative initiatives.  Conversely, both business and IT leaders need to receive continued education on the architecture group’s role and services it provides.

VIII. Innovation Research and Development

The architecture group is responsible for being current on new technologies and therefore must continuously research and explore the development and changes in technology, as well as the impact on business.  Thus, it is imperative that they understand and are aware of any updates to the vendor’s product roadmaps.  The architecture group must also make the effort to understand how the business is changing and how technology is helping other companies in the same business sector and/or industry.

IX. Architecture Plans and Roadmaps

The architecture group must develop and maintain both technology roadmaps and future-state application landscapes to support the current and future needs of the business.  These architecture plans and roadmaps should include the underpinning technology, business applications, and end user computing. These roadmaps and the architecture plans must be adhered to by all solutions and updated regularly. Vendor technology roadmaps are critical in understanding how and when the technology is changing.  The architecture group must take into consideration these roadmaps and update their architecture plans and roadmaps to support their business needs.  Any changes to the infrastructure, application and processes can be identified by the architecture group and allow the delivery and operation teams to make the necessary changes. 

Summary

An architecture group can only be effective if it has the full support from the VP of IT/CIO and is empowered to do its job. They must be adequately funded to operate as a critical and pivotal unit of IT.  This means working with the business and understanding their requirements, and then aligning technology solutions at an enterprise level to meet business requirements across the organization.  This means that technology is shared and reused for the same and similar business processes and functions.  This means that government agencies cannot allow their various business units to operate autonomously and view their IT needs as specialized for their own purposes, such as HR and finance where shared-service models are not considered best practice. 

The integration between business processes across business units must be at the forefront by understanding everyone’s business needs collectively.  The business units must work with the architecture group, rather directly with their own vendors, to deliver IT solutions supporting business needs.  This stop the proliferation of incompatible technologies and increased cost to support and maintain the overall application landscape of the organization.  Although bureaucracy and the sheer size of government agencies is at the root of the problem, government agencies must take steps to operate within a controlled corporate structure and engage IT as a provider of enterprise-level solutions.  And this is where the architecture group can help.  The architects are very skilled and experienced professionals who not only understand the technology, but the value of a holistic view. Putting them in position to not only understand the technology but the business and their interaction with each other, empowers architects as trusted IT partners to the business.