2 Enterprise architecture Di banyak perusahaan,perangkat lunak dan perangkat keras merupakan bagian yang signifikan dari total aset perusahaan. Tujuan mendasar adalah untuk mendukung dan memajukan tujuan bisnis dari perusahaan. Hardware dan software pada dasarnya bersifat untuk memajukan tujuan bisnis
3 Enterprise architecture model BussinessInformationOperationalOrganizationalArchitecturalInfrastuctural
4 Considered as Systems Architecture best practices Know the business processes that the systems architecture is supporting. Know them inside and out.Keep support of those business processes first and foremost on your agenda. Know what the business needs and keep the business side aware of your accomplishments.Know the components in your systems architecture: all the machines, applications, network connections, and so on.Instrument, your system. That is, install monitoring and measurement systems that allow you to find the problem areas and the bottlenecks.
5 Considered as Systems Architecture best practices Attack the cheap and easy problems first. That will build and help maintain credibility and trust with the business side of your company.Prioritize and be proactive. If you are not constrained to produce immediate results, identify the most important systems architecture problems and attack them first, even before they become problems. Good system measurements are key to being able to identify problem areas in your systems architecture and to establish the most effective means to deal with them.
6 Considered as Systems Architecture best practices Know all your stakeholders. The people aspects of your systems architecture are at least as important as the machinesOnly buy as much security as you need. Give up on the idea of becoming invulnerable. Prioritize your security issues into A, B, and C lists
7 Three Important aspects to Emphasize about Systems Architecture It must align (selaras) with the business goals of the organization.It must provide what the stakeholders need to perform their functions. This is a two-way street. The architecture team should take responsibility to establish communication with systems architecture stakeholders and to understand their issues.The software and hardware infrastructure of an enterprise is a major asset that must be managed to provide the greatest return on that investment.
8 Software Architecture Arsitektur Software dari sebuah sistem memiliki pengaruh pada kualitas dari arsitektur organisasi enterpriceSementara desain dari software sistem berkonsentrasi pada terealisasinya fungsi yang dibutuhkan system.
9 Software Architecture Software Architecture dari sebuah system mensupport semua kebutuhan dari systemSebagai contoh system harus terkoneksi dengan wifi atau terjadi perubahan dari bisnis rule enterprice maka software arsitektur dapat beradaptasi.
10 Apa Software Architecture itu? Arsitektur Perangkat lunak suatu program atau sistem komputasi yang memiliki struktur sistem, yang meliputi komponen perangkat lunak, yang terlihat nyata , serta hubungan diantarnya.
11 Apa Software Architecture itu? Arsitektur Perangkat lunak adalah satu set konsep dan keputusan disain tentang struktur dan tekstur perangkat lunak yang harus dibuat sebelum jadinya sebuah software
12 Peran Arsitek Perangkat lunak (The Role of a Software Architect) Arsitek perangkat lunak mempunyai pekerjaan yang paling sulit dalam merancang suatu perangkat lunakIa harus mempunyai kepercayaan dari semua stakeholdersKepercayaan ini didasarkan pada track record dari proyek yang sukses dikerjakannya
13 Peran Arsitek Perangkat lunak Arsitek harus mampu berkomunikasi dengan semua komponen dalam suatuArsitek harus memiliki kemampuan dalam mendisain, kemampuan teknologi, dan mengerti tentang aplikasi perangkat lunak
14 Mengapa kita butuh Arsitektur PL? Sama halnya peta, tujuan dari arsitektur PL adalah untuk mengabarkan/menginformasikan pemahaman perancangan sistem kepada timuntuk mengkomunikasikan suatu gagasan.membawa ke dalam perangkat lunak dan menjelaskan konsep yang penting.membantu mereka memahami aspek yang penting dari sistem dan memberi mereka nilai rasa suatu sistem tanpa benar-benar melihat kedalamnya.
15 Dua pendekatan dalam Pengembangan Software Software development approaches vary between two extremesThe first method involves little or no upfront modeling or designThis is the "shanty town" method of system development in which a few developers code without a mental picture in their heads about the system they are building.
16 First methodSome managers believe that if developers aren't coding, they aren't workingThese project managers also believe that the sooner developers begin coding, the sooner they will be done.This stems from the incorrect belief that a constant amount of time is involved in the coding of the system no matter what upfront process is used.
17 First methodIn this type of environment, developers don't fully understand the requirements for the system. Some of these environments deliver decent software through heroics by developers and frequent rewrites, although this approach is not repeatable, and it is extremely risky.
18 Second method"ivory tower" software architecture in which a design team or a single architect design a system in every detail, down to the class and method level.The architect has a clear picture in his or her head about the design of the system but has not left many of the implementation details to the developers.
19 Second methodThe belief in these environments is that the architects are the most experienced developers and thus can design the best possible system from start to finish.No one person or small team can possibly understand all the requirements, predict every change in requirements, and have expertise in every technology that the project is built upon.
20 Second methodDevelopers in these environments also suffer from low morale because they are perceived as somehow inferior to the designers of the system.Morale is also poor because the developers must implement the design in a prescriptive way with little or no input into the design of the system.
21 The Middle of the RoadSo what does all this have to do with software architecture? Software architecture is the middle road between no design and complete design.It is a view of the system design that shows how the design satisfies the critical requirements of the system.
22 The Middle of the RoadIt is the role of the software architect to design the structures of the software such that those critical requirements are satisfied. It is also the goal of the software architecture to facilitate the development of the system by multiple teams in parallel.
23 The Middle of the RoadIn addition, if multiple teams or departments within an organization will support and maintain the software, the software architecture will allow those parts of the system to be managed and maintained separately. The most important role that the software architecture has is that of an organizing concept for the system.
24 The Middle of the RoadThe software architect has an idea how the system should work.The software architecture is the communication of that idea to other system stakeholders so that everyone understands what the system does and how it does it.
25 The Middle of the RoadIn a practical sense, two rules determine whether or not a design detail should be included in the software architecture:The design detail must support a quality requirement.The design detail must not detract (mengurangi) from stakeholder understanding of the software architecture.
26 The System Stakeholders Many people believe that the software architecture is meant only for developers to use as an overall guide for system design and construction.While this may be the software architecture's primary purpose, other system stakeholders can use the architecture as a basis to guide their activities as well. The following are some of the system stakeholders:
27 The System Stakeholders DevelopersManagersSoftware architectsData administratorsSystem customersOperationsMarketingFinanceEnd-usersGeneral managementSubcontractorsTesting and quality assuranceUI designersInfrastructure administratorsProcess administratorsDocumentation specialistsEnterprise architects
28 The System Stakeholders The software architect must elicit (menimbulkan/memunculkan) input from all the system stakeholders to fully understand the requirements for the architecture.This is important because the requirements are built from the perspective of what the system should do. However, the architecture must reflect how the system will perform those functions.
29 The System Stakeholders The system's customers want the system to be of high quality.They want the system to be delivered in a timely manner. And they want it to be developed as inexpensively as possible.
30 The System Stakeholders The development organization is looking for a vision for the system it is going to design and develop.It wants to know that the architecture is easy to implement. It has hard deadlines that it must meet, so reusability is important.The developers are going to be looking for technologies in the architecture that they currently understand.
31 The System Stakeholders They want the architecture to match their desired platforms, development tools, libraries, and frameworks.They need to meet dates, so the architecture should ease their development effort.Most of all, they want an architecture that they have participated in developing and evolving throughout the lifetime of the product.
32 Creating a Software Architecture: An Example The architects on the project faced a difficult job.They realized that the software architecture is implemented at the beginning, middle, and end of every project.However, much more emphasis is on it at the beginning of every project.
33 Creating a Software Architecture: An Example Before the architects started, they created a checklist of principles they would strive to follow while they created the architecture:The architecture should be thin.The architecture should be approachable.The architecture should be readable.The architecture should be understandable.The architecture should be credible.
34 Creating a Software Architecture: An Example The architecture doesn't have to be perfect.Don't do big upfront design. If given a choice between making the model perfect or implementing it, implement it.Do the simplest thing that could possibly work without precluding future requirements.The architecture is a shared asset.Involve all stakeholders but maintain control.The architecture team should be small.Remember the difference between a pig and a chicken.
35 referenceJames McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, Elias K. Jo , 2003, “A Practical Guide to Enterprise Architecture”, Prentice Hall PTR