Principles at this level focus on how applications are designed and constructed. These principles are owned by the architect-working group, and by senior management. The architect working group charter includes the creation of these principles, as well as their enforcement through architecture review steps within the development process.
Principles are grouped in these major groupings:
· General - applicable to applications architecture in general.
· Methodology - focus is on the process of design and construction.
· Software Component Development - applicable to all components.
· Data – For data concerns.
· Support – things related to infrastructure.
· General
1. Business Systems are Architected
2. Standards Based
3. Principle of Mediocrity
4. Simplicity
5. User-Centered Design
6. Electronic Data Interchange assumed
7. Dynamic versioning is supported
8. Date tuning is supported
· Methodology
1. Methodology is applied in a disciplined manner
2. The Design Process is Public, not Private
3. Function is delivered incrementally
· Software
1. Component Based Design
2. Components are Loosely Coupled
3. Components are accessible
4. Components are reusable
5. Components are extensible
6. Components are scaleable
7. Components are maintainable
8. Service Components are shared across the system.
9. Visual Development Components are provided.
· Data
1. Data access is consolidated into a common layer or component.
· Support
1. Training support is integrated into system design.
2. Security is consistent and universal.
3. Distributed availability is a consistent design goal.
4. High System Quality is a primary expectation.
5. Performance monitoring is integrated into design.
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.
or
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 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 walk-throughs 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 logical increments, implemented in minimal timeframes.
Rationale:
· Iterative design allows for more rapid understanding of what is possible and desirable between developer and business partner.
· Iterative delivery increases productivity by focusing efforts to shorter milestones.
Implications:
· Iterations must be formally planned as part of the development plan.
· Deliverables do not extend beyond 3 months without exceptional approval.
Software components include the following:
· objects
· code
· databases
· frameworks
· models
· modules
· systems
· system services
· procedures
Component Based Design
Principle:
· A system is designed as a collection of independent components.
Rationale:
· Components-based design enhances system flexibility and scalability as well as maintainability.
· Components contribute to overall simplicity and maintainability. When in doubt, simplicity should rule for interface and component design.
· Developer productivity is best achieved through reusable components that can be readily seen and utilized within the development tool framework.
· Components that are not tied to a specific language, can be reused across different platforms and tools, and be developed in different tools.
· Components provide flexibility to deploy services on the client, or on servers using distributed support options.
Implications:
· All common services within the system are defined expressly as components.
· Component size and numbers are maintained at a manageable level. A few (hundreds, not thousands) reasonably sized collections of services, with consistent interfaces.
· Common infrastructure services are provided by means of components that are incorporated into the system infrastructure.
· Component use is promoted through the use of a visual development tool, that presents components as available functions, with their interfaces visibly defined.
Components are Loosely Coupled
Principle:
Components are integrated through consistent use of well-conceived, generalized relationships, rather than through definition of component specific relationships.
Rationale:
· Loosely coupled components interoperate well, but are not dependent on each other’s implementation specifics.
· Loose coupling is critical to achieve graceful evolution of system function over time.
Implications:
· Component relationships must be carefully designed early in the design cycle to ensure that integration objectives are met while preserving loose coupling.
· Well integrated is not synonymous with tightly coupled. Functions can be integrated while remaining loosely coupled.
Issues:
· Tight coupling achieves high system performance, at the cost of system flexibility over time.
Supporting Materials:
· Loosely coupled components have the following attributes
(this could be broken out as a separate component design guide):
1. Logically Isolated
2. Independent / Orthogonal
3. Distributable
4. Multi-tiered
5. Support Peer to Peer Relationships
6. Support Anonymous Interaction
7. Support Publish / Subscribe Interaction Model
8. Encapsulate Foreign Components.
More Details on Each
1. Logically Isolated
Components have well defined boundaries of small scope, and confine their impact on the system to these boundaries.
Rationale:
- Good isolation of components promotes flexibility, availability, maintainability.
- Systems can evolve more easily if the components are clearly and cleanly isolated.
Implications:
- Components have a minimum number of interfaces to other components.
- Component interfaces must protect the internal integrity of the component.
- Components must observe programming practices that prevent unintentional linkages – for example, memory and file management practices.
- Systems must allow for replacement or addition of other components with little impact on other parts of the system.
- The initial partitioning of the system into logical components is the key step to develop isolated components.
Issues:
- Easy to say, tough to do.
2. Orthogonal
Changing the behavior of one component does not require that the behavior of other components change.
Rationale:
- Responsive systems must be easily modified.
- Changes are easier to make if the components implement their functions in an orthogonal manner – simply, with clear independence between pairs.
Implications:
- Components are designed to serve distinctly different purposes.
- Within each component, functions are cleanly delineated, and implemented with change and independence in mind.
Issues:
- This may not be the easiest attribute to grasp.
Supporting Materials, Example:
- To be developed.
3. Distributable
Logical components can be distributed over an arbitrary number of hardware nodes.
Rationale:
- Distribution allows cost effective scaling of system capacity.
- Distribution provides improved fault tolerance.
Implications:
- Components are structured to allow the addition of independent parallel resources for increased capacity.
- System design must provide a mechanism to support the cooperative / coordinated behavior of distributed components.
- No two components are required to reside on the same node, by either hardware of software dependencies.
- Ideally, systems should be designed to support heterogeneous execution platforms.
Issues:
- Distribution requires careful design, or it may create complexity and performance issues in itself.
- System management of distributed systems adds additional complexity.
4. Client-Server Model
Components are designed to act as “servers” to provide services on request for other components which act as “clients”.
Rationale:
- The client-server model provides a uniform set of relationships and good isolation between components.
- The model also promotes specialization, allowing many components to make use of a highly refined common service.
- The model allows for graceful scaling of function within distributed systems.
Implications:
- Client-Server relationships must be broken into separate components.
- Servers must be able to deal with multiple, simultaneous clients.
- Clients must not be aware of or sensitive to which server they are connected.
- Multiple servers of the same type should coexist peacefully.
- Clients and servers may be arbitrarily distributed over separate, heterogeneous hardware platforms – multi-tiered.
- Responses may be returned synchronously or asynchronously.
5. Support Peer to Peer Relationships
Components interact as peers, without implied master-slave relationships.
Rationale:
- Peer to peer control relationships preserve the symmetry of the architecture, and simplify substitution of components.
- It avoids the assumptions of unique privilege by any component, which could limit opportunities for integrating other components.
Implications:
- No “master” component exists at any level of the architecture.
- Components may take control of a function as a server.
- No component has exclusive ownership of the user interface.
- The preferred interaction is a service request, in place of direct command relationships.
- Avoid “coordinator” components, which server primarily to synchronize other components.
Issues:
- Some purchased products may assume a “master” role by default. This behavior must be encapsulated if it is to be readily incorporated into the architecture.
6. Support Anonymous Interaction
Components are unaware of the identity, quantity, location, or behavior of other components in the systems.
Rationale:
- New service providers or requesters can be added or replaced in the infrastructure without disrupting those interacting components already in place.
- If interactive components are aware of each other, this flexibility is impossible.
Implications:
- Services are requested by service name, not by server name.
- Service requests are mapped dynamically to the requesting client, not through a fixed list or embedded names.
- The infrastructure provides a mechanism for distributing service requests among equivalent service providers.
- Clients are not aware of the topology or location of servers.
7. Support Publish-Subscribe Interaction Model
Components publish and subscribe to pertinent information and events without knowledge of the source or destination, or whether the information or events are available or used. Published information and events are available to all authorized subscribers.
Rationale:
- Publish and subscribe supports anonymous interaction.
- Information and events represent commodities that are shared and utilized wherever they are available.
- Publishing provides information and events whenever they are available.
- Subscribing allows processes to receive information or events when they are available.
Implications:
- The system infrastructure supports publish-subscribe as a normal mode of interaction between components.
- Components publish information or events as soon as they become available.
- Subscribing components subscribe to information or events of interest, and assume that they are delivered as soon as they are available.
- Publish-subscribe is one of several interaction models possible among client-server components.
Supporting Materials:
- A restaurant analogy provides a real world example of publish / subscribe:
i. The waiter at the counter (the client) shouts an order (publishes) that has just been taken from a customer. The waiter has no idea who if anyone is working behind the counter.
ii. One or more people in the kitchen (servers) are listening (subscribed to) and hear the order. Each server recognizes the part of the order for which they are responsible, and they produce that part. They deliver (publish) the pieces of the order back to the warming tray. The servers do not know which waiter or customer asked for the order.
iii. The waiter watches for the pieces of the order to arrive (subscribes) to complete the transaction.
8. Encapsulate Foreign Components.
Components that are not compliant with this architecture are self-contained within an adapter component, which provides architecture compliant interfaces.
Rationale:
- Non-compliant components may be present for a variety of reasons:
- legacy systems
- purchase products.
- Encapsulation provides the functions of these components to others so that they can gracefully evolve.
Implications:
- Components that are not architecture compliant must be encapsulated within a compliant boundary.
- Encapsulation itself must be maintainable, so that major changes are not required if the underlying component is changed.
Components Are Accessible
Principle:
Software components must be accessible from all locations and execution environments.
Rationale:
· Software components that are not accessible will not be used.
· A modest variety of execution environments will always be with us.
· Design components that are not extendible across different environments constrain the flexibility and integration of those different computing platforms for the future.
Implications:
· Software components are centrally managed with a common method available to locate them.
· Software components are available in multiple execution environments. This includes all of our supported "environments" -- mainframe, and client / server generations.
· Software components must have clear, concise, and consistent interfaces across all environments. The complexity of the technology infrastructure is hidden behind consistent API's.
· Externally, software components utilize industry standard interfaces to ensure reuse into the future and with standard products. SOAP (XML), COM and CORBA are the prevailing standards which are utilized for all-external services.
Components are reusable
Principle:
Business Systems reuse components wherever possible.
Rationale:
· New systems can be built more quickly and at less cost when components are reused rather than created from scratch each time.
· Systems with common components are easier to learn and cheaper to maintain.
· Reuse tends to produce higher-quality systems because it takes advantage of proven, tested components.
· Research has shown that the highest productivity and quality rates are achieved by organizations that practice reuse.
Implications:
· Reusable components include objects, code routines, interface templates, control patterns, databases, models, systems, and procedures.
· Low-level components are built for one and only task; and that component is the only place where the task is handled. A higher level of granularity promotes greater reuse.
· New components are built or purchased with reuse in mind.
· Components have a simple, consistent interface; complex logic is hidden inside.
· Components are built that require the least possible knowledge of other components.
· Reuse is supported by education, which has been shown to be the single highest supporting factor.
· Organization support for reuse includes a centralized repository, catalogue, search, librarian, and reuse engineers.
Components are extensible
· Principle:
· Components are designed to facilitate extensions of their functionality.
· Rationale:
· Most business requirements change over time.
· Components will need to be modified to provide new functionality to meet new business needs, without having to be rebuilt.
· Reuse and its benefits are easier to attain with extensible components.
Implications:
· Layered design and clear component interfaces promote greater extensibility.
· Designs avoid any arbitrary limits, hard coded edits.
· Design reviews focus on the potential use of components in other applications, present or future.
· Design sessions gain input from more than one user, more than one potential application area.
Components are scaleable
Principle:
Components are designed to be able support applications that can support enterprise wide services, in terms of data and transaction volumes.
Rationale:
· Reuse and extensibility encourage the extension of system applications beyond their initial usage.
· Components of the framework need to service applications with large amounts of data or transactions in addition to small applications.
Implications:
· Stress testing pushes all designs beyond the expected limits to determine the feasible range, e.g., from a single home user, to a large centralized office.
· The design process includes the awareness that this component might be used far beyond its initial target.
Components are maintainable
Principle:
Components are designed and documented to facilitate ease of maintenance.
Rationale:
· Building with components and building with objects are two different activities. With objects we start from use cases and design the objects around them. Components on the other hand are application independent, and documented in different ways.
· Components are typically discovered when developers find themselves repeatedly writing similar pieces of code. To minimize this "discovery" period, components must have clearly understood, easy to use documentation.
· Since good components will have a long life, their maintenance becomes paramount. Issues surrounding backward compatibility, and version control will need to be addressed just like any other software product.
Implications:
· Components are built with a high degree of understandability, i.e. standardization on names, fault handling, and structure.
· Every component has a specifications sheet that describes the component functionality, what a user needs to know in order to use it, and any known limitations.
· Component documentation is registered with a centralized object librarian.
Service Components are Shared Across the System
Principle:
Component reuse is fostered and promoted across the system by common service components.
Rationale:
· Common component use is the most effective means of achieving high productivity, quality and flexibility in design.
Implications:
· The planned list of service components includes:
- Access security
- Field validation, default entry
- Business rule validation
- Table management
- Document management
- Work-Flow
- Diary
- Communications interfaces
Visual Development Components are Provided
Principle:
Common architecture services are provided by means of components that are incorporated into the development desktop tool with a visual metaphor.
Rationale:
· Developer productivity is best achieved through reusable components that can be readily seen and utilized within the development tool framework.
· Components that are not tied to a specific language, can be reused across different platforms and tools, and be developed in different tools.
· Components provide flexibility to deploy services on the client, or on servers using distributed support options.
Implications:
· Any common service that is identified as part of the architecture must have a visual component provided to the developer's desktop.
· The desktop component provides a visual, flexible 'wrapper' for the service or component's functionality, and does not just expose a highly complex interface or set of options.
Data access is consolidated into a common layer or component
Principle:
System function code is separated from physical data stores through the implementation of a data access layer or component.
Rationale:
· Consolidation of the data access allows for future flexibility in modifying the logical or physical data model.
· Consolidation of data access provides for simpler application logic, which is easier to maintain.
Implications:
· Data access is “encapsulated” so that requests for data are all through a single, consistent API or set of methods that implement basic functions: get, put, search, add, delete.
Training Support is Integrated into System Design
Principle:
Staff training is fully supported within the production run time version of the system.
Rationale:
· Training is a constant need and must be supported at the same level as the production system.
· Training is an option selected at the discretion of the user at the time of system entry or sign on.
Implications:
· All critical services have a training option inherent in their design.
· Interfacing services must also be extended to support an integrated training option.
· Training information is carried on production databases and can be uniquely distinguished so that all functions recognize a training transaction or data element easily.
· User interfaces and reports conspicuously identify training data.
Security is Consistent and Universal
Principle:
Adequate security is consistently exercised across every function and interface of the system.
Rationale:
· Security software can be implemented most effectively and with the lowest resource consumption through a single, consistent framework.
Implications:
· The identity of the end user and / or requesting component must be carried with every request.
· A consistent authorization scheme is utilized throughout the system.
· A "security framework" is provided, which acts as a "gateway" in front of every resource. When security is implemented, the gateway requests authorization from the security service before granting access.
· Every gateway identifies itself as the point at which access is granted to a specific resource.
· The security administrator has the ability to dynamically adjust the security level of any given component’s security gateway at run time.
Distributed Availability is a Consistent Design Goal
Principle:
When a system component ceases to perform, it does not prevent the user from continuing to access the remaining functionality of the system.
Rationale:
· The complexity of distributed systems is enormous.
· If tightly coupled, the availability of the whole is no greater than that of any component.
· Business users must be able to perform whatever functions are available, and not be completely out of business because of the failure of a single component.
Implications:
· Formal risk assessments and fallback procedures are created for every major system change.
· Impact on reliability of any system change is fully investigated and weighed before implemented.
· Every design interface must be prepared to accept a "no response" or "failure" as a legitimate reply from a service provider.
· In the event of a service failure, the user is notified, the central site is notified, and that service is temporarily disabled.
· Services that do not depend on a disabled function remain available.
· See the architecture design guidelines for loose coupling guidelines.
High System Quality is a Primary Expectation
Principle:
System quality is the foundation upon which all other principles rest
Rationale:
· Our systems are our reputation, and errors will destroy our reputation and market.
· The productivity of end users is the highest benefit of systems development, and must be placed before most other system goals.
· The productivity of developers is most effectively improved by reducing the effort expended to fix problems after the fact.
Implications:
· Quality support practices are employed throughout the development life cycle.
· We do not ship software with known errors.
· Errors are tracked, analyzed, and destroyed at the root, not just fixed at the end.
Performance Monitoring is Integrated into Design
Principle:
Performance monitoring tools are needed and distinct from application systems.
Rationale:
· Customer service and productivity are one of the primary goals of the system.
· System errors need to be captured quickly and efficiently to allow rapid response and to provide data for defect analysis.
· System performance data must be captured easily and allow for dynamic tuning.
Implications:
· The end user interface provides an easy method for the user to capture an error and send a message to the central monitoring area. The message automatically captures as much information as it can about the state of the system, version, date and time, etc.
· A common component, external to the application(s), provides centralized data capture for performance information.
· Performance information, both availability and response time, is captured and logged to a central resource. This optional capture or logging can be turned off or on from the central resource.
· In the ideal world, every resource would have a "performance" gate in front of it, which is normally not active, but can be activated from the central control. The gates would be grouped into typical categories, depending on the type of problem being experienced, so that they could be turned on in groups or automatically, and selectively by workstation, or workstation type.
Excerpted from Gamma, Helm, Johnson, and Vlissides, Design Patterns.
Under development!
Excerpted from Systems Architecting: Creating and Building Complex Systems, by Eberhardt Rechtin, published by Prentice Hall, Englewood Cliffs, N.J. 1991.
In the conceptual phase:
· All serious mistakes are made the first day.
· The choice between architectures may well depend upon which set of drawbacks the client can handle best.
· Extreme requirements remain under challenge throughout system design, implementation, and operation.
· Don't assume that the original statement of the problem is necessarily the best or even the right one.
· No complex system can be optimum to all parties concerned, nor all functions optimized.
· A model is not reality.
· Complex systems will develop and evolve within an overall architecture much more rapidly if there are stable intermediate forms than if there are not.
· Build in and maintain options as long as possible.
· Don't make an architecture too smart for its own good.
The build and test phases:
· The product and process must match.
· An element good enough in a small system is unlikely to be good enough in a more complex one.
· Within the same class of products and processes, the failure rate of a product is linearly proportional to its cost.
· High quality, reliable systems are produced by high quality architecting, engineering, design, and manufacture, not by inspection, test and rework.
· Regardless of what has gone before, the acceptance criteria determine what is actually built.
· To be tested, a system must be designed to be tested.
· Qualification and acceptance tests must be both definitive and passable.
· The cost to find and fix a failed part (or software bug) increases by an order of magnitude as that part is successively incorporated into higher levels in a system.
The operations phase:
· Before the flight, it's opinion. After the flight, it's obvious.
· The first quick-look failure analysis is often wrong.
· For every competitive system, there is a counter system.
· Success is defined by the beholder, not the architect.
· There's nothing like being the first success.