Scrum - Software Architect (Yazılım Mimarı)

Giriş
Yazılım Mimarı rolü Scrum' da tanımlı değil. Bu rolü ekipteki herkesin ortak bir şekilde oynaması isteniyor. Bence bu fikir çok makul değil, hatta belki Scrum' daki zayıflıklardan bir tanesi.

1. Yazılımı Kim İnşa Eder?

Cevaplar şöyle

A) UX designer

B) Architect;

C) UX designer ve Architect 

D) Developer

1.1 Sadece Architect Cevabı

Eğer sadece B cevabını veriyorsak bu cevapla ilgili bir açıklama şöyle. Yazılım User Story' lere bölündüğü ve bunu yazılımcılar geliştirdiği için mimari de biraz buna göre şekilleniyor.

If you choose B, I would argue that building software is not like constructing a building. It’s much more complex, you can’t copy and paste a lot. ... However, when software is broken down into user stories or tasks, they are very different and need so much intelligence. Some development teams don’t have an architect role at all.

1.2 UX designer + Architect Cevabı

Açıklaması şöyle. Bu ikilinin mimarisi, yazılımcılar tarafından benimsenmeyebiliyor.

What I found in my personal experiences is when BA is keen on giving suggestions or estimation in technical details, their contribution to software design and implementation quickly become chaos or be treated as a conspiracy act. They either overlook the technical risk or their technical knowledge is decayed.

1.3 Developer Cevabı

Aslında developer 'ın kattığı şeyler mimariyi şeyler mimariyi şekillendirse de sadece budur demek mümkün değil.

1.4 Cevap

UX designer + Architect + Developer :) Yani herkes. Açıklaması şöyle

In my software development and consulting career, I do see a few shining moments, when BA was working together with developers to create very good software design activity and conversations. Sometimes BA was drawing their mind in a piece of paper with endangered UML language; sometimes BA was doing a role play to explain the business scenario, the developers pick those messages up and translate them into some workable software. Harmonious!

2. Peki Yazılım Mimar Neden Lazım

Yazılım mimari ne değildir sorusuna cevap vermekle başlayabiliriz. Yazılım mimarı şu değildir.

Senior Developer

Firefighter

Project Manager

Scientist

2.1 Bilgi Temeli - Broad and deep technical knowledge

- Yazılım Mimarları diğer projeleri bildikleri için tekerleğin yeniden icat edilmesine müsaade etmezler. Gerekli bilginin bir başka projeden aktarılmasını sağlarlar. Eğer her proje benzer bir işi sil baştan yaparsa mimara zaten gerek kalmaz.

- Yani bazı genel kural ve kararları mimar(lar) alması/önermesi ve bir probleme birden fazla çözüm getirebilmesi beklenir. Yani çözümleri artı ve eksileriyle karşılaştırabilmelidirler.

2.2 İletişim - Communicability
- Mimar satış, müşteri, geliştirme ekibi ile sürekli temas içindedir.

- 10+ büyüklükteki ekiplerde takımlar arasında arayüz oluşturmak gerekiyor ve normal bu rolü mimar yerine getirir.

- Tasarım kararlarını açıklamak her zaman zor bir iştir. Architect 'in birazcık kararları diğer insanlara 

satabilme/beğendirebilme kabiliyeti olması gerekir.

- Bence yazılım mimarlarının oynadığı bir diğer önemli rol ise üst yönetimin bazen dar/kısmi olan bakış açısını değiştirmek. Açıklaması şöyle.

...there is an often valuable role of middle managers in counter-balancing the sometimes narrow view of senior leaders. 

2.3 Problem Çözebilme

Bu yetenek çoğunlukla ön plan çıkmıyor. Projelerde yazılım mimarı zor problemlere elini sürmüyormuş gibi görünüyor. Ancak aslında bu işe de dahil olması ve şu özelliklere de sahip olması gerekiyor.

Unrelenting willpower : Kolay vazgeçmemek

Breaking big problems into chunks : Problemleri yalıtarak çözebilmek

Big picture : Sadece yazılımı değil, çalıştığı ortamı, müşteriyi, donanımı vs. gibi daha büyük resmi görebilmek

Methodical : Problemleri rastgele değil, daha metodik yöntemlerle çözmeye çalışmak. Örneği tüm olasılıkları denemek ve karşılaştırmak

2.4 Diğer

Diğer bazı maddeler şöyle.

- Responsibility
- Stress resistance
- Management skills
- Analytic skills

3. Diğer Architect Unvanları

Şeklen şöyle

Genel açıklama şöyle. Yani Solution Architect daha özelleşmiş durumda

Enterprise architect: Plan for a wide view on required components for the enterprise at strategic level with big picture for long term development

Solution architect: Plan for a particular solution / building block within the big picture (e.g. the enterprise data warehouse solution)

Enterprise architect çeşitleri şöyle

Chief Enterprise Architect — Chief EA is responsible for the overall enterprise architecture and monitoring all the domain EAs

Domain Enterprise Architect — Focusing on specific domain, e.g. finance / sales, and responsible for the EA to build out the defined business visions

Solution Architect — As mentioned above, solution architecture creates the overall technical vision for a specific solution to a business problem defined in the enterprise architecture under the domain

Application Architect — Next level of solution architecture, focus on creating and maintaining documentation surrounding the software architecture, application design processes, component integration, testing guidelines and other key elements

Except the solution / domain focus architects, there are number of architects responsible for very technical focus on cloud, infrastructure (e.g. Network, Hardware) and security (e.g. Authentication protocol, encryption standard, key vault).

Cloud Architect — responsible for cloud adoption plans, cloud application design, and cloud management and monitoring

Infrastructure Architect- responsible for designing and implementing information systems to fit with a business’ existing infrastructure and initiatives

Security Architect- responsible for overseeing the security of an enterprise’s network, encryption standard, key management