Distributed / Collaborative Enterprise

Architecture
 The Customer is the Judge of Quality
 Simplified communication mechanism The customer should be involved in the process as much as
possible, giving frequent and honest feedback on all aspects
 Reliable Security Model of the system architecture.
 Interoperable, Interchange Integration,
Message Driven  Holistic Thinking
 Easy Database Connectivity ensure the best modularization of the system architecture, so
as to allow for all the benefits of modularity: easier testing,
easier accommodation of new requirements at the component
Service Characteristics level, and easier accommodation of new components at the
system level.
 Open
 Loosely coupled
 Modularity
 Well-defined service contracts strive to think holistically about the system, its components,
 Meaningful to service requesters its usage contexts, and other relevant systems.Keep it simple
 Standards-based
 Predictable service level agreements
 Dynamic  Endeavor for Simplicity
 Discoverable Architecture should be as simple as possible without
conflicting with other design principles.
 Meta-Data Driven
 Implementation independent of other services
 Design for multiple invocation styles  Conceptual Brilliance Doesn't Blind the
 Stateless Laws of Physics
 Multi-Channel Access A system architecture may be elegant, but the architect must
not become so enamored with his or her work so as to lose
BENEFITS:: track of the basic governing laws of the usage context in
which the system operates
 Reuse
 Efficient Development
 Simplified Maintenance  Develop a common language for your
 Incremental Adoption team
 Division of Responsibility Not only is the job of the architect to drive ambiguity out of
 Graceful Evolutions the system by defining the boundaries of the system, to
creating the concept of the system, by allocating functionality
and defining interfaces and abstractions, but the architect
Principles of Architecture need to be able to communicate these goals completely and
clearly in the deliverables.
 What Is Good Architecture?
 A good architecture is one that meets the needs of the  Garbage In, Garbage Out
stakeholders (especially the users) to their satisfaction, The quality of a system architecture depends largely on the
does not violate established principles of system inputs provided to the architect; responsible for ensuring high-
architecture, and takes into account the relevant ilities by fidelity inputs.
allowing for maintenance, evolution, further
development, embedding, etc. as the customer requires.
 Also elegant (intellectually clean of unnecessary  Between the Idea and Reality Falls a
complexities or 'exceptions'), can direct a builder to cost- Shadow
effective structures that can be completed within a The ability of state an idea simply does not necessarily or
reasonable time frame, conceptually pleasing to all frequently lead to simplicity in execution of said idea.
stakeholders (especially the user), and provide some
special advantage (such as a competitive advantage) or
utility to the customer.
 Must Do To Learn
Chinese proverb: ""I hear and I forget, I see and I
remember, I do and I understand."
 Robust Functionality Drives Essential
Complexity  Systemic Uncertainty
Essential complexity is that which is essential to deliver Decisions are almost always based on uncertain information
functionality before gratuitous complexity slips in. and almost always depend on future things happening, future
technologies, future values
 Every System Consists of Subsystems
 Standardized Process Improvement
 All Design Processes Should Involve A process should be standardized before it's improved, for
maximum effect. If a process is not standardized the benefit
Iteration from improvement will be reduced.
All design processes can and should involve iteration.

 Local versus Global Optimality  Early Defect Elimination

The optimal architecture or design for a given subsystem may Defects should be identified and eliminated as early as
result in sub-optimal global functionality of the bigger system. possible in the product development process.

 Omnipresent Risk  Value is Identified Outside

Risks can rarely be completely eliminated, but they can be Most often, customers judge the value of a product, system,
noted and accommodated in the architecture. or service by looking at its external interfaces and their
function and form. They frequently treat the product/system
as a black box for their use and for their value.
Hybrid Topologies
Servers Centralized + Decentralized / Centralized
 Web
Ring
 File
 Mail
 Print
 Database
 General-Purpose
 Proxy
 Other: FTP, IRC, FAX

Typical Java Enterprise N-Tier System J2EE

Persistence - created objects and variables

continue to exist and retain their values between
runs of the program
.NET System Architecture

Invocation Styles

 Asynchronous Queuing
 Request/Response
 Request/Callback
 Request/Polling
 Batch Processing
 Event Driven
 Publish/Subscribe