Acclaimed American architect, Frank Lloyd Wright, advised architects to "reduce the whole of its parts to the simplest terms, getting back to first principles". All too often in IT organizations, the basic underlying first software architecture principles needed to guide its journey and to inform key decisions are left unspoken.
In this article, we will look at why every successful IT organization needs commonly held architecture principles, the components of well defined architecture principles, and practical advice for putting these principles into practice.
Why Do I Need Architecture Principles?
Architecture principles define the fundamental assumptions and rules of conduct for the IT organization to create and maintain IT capability.
Without architecture principles, the IT organization has no compass to guide its journey from the current state to the desired future state, nor standards to measure its progress. There is no framework for decision making as each initiative is left to weigh decisions which the enterprise will live with for years to come based upon its own parochial measures of success.
Without a common set of underlying principles held by business and IT leaders, each initiative will be left on its own to determine what projects will be funded, which assets will be leveraged, what vendors will be used and how applications will be constructed, maintained and retired.
Architecture Principle Characteristics
A well defined architecture principle consists of a name, definition, motivation and implications.
The name of the principle should be short and recognizable. Its definition describes "what" the principle means in language understood by business and IT stakeholders. The motivation describes "why" the principle is important to achieving the organizational mission. The implications describe "how" the principle changes behavior.
Consider the following example architectural principle for creating new IT capability:
Click here for larger image
Figure 1 - Reuse, Buy, Build Sample Principle
A principle such as "Reuse, Buy, Build" can be a game changer for an organization. A principle should not be adopted lightly. It should be deliberated and explicitly adopted by business and IT leaders. Once a principle is in place, it becomes a core shared assumption for all initiatives in the enterprise. This radically simplifies decision making. It ensures that all projects align with and are moving the needle toward the desired future state.
Other enterprise architecture principles an organization might consider include:
- The Business Case Principle
- Don't Automate Bad Business Complexity Principle
- Application Ease of Use Principle
- Prefer Service Orientation over Application Orientation Principle
- Don't Over / Under Engineer Principle
- Avoid Package Customization Principle
I'll leave it up to you to further define these principles and to articulate the motivation and implications of adopting them. This should stir some thoughts in your mind as to the underlying principles your organization may implicitly have or would benefit from.
Putting Principles into Practice
There are four factors to successfully put principles into practice: effective principle definition, explicit principle adoption, clear organizational accountability and a consistent process for evaluating decisions according to principles.
Success Factor #1: Effective Principle Definition
The first success factor in putting principles into practice is to effectively define relevant and practical principles
As you consider a set of architecture principles for your IT organization, be careful not to take a "where the rubber meets the clouds" approach. You do not want ivory tower principles to which the organization pays lip service. Take a "where the rubber meets the road" approach. Try to define a set of first principles essential to achieving your organization's mission with practical implications for how they will become embedded in the organization.
Think about concrete past decisions which did not follow a proposed principle and for which the organization suffered consequences. Make these cases poster children for why this principle is needed to avoid these consequences in the future. For example, your organization may have learned the hard way that an "Avoid Package Customization Principle" is sorely needed after it spends more on a package upgrade than the initial deployment itself due to the upgrade impact caused by extensive customizations.
Try to define a core set of principles and recognize that less is more. Only define principles which are absolutely necessary. Keep in mind that the framers of the United States constitution settled on a set of just 6 core principles.
Success Factor #2: Explicit Principle Adoption
The second success factor in putting principles into practice is explicit adoption of principles.
Key stakeholders must understand how the motivation behind a set of principles aligns with the organizational mission. They also must understand the implications to adopting these principles and commit to abiding by them. Half heartedly adopting a principle and not changing behavior will result in the continuation of past errors.
It is essential that there be some ceremony in having IT and business leaders commit to the adoption of architecture principles. One approach I've used in the past is to ask business and IT leaders to sign a document in ink. I have one such document hanging in my office as a reminder of the commitment made by business and IT leaders to abide by a certain principle. This provides traceability and prevents organizational amnesia when it is convenient for someone to ignore commitments made.