Arsitektur Enterprise: Pertemuan 10-Arsitektur Enterprise Menggunakan TOGAF

Kita telah membahas mengenai architecture dan transformation, pada pembahasan ini akan dibahas kembali mengenai istilah “architecture” dan isinya. Dalam pengantarnya, TOGAF memberikan definisi mengenai “architecture”:

1. “A formal description of a system, or a detailed plan of the system at component level, to guide its implementation.”
2. “The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.”

The first definition considers the term “architecture” as a synonym of “system description.” For the second, “architecture” designates the structure andprinciples of the system, independent of its description.

• This double definition may seem surprising, but it does reflect a very real situation. Software systems are, by nature, opaque, so much so that their structure is only visible through representations.
• Factories, ships, or engines all have a physical structure, which is more or less visible. However, it is impossible to “lift the hood” of an IT system, whose architecture only exists through its representation.
• This is also the case for business elements such as processes, organization, or strategy, which can only be communicated through descriptions or models. The proliferation of schemas, diagrams, and tables within enterprises is testament to this reality.
• In this context, communication on architecture plays a determining role. Just like the blueprints of a building, communication is a vital tool for those working on the different tasks involved: development, evaluation, exchange,and construction.

Domain and Phases

Apa saja subjek utama pada area di dalam enterprise architecture? TOGAF mengusulkan high-level breakdown ke dalam empat bagian besar:

1. Business architecture, yang mencakup strategi, tujuan, proses bisnis,fungsi, dan organisasi.
2. Data architecture, didedikasikan untuk organisasi dan manajemen informasi.
3. Application architecture, menyajikan applications, software components,dan interaksinya.
4. Technology architecture, yang menjelaskan teknik dan komponen yang digunakan, serta jaringan dan infrastruktur fisik tempat aplikasi dan sumber data berjalan..

Architecture repository
Secara alami, enterprises perlu mengkonservasi, menyebar, dan menggunakan kembali informasi EA yang merupakan salah satu aset utama mereka. Ini adalah peran repositori arsitektur, yang mencakup deskripsi dari masing-masing dari empat domain, serta seluruh host pengetahuan, prinsip panduan, dan teknik yang terkait dengan arsitektur enterprise.

Sebelum menjadi sumber informasi yang statis, repository terus berkembang sepanjang transformasi arsitektur, sehingga berpartisipasi dalam kapitalisasi pengetahuan. Ini juga memberikan gambaran arsitektur, yang memfasilitasi pengambilan keputusan pada level strategis.

• Untuk pembaca TOGAF, satu item kosa kata masih harus dijelaskan. TOGAF sering merujuk pada arsitektur solusi. Di sini, istilah "arsitektur" menunjuk deskripsi, dan lebih tepatnya pandangan logis, sebagai lawan dari "solusi," yang mewakili realitas teknis.
• Perbedaan ini dapat dilihat dengan jelas dalam istilah“Architecture Building Block” dan “Solution Building Block”(respectively ABB and SBB). Spesifikasi logis suatu elemenadalah ABB, sedangkan padanan fisiknya adalah SBB. Keduajenis elemen ini ada dalam repositori arsitektur, yangmemungkinkan dokumentasi atau komponen fisik untukdigunakan kembali, sesuai dengan konteksnya.
  

Goals, constraints, and requirements
Agar berhasil melakukan operasi transformasi, kita harus benar-benar jelas tentang hasil yang ingin kita dapatkan. Pernyataan ini mungkin tampak sepele, tetapi perlu diingat. Dalam domain ini, TOGAF membedakan serangkaian elemen yang berpartisipasi dalam formalisasi yang lebih terstruktur:

