Teknik stratejiyi iş gereksinimleriyle uyumlu hale getirme

Bulut mimarı olarak ilk göreviniz netlik oluşturmaktır. Anlamlı mimari kararlar verebilmeniz için önce sistemin neleri başarması gerektiğini, kime hizmet etmesi gerektiğini ve hangi kısıtlamalar içinde çalışmanız gerektiğini anlamanız gerekir. Beklenen sonuçları ve işletme tarafından belirlenen sınırları net bir şekilde görüntülemeniz gerekir.

Her karar gerçek baskılara göre şekillendirilir: bütçeler, teslim zaman çizelgeleri, uyumluluk kuralları, performans beklentileri ve hizmet düzeyi taahhütleri. Bunlar isteğe bağlı olarak dikkat edilmesi gereken noktalar değildir. Tasarımınızın karşılaması gereken koşullar bunlar.

Bu faktörleri anlamıyorsanız sistemin hata olasılığı yüksektir. Gereksinimler bazen gerçek ihtiyaçlar yerine varsayımlar olarak başlar. Örneğin, istenen özelliklerin bir listesi olabilir, ancak sistemi strese alacak trafik desenleri hakkında hiçbir şey yoktur. Gelecek yılki büyüme ne olacak? Müşterilere önceden hangi taahhütler verildi?

Bu noktada rolünüz netlik kazanmanıza yardımcı olur. Dikkatle dinlemeniz, isteğin neden var olduğunu sormanız ve gerçek gereksinimleri erken varsayımlardan ayırmanız gerekir. Konuşmaları uygulamaya değil hedeflere geri yönlendirirsiniz. Bir istek gerçekçi olmadığında veya yanlış hizalandığında, yine de istenen sonuca ulaşmak için alternatifler önermeniz gerekir.

Bu makalede, 5 adımlı bir işlemi izleyerek bunu nasıl yapabileceğiniz gösterilmektedir. Bir şey tasarlamadan önce doğru bağlamı toplamayı, doğru soruları sormayı ve paylaşılan bir anlayış oluşturmayı göstermek için bir örnek kullanır. Bu şekilde, yalnızca teknik açıdan sağlam olmayan, aynı zamanda gerçek motivasyonlar, iş baskıları ve uzun vadeli hedeflerle uyumlu mimariler oluşturursunuz. Bu rolü kullanmaya yeni başladıysanız, role ve başarıyı tanımlayan şeylere genel bir bakış için Çözüm mimarının temel bilgileri kılavuzuyla başlamanızı öneririz.

Dinle: Paydaş isteklerini yakalama

Bulut mimarı yeni bir girişime katıldığında, iş paydaşları genellikle istediklerine yönelik bir vizyona ve genellikle bütçe kısıtlamalarına sahip olur. Ürün sahipleri, iş analistleri ve etki alanı uzmanları belgelenmiş gereksinimlere sahip olabilir ve bu içgörülerden bazıları değerli olabilir. Bunları gereksinimler yerine istek olarak kabul edin. İş ekibinin temel alınan motivasyonlar anlaşılmadan çok önce çözüm moduna geçmesi, özellik, araç veya teknoloji kararları istemesi sık karşılaşılan bir durum değildir. Ayrıca erken girişler, küçük ayrıntıların aşırı vurgulandığı ve temel ihtiyaçların göz ardı edildiği çarpık yargılara karşı da savunmasızdır. Bir mimar olarak, iş yükünün netlik eksikliğini, varsayımların gereksinimler için nerede yanlış olduğunu ve bilgilerin eksik veya eksik olduğu yerleri belirleyin.

Her mimari görevlendirme dinlemekle başlar. Bu aşamada, işiniz eleştiri yapmak veya çözmek değildir. İstenen sonuçları benimsemek ve motivasyonların erken belirtilerini fark etmektir. Muhtemelen kendinizi "bana daha fazla anlat" derken bulacaksınız. Belirtilen istekleri, bunların arkasındaki varsayımları ve genellikle "X'i inşa etmemiz gerekiyor" gibi görünen gömülü çözüm önyargılarını belirleyin.

Bu yaygın senaryoyu düşünün. Bir iş ekibi "100% çalışma süresine ihtiyacımız var" diyor. İlk başta, basit bir gereksinim gibi geliyor. Bununla birlikte, yüksek kullanılabilirliği yüksek kaliteyle eşitler veya yakın zaman önce yaşanan bir kesintiye karşı düşüncesiz bir tepki verebilirler ya da rakipler tarafından uygun analiz yapılmadan benimsenen bir eğilimi takip edebilirler.

