1 / 73

Architects and Architectures

Architects and Architectures. Definitions. System A group of interrelated elements forming a collective entity Architecture A style and method of design and construction. What is System Architecture?.

manton
Télécharger la présentation

Architects and Architectures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Architects and Architectures

  2. Definitions • System • A group of interrelated elements forming a collective entity • Architecture • A style and method of design and construction

  3. What is System Architecture? • A set of agreed-to methods, standards, and techniques that promote both efficient division of responsibility and increased functional reliability while building complex functions from simple components. • A holistic set of models that represent an enterprise’s information systems in order to manage change. • Exercise: Give an example of a system architecture. Analyse how it supports the two definitions

  4. Everyday Example • System architectures are everywhere and can be recognized by standards bodies, government regulation, or commodity products • Eg: food health and safety regulations, building codes, consumer electronics

  5. Bringing Home a New TV • A television relies upon two systems • Electrical distribution • Broadcast distribution • The consumer has an application and relies upon these systems implicitly

  6. Reliability • Standards: voltage, plug configuration, fusing, codes • Methods: metropolitan distribution, long-line transmission, generation • So, the customer doesn’t check the wiring before plugging in the TV

  7. Modularity • Standard interfaces allow architectures to upgrade components as needs or technologies change • Broadcast has changed several times over the lifetime of TV

  8. TV Architecture Changes Display Display Display Display Broadcast Broadcast Broadcast Broadcast Program Program Program Program Film Film Film Film Black & White Colour Satellite Pay Per View

  9. Architectures Enable Change • Designers can add new standards within an existing framework and create new services • Migration to new services is gradual and modular – not sudden and universal

  10. Enterprise Systems • Goals of a systems architecture for enterprise systems include: • Smooth flow of transactional information across multiple systems • Accountability and security through elimination of custom interfaces or manual processes • Access to current information aggregated across organizational domains • Improve systems incrementally • Goal to be like Lego™ bricks • Fit together easily • Easy to recombine in different ways • Flexible to solve many different problems

  11. Architecture Examples • Architectures can exist at an individual layer of the technology stack or span multiple layers. Any organisation will utilise multiple architectures. • The following are examples of architectures that are used in organisations. • Client/server - widely used and relies and clients that request services and servers that respond to these requests. The workload is shared and distributed. • Peer-to-peer – networked computers share resources, every system is equal. • Wireless (mobile) – allow communication from remote locations.

  12. The role of the architect • The architect develops plans based on a vision of the requirements for the system which is a blueprint of the company’s systems. • This “blueprint” is used for translating business strategy into a plan for IT. • Architect • Must understand what is expected from business. • Must clearly communicate between technology and business

  13. Some relevant questions for architects • What IT architecture is already in place? • Is the company developing the IT architecture from scratch? • Is the company replacing an existing architecture? • Does the company need to work within the confines of an existing architecture? • Is the company expanding an existing architecture?

  14. Understanding existing architecture • Understanding existing architecture allows managers to evaluate the IT requirements of an evolving business strategy vs. their current IT. • Plans for the future architecture can then be compared with the current infrastructure to help identify which components of the current system can be used in the system being developed. • Plan for existing architecture • Analyse the existing architecture and infrastructure • Analyse the strategy served by the existing architecture. • Analyse the ability of the existing architecture and infrastructure to further the current strategic goals.

  15. Understanding time scales • Strategic Time Frame • What is the life span of the system? • Technological Advances • Can the infrastructure and architecture support these advances? E.g. SOA (Service Oriented Architecture) defines a service or an interface as a reusable piece of software. • Growth Requirements • Will it meet future demand? Is it scalable?

  16. Assessing Financial Issues • Evaluate on expected financial value. • Can be difficult to quantify. • Steps • Quantify costs • Determine the anticipated life cycles of system components • Quantify benefits • Quantify risks • Consider ongoing dollar costs and benefits

  17. Assessing Technical Issues • Scalability. • Standards. • Maintainability. • IT staff skill set.

  18. Two histories of enterprise computing

  19. A history of enterprise computing I: Calculation systems • 1950s-80s • Single purpose • Eliminate tedious human work • Examples: Payroll, General ledger, Inventory • Technology used: Mainframes, magnetic tapes, batch processing

  20. A history of enterprise computing II: Functional systems • 1975-2001 (say) • Use computers to improve operations • Applications: Human resources, order entry, manufacturing resource planning • Technologies: Mainframes, PC’s, LAN’s

  21. Functional systems • Typically contained within a department • Islands of automation • Applications independently developed and deployed • Driving force: availability of mini-computers

  22. Functional system applications • Human resources System • Accounting and finance systems • Sales and marketing System • Operations management System • Manufacturing Systems

  23. History part III: Pressures on business forced integration • It becomes less and less possible to think about isolated systems. The world is becoming more joined up. • eCommerce • Need to allow access to customers • Out sourcing • Need to integrate with 3rd party systems • Mergers and acquisitions • Regulation • Post-9/11 and Sarbanes-Oxley requires must better integration and reporting • Post-credit crunch regulation still emerging

  24. Organisational systems 2000-date (say) Use computers to drive efficiency and support control across organisations and beyond to partners and suppliers Applications: Risk management, customer relationship management, supply chain management Technologies: Middleware, business intelligence, data integration technologies 24

  25. Types of Organizational information Systems • Administrative systems • Scheduling / Transaction systems • Value oriented systems • Reporting and controlling systems • Analysis and information systems • Planning and decision support systems

  26. Exercise • Each group chose a different business function within the organisation. • Define how a customer will be represented. • Personal details • 1 or more details specific to your selected business function

  27. Problems with function based application • Sharing of data between systems • Data duplication • Data inconsistency • Applications that don’t talk to one another • Limited or lack of integrated information • Isolated decisions lead to overall inefficiencies • Increased expenses Sales HR Manufacturing Stovepipe systems

  28. An architectural history of computing • 1 tier architecture • monolithic Information Systems • presentation, application logic, and resource management were merged into a single tier • 2 tier architecture • separation of presentation tier from other 2 tiers (app + resource) • became popular as 'client/server' systems • 3 tier architecture • can be achieved by separating RM (resource management) from application logic tier

  29. Tiers of an architecture browser Client <html> ... </html> Presentation tier Visualise Calculate Application logic tier information system Resource management tier Store

  30. Presentation Tier • How the data should appear to the user and how the user should interact with the interface

  31. Application Logic Tier • Data Processing (Business Logic & calculation) • Here the algorithms are implemented • This tier is often referred to as • Services • Business logic • Business rules • Server

  32. Resource Management Layer • Deals with and implements different data sources of Information Systems • The 'data layer' in a restricted interpretation as in JEE (aka J2EE) or Database Management System • Can also be a gateway to recursively using other Information systems

  33. 1 – Tier Architectures • Monolithic Information Systems • Presentation, application logic, and resource management were merged into a single tier • Many of these 'old' Systems are still in use!

  34. Design of 1 – Tier Architecture Client Advantages: • easy to optimise performance • no context switching • no compatibility issues • no client development, maintenance and deployment cost Disadvantages: • monolithic pieces of code (high maintenance) • hard to modify • lack of qualified programmers for these systems Presentation layer Application logic layer information system Resource management layer

  35. Client Information system Resource management layer 2 - Tier Architectures • fig 1.7 p.12 Presentation layer Application logic layer Server

  36. 2 - Tier Architectures • Separation of presentation layer from other 2 layers (app + resource) • Client/server systems with thin clients/fat clients • Use RPC (Remote Procedure Call) to communicate between tiers • Need for standardisation for inter-tier communication • Advantages • portability • no need for context switches or calls between component for key operations • Disadvantages • limited scalability • legacy problems (blown up clients)

  37. 3 - Tier Architectures client presentation layer application logic layer information system middleware resource management layer

  38. 3 - Tier Architectures • Separating RM (resource management) from application logic layer • Additional middleware layer between client and server • integration logic • application logic • Lead to the introduction of clear RM layer interfaces • Good at dealing with integration of different resources

  39. Business logic resides in middle tier • Alternatives • Client tier leads to • Fat clients • Reimplementing it for each different type of client • Redistributing clients after each software update • Data tier leads to • Vendor and technology dependence grows • Different applications have different needs for the same data • Performance issues in resource usage

  40. 3 - Tier Architectures • Advantages • scalability by running each layer on a different server • scalability by distributing AL (application logic layer) across many nodes • additional tier for integration logic • Flexibility • Disadvantages • performance loss if distributed over the internet • problem when integrating different 3 – tier systems

  41. information system resource management layer 3 - tier Architectures client GUI clients C++, VB, Java presentation layer application logic layer Middleware Server middleware Databases Legacy Systems

  42. Middleware • Middleware refers to the software which is common to multiple applications and builds on the network transport services to enable ready development of new applications and network services. • Middleware typically includes a set of components such as resources and services that can be utilised by applications either individually or in various subsets. • Examples of services: Security, Directory and naming, end-to-end quality of service, support for mobile code. • Examples: • OMG’s CORBA • J2EE - Java 2 Enterprise Edition • Microsoft’s .Net

  43. Middleware features • Allows communication • through a standard language • across different platforms • between legacy and modern applications • Takes care of • transactions between servers • data conversion • authentication • communications between computers

  44. Middleware features • Provides runtime environment for components in the middle-tier • Component lifecyle and management • Transaction, event and security services • Provides connections to databases, mainframes and legacy systems • Separates client-tier from the data source • Clean separation of user-interfaces and presentation logic from the data source

  45. n -tier client • fig 1.12 p. 20 2 cases of n – tier • Systems linked with added connectivity through the internet • Resource layer is a full fledged 2 - or 3 - tier system Web browser Web server presentation layer HTML filter information system application logic layer middleware resource management layer

  46. n - tier remote remote remote remote remote remote ... client client client client client client [fig 1.13 p. 21] INTERNET FIREWALL internal clients Web server cluster middleware LAN application gateways logic middleware middleware application application database file logic logic application server server additional RM layers

  47. General benefits of adding tiers With growing number of tiers one gains: • flexibility • functionality • possibilities for distribution But: • Each tier increases communication costs • Complexity rises leading to higher cost and risk • Higher complexity of development • Higher complexity of management and tuning • Redundancy increases

  48. Exercise • Why is performance a harder issue to resolve with n-tier systems than with 1-tier systems? • Identify 10 ways to improve performance in an n-tier system

  49. Example: Resolving scalability in an n-tier architecture • Use faster machine • Increases the ability to do more work in a unit of time by processing tasks more rapidly. • Applies to almost any nodes in the system (from edge servers to database server). • Need to analyse reasons for slow processing to correctly specify machine (i.e. CPU, networking, disk access, memory) • Cluster machines • Splits up workload into managable chunks to obtain more predictible response times. • Applies to Web representation server, Web application server, the data server and the network. • Need to identify and address any data synchronisation issues between clustered machines and select appropriate load balancing mechanisms.

  50. Resolving scalability II • Use dedicated machines • Improves efficiency of a component by using a special purpose machine, which is optimised for a specific function • Applies to edge server, Web presentation server, directory and security servers, the network and the Internet firewall. • Need to balance benefit of dedicated machine against potential increase in network traffic (e.g. use of a centralised message transformation server could increase network load excessively.) • Segment the workload • Services more client requests. improves response time through parallelism • Can be applied to Web presentation server, Web application server, directory and security servers. • Need to balance improved response time against increase network latency and load. Also need to verify that segmentation across multiple machines is better than upgrading the individual server.

More Related