Putting Architecture Principles into Practice

by Jeff Ryan

Learn how to explicitly define the principles upon which your IT organization stands and practical advice for putting them into practice.


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:

architectural principle example 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.

Success Factor #3: Clear Organizational Accountability

The third success factor in putting principles into practice is to have clear organizational accountability and responsibility for adhering to principles.

The Chief Information Officer and Chief Technology Officer of an organization have ultimate accountability and must adopt architecture principles as a moral code by which their organizations are run. They must walk the walk as well as talk the talk.

The enterprise architecture organization has responsibility to utilize the principles in making and evaluating decisions. Enterprise architecture must call fouls loudly and clearly when they see them. The CTO and CIO must have their back when they recommend alternatives in alignment with agreed upon first principles and attempt to change course. This means being willing to stop a project or to make available additional funding to re-architect a solution in a way which adheres to a first principle.

Development and maintenance organizations must follow the example of their leaders and leverage principles in day to day design, development and maintenance activities. Audit checkpoints are essential to ensure that projects are implemented according to their agreed upon architectural design.

Success Factor #4: Consistent Processes

The fourth success factor to putting principles into practice is to have consistent processes in the planning, budgeting and software development lifecycles which ensure principles are used to evaluate alternatives and guide decision making.

Enterprise architects have a key role to play in the overall planning and budgeting process for IT initiatives. Architects are responsible for articulating an architecture blueprint and roadmap of initiatives framed according to first principles. Through these incremental initiatives, the evolution of the portfolio is incrementally guided toward the desired future state.

Architecture governance is a core process through which proposed solutions are evaluated for alignment with principles, standards and blueprints. The governance process will have review gates as an initiative goes through the inception, elaboration, construction and transition phases of the software development lifecycle. Initiatives must produce standard artifacts to be reviewed at these gates. Initiatives found to be in alignment with principles will follow the path of least resistance through the review gates and proceed. Initiatives which are not in alignment will be stopped or redirected.


Architecture principles establish a framework for decision making and a moral code of conduct in an IT organization. They guide the organization from the current to the future state. A core set of principles should be explicitly defined in every organization so that the principle (what), motivation (why) and implications (how) are understood by business and IT stakeholders.

There is a danger that defined principles will not be put into practice at all, or that they will fall into disuse. Four success factors to put principles into practice were examined. First of all, principles must be relevant and practical. Second, leaders must explicitly commit to them. Third, there must be clear organizational accountability and responsibility for enforcing them. Fourth, certain key processes must be in place such as architecture governance to evaluate whether principles are being followed and so corrective action can be taken when necessary.

Has your organization defined the core principles by which it makes key architecture decisions which will impact its future? Have they been adopted by business and IT stakeholders? Are they thoughtfully considered in developing solutions? Is there push back to change the course of projects which have deviated from agreed upon principles?

If your answer is no to any of these questions, consider using the information in this article to define, adopt, and leverage architecture principles in your organization. The rest is up to you!

Recommended Resources

Those interested in learning more about architecture principles would do well to begin with the following resources:

  1. TOGAF, Part III ADM Guidelines and Techniques, Architecture Principles
  2. Pragmatic EA Framework, Governance, Architecture Principles

About the Author

Jeff Ryan - Author Jeff Ryan is an enterprise architect with over twenty five years experience architecting and implementing thoughtful solutions to business problems. This article reflects Jeff's experience in putting architecture principles into practice for a large financial service organization. Click here to browse Jeff's catalog of articles on enterprise architecture, front end architecture, portal, SOA, Java, XML and XSLT.

This article was originally published on Friday Dec 4th 2009
Mobile Site | Full Site