Every organization should have a vision for what that organization should be in the future. A well-run organization has a documented and approved strategy or business plan that provides a roadmap to take the organization from here to there. In the digital age, the road to any organization's future is paved with technology decisions. Therefore, it follows that making better technology decisions gets to that future quicker, cheaper, and more safely. A literal road has guardrails to keep you on the right path. In this article, we will discuss technology guardrails, which serve the equivalent purpose for this organizational journey.
Wikipedia provides a good working definition for a guardrail in a technology context:
an artifact that defines the boundaries in which technology change can be executed in a manner that is aligned with organizational strategy, risk, architecture, operational, and cybersecurity requirements."
Wikipedia
We previously explained what makes a technology decision better in Making Better Technology Decisions. A better decision:
Meets the specific business need
Aligns with the organizational vision
Aligns with the IT vision
Complies with the organization's risk appetite
Operates well in the organization's environment
In most organizations, meeting a specific business need receives all the attention and is the driver for most technology decisions. The business need is the immediate problem to be solved and that information is readily available. A technology guardrail provides technology decision-makers with the information and guidance needed to meet the remaining four criteria and make better decisions for the organization.
Self-Service Governance
Publishing guardrails empowers self-service governance. In an organization with strong, centralized technology governance, these streamline the governance process. Technology guardrails set expectations upfront, enabling people to do the right thing and avoid governance roadblocks later. Providing the governance criteria in advance helps decision-makers make better decisions. Applying governance criteria later at some formal checkpoint without providing expectations in advance, generates re-work and frustration.
Everyone loves self service!
In an organization with less centralized technology governance and more distributed decision-makers, guardrails are even more critical. Without them, it is even less likely that people will consider any criteria besides the immediate business need. In this type of organization, guardrails can make a significant difference, especially if the guardrails include references to the associated organizational benefits (the "why"). People find it easier to do the right thing if they understand why something is the right thing.
That benefit should highlight why aligning with a guardrail will result in a better, faster, cheaper, or safer journey or outcome. If you are unable to articulate that, then perhaps you should re-think the guardrail!
Common Technology Guardrails
Technology guardrails can take many forms, but here are some typical technology guardrails.
Guiding Principles. A guiding principle is a fundamental value that establishes a framework for expected behavior and decision-making. A guiding principle is broad and unspecific and provides directional guidance. e.g., Put the Customer First.
Policies. A policy is a statement of intent, implemented as a procedure or protocol. Policies are the internal laws for an organization, and since they can have legal implications for the organization, they are usually managed and enforced through a highly governed process. e.g., Information Security Policy.
Standards. Formally established requirements regarding technology products, product usage, and configuration. e.g., Netscape Navigator 8+ is the browser standard.
Strategies. A strategy is a general plan to achieve one or more long-term or overall goals. We use it here to encompass any documented plan formalizing the roadmap for any technology domain. e.g., Data Warehousing Strategy.
Target Architectures. A target architecture is a formal view depicting an aspirational future state for an organization's technology architecture or any subdomain within it. It can be conceptual, logical, or physical level. e.g., Digital Platform of the Future.
Reference Architectures. A reference architecture is a template solution for a specific business and technology use case. It can also take the form of a Pattern, and it can be conceptual, logical, or physical level. e.g., Authenticated Web Application.
Non-Functional Requirements. A non-functional requirement provides details on how a technology solution should be built, installed, or implemented. e.g., Solutions must run in a virtualized, shared-compute server environment.
This list is not exhaustive. The form of a technology guardrail should be whatever works most effectively for the organization.
Establishing Technology Guardrails
Some additional info for the gratuitous reference to the Eisenhower Matrix
Documenting technology guardrails is a journey unto itself! It requires introspection and forward-thinking that is not easy to find time for amidst the challenges of keeping the lights on (KTLO): the day-to-day operations supporting the current infrastructure and apps. However, it is a crucial Eisenhower Decision Matrix "Quadrant 2" activity that is worth the investment in time. Empowering better technology decisions now will reduce KTLO needs in the future (see #3 - #5 above).
Not surprisingly, we have a recommended approach for getting started!
Define your process. It is important to determine upfront how standards will be defined and approved. This process will be the machinery for turning all the guardrails below from ideas into guardrails!
Gain executive remit. Guardrails need to be organization-wide to be effective. And to be effective organization-wide, they will need executive-level backing. Put together a value-driven story, and get that remit!
Document guiding principles. These are usually "top-down" messages that can be determined by a small executive audience. Since they provide broad coverage, they can move the organization quickly from no guardrails to some guardrails. Decisions will still require ample discussion, but they should be the right discussions.
Turn what you already have into guardrails. With the blessing of #2 and using the process in #1, gather any documented guidance that any technology competency areas might have, then review, refine, and publish as guardrails.
Document "de facto" standards. At even the least formal organization, undocumented standards exist in practice, through company lore, or in the heads of individuals heading different technology competency areas. A few workshops can elicit that information into documents. Boom! You now have more guardrails. As a bonus, instead if using subject matter experts' valuable time, people can now check the standards for this information.
Non-Functional Requirements. A few facilitated sessions with the IT competency area owners can also result in a great starter list of NFRs that can be injected into your project processes to improve project outcomes.
Prioritize more guardrails based on pain points. Perform interviews or have a few facilitated workshops with both business and technology stakeholders to determine which guardrails gaps are causing the most problems. Use this information to prioritize what guardrails need to develop next.
Develop a Guardrail Topics Taxonomy. After pain points are prioritized, we recommend creating a comprehensive taxonomy to identify all the potential topic areas for Guardrails. This taxonomy can ensure coverage and measure maturity as you build out your guardrails.
That's a wrap!
We wish your organization well on your journey ahead. And trust us, you'll enjoy the ride quite a bit more with some technology guardrails in place. Plus, the great thing about guardrails is that having any guardrails is better than having no guardrails, so you can start small with minimal effort and mature over time.
If you would like any support for anything from pitching the value to creating the guardrails please contact us. It's what we do!
Dan is the founder of Wittij Consulting. Prior to founding Wittij, he spent a decade in software development before moving into IT architecture, where he created an Open Group recognized architecture method and led delivery of all services for a company specializing in enterprise and solution architecture for 15 years. He is an energetic, thoughtful leader with an ability to engage and motivate people, and has been called a “force multiplier” for his ability to not only deliver great value, but also increase the value and capability of the people around him. Dan is a strong facilitator, able to understand and resolve complex disagreements with diplomacy. He comprehends and communicates clearly both at the detail level and the boardroom summary level to both business and technical audiences. His knowledge of enterprise techniques and technologies is broad and deep, and includes industry expertise in manufacturing, financial services, banking, health care, insurance, regulatory compliance, and NGOs.