Bu adımda, iş perspektiflerine saygı duymanız ve iş paydaşlarının endişelerini kapatmamanız önemlidir. İyi dinlemek güven oluşturur ve isteği gerçekten neyin yönlendirdiğini ortaya çıkarmanın temelini oluşturur.

Araştırma: Motivasyonu anlama

İşletmenin ne istediğini temel olarak kavradıktan sonra, bir sonraki adım "neden?" sorusunu sormak ve bunu tekrar tekrar yapmaktır. Amaç, gerçek ihtiyaç yüzeyine gelene kadar araştırma yapmaktır. Sormanın ardındaki baskıları, kısıtlamaları ve teşvikleri anlayın. Çözümün daha geniş iş bağlamı içine nasıl uyduğunu anlamak da aynı derecede önemlidir. Motivasyonu anlamadan, yanlış hedefi hedefleme riskini alırsınız. Aşağıdakiler gibi sorular sorabilirsiniz:

• Geliri destekliyor mu yoksa öncelikli olarak işletmeyi mi destekliyor?
• Kuruluşun temel bir bölümünü etkiliyor mu yoksa bir niş sorunu mu ele alıyor?
• Bu bir üretim sorununu mu gideriyor?
• Rekabet veya pazar değişimleri tarafından mı sürülmektedir?
• Uyumluluk için gerekli mi?
• Daha geniş bir stratejik yönün parçası mı?

Motivasyon önemlidir çünkü iki benzer istek çok farklı amaçları temsil edebilir. Yasal bir son tarihi karşılamak için gereken bir özellik, yeni bir büyüme fırsatı ortaya çıkarma amaçlı mimari yaklaşımdan farklı bir yaklaşım gerektirir.

Örniğe geri döndüğünüzde, yoklama, son zamanlarda yaşanan bir kesintinin siparişlerin kaybolmasına neden olduğunu ortaya çıkarır. Bir rakip artık gerçek zamanlı sipariş kullanılabilirliğini tanıtıyor ve yöneticiler başka bir hatadan marka hasarından korkuyor. Ayrıca, ödeme süreci çöktüğünde müşteri desteği aşırı yüklenir.

Bu noktada "100% çalışma süresi" farklı bir anlama gelir. Gerçek etmen mükemmellik değildir, gelir açısından kritik akışlar için iş sürekliliğidir, özellikle de ödeme.

Bu adımda çözümlere karar vermiyorsunuz. Mimariyi doğru iş bağlamında tutturabilmeniz için isteğin arkasındaki güçleri ortaya çıkarıyorsunuz.

Netleştirin: İstekleri gereksinimlere çevirin

Motivasyonlar net bir şekilde belirlendikten sonra, bir sonraki adım işletmenin gerçekten neye ihtiyaç duyduğunu netleştirmektir. burada işletmenin motivasyonlarını veya isteklerini somut sonuçlara ve ölçülebilir gereksinimlere çevirebilirsiniz.

Örnekte, daha ayrıntılı bir şekilde inceleyin ve aşağıdakiler gibi kullanıcılar üzerinde etki konusunda fikir birliği elde edin:

• Hangi kullanıcı akışları her zaman kullanılabilir olmalıdır?
• İkincil akış geçici olarak kapatılırsa ne olur?
• Geliri etkileyen işlevler hangileridir?
• Kabul edilebilir düşüş modları nelerdir?

Bu adımda "100% çalışma süresi" akış düzeyi gereksinimlerine ayrılır:

• Sipariş verme. Yüksek oranda kullanılabilir olmalıdır. Kapalı kalma süresi geliri doğrudan etkiler.
• Katalog Gezinme. Kritik zarar vermeden kısa süreli olarak bozulabilir.
• Sipariş geçmişi. Planlı bakımı tolere edebilir.

Bunların henüz mimari seçimleri değil, iş sonuçları olduğunu unutmayın. Gereksinimleri netleştirme, "Her şeyi her zaman kullanılabilir hale getir" ile "Değer oluşturan akışların sürekliliğini sağlama" gereksinimini yeniden çerçeveler.

