P. 1
distributed collabarative enterprise architecture

distributed collabarative enterprise architecture


|Views: 243|Likes:
Published by sanathkp
distributed collabarative enterprise architecture
distributed collabarative enterprise architecture

More info:

Published by: sanathkp on May 16, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Distributed / Collaborative Enterprise Architecture  The Customer is the Judge of Quality     Simplified communication mechanism Reliable Security Model

Interoperable, Interchange Integration, Message Driven Easy Database Connectivity
The customer should be involved in the process as much as possible, giving frequent and honest feedback on all aspects of the system architecture.

 Holistic Thinking
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 level, and easier accommodation of new components at the system level.

Service Characteristics
             Open Loosely coupled Well-defined service contracts Meaningful to service requesters Standards-based Predictable service level agreements Dynamic Discoverable Meta-Data Driven Implementation independent of other services Design for multiple invocation styles Stateless Multi-Channel Access

 Modularity
strive to think holistically about the system, its components, its usage contexts, and other relevant systems.Keep it simple

 Endeavor for Simplicity
Architecture should be as simple as possible without conflicting with other design principles.

 Conceptual Brilliance Doesn't Blind the Laws of Physics
A system architecture may be elegant, but the architect must not become so enamored with his or her work so as to lose track of the basic governing laws of the usage context in which the system operates

      Reuse Efficient Development Simplified Maintenance Incremental Adoption Division of Responsibility Graceful Evolutions

 Develop a common language for your team
Not only is the job of the architect to drive ambiguity out of 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 need to be able to communicate these goals completely and clearly in the deliverables.

Principles of Architecture  What Is Good Architecture?
 A good architecture is one that meets the needs of the stakeholders (especially the users) to their satisfaction, does not violate established principles of system architecture, and takes into account the relevant ilities by allowing for maintenance, evolution, further development, embedding, etc. as the customer requires. Also elegant (intellectually clean of unnecessary complexities or 'exceptions'), can direct a builder to costeffective structures that can be completed within a reasonable time frame, conceptually pleasing to all stakeholders (especially the user), and provide some special advantage (such as a competitive advantage) or utility to the customer.

 Garbage In, Garbage Out
The quality of a system architecture depends largely on the inputs provided to the architect; responsible for ensuring highfidelity inputs.

 Between the Idea and Reality Falls a Shadow
The ability of state an idea simply does not necessarily or frequently lead to simplicity in execution of said idea.

 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
Essential complexity is that which is essential to deliver functionality before gratuitous complexity slips in.

 Systemic Uncertainty
Decisions are almost always based on uncertain information 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 Iteration
All design processes can and should involve iteration. A process should be standardized before it's improved, for maximum effect. If a process is not standardized the benefit from improvement will be reduced.

 Local versus Global Optimality
The optimal architecture or design for a given subsystem may result in sub-optimal global functionality of the bigger system.

 Early Defect Elimination
Defects should be identified and eliminated as early as possible in the product development process.

 Omnipresent Risk
Risks can rarely be completely eliminated, but they can be noted and accommodated in the architecture.

 Value is Identified Outside
Most often, customers judge the value of a product, system, 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 Centralized + Decentralized / Centralized Ring

        Web 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

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->