Introduction
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:
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.
Summary
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:
- TOGAF, Part III ADM Guidelines and Techniques,
Architecture Principles - Pragmatic EA Framework, Governance,
Architecture Principles
About the 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. |