Bazı iş gereksinimleri, açık tartışma gerektiren diğer gereksinimleri örtük olarak getirir. Veri ikamet yeri, güvenlik standartları, veri saklama veya diğer endüstri standartları gibi gereksinimler gözden kaçabilir çünkü paydaşlar bunların anlaşıldığını veya geçerli olduğunu fark etmeyebilirler. Sürecin başlarında bu gereksinimleri belirleyin ve açıkça belgeleyin.

Değerlendirme: Test fizibilitesi, kısıtlamalar ve dengeler

Gereksinimler tanımlandığında, bir sonraki adım bu ihtiyaçların uygulamada ve sabit ve esnek kısıtlamalar içinde nasıl karşılandığını değerlendirmektir. Bu adım teknik ve operasyonel fizibilite, maliyet etkileri, riskler ve kuruluşunuzun standartlarına uyum hakkındadır. Mühendislik yargısını ve mimari deneyimi burada getirirsiniz. Kısıtlamaları ayıklayarak ve başarıyı tanımlayarak başlayın. Gerçekten önemli olan şeylere odaklanın, fazla mühendislikten kaçının ve daha basit bir çözümün ne zaman yeterli olduğunu bilin.

Yüksek kullanılabilirlik örneğine devam ederek aşağıdaki gibi dengelemeleri gerçekleştirin:

• Maliyet: Çok bölgeli etkin-etkin mimari, altyapı harcamalarını ikiye katlar.
• Mühendislik karmaşıklığı: Bölgeler arası durum çoğaltımı basit değildir.
• Güvenlik ve uyumluluk: Birden çok bölgede veri yerleşimi endişeleri ortaya konur.
• Operasyonel çalışma: 7/24 nöbet rotasyonları ve sofistike yük devretme süreçleri.

Her yanıtın kaçınılmaz olarak "bağlıdır" ile başladığı nokta budur. Değerlendirme genellikle işletmenin istedikleriyle pratik olan arasındaki uyuşmazlıkları ortaya çıkarır. İşletmenin "100% çalışma süresi"nin gerçekte ne istediğini anlamasına yardımcı olur. Ödeme akışının çok bölgeli dağıtımı haklı çıkardığını, ancak katalog ve sipariş geçmişinin bunu gerektirmediğini fark edebilirsiniz. Ayrıca, olgunlaşmamış ekip özellikleri, fazla tahmini avantajlar veya hafife alınan maliyetler gibi riskleri ortaya çıkarabilirsiniz. Ayrıca maliyeti, karmaşıklığı ve güvenilirliği daha iyi dengeleyen alternatif yaklaşımlar uygulama fırsatlarını da ortaya çıkarabilirsiniz. Örneğin, kataloğu bir CDN'de önbelleğe almak, dengelemeler bu akış için uygun olduğunda bu dengeyi sağlayabilir.

Henüz teknolojiyi seçemediğiniz için. Bu adım sınırları tanımlamayla ilgilidir. Buna eşleme kısıtları, ödünleşimleri vurgulamak ve çözüm alanını gerçek dünya koşullarında belirginleştirilmiş gereksinimleri karşılayacak yaklaşımlara daraltmak dahildir. Perspektifleri birleştirmek ve bir yol üzerinde anlaşmak için işbirliğine dayalı bir yaklaşım getirin.

Öneri: Teknik stratejiyi önerme

Fizibilite ve dengeler anlaşıldıktan sonra, bir sonraki adım gerçek iş gereksinimleriyle uyumlu teknoloji seçimleri ve diğer kararları önermektir. Bu, bulma sırasında yakalanan bilgileri işletmenin istediği, gerçekten ihtiyaç duydukları ve derlemeyi önerdiğiniz şeyler arasındaki döngünün kapatılmasını sağlayan net, eyleme dönüştürülebilir bir yöne dönüştürmek anlamına gelir. Her öneri bir müzakere, bir uzlaşma ve zaman içinde daha iyi hale getirme fırsatıdır.

Öneriniz belgelenmeli ve şu konuları ele almalıdır:

• Netleştirilmiş gereksinimleri karşılama
• Değerlendirme sırasında tanımlanan kısıtlamaları ve dengeleri yansıtma
• Seçenekleri ve bunların etkilerini paydaşlara net bir şekilde iletme

Çalışma süresi örneğine geri dönersek, bir öneri şu şekilde olabilir:

