#zachman

[jestre]

Speaking of characters, did somebody say retro replays of classic games? (Streamed nostalgic gaming series soon!) http://twitch.tv/jestre_derama

[eacoe]

How to Choose the Right Enterprise Architecture Framework (Without Getting Stuck in Framework Wars)

Framework selection paralyzes more enterprise architecture programs than almost anything else. TOGAF, Zachman, FEAF, a homegrown hybrid, teams spend months debating the choice as if picking the "right" framework will make everything else fall into place.

It won't.

And that belief is often the real problem.

Start with the Right Mental Model

A framework is a tool, like a wrench.

The wrench doesn't fix the engine. The mechanic does.

The most rigorous framework in the world, in untrained hands, produces an expensive binder full of diagrams that nobody uses. A modest framework in skilled hands can deliver meaningful business results.

That perspective takes the pressure off framework selection and shifts attention to the factors that actually determine success.

Three Questions That Actually Matter

Instead of asking, "Which framework is best?", ask:

1. What problem are we trying to solve?

Portfolio rationalization, AI readiness, merger integration and governance modernization are different challenges. Start with the business problem, not the framework brand.

2. Who needs to use the output?

If stakeholders won't read or act on the artifacts, additional rigor creates little value. Match the framework approach to the audience and decision-makers.

3. Do we have people who can successfully execute it?

This is the question organizations skip most often.

A framework only creates value when practitioners know how to apply it effectively. Without the right skills, even the best methodology becomes shelfware.

A Practical Example

Consider a 200-person software company trying to rationalize an application portfolio that has grown through acquisitions.

They may not need the most comprehensive or process-heavy framework available. They need a capability-based approach that they can realistically execute with their existing team and resources.

In this situation, a lightweight, fit-for-purpose framework paired with a skilled architect will typically outperform a sophisticated enterprise methodology that nobody internally can sustain.

By contrast, a federal agency operating under strict governance requirements may benefit from a more formal architecture framework.

Same question. Different answer.

Because the answer depends on the problem, the stakeholders and the organization's maturity, not on which framework has the strongest marketing.

Think Beyond the Framework

Successful architects view frameworks as scaffolding: useful, valuable and necessary in many situations, but not the building itself.

They remain tool-agnostic and focus on developing the capabilities required to model, analyze, govern and deliver change effectively.

Framework knowledge matters.

Practitioner capability matters more.

Key Takeaway

Choose a framework that aligns with your business objectives, stakeholder needs and organizational maturity.

Then stop optimizing the wrench and start training the mechanic.

The framework is the starting point.

The practice is what produces results.

EACOE helps architects develop practical, implementation-focused skills that work across TOGAF, FEAF, Zachman and hybrid enterprise architecture approaches. The goal is not framework loyalty. The goal is delivering measurable business outcomes and helping organizations Succeed Fast.

Learn more at https://www.eacoe.org/

[eacoe]

The Zachman Framework's Six Questions, Explained Simply

The Zachman Framework's six questions are often presented as part of a complex-looking grid. That can make the framework seem intimidating. In reality, the foundation is surprisingly simple.

At its core, the Zachman Framework is built around six questions that journalists, investigators, and business leaders ask every day. Understand those questions, and you understand the backbone of enterprise architecture.

The Six Questions

The Zachman Framework's six questions organize everything needed to describe an enterprise:

WhatThe data and things the enterprise cares about, such as customers, products, orders, and invoices.

HowThe processes, functions, and activities the enterprise performs.

WhereThe locations, networks, and operating environments across which the enterprise functions.

WhoThe people, teams, stakeholders, and organizational roles are involved.

WhenThe timing, events, schedules, business cycles, and triggers that drive activity.

WhyThe motivations, goals, business rules, strategies, and objectives behind everything the enterprise does.

Answer these six questions thoroughly and you've described the essential elements of the enterprise. Few aspects of an organization fall outside these categories.

The Clever Part: Perspectives

The six questions are only half of the framework.

The Zachman Framework also organizes information across multiple perspectives, from the executive view at the top, through business and system perspectives, down to the technology and implementation levels.

The same six questions are asked from every perspective. Each level adds detail without contradicting the levels above it.

This structure helps create a complete and consistent architectural description. Each architectural artifact is intended to have a unique place within the framework, reducing redundancy and confusion while improving traceability across the enterprise.

A Simple Use Case