• Strategic objectives, or goals, yang menggambarkan orientasi umum.
• Operational objectives, or objectives, yang memformalkan tujuan-tujuan ini dalam hasil yang terukur.
• Drivers, yang sering memotivasi keputusan mengenai perubahan arsitektur, seperti perubahan dugaan atau kebutuhan untuk beradaptasi dengan evolusi teknis. Inilah "mengapa", yang membenarkan dan mengarahkan tujuan.
• Requirements, yang menentukan dengan tepat apa yang akan diterapkan secara konkret untuk mencapai tujuan-tujuan ini.
• Constraints, yang merupakan elemen eksternal yang mempengaruhi sistem,terkadang menahan kapasitasnya

Stakeholders and the human factor

• We know that the organizational aspect is one of the most delicate points in this type of operation. Like any enterprise process, architecture transformation involves a combination of activities involving different participants, each one of them a “stakeholder” in the operation he or she undertakes. TOGAF deals with this question through the following themes:

1. Stakeholder management
2. Transformation Readiness Assessment
3. Efficiency of communication through the concept of viewpoints

1. Managing Stakeholder

First, it is essential to clearly define each stakeholder as early as possible during the ADM cycle. This identification mainly uses a pragmatic approach in order to avoid simply reusing existing organizational structures, which only partially represent the reality of the activities and responsibilities that will be put in motion. Leaving a key participant by the wayside would significantly affect the quality of the results.

Consequently, in order to determine with whom and in what form work will be carried out, a series of key questions must be answered on the subject:
• Who defines goals?
• Who gains and who loses from this change?
• Who controls the transformation process?
• Who designs new systems?
• Who will make the decisions?
• Who procures IT systems and who decides what to buy?
• Who controls resources?
• Who has or controls the necessary specialist skills?
• Who influences the project?

From these questions, TOGAF recommends that the position of each stakeholder be clarified, notably his or her degree of involvement. The Figure presents these different degrees. Each stakeholder will be positioned using these degrees of involvement, which determine the relationships to develop and the level of involvement in architecture project steering committees. Naturally, key players play a determining role and must be on the front line in all areas of decision making.

This qualification is cross-referenced with the role played in the context of the current project:

• The executive management, who defines strategic goals
• The client, who is responsible for the allocated budget, with regard to the expected goals
• The user, who directly interacts with the system in the course of his or her activities
• The provider, who delivers the component elements of the architecture, notably its software components
• The sponsor, who drives and guides the work
• The enterprise architect, who turns business goals into reality within the structure of the system

2. Transformation Readiness Assessment

• Is the organization ready for the envisaged change? This question may seem incongruous, but how many projects have finished unsuccessfully because this dimension was not taken into account? In just a few years, “change management” has become a discipline in its own right, producing a large number of articles and seminars.
• TOGAF is entirely dedicated to this question, which is widely discussed in the description of the ADM phases. The identification of change resistance risks and the definition of actions to take to limit these risks are essential tasks that must be carried out before embarking upon a transformation project. This is particularly important for an operation covering a broad scope and resulting in significant restructuring.
• While it is not possible to provide turnkey solutions on such a subject, it ispossible to use certain techniques that will help reduce this type of risk:
  

1. A clear presentation of the impacts of changes made, notably on an organizational level
2. A concrete view of the expected business benefits, in the form of “business cases”
3. An objective assessment of the enterprise’s IT, business, and financial aptitudes, with no over estimation of its real capacities
4. An executive management team recognized as being able to defend the project in the long term
5. High-quality communication, which aims to promote a common understanding of the stakes and the solutions to implement

3. Views and viewpoints

• If a message is to be successfully understood, the most important aspect to consider is that its content and form must be tailored to the intended
• For this, TOGAF uses the concept of viewpoints. A viewpoint designates the most appropriate perspective for a given participant, and is materialized by a certain number of views of the architecture, in the form of diagrams, documents, or other elements. For example, executive management will be more interested in a high-level description, while communication with operational staff will require much more detailed recipient. representations.
• This is a critical point, one that will condition the quality ofcommunication and that will be encountered during eachphase of the ADM cycle. Consequently, it is imperative thatviews and viewpoints be defined for each stakeholder beforebeginning work on the four architecture domains (business,data, application, and technology).

Latihan Pertemuan 10