“Architecture” is a set of disciplines to organize and simplify complex things, and “governance” is a process for managing and controlling the building of and maintaining things. While it is obvious that both are necessary, which “architecture” and what form of “governance” are anything but obvious.
To make architecture governance successful, experts from Forrester and Gartner are quick to point to the importance of “getting executive approval,” for giving it “teeth,” and for “communicating it” to the broad audience.” However, this article will not regurgitate the same old tired message for two reasons. First, it doesn’t help anyone determine what architecture governance should be and, secondly, it is simply not true.
In fact, the message from the “so called” experts is most likely to achieve a form of architecture governance that may both raise the cost of providing automation services and bring the development process to a grinding halt.
If someone can only achieve something by imposing it against the will of others, then it may not be the best solution.
In contrast, we are going to enter into the core issues of what successful architectural governance is and the most effective route for getting there.
The Value PropositionThe way to determine useful architecture and the ideal form of governance is not easy. If it was easy, everyone would have it by now. But first, what exactly are the benefits we seek?
When an appropriate balance of architecture and governance is achieved the business gets automation that addresses their needs in a shorter amount of time than it would otherwise take with less complexity at a lower lifetime cost.
In addition to the aforementioned benefits, for architecture and governance to be successful, the business needs be assured of three additional things that they will get in return:
Local Architectural GovernanceThe first thing that is not negotiable is that the needs of the business must continue to be met. In a large conglomerate, the ideal approach for gaining cooperation is to offer value using a “non-intrusive” approach.
Some organizational structures are more challenging to operate within and across than others. At the top of that list are the organizations that employ a “federated” management structure for the company, where multiple lines of business exist across a corporate conglomerate, much like states do across the United States.
Similar to local, state, and federal government, the multi-tiered system of management in a federated model exists at the project level, the “line of business” level, and at the “enterprise” level. The challenge is to identify a “non-intrusive” approach that protects the interests of stakeholders at the “line of business” and “enterprise” levels that are unaware of what may be happening at the project level.
The key to achieving “non-intrusive” governance is to foster an approach that:
- Determines every solution as close to the business need as is possible
- Maximizes the ability of local projects to self-govern
- Addresses business needs without unnecessary interference
- Makes use of clear guidelines, standards, and frameworks that steer application teams away from problem areas
- Avoids the budget and calendar resources that are typical when intervention is routinely imposed
The primary feature that makes a “passive” form of architecture governance possible is having standards, guidelines, and architectures for the “line of business” already in agreement with the architectural artifacts of the “enterprise.”
To create standards, guidelines, and architectures for the “line of business,” ideally the “enterprise” can participate with the “line of business.” In this situation, the objective is to establish the architectural artifacts that specifically address the needs of the “line of business” while leveraging the standards, guidelines, and architectures for the “enterprise.”
The architectural artifacts of the “enterprise” can be established by adopting and leveraging the best guidelines, standards, frameworks, blueprints, and reference architectures from the various “lines of business.”
Once the “enterprise” and “lines of business” establish their architectural artifacts, the only time when an architectural governance body is needed is when conditions are triggered that indicate that the interests of another stakeholder outside the project may be impacted.
The conditions that trigger local architectural governance then act as the “entrance criteria” to the architectural governance body of the “line of business.” It is critical to all stakeholders that these “entrance criteria” be carefully devised so that they are easy to understand, and effective at identifying when the interests of stakeholders.
Stakeholders outside the project team may include the CFO, CIO, CTO, auditors, regulatory bodies, or any other product line owners anywhere across the company.
Sample entrance criteria for “line of business” architectural governance body should stipulate criteria that:
- Affects more than one application
- Alters any specific architecture (system, software, workflow, hardware, security, application, network, data, or future state architecture)
- Creates a single point of failure
- Requires long-term funding commitments
- Impacts credit risk or regulatory risk
Using this approach, the project team would be free to design solutions that comply with the standards, guidelines, architectures for the “line of business” and “enterprise.”
As soon as it is determined that the project team may impact a stakeholder that is not represented on the project, the project team takes the issue to the governance body, which should promptly gather the appropriate stakeholders together to provide the level of coordination required.
If the affected stakeholders extend beyond the “line of business,” then “enterprise” architectural governance may be needed in order to promptly bring the issue to their attention.
“Enterprise” Architecture GovernanceEvery effort should be made to afford the “line of business” the opportunity to self-govern. Circumstances, however, will arise when the interests of stakeholders outside the “line of business” may be at risk. These stakeholders include the “enterprise” CFO, CIO, CTO, auditors, regulatory bodies, or product line owners of another “line of business.”
Therefore, just as “entrance criteria” would alert the project team to engage architectural governance within the “line of business,” another set of “entrance criteria” would be needed to alert the architectural governance body of the “enterprise.”
Sample entrance criteria for “enterprise” architectural governance should stipulate criteria that:
- Requires the acquisition of technology that is not already approved for use across the company
- Can impact more than one “line of business”
- Alters any specific enterprise architecture (e.g., system, software, workflow, hardware, security, application, network, data, or future state architecture)
- Impacts global financial exposure to risk or regulatory compliance
- Requires higher levels of enterprise infrastructure funding or support
When determining the entrance criteria for architecture governance, it is critical to consider the relevance of Sarbanes-Oxley1 and Gramm-Leach-Bliley2. Financial accountability is no longer limited to the CIO and or CFO of the particular line of business, especially within a financial conglomerate.
Whenever there is even the least possibility that any C-level officer of the enterprise may face fines and or imprisonment, it is advisable to promptly engage “enterprise” architecture governance in order to bring the appropriate stakeholders to the table.
Adhocracy Instead of BureaucracyThe purpose of “non-intrusive” architecture governance is to protect the interests of stakeholders without the costs associated with:
- Headcount to support a bureaucracy
- Delays imposed by a bureaucracy
- Overhead of additional signature cycles and micromanagement
To achieve “non-intrusive” architectural governance, each architectural governance body is best structured as an adhocracy, in contrast to a bureaucracy. An adhocracy is an organic structure whose members are determined on an “as-needed” basis chosen for their skills to meet the demands of a dynamic business environment.
Consistent with the approach of an adhocracy, application development teams would follow the guidelines, standards, frameworks, blueprints, and reference architectures of their “line of business,” while monitoring a set of rules, referred to as entrance criteria, to determine whether conditions warrant engaging an architectural governance body. When this occurs the appropriate stakeholders would be promptly brought together to represent their interests.
As an example, indications that may warrant an application development team consulting architecture governance would be if they have a need to capture, or replicate any customer, financial, or medical data.
To make the process move as smoothly as possible when entrance criteria are triggered, it is recommended that a few basic artifacts be prepared and delivered in advance to help the architectural governance body readily understand the issue and have the appropriate stakeholders present:
- Business summary identifying the issues being addressed and the scope of the effort (PID)
- Identification of viable alternatives, their total cost of ownership (TCO), support model and return on investment (ROI)
- Potential business impacts outside their local scope of the project
In a less than ideal implementation, architectural governance can act as an impediment upon the organization. It can raise costs, delay development, and stifle change. As such, for architectural governance to be successful, it is not only essential that it be well led, but also it is important that those who require its services be prepared to represent the issues as clearly and concisely as possible.
As one would expect, the difference between a successful and unsuccessful governance body can be the difference between allowing its members to practice product “brand” zealotry versus ensuring “brand” agnosticism, between deploying experience that is monochromatic versus extremely diverse, between exclusion of versus inclusion of business stakeholders, or simply convening too infrequently or convening promptly when needed.
When architectural governance is in its optimal state it:
- Renders decisions as close to the project as possible
- Convenes promptly on an “as-needed” basis
- Selects members for the skills required
- Requires almost no budget
- Operates “passively” and “non-intrusively”
SummaryThe perils of operating without architectural governance may not be as evident to executive management as one would expect.
Depending upon the extent to which your industry is regulated, and considering the financial damages and fines that are plausible, as well as potential damage to brand reputation, operating without any form of architectural governance can be construed as reckless and irresponsible.
At the same time from a financial and competitive standpoint, it would be equally irresponsible to impose a form of architectural governance that will bring the rate at which IT delivers automation to your business to a grinding halt.
Architecture governance can be easy for project teams, “lines of businesses,” and the enterprise to adopt when it is clear that the result will be a healthy and competitive organization by using a “non-intrusive” adhocracy.
The degree to which architectural governance is required will seemingly depend upon the extent to which new development and change occurs within your environment. However, regardless of the amount of development or how knowledgeable and effective application designers and architects may be in your environment, the need to represent the interests of stakeholders across the enterprise cannot be overlooked.
Operating without architectural governance will most assuredly compromise the interests of the various stakeholders that are kept out of touch in the matters that affect their interests.
The old adage of “what they don’t know, won’t hurt them” is simply untrue.
When stakeholders remain unaware, their interests will most assuredly be violated for reasons of expediency.
As an example, it may be expedient to allow read access to production systems to replicate personal information of customers and employees into unprotected files in unprotected directories on unprotected disks for ad-hoc reporting.
If uninformed, stakeholders can never ensure that the appropriate decisions are made, such as those affecting the management of regulatory requirements pertaining to customer information.
The role of architectural governance is two things. Its architectures provide a set of disciplines that organize and simplify complex things, and its governance provides representation for the various stakeholders across the company.
Hence, the path to a successful and efficient form of architectural governance is simple.
- First, provide the necessary guidance in the form of guidelines, standards, and frameworks that steer the project teams away from controversial approaches.
- Second, operate passively to not intrude until entrance criteria have been met.
- Third, promptly assemble the appropriate skills and stakeholders to promptly render a consistent and responsible direction for the enterprise as a whole.
This article is the first of “The Governance Series” within “Architecture Made Easy,” and it is our hope that it may help determine the appropriate balance for your corporate conglomerate in architecture governance.
Please don’t hesitate to let me know which articles in the “Architecture Made Easy” series are useful to your organization. In addition, corrections, enhancements, and suggestions are always welcome and are requested.
[Architecture Governance – Attaining the Appropriate Balance is the 9th article in the Architecture Made Easy Series]
End Notes:
- The Sarbanes-Oxley Act of 2002 addresses financial assets, such as:
- Responsibility of executives to certify financial reporting
- Prohibition of “material off balance sheet transactions and omissions”
- The inability to produce records that would impede an investigation
- The Gramm-Leach-Bliley Act of 1999 addresses customer privacy, such as: