Transcript Slide 1
X36SSP Správa softwarových produktů 3. přednáška Ing. Martin Molhanec ČVUT – FEL K13113 IT Architecture (ITA) • Co je to ITA? • Jaká je struktura ITA? • Stručná historie ITA. What is IT architecture? • Architecture is the important stuff. If you ask a system's expert what is important, their response defines the architecture. • The architecture of a system is the highest level of shared understanding of that system by the experts who create it. • It is the main parts of the system that need to be understood so that the system, the main components, and how they relate and interact can be understood. • An architecture is whatever the expert designers find important at the top level; the architecture drills down into important details while less important ones are determined at lower levels of design. How IBM defines IT architecture? • Information technology (IT) architecture is the fundamental organization of a software-intensive system. • A system is software-intensive because the most prominent part of an IT architecture is its applications, the part that enables the users perform their business tasks. How IBM defines IT architecture? • Besides applications, there are other aspects to IT architecture. • The applications in an IT architecture require infrastructure, a foundation to run on. This foundation is made up of hardware-server computers, desktop workstations, storage, and networking. • It's also made up of server software, including middlewareapplication servers, database servers, messaging systems, workflow engines, and rules engines. • Data is stored in this foundation, managed as an asset, and made available by controlled access to multiple applications. • This foundation is also the host for integration solutions to let applications communicate with each other. IBM defines the following six architecture disciplines: • Enterprise architecture. An enterprise architect focuses on mapping IT capabilities to business needs. The architect is responsible for an enterprise's full range of software-intensive systems, including the relationship between multiple applications, data shared between applications, integration of the applications, and the infrastructure to run applications. • Application architecture. An application architect focuses on the design of applications to automate business processes and provide functionality that helps users perform business tasks. The architect's responsibilities include designing the application to meet user functional and quality of service requirements including performance, availability, scalability, security, and integrity. Responsibilities also include evaluating and selecting the software and hardware necessary to run the application, as well as the tools and methodologies to develop the application. IBM defines the following six architecture disciplines: • Information architecture. An information architect focuses on the data used by multiple applications, including the structure, integrity, security, and accessibility of that data. The architect's responsibilities include designing, building, testing, installing, operating, and maintaining the systems for managing that data. Design of these systems must account for data requirements such as source, location, integrity, availability, performance, and age. • Infrastructure architecture. An infrastructure architect focuses on the design of hardware and server software including server computers, storage, workstations, middleware, non-application software, networks, and the physical facilities that support the applications and business processes required by the enterprise. The architect's responsibilities include evaluation and selection of these components; modeling, simulating, and testing to validate the designs and selected products; and performance, availability and scalability of the resulting infrastructure. IBM defines the following six architecture disciplines: • Integration architecture. An integration architect focuses on the design of solutions that enable existing applications, packaged software offerings, networks, and systems to work together within an enterprise or among enterprises. These solutions may use different technologies, vendors, platforms, and styles of computing. • Operations architecture. An operations architect focuses on the design of solutions to manage the infrastructure and applications used by the enterprise. The architect's responsibilities include defining plans, strategies, and architectures for the installation, operation, migration, and management of complex information systems. The relationship between the six architectural disciplines. Why architecture matters • Architecture is important because every system has one. • Sometimes an architecture is developed before any part of the system is implemented. • Other times, system implementation takes place without formal definition of an architecture. • Most cases fall between these two extremes. • However, even in the latter scenario, the system has an architecture, and in the software world, more often than not, the system architecture becomes apparent only after the system is built. There are three general types of these nonarchitected architectures, each with its own derogatory yet memorable name: • • • – – – Big ball of mud (a.k.a. Shantytown) This kind of system contains large segments that are unused. Yet the unused parts are so enmeshed with everything else that they're impossible to identify, much less remove. Spaghetti This is a system with no logical flow, where any part may be connected to any other part. In such a case, most of the parts share some dependency on many or most of the other parts, even if such dependencies make little difference to the overall functionality of the system. House of cards With this non-architecture, every part depends on many others, so that a change to one part breaks several, and fixing one problem introduces many more. The role of an IT architect • An architect is the person responsible for developing the architecture and ensuring that it is created. • Although an individual architect could do all of the work, the development usually involves a team approach. • In this sense, the architect is like the coach of a team, the conductor of an orchestra, or the director of a film. • The architect's vision of the system to be created becomes the plan for the team to create it. What skills are required of an IT architect? • IT architects must see the big picture, understand the main parts, and know how they fit together. • IT architects need to be able to balance conflicting needs, such as requirements, budget, manpower, and timeframe. • They need to look at what the system must do. • They must also anticipate future needs and the problems the system may face and prepare for how to resolve those problems. • Architects must be able to develop a vision, then communicate that vision to the team and motivate its members to enact it. A brief history of architecture • Mainframes. – The first applications ran on one central computer. Users connected through dumb terminals or teletype machines. Architecture was simple: The application did everything beyond the operating system. For persistence, there was no external database like IBM DB2® or Oracle--the application stored its data in files itself. There were no messaging systems, no GUIs, no shared data, and no interaction between applications. A brief history of architecture • Workstations. – As desktop computers became common, so did applications that ran on them. These are personal productivity applications like VisiCalc, WordPerfect (now published by Corel Corporation), and the Microsoft® Office applications. These were personal applications; each user ran a locally installed copy and quit it after its use. No data was shared; it was stored in files on local disk and only distributed by sneaker-net. A brief history of architecture • Networking. – Networks connected workstations to each other, to shared server computers, and to mainframe-style central processing computers. This enabled email capability within an enterprise and sharing files on a file server. A brief history of architecture • Client/server. – Networking enabled client/server computing, where the application no longer ran completely on a central computer or on a workstation, but was split across the two. Original client/server applications ran on the workstation but accessed centralized data from a database server. Later architectures split the application itself into two parts: a shared component for business logic that ran on the server and local clients that implemented the user interface. The need to host this central business logic led to the development of application servers for running and managing the server part of the application. A brief history of architecture • N-tier. – A client/server architecture is said to be a two-tier architecture. When the database server runs on a different host computer from the application server, that's a three-tier architecture. As network-based applications became more sophisticated, designers divided the application stack--from the GUI to the database--into more processes on both the client and the server. Such a multiple-tier design became generically known as an n-tier architecture. A brief history of architecture • Internet. – The Internet is networking on steroids, a global network. The Internet is actually older than the networks in most enterprises, but it was impractical to access it in the business world until an enterprise constructed an internal network that could connect to the Internet. The Internet enabled communications and information sharing not just between users in an enterprise, but between users anywhere in the world. A brief history of architecture • World Wide Web. – The Web made the Internet graphical. It enabled authors to publish words and pictures--using Hypertext Markup Language (HTML)--as a combined document that could be viewed by anyone anywhere in the world. These HTML documents contained hyperlinks to other documents, so any reference to another document became active and provided the reader direct access to the referenced source. This was the beginning of information on demand, to links being as important as nodes. A brief history of architecture • Browser GUIs. – The Web introduced HTML browsers for viewing static HTML documents. This paradigm was quickly adapted to provide interactive GUIs for accessing remote applications. This was a return to the centralized computing model. It wasn't actually a client/server model, because practically none of the application ran on the client except for HTML rendering and some simple scripting. Even the validation of input values had to be performed on the server. A brief history of architecture • Web services. – The Internet was created to connect applications, but the Web connected people to static content and to server applications. Web services use the Web to connect applications so that one application can invoke behavior in another application through a Web connection. A brief history of architecture • Web 2.0. Tim O'Reilly provided a compact definition of Web 2.0 in 2006: – This is the application of Web services to Web sites. The user of a Web site is no longer a person, it's another application. "Web 2.0 is the business revolution in the computer industry caused by the move to the internet as platform, and an attempt to understand the rules for success on that new platform. Chief among those rules is this: Build applications that harness network effects to get better the more people use them." A brief history of architecture • Service-Oriented Architecture (SOA). – Applications have tended to be monolithic, running entirely either on a central computer or on a workstation. Client/server and n-tier architectures distributed application layers; browser GUIs moved the application back to the server. Even with n-tier architectures, this architecture was still rather monolithic because the run-time stack is self-contained; applications at best interacted as peers. SOA divides an application into a service coordinator (the top set of consumers in a composite application) that represents user functionality and service providers that implement the functionality. While the coordinator tends to be unique to a particular application, a service can be reused and shared by multiple composite applications. A brief history of architecture • Event-driven architecture. – With SOA, the service coordinator explicitly specifies and invokes the desired services. With event-driven architecture (EDA), an application detects an event and emits a notification; other applications have handlers that can receive the notifications and react by invoking services. In this way, the detection application doesn't have to know all the services it should invoke in response to an event; it can simply announce the event and let the other applications decide which services to invoke in response. A brief history of architecture • Virtualization – Virtualization makes resources logical, hiding their implementation structure. • Grid – Grid computing pools resources and distributes tasks optimally. • Autonomic computing – Autonomic computing enables a system to be self-healing, dynamically adjusting in response to demand and problems. Závěr • Současné IT systémy jsou čím dál více složitější. • Velké IT systémy jsou také silně heterogenní. • Velké IT systémy jsou částí obchodních, výrobních, organizací služeb, státní správy, armády a školství systémů. IT architektura je konceptuálním vyjádřením struktury a koncepce IT složitých systémů.