You probably also know how it got this way: Your organization may operate in silos, with technology decisions made at the department level. Perhaps a recent acquisition forced disparate technologies together. Or maybe you just feel like a hostage to particular vendors or the whims of other senior executives’ preferences.
But you also know the status quo is driving up costs, diverting talent and preventing true innovation.
The first step to tackling this common problem is to move the discussion about your organization’s technology architecture up a level, to a discussion about “Principles” rather than implementation options.
Getting Principled
What are Principles, in the context of technology architecture? Simply put, they are statements of direction or position that, when adopted, can then inform the decisions made at lower levels of architecture strategy and policy. Principles can be based on generally understood statements of best practices in the use of technology, or as statements of desired business directions or outcomes.
Principles help “break a tie” when alternative choices exist, by allowing a team to favor the option aligned most closely to them.
Most likely, getting to an agreed-upon set of Principles will involve some debate. But, in the end, architectural Principles are a set of “We Believe” statements that guide the organization’s technology-related activities. Thus:
- Principles are statements that define the best practices and goals of IT.
- They should be based on business drivers, service requirements, and company culture.
- They should guide the IT decision making-process for architecture definitions and to arrive at product selections, standards and usage.
- They provide the foundation upon which the enterprise architecture is defined, applied and managed.
This notion of architecture principles is also endorsed by IT research organizations. More than a decade ago, MetaGroup (since acquired by Gartner) commented as follows on how to form Principles:
“A good Principle…
- States a fundamental belief of the enterprise in one or two clearly written sentences.
- Recommends an action against which some arguments could be made.
- Has relevance to a technical architecture.
- Is worded directly and simply in terms understandable by all stakeholders.
- Is durable; will not be outdated quickly by advancing technology.
- Has objective reasons for advancing it instead of the alternatives which were considered.
- Has Impacts which need to be documented.“
For example, a potential Principle statement could be:
The Company must be able to offer different pricing and service levels, and support different value propositions, across customer segments.
You can see how this simple statement could have potentially profound and cascading impact across business and technology activities.
Part of a blueprint architecture
Principles are only one component of an overall “blueprint architecture,” which also ties together a solutions framework and the enabling technologies:
What Principles look like
Principles are expressed in terms of “What” is desired. Each Principle’s description should include the reason for its existence and the implications of its adoption. Ultimately the specific technologies employed are examples of “How” the Principle is implemented.
We’ve found it useful to organize Principles into three categories:
- Governance
- Technology
- Operations
Here is a fully formed statement of a sample governing Principle:
The Company will manage technology assets as a portfolio.
Rationale:
- Establishes aggregate view of technology
- Improves risk management capabilities
- Simplifies the IT environment over time
- Reduces IT resources required for support of fragmented technologies
- Improves business agility
Implications:
- Need to conduct a technology portfolio assessment
- Need to define a governance process
- Need to evaluate the cost of maintaining vs. exiting in place technologies
- Need to ensure coordinated retirements (“don’t cut users off”)
- Need to know all interfaces (don’t break things)
- Need for development of a cost of ownership model
In our work with clients to define forward-looking architectures, we have identified a starter set of technology-level Principles. We’d be pleased to discuss these with you. Drop us a note at info@Mod Op Strategic Consulting.com to set up a chat.