Imagine you're trying to improve a broken order-to-cash process.

Using the Zachman Framework, you would ask:

What data is involved? (Orders, invoices, customers, payments)

How does the process flow?

Where does the process occur across systems and locations?

Who owns or performs each step?

When do key events occur?

Why does the process exist and what business objective does it support?

By answering all six questions at the appropriate level of detail, you gain a complete picture of the process and can identify gaps, bottlenecks, ownership issues, or system failures.

What the Diagrams Won't Tell You

Here's the important part.

The Zachman Framework is a classification scheme (taxonomy), not a methodology. It helps organize architectural descriptions, but it does not prescribe a step-by-step process for creating them.

Knowing the framework is easy. Producing accurate, useful answers about a real organization is where the real work begins.

That skill comes from experience, practice, mentoring, and continuous feedback, not from memorizing rows and columns.

Key Takeaway

The Zachman Framework's six questions provide a structured way to ensure nothing important is overlooked when describing an enterprise.

By asking What, How, Where, Who, When, and Why across multiple perspectives, organizations can build a complete, consistent, and non-redundant understanding of how the enterprise operates.

The challenge isn't memorizing the framework. The challenge is answering the questions accurately.

EACOE's connection to the Zachman tradition is particularly strong through our Managing Director, Sam Holcman, who serves as President of the Zachman Institute (ZIFA). Our approach focuses on helping practitioners learn how to model real enterprises through hands-on application, mentoring, and practical experience so they can truly Succeed Fast.

Learn more about enterprise architecture training, mentoring, and Zachman-based modeling at eacoe.org

[mabufadda]

Pleased to be on the architecture discussion panel with John #Zachman representing DEWA ENTERPRISE & IT ARCHITECTURE WORLD SUMMIT, NEW YORK (at New York, New York) https://www.instagram.com/p/BqviqtxH_sSDXpZ5eUEuMy1zsD0RICdLeqYvUs0/?utm_source=ig_tumblr_share&igshid=1ndn5se6ojg3o

[sebuahdiskusi]

IMPLEMENTASI ARCHITECTURE DEVELOPMENT METHOD(ADM)

Architecture Development Method(ADM) merupakan salah satu komponen TOGAF sebagai kerangka kerja Enterprise Architecture(EA), ADM menggambarkan metode untuk membangun EA dan merupakan core dari TOGAF.  Struktur dasar dari ADM terdiri dari fase-fase berikut:

Preliminary,

Architecture Vision,

Business Architecture,

Information System Architecture,

Technology Architecture,

Opportunities and Solutions,

Implementation Governance,

Architecture Change Management.

Setiap fase pada ADM cycle, dapat didekomposisi dalam beberapa langkah yang lebih detil. Namun langkah-langkah tersebut tidak dibahas dalam diskusi ini.

Implementasi dari tiap fase dalam ADM cycle dapat dilakukan secara terpisah antar masing-masing fase, atau dilakukan dalam bentuk kelompok-kelompok fase. Kapan sebaiknya tiap fase ADM dieksekusi per fase atau per kelompok fase, dapat ditentukan oleh beberapa kondisi. Pada beberapa organisasi, telah ditentukan petunjuk teknis atau petunjuk pelaksanaan dalam menjalankan suatu proses bisnis, sehingga eksekusi fase ADM harus selaras dan mengakomodasi pengendalian proses yang telah berlaku atau disepakati pada organisasi tersebut.

Jumlah, tingkat dan tipe dari stakeholder menentukan bagaimana fase ADM dieksekusi. Penyajian laporan eksekusi proyek untuk stakeholder dengan kekuasaan untuk dapat menentukan diterima atau tidaknya suatu pekerjaan dan mempunyai antusiasme yang tinggi dalam suatu proses, tentu saja berbeda dengan penyajian untuk stakeholder yang hanya memedulikan hasil dari suatu proses bisnis. Eksekusi fase ADM yang terkait dengan stakeholder yang mempunyai kekuatan pengambilan keputusan dan antusias tinggi, sebaiknya dilakukan lebih detil dan intensif. Sebaliknya eksekusi fase ADM dengan stakeholder yang kurang antusias dan tidak mempunyai kekuatan untuk mengambil keputusan, dapat dilakukan secara periodik atau merupakan gabungan dari beberapa fase.

Ketersediaan tim dalam waktu yang bersamaan serta tersedianya waktu eksekusi yang disediakan, dapat mempengaruhi bagaimana fase ADM dieksekusi. Apakah seluruh fase ADM dieksekusi oleh satu tim tertentu, atau apakah dapat dilakukan oleh beberapa tim baik secara sekuen atau paralel. Kompleksitas yang muncul terkait dengan penjadwalan proses dan alokasi tim.

Tingkat keberanian organisasi dalam menerima suatu tingkat risiko, menentukan sejauh mana kedalaman eksekusi suatu fase ADM. Misal dalam menentukan kedalaman eksekusi fase Data Architeture, untuk organisasi yang dapat memahami pengelolaan basis data, maka fase ini dapat dieksekusi cukup hingga level tabel, namun pada organisasi yang lain fase ini harus dieksekusi hingga ke level field dan tipe data.

TOGAF menyarankan beberapa kelompok iterasi yang mencoba mengelompokkan fase-fase ADM dalam beberapa kelompok fase sebagai berikut:

Architecture Context Iteration, yang merupakan langkah awal dalam aktivitas pengembangan arsitektur dengan membangun dan menentukan metode pendekatan, prinsip, ruang lingkup dan visi organisasi,

Architecture Definition Iteration, yang menyasar pembangunan konten arsitektur. Iterasi ini secara fokus dan berkelanjutan mencoba membedah arsitektur di level bisnis, sistem informasi yang terdiri dari data dan aplikasi, serta di level teknologi sebagai enabler implementasi konten bisnis dan konten data. Pada iterasi ini terbentuk rencana pengembangan EA yang terpetakan dalam kedalaman dan kelebaran bahasan arsitektur pada rentang waktu yang disepakati, sehingga dapat disimpulkan bahwa pada iterasi ini terbentuk blueprint dan roadmap dalam implementasi EA pada organisasi,

Architecture Transition Planing Iteration, merupakan iterasi yang memastikan kelancaran perubahan yang muncul akibat diimplementasikannya blueprint pengembangan EA,

Architecture Governance Iteration, memberikan dukungan dalam bentuk tata kelola yang harus dipatuhi oleh semua pihak yang terkait dalam implementasi EA. Tata kelola ini mengatur aktivitas-aktivitas dalam pencapaian arsitektur target yang telah ditetapkan.

Hal yang cukup menarik pada penggambaran fase-fase EA diatas adalah, peletakan fase preliminary yang berada diluar cycle. Penjelasan yang cukup menarik bahwa fase preliminary dapat dilakukan sekali untuk beberapa rangkaian cycle eksekusi fase-fase EA. Metode dan prinsip-prinsip implementasi EA dapat dilakukan satu kali untuk beberapa visi arsitektur yang berbeda. Kondisi ini dapat terjadi pada saat suatu prinsip EA telah ditentukan oleh suatu organisasi, maka prinsip ini juga harus dianut oleh semua aktivitas yang disepakati oleh organisasi tersebut.

Hal lain yang menarik adalah implementasi suatu fase ADM, dapat diejawantahkan dalam bentuk satu cycle ADM secara penuh. Misalkan fase business architecture, dapat dieksekusi sebagai suatu siklus lengkap dari fase ADM dalam implementasi proses bisnis tertentu. Selain mengenal sifat iteratif dalam eksekusi fase-fase ADM, maka dikenal juga sifat rekursif dalam masing-masing fase ADM.

Setiap perkembangan pada implementasi fase-fase ADM merupakan implementasi dari Enterprise Continuum. Namun hasil dari implementasi ADM akan mempengaruhi koleksi solusi yang tersedia pada Enterprise Continuum, sehingga Enterprise Continuum dapat dikatakan sebagai “Virtual Repository” yang menyimpan semua aset yang tersedia pada perusahaan, termasuk model arsitektur, pola arsitektur, deskripsi atau artifact-artifact lain yang berada di dalam lingkungan perusahaan maupun yang berada dalam lingkup industri yang lebih luas.

Eksekusi fase-fase ADM yang bersifat iteratif dan rekursif dapat membentuk rangkaian identifikasi, definisi, representasi, spesifikasi dan configurasi yang pada kerangka kerja Zachman dipandang dari perspektif user dan nama model.

gambar dari : Zachman.com

  Implementasi fase-fase ADM sangat erat kaitannya dengan implementasi kerangka kerja Zachman yang juga merupakan salah satu kerangka kerja implementasi EA.

=Zuliansyah=