Ödeme işlemi, geliri korumak için çok bölgeli aktif-aktif bir yapılandırmada çalıştırılmalıdır. Katalog hizmetleri, dirençlilik için okuma amaçlı çoğaltmalarla tek bir bölgede çalıştırılabilir. Sipariş geçmişi, planlı bakım pencereleriyle tek bölgeli olarak kalabilir. Bu yaklaşım gereksiz yineleme ve maliyetten kaçınırken süreklilik gereksinimini de karşılayacaktır."

Bu son adım gibi görünse de, aslında yinelemeli bir işlemdir ve her tasarım kilometre taşında paydaş geri bildirimleri, takas tartışmaları ve anlaşma yoluyla kararların iyileştirilmiş olduğu tasarım sürecinin başlangıcını işaret eder.

Beklenen sonuç

Bu aşamada, dinleme ve gereksinimleri toplama sürecini tamamladınız, bulgularınızı işletmeyle paylaştınız ve yol boyunca ortaya çıkan hedefler, kapsam ve iyileştirmeler üzerine hizalandınız. Bu içgörüler doğal olarak özgün iş gereksinimlerinde ayarlamalara ve erken tasarım konularının oluşmasına yol açar. Bu netlikle, artık net ve topraklanmış işlevsel belirtim üretmeye yardımcı olmak için gereken bilgilere sahipsiniz. Bu belgeye genellikle ürün paydaşları sahip olsa da, mimarlar yakalanan bilgilerin yapısını şekillendirmeye yardımcı olarak ve güçlü bir teknik tasarım için gereken netliği sağlayarak önemli bir destekleyici rol oynar.

Bu belge, iş yükünün veya özelliğin neleri başarması gerektiğini ve neden önemli olduğunu tanımlar. Başarıyı tanımlayan ölçülebilir sonuçlarla çözülen iş sorunlarını açıklamalıdır. Bu öğeler, sonraki tüm teknik tasarım çalışmalarına yol gösterecek temeli oluşturur.

Bu aşamada iyi geliştirilmiş bir işlevsel belirtim şunları içermelidir:

• Kapsam içinde ve kapsam dışında olan, belirsizliği azaltan ve kapsam kaymasını önleyen sınırlar sağlayan net bir tanım.
• Değişikliği değerlendirmek ve iş hedeflerine bağlamak için kullanılacak ölçümler ve başarı ölçütleri.
• Ayrıntılı kullanıcı süreçleri, gerekli görüldüğünde düşük sadakatli taslaklar tarafından desteklenmektedir, hataların veya özel durumların beklenen şekilde işlenmesi dahil.
• Erişilebilirlik, uyumluluk, performans, gizlilik veya güvenlikle ilgili tüm gereksinimler.
• Aşamalı dağıtım veya hedeflenen beta sürümü gibi tanımlı bir dağıtım stratejisi.

Mimari hiçbir zaman tek seferlik bir etkinlik değildir. Birden çok zaman ufkunu göz önünde bulundurarak: 1. Gün, yakın vadeli büyüme ve uzun vadeli ölçek. Büyüme eşiklerinin kararları ve ödünleri yeniden gözden geçirmeyi gerektirebileceği noktaya yönelik plan yaparken, çok erken aşamada aşırı mühendislikten kaçının. İlk tasarımların en düşük güvenilir özellikleri yakalaması kabul edilebilir bir durumdur, ancak sonraki her döngü gözlenen kullanıma, değişen önceliklere ve yeni iş hedeflerine göre mimariyi iyileştirmektedir. Bu belirtimi ve diğerlerini evrimi yansıtacak şekilde güncelleştirin ve tüm paydaşları aynı sayfada tutun.

Belirtimleri teslim etmek sürekli, işbirliğine dayalı bir süreçtir. Mimarlar uygulama boyunca iş paydaşları ve teknik ekiplerle etkin bir şekilde etkileşimde kalarak tasarımların doğru yorumlanmasını, risklerin yönetilmesini ve sonuçta elde edilen sistemin iş hedeflerine uygun olmasını sağlamaya yardımcı olur. Ayrıntılar için bkz. İş yükü ve platform ekipleriyle işbirliği yapma.

Sonraki Adımlar

İş gereksinimleri konusunda fikir birliği elde ettiğinize ve işlevsel belirtim kapsamında belgelendiğine göre, tasarım seçimlerini açıklayan ve diyagramların eşlik ettiği ayrıntılı bir teknik belirtim yazmaya başlayın.

Mimari tasarım belirtimi geliştirme