![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
This article discusses the role of principles in developing an architecture, whether it is a reference architecture, an application architecture, or one of the other architecture types. Architecture is a complex effort that must balance the needs of the business with the reality of how technology can support it. Architecture can be defined as the:
- Overall design or structure of a computer system, including the hardware and software required to run it
- Discipline surrounding the principles of design, construction, and ornamentation of IT systems
- Art and discipline of creating an actual, or implied, plan of any complex object or system
Principles are fundamental to making decisions related to the design and construction of the architected system. Principles also address the acceptance and governing of IT architecture decisions. This article examines the impact of principles on the architecture.
A principle signifies a point, or points, that allows for the formation of a norm or rule that guides the development of ethics by which you operate. Reducing a rule to its principle says that, for the purpose at hand, the principle cannot be questioned or further derived unless you create a new rule.
Principles are used by an organization to support its overall mission. They are used for decision making because they are general rules and guidelines. They should be long-lasting, and rarely change. Principles are based on industry best practice, and reflect the enterprise's purpose, vision, and values that are implemented through policies, procedures, and standards.
Architecture principles are a specialized subset of general principles. They guide the development of an enterprise's architecture and its continued evolution. They are used as the compass in the development of information and technology systems that meet a company's needs.
Architecture principles are formulated by the chief architect, who works with the enterprise CIO, the architecture board, and other key business stakeholders. They will change over time if the business or mission of an organization changes. Figure 1 shows how principles reflect an enterprise's purpose, vision, and values, which are the foundation for a company's business. These conceptual attributes, as captured by principles, are the driving force in developing a company's architecture.
Architectural principles:
- Are statements of preferred direction or practice. They reflect a level of consensus among the various organizations within an enterprise, such as business units, IT, and support groups.
- Require developing a framework that includes appropriate policies and procedures to support the implementation of the principles. Polices and procedures are used to support the application of governance to architecture for its information and technology components.
Governance is the structure of relationships and processes to direct and to control the applicable components to achieve the enterprise's goals by adding value while balancing risk against return.
- Establish a context for design decisions in which business criteria can be translated into language and specifications. Then technology managers can use this information as they plan, design, develop, implement, test, and deploy an information system's IT resources and assets across the enterprise.
- Are long-term statements that are simple and direct, and frame how an organization intends to make decisions about IT. These principles are critical to achieving the goals and objectives of a company.
Figure 1. Architectural principles
Attributes of a good principle
The main attribute of a good principle is reuse, for the present and future. Principles are created to drive and guide the behavior needed to develop an architecture and instances of its implementation. They must be relevant and expressed in a way that different groups understand what they mean and when to use them. This is important since some principles may be in conflict, depending on the context of their usage.
Principles are important only if you have both technical and business support at the senior management level. Principles should be relatively few -- on average 10 to 20. This number may be larger depending on the complexity and size of the effort. Too many principles add confusion, and they lose their value.
To help define a good set of principles, keep the following criteria in mind.
- Simplicity
- Key points must be clear and understandable by different groups throughout the organization. Take care not to have too many principles, or it leads to confusion.
- Consistency of interpretation
- A robust principle includes policies and standards that allow support of governance in a consistent manner. To support this concept, words that define a principle must be carefully chosen so there will not be multiple interpretations of a principle.
- Relevancy
- Principles must cover all relevant and important constructs of an organization. The value of a principle is that it fits in the realm of what is needed to support the architecture applicable to the IT needs of an organization.
- Granularity
- Principles are large grained. Care must be taken not to define principles that are too fine grained and too narrowly focused.
- Flexibility
- Principles must be expressed in a way that they can adapt to other principles with only some degree of conflict. No principles should be in conflict where one invalidates the intent of the other.
- Stability
- Principles should be enduring, yet able to accommodate changes. Principles have a life cycle; a process must be developed that ratifies changes to a principle that will allow for adding, deleting, and updating of the principles.
Application of architecture principles
Architecture principles capture the fundamental truths about how the enterprise will use and deploy IT resources and assets. They can be applied in a variety of ways predicated by the role a person plays. Once defined, principles are to be used in developing the reference architecture and implementations (application architecture) of the reference architecture.
Principles are used in several different ways. In IT decision making, as a foundation, they supply guidance, constraints, best practices, and criteria to be used in making well-structured, focused decisions. In governance of decisions, principles can define the control attributes of the decision-making process. This criterion can be used for assessing architecture compliance.
With product selection, principles establish relevant evaluation criteria for the selection of products to support the IT architecture. They can also be used for rationale and to highlight the value or purpose of the architecture to the enterprise. Principles can be used to identify the impacts of not using a principle and the value it adds in fulfilling the mission of the organization (for example, the type of operation problems that will occur or the potential reuse).
Principles are used to supply inputs to planning decisions. You can use them as requirement mediators to balance the usage of conflicting requirements. As a measure of evaluation, principles are used to determine whether or not business goals can be met by existing and proposed IT systems based on the company's priorities. You can also use principles as drivers for defining the functional requirements of the architecture.
Architecture principle specification template
A template gives consistency in defining architecture principles. Using the template guidelines results in content and form that can be understood by a diverse set of people. Each principle should have a meaningful name and definition statement. Each one should also have associated rationale and implications statements to promote understanding and acceptance of the principles, and to support the use of the principles in explaining and justifying why specific decisions are made. The template is shown here.
Architecture template
| Name | Should represent the essence of the rule and be easy to remember. It must also be meaningful to people with different roles and responsibilities. |
|---|---|
| Statement | Should succinctly and unambiguously communicate the fundamental rule. Usually, the principle's statement for managing information is similar from one organization to the next. It is vital that the principles statement be unambiguous. Avoid ambiguous words such as: support, open, consider, and avoid. Be careful with terms about "manage" or "management" and look for unnecessary adjectives and adverbs, or "fluff." |
| Rationale | Should highlight the business benefits of adhering to the principle, using business terminology. Describe the relationship to other principles and the intentions regarding a balanced interpretation. Describe situations where one principle should be given precedence or carry more weight than another for making a decision. |
| Implications | Should highlight the impacts of carrying out the principle in terms of resources, costs, and activities and tasks for both the business and IT. Often it is apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The reader should readily discern the answer to: "How does this affect me?" It is important not to oversimplify, trivialize, or judge the merit of the impact. Some of the implications will be identified as potential impacts only and may be speculative rather than fully analyzed. |
The value of developing principles is that they stipulate what should be governed. As a result, each principle should contain some measurable attribute. The following two examples use the above template. Example 1 highlights how you can measure the reduction in asset development costs and the time it takes to develop a new application using the reusable asset.
Example 1. Measuring the reduction in cost and development time
| Name | Reuse |
|---|---|
| Statement | Common components in the IT architecture should be used while building an application and enterprise requirements. |
| Rationale | Business units have common needs and requirements, yet each business unit has developed their own implementations of these common tasks. |
| Implications |
|
Example 2 shows that system reliability can be measured against reliability requirements. In both examples, there is at least one attribute that can have governance applied.
Example 2. Measuring system reliability against system requirements
| Name | Business continuity |
|---|---|
| Statement | Enterprise operations need to be maintained despite system interruptions. |
| Rationale | As system operations become more pervasive, we become more dependent on them. We must consider the reliability of systems throughout their design and use. Business premises throughout the enterprise must have the capability to continue their business functions regardless of external events. Hardware failure, natural disasters, and data corruption should not be allowed to disrupt or stop enterprise activities. The enterprise business functions must be capable of operating on alternative information delivery mechanisms. |
| Implications |
|
As stated, you should try to limit the number of principles so as not to overwhelm the person trying to understand them. A general rule is to keep it to 20 or less. This number will be higher if you are developing a reference architecture that is enterprisewide.
As the number of principles increase, it will become clear that there are some natural groupings. Most architectures end up with the following principle groupings:
- General architecture
- Business
- Technology
- Information/data
- Management
- Industry trends
- Security
- Testing
The following sections briefly cover these principles and can be used for your next project. They reflect the natural groupings, listed above, that enable people to better understand their focus and applicability to their role.
General architecture principles
- On demand
- An enterprise's business processes must be integrated end to end with key partners, suppliers, and customers. A business must rapidly respond to any customer demand, market opportunity, or external threat.
- Ease of use
- The IT architecture will promote ease of use in building and supporting the architecture, and solutions based on the architecture.
- Nonfunctional requirements weighted equally to functional requirements
- Nonfunctional requirements will be designed, developed, tested, and managed with the rigor of functional requirements.
- Single point of view
- The IT architecture will enable solutions that provide a consistent, integrated view of the business, regardless of access point.
- Buy compared to build
- Business applications, system components, and enabling frameworks will be purchased unless there is a competitive reason to develop them internally.
- Simplicity
- The IT architecture should be kept as simple as possible while still meeting business and enterprise requirements. Where complexity is needed, it should be encapsulated to promote simplicity of solutions built on the architecture.
- Speed and quality
- Architectural decisions will be made with an emphasis on accelerating time to market for solutions, while still maintaining quality.
- Flexibility
- The IT architecture will incorporate flexibility to support changing business needs and enable evolution of the architecture and the solutions built on it.
- Technology risk
- Stability of business systems will be preserved through controlled usage and management of technology across its life cycle.
- Integrated solutions
- The IT architecture will support the delivery of business solutions composed of integrated application and infrastructure components.
- Alignment of IT to business
- The IT architecture will be aligned with the business vision, objectives, and strategies and will support the business operations.
- Strategic use of relationships
- The IT architecture will leverage strategic relationships with other businesses and vendors to facilitate building and evolution of the IT architecture.
- Optimize IT infrastructure
- The IT infrastructure will be optimized based on business requirements and technology capabilities.
- Innovative and agile
- The IT architecture will readily support incorporation of new technologies to support business and technology innovation.
- Technology- and vendor-independence
- The IT architecture will be designed to reduce the impact of technology changes on the business, as well as be resilient to change.
All components of the computing environment must maintain confidentiality and integrity of the information that is used to conduct business, with decisions based on data classification.
- General governance
- Compliance to and evolution of the architecture will be managed through controlled governance processes.
- Cost performance
- The IT architecture will be managed to ensure the cost effectiveness of the information and technology environment.
- Applications and infrastructure components
- These elements will be designed and implemented to facilitate monitoring and measurement.
- Service-level management
- The IT architecture will support operation of business processes as defined by service-level agreements.
- Open standards
- The IT architecture will use open industry standards.
- Leverage industry knowledge
- The IT architecture will leverage industry best practices.
- Service-oriented
- The IT architecture and components built upon it should be viewed as a set of independent services that can be composed to provide a solution.
- Separation of concerns
- The IT architecture will support clearly defined, well partitioned, and loosely coupled components, processes, and roles.
- Reuse
- Common components in the IT architecture should be used while balancing application and enterprise requirements.
The following principles are value statements that the business requires for the delivery of security (including trust model, asset profile).
- Defense in depth
- Greater security will be obtained by layering defenses.
- Managed risk
- Risk and security controls should be balanced according to business objectives -- security controls should be proportionate to risk.
- Security by design
- Security should not be an afterthought or add-on. Security considerations should begin with the requirements phase of development and be treated as an integral part of the overall system design.
- Requirements-based access
- A user (human or computer) should only be given enough privileges to do those tasks needed to perform a specified job activity, function, or task; no more, no less.
- Transparency
- Security should be user transparent and not cause users undue extra effort. Administration and configuration of security components should not be overly complex or obscure.
- Resilience in response
- Design and operate IT systems to limit vulnerability and to be resilient in response.
- Enforced policy
- Implement processes, procedures, and systems that promote enforcement of organizational security policies.
- Testability
- IT architecture should be designed for testing. Test environments will provide simulation of the production environment to a degree appropriate for the level and type of testing. The design of the IT architecture should not preclude simulating the production environment due to cost or complexity.
The IT architecture should support test efforts that are able to work independently, without excessive coordination or scheduling.
Architecture principles focus on two main areas. They are used to govern the process of:
- Developing the architecture. Architecture principles are needed to guide the development, maintenance, and use of the enterprise architecture.
- Implementing the architecture. This means establishing the tenets and related guidance for designing and developing an IT system.
Figure 2 shows the architecture components.
Figure 2. Architecture components
Principles are created from business objectives and architecture drivers (business and design) and are used as the foundation for governance over the development of the architecture and the implementation of the architecture. Architecture principles, required capabilities, and requirements are all used to make architectural decisions, which reflect the created architecture.
Architecture is both an art and discipline that deals with the principles of design and the construction and ornamentation of IT systems. This definition of architecture implies that structure or concepts, which help make an architecture more robust and long lived, are a good thing. Defining architecture principles is critical to developing a successful architecture that can be governed through its life cycle.
Every architecture requires principles that allow measurement and control attributes that then enforce consistency of usage. Failure to have architecture principles reflects a lack of understanding about what drives the business and its values, and will result in an incomplete architecture that lacks the breath and depth needed for long-term value.
Learn
-
For more information about architecture frameworks, see FEAF. The US Federal CIO Council published the Federal Enterprise Architecture Framework (FEAF) (Version 1.1) in September 1999.
-
Read more about Architecture Principles from The Open Group Architecture Framework (TOGAF).
-
"IBM's SOA Foundation - An Architectural Introduction and Overview" (developerworks, Jul 2005) introduces the SOA Foundation as defined by IBM and explains IBM's view of what Service-Oriented Architecture is about.
-
From IBM Redbooks: Patterns: SOA Foundation Service Creation Scenario provides an introduction to the IBM SOA Foundation and includes a detailed implementation example for the Service Creation scenario.
-
From IBM Redbooks: Patterns: Implementing an SOA Using an Enterprise Service Bus focuses on how the service-oriented architecture profile of the Process Integration patterns can be used to start implementing service-oriented architecture using an enterprise service bus.
-
In the Architecture area on developerWorks, get the resources you need to advance your skills in the architecture arena.
-
Browse the technology bookstore for books on these and other technical topics.
- Stay current with developerWorks technical events and webcasts.
Get products and technologies
-
Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
Discuss
- Participate in the discussion forum.
-
Check out developerWorks
blogs and get involved in the developerWorks community.
Mark Schultz is a senior Certified IT Architect at IBM. He does enterprise architecture that reflects more than 20 years of experience in software development and IT architecture. His enterprise architectures encompass cross-brand products from IBM as well as products from other vendors. Mr. Schultz started at IBM in IGS and then moved to the Software Group Services. Prior to joining IBM he worked at Digital Equipment and Unisys.
