On Principles of Applications¶

As discussed previously, principles are high level statements of the fundamental values that guide business and technology decision-making and activities and are the foundation for architecture, standards, and policy development. Principles are stable enough to withstand technological and process changes but timely enough to maintain a clear relevancy with markets, policy, program, and management changes.

Principles consist of the principle statement, rationale, and implications. Though the wording for principles should remain consistent, the rational and implications will evolve over time, as an organization responds to factors such as the current IT environment, internal initiatives, external forces and markets, and changes in mission, vision, and strategic plan.

In my prior role as an Enterprise Architect, I used the following Principles for the foundation of the Enterprise Applications. Even with the changes in the industry since I last wrote these - public, private and hybrid cloud computing, dev-ops, etc - these principles have been steadfast.

Application Integration¶

Enterprise applications will include known, published mechanisms for integration.

Rationale – Better application integration will reduce redundant data entry, will decrease the number of reconciliation problems and will make accurate data available quickly.
Implications – None.

Standards Compliance¶

Developers of enterprise applications will comply with all enterprise standards in effect at the time. This principle applies to internal or outsourced development and to COTS software, although to a lesser extent.

Rationale – Organization policy (a) mandates the adoption of standards and (b) favors COTS applications when suitable. Therefore, when COTS software does not fully comply with enterprise standards, a balanced evaluation is necessary.
Implications – None.

Application Ownership¶

Applications will have an identified business owner and technical owner or lead.

Rationale – Technology is effective only when aligned with business needs. Both technical and business interests will be represented when making decisions.
Implications – None.
Comments – Applications will have an identified business owner and technical owner or lead. The owners will share responsibility for the application, with the business owner taking the lead on business matters and the technical owner taking the lead on technical matters.

Application Documentation¶

Enterprise applications will be documented, both internally and externally.

Rationale – Poorly documented applications are expensive to maintain or modify.
Implications –D ocumentation standards need to be developed.

Business Alignment¶

Applications will have a stated business purpose. If there are multiple business purposes, they will be closely related.

Rationale – Technology is effective only when aligned with business needs. Also, it is easier to renew applications if there is modularity at a high level.
Implications – None.
Comments – This principle is a well-known tenet of information engineering.

Decision Analysis for Acquisition¶

A decision to custom build can be made only after an analysis that considers other sources such as COTS and Open Source alternatives.

Rationale – Decisions that are made without considering the alternatives may be suboptimal.
Implications – None.
Comments – No one alternative is favored for all cases.

Application Scope Definition¶

Enterprise Applications will meet broad needs. The requirements and design will be published prior to development, and all business units will have the opportunity to comment.

Rationale – Enterprise applications that consider only a subset of needs are unsuitable for enterprise-wide use. The result is a necessary proliferation of extension systems, which is inefficient.
Implications – The project plan will provide for this. Adequate communication methods will be developed.

Software Configuration and Change Management (SCCM)¶

The Software Configuration and Change Management (SCCM) process will be documented and all parties will adhere to it.

Rationale – When software is put into production without a SCCM process, reliability suffers, users are adversely affected, and extra cost is incurred to fix the problems.
Implications – Developers and maintainers of enterprise applications will have a CM process.

Systems Development Lifecycle (SDLC)¶

The systems development lifecycle will be documented and repeatable.

Rationale – Without an SDLC, software development is haphazard and risky.
Implications – Developers and maintainers of enterprise applications will have a documented SDLC.
Comments – The authors of this principle recognize that there are many well-know development methodologies. They intentionally avoided favoring one.

Reusability of Components¶

Applications should be assembled, in part, from reusable components or services.

Rationale – Reusable components lower cost of subsequent application development, but are initially more expensive to build than single-use components.
Implications – Developers should create new components as part of the implementation of new functionality.
Comments – The development of modular components and services is always favored, but not all components will or should be highly reusable.