Design Principles

General Applications Architecture Principles

Business Systems are Architected

Principle:

· All business systems are designed to conform to the principles and models of the IVANS applications architecture.

Rationale:

· Architected systems provide better productivity through consistent internal and external interfaces, to development and business staff.

· Maintenance flexibility is enhanced by conforming to a developing architecture that allows for component based iteration and replacement.

· System integration is enabled when all business systems adopt a similar internal structure and external interface.

Implications:

· Every project has an identified architect role that is responsible for the overall system design, the identification of components, their responsibilities, and the interactions between components.

· Systems development methodology includes formal internal and external architecture reviews and approval.

· The applications architecture principles, standards and models are the basis for architecture design and review.

· The annual planning process identifies strategies and projects which support the development of the architecture components.

Standards Based

Principle:

Systems shall be based on broadly accepted standards wherever these exist.

Rationale:

· Components which are compliant with broadly accepted standards will be the most likely to be easily integrated with new components over time.

· Broadly accepted standards are most likely to be supported by tools and training.

· They will also be more easily replaced with commercially supplied components.

· Accepted standards provide a higher level of robustness and stability than custom developed approaches.

· Standard approaches save time and energy, as well as training and support costs.

Implications:

· Where broadly accepted standards exist, one must be chosen and followed.

· Interoperability between competing standards should be considered, but internal development focuses on one standard.

· Where insurance industry standards exist, such as ACORD, they are utilized.

Principle of Mediocrity

Principle:

No component is be significantly more complex or intelligent than the others.

Control, intelligence and function is evenly distributed throughout a design.

Rationale:

· Distributed control and intelligence functions tend to be less complex, and more adaptable to change.

· Even distribution contributes to higher quality, because it is less likely that any one component will be too complex and prone to problems.

· Distributed control reduces the number of complex inter-relationships or contracts between segments of a design.

Implications:

· Each component is a self contained, black box to the external user, accessible only through its published interfaces.

· The number of interfaces between components is evenly distributed.

· The number of functions within a component are evenly distributed.

Implementation

· This section would show examples, templates, patterns.

Simplicity

Principle:

The simplest solution is the best solution.

Rationale:

· Many systems or components are built to solve more problems than they need to. Besides being difficult to build and maintain, the reusability of components is reduced by the presence of excess baggage.

Implications:

· If you don’t need something, get rid of it

· If you don’t need to do something, don’t do it

· Put related things together to simplify the overall picture

· Split up complex things to keep them simple and understandable.

· Use a layered design, where large components talk to large components, and small components talk to small components, internal to the large ones.

· Rule of 9's -- no component or grouping has more than 9 visible elements, layers, groupings, etc. This includes the user interface, API, system design, model layers, etc. Even in a highly detailed entry screen, discrete data elements are grouped structurally for easier reference.

User-Centered Design

Principle:

Users’ needs are placed high¾if not first¾on the list of design priorities.

Rationale:

· This ties in closely with total quality management goals, i.e., bending over backwards to understand customers’ needs to be in a better position to fulfill them.

· Users base their first and lasting impression of a system on the quality of the human interface.

· Early and continuous focus on users throughout the analysis, design and development process will lead to high quality systems.

· Bottom-line impact is faster, easier, and more error-free task performance, and decreased training costs.

· This moves the focus from easy to build to easy to use, since the number and cost of end users is much more significant than developers.

Implications:

· This does NOT mean that the design process STARTS with the user interface. Only that it is focused on serving the needs of the user. Design begins with overall requirements and system architecture, or the components needed to accomplish those requirements.

· All producers of software systems apply user-centered design methods: use case analysis, usability objectives, early prototyping, usability testing, and iterative design.

· All business systems share a common and consistent human interface. Microsoft Interface Standards are the base, with extensions as noted in the Client / Server Development Guidebook.

· Human interface design guidelines are rigorously followed by all development teams, and exceptions are rare.

· Standard templates are utilized for common human interaction patterns and data presentation in the technology appropriate to the platform.

· A usability workshop and human interface design review is an absolute requirement for all systems.

· An Integrated Performance Support (IPS) framework is an essential component of all new system architectures. IPS, Integrated Performance Support, refers to a generalized framework that allows a developer to easily specify context sensitive and path sensitive help to the end user.

· Usability methods are integrated into all systems development processes.

Electronic Data Interchange assumed

Principle:

All data exchanges support the alternative of electronic data interchange in the future, utilizing XML and WWW technology.

Rationale:

· The future trend is to transfer data immediately and electronically.

· Bandwidth is expanding rapidly and the cost is falling.

· Faster, cheaper, better (response, cost, quality) is enhanced by removing transfers and hand-offs of information.

· XML is becoming a standard requirement for every business.

· The WWW is moving the perceived center of focus from the desktop to the external resource.

Implications:

· XML and WWW access is the assumed interface direction for all business systems.

· Business system input and output are encapsulated in components and layers, so that they can be directed to human or electronic exchange.

· We have standard tools or frameworks in our development environments that enable messaging, XML and WWW access for business systems.

· Immediate data transfer and availability is the basic design assumption, not delayed or queued.

· Messaging provides the required immediacy together with lower coupling required for availability.

· At the same time that bandwidths are increasing, the ability to maintain a connection in a wireless world is increasingly problematic. The queuing mechanism must provide “long transaction support” to maintain disconnected users.

Implementation

· This would outline how this is best accomplished in each environment.

Dynamic Versioning is Supported

Principle:

System software updates are designed to support dynamic versioning.

Rationale:

· Components executing on multiple distributed platforms cannot all be updated at the same time.

· New functions and system changes must be able to be implemented in a piece meal fashion, one workstation at a time, to minimize interference with data entry and user workflow.

Implications:

· All interfaces must support a dynamic version interchange.

· The basic model for this is the following:
- The Client or invoking component requests the anticipated version number.
- The Server or responding component carries out its function according to the expectations of the version requested, or replies that the requested version is no longer supported.

· The number of versions supported by server components will depend on the business need.

Date Tuning is Supported

Principle:

System applications must be sensitive to date critical requirements.

Rationale:

· Changes are frequently driven by business needs around effective dates. For example, the law changes on 12/1, therefore the system will act differently on that date.

· Coding date sensitive code everywhere it is needed generates much redundant effort.

Implications:

· Changes specific to a specific set of date sensitive requirements are identified as a group called a "change package".

· A common infrastructure or framework allows the date to be modified in one place for the associated change.

· All dates of associated "change packages" are presented to a specific end user task which is authorized to modify the dates.

Methodology Principles

Methodology is applied in a disciplined manner

Principle:

All system development, enhancement, and maintenance projects follow a prescribed methodological approach that includes development and maintenance of a project plan based on best practices, proven techniques, regular walkthroughs and reviews, and adherence to IVANS Standards and Procedures.

Rationale:

· In the current environment, we must react quickly to changing business needs and take advantage of rapidly changing technology.

· A disciplined methodology provides the consistency and the flexibility needed to accomplish this rapid response.

Implications:

· Certain activities/deliverables (Project Initiation Reports, Architecture Workshops) are required of all projects. Applicability of other activities/deliverables will be determined based on the characteristics of the project.

· Applications project managers and developers must receive adequate training and mentoring in order to use project management or methodological techniques that are new to them.

· A Process Management process must be implemented in order to provide a feedback and update loop for refining and enhancing IS development processes and procedures.

Implementation

· Project managers work with their Architecture representative to determine which standard processes are appropriate for their projects.

· Architecture workshops are conducted for all systems where there is significant new or changed functionality, new databases or extensive changes to existing databases, use of technology that is new to the application or to IVANS.

The Design Process is Public, not Private

Principle:

All system related designs are created in a group or reviewed by others.

Rationale:

· Design is a complex and difficult exercise, which is improved by the public exchange of information with other designers.

· Public design reviews support a more consistent architecture by making designers aware of the work of others.

· A public design is more flexible and conform more closely to architecture principles than a private one.

· The public design process enhances communications among developers and tends to produce higher quality systems.

· Public design reduces the autocratic character of design, and generates more buy in and commitment from developers and users.

Implications:

· The design process is more of a social event than a private work.

· Formal reviews and walkthroughs are an iterative part of the design process, not a review at the end.

· All designs are reviewed by means of a formal inspection or walk-through before they can be implemented or approved.

· The level of formal review may vary depending on the size and complexity of the design, but every design must be reviewed by at least one other person, and the larger and more complex, the more formal should be the review.

· Large and critical systems have formal design reviews with people external to the system effort.

· Designs are stored in a public repository for each project, in a form that is open to inspection by all.

· Designs are easily referenced by means of a common search engine and cataloguing scheme

Function is delivered incrementally

Principle:

Application functionality is designed and delivered in lo

Applications Architecture – Design Principles

Applications Architecture Principles

Summary

General Applications Architecture Principles

Business Systems are Architected

Standards Based

Principle of Mediocrity

Simplicity

User-Centered Design

Electronic Data Interchange assumed

Dynamic Versioning is Supported

Date Tuning is Supported

Methodology Principles

Methodology is applied in a disciplined manner

The Design Process is Public, not Private

Function is delivered incrementally