Yazar Arşivi: Mustafa Ulus

Bilgi Teknolojileri Projelerinde Kurumsal Mimari ve Proje Yönetimi Yaklaşımlarının Etkileşimleri Üzerine Bir Literatür Araştırması

ÖZET
Kurumsal Mimari, kurumun hedef stratejileri ve Bilgi Teknolojileri (BT) sistemleri arasındaki ilişkiyi yöneten bir belgedir. Bu kapsamda; yalnızca mevcut yapıyı yönetmekle kalmayıp, kurumun gelecek planlarını destekleyecek BT altyapısınının belirlenmesinden ve bir projeksiyon oluşturulmasından sorumludur. Proje Yönetimi ise, kurum stratejilerine hizmet eden çıktılara sahip proje kavramına ait gereksinimlerin karşılanması amacıyla; bilgi, beceri, araç ve tekniklerin proje faaliyetlerine uygulanmasıdır. Bu makalede, kurum stratejilerinin hayata geçirilmesi ve bu sürecin yönetişiminin sağlanması konularında farklı seviyelerde sorumluluk ve etki alanlarına sahip bu iki disiplinin, birbirleriyle olan etkileşimleri ve ortak çıktıları üzerine bir araştırma yapılacaktır. Bu sayede, Proje Yönetimi ve Kurumsal Mimari birimlerinin, stratejilerin hayata geçirilmesi sürecindeki olası iş birlikleri hakkında farkındalık oluşturulması amaçlanmaktadır.

ABSTRACT
Enterprise Architecture is a document that governs the relationship between the organization’s target strategies and IT systems. In this context; not only does it manage the existing structure, it is also responsible for determining the IT infrastructure that will support the future plans of the organization and creating a projection. Project Management, in order to meet the requirements of the project concept with the outputs that serve the corporate strategies; application of knowledge, skills, tools and techniques to project activities. In this article, a study will be carried out on the interactions and common outcomes of these two disciplines with different levels of responsibility and impact in the implementation of
organizational strategies and the governance of this process. In this way, it is aimed to raise awareness about possible cooperation in the process of realization of strategies in Project Management and Enterprise Architecture units.

  1. GİRİŞ

Bilgi Teknolojileri (BT)’nin stratejik rolü ve organizasyon içindeki önemi, karmaşıklığı, çeşitliliği ve değişim gereksinimini arttırır. Bu nedenle, BT yönetimi farklı, çelişkili ve sürekli değişen taleplerden kaynaklanan belirsizliklerle baş etmek zorundadır. Bu anlamda, Kurumsal Mimari (KM) BT yönetimi uygulamalarının geliştirilmesinde giderek daha önemli bir rol oynamaktadır. Eğer çağdaş organizasyonlar mimari meseleleri yönetmeyi başaramazlarsa, kayda değer kaynaklara ulaşılmaksızın kayda değer kaynakların yatırılması konusunda net bir risk oluşacaktır (Pessi ve diğerleri, 2011). Bu makale, Kurumsal Mimari ilkelerinin büyük kuruluşlar bağlamında BT yatırımlarının yönetimini nasıl etkilediğini incelemektedir. Makalenin amacı, iki önemli ilke türünün aydınlatılması yoluyla EA ile Proje Yönetimi (PY) arasındaki ilişkiye daha derin bir öngörü kazandırmaktır.
KM çalışma alanı 30 yıl önce ortaya çıkmış olmasına rağmen, çoğu KM uygulayıcısı yapılan yatırımdan elde edilen değeri göremediğinden günümüzde güvenilirlik sorunuyla karşı karşıya kalmaktadır (Kaisler ve Armour, 2017). Literatürde çok sayıda değer iddiası vardır, ancak bunlar genellikle ampirik kanıtlarla açıklanmamakta veya desteklenmemektedir (Niemi ve Pekkola, 2016; Tamm ve diğerleri, 2011). Kuruluşların KM değerini net bir şekilde anlamaları gerekmesinin iki temel nedeni vardır (Rodrigues ve Amaral, 2010) :
1- KM girişimlerinin getirilerine erişmek ve risklerini anlamak,
2- Çeşitli paydaşları farklı değer beklentileriyle eşit konuma getirmek.

Çoğu BT organizasyonunun hedeflerini belirleyen ve yeni donanım ve yazılım sistemlerinin edinimini ve geliştirilmesini yöneten grupları vardır. İyi hizalanmış bir organizasyonda, BT organizasyonu amaçlarını ve önceliklerini kurumsal strateji ve planlama gruplarından alacaktır. Bu, BT projelerinin rutin olarak kurumsal hedefleri desteklediğini garanti eder. Çoğu organizasyonda eksik olan, kurumsal stratejistlerin ve BT proje yöneticilerinin kaygıları arasında boşluğu doldurabilecek bir mekanizmadır (Buchanan ve Soley, 2002). Bu kapsamda KM’nin BT projelerinde önemli bir rol sahibi olan Proje Yönetimi (PY) disiplini ile sorumluluklarının kesiştiği ve zaman zaman sürtüşmelere neden olduğu noktalar bulunmaktadır. Bu gibi durumlarda BT projelerininn yürütülmesiyle ilgili sorunlar yaşanmakta ve süreçlerin icrasında aksaklıklar oluşmaktadır. Araştırma, KM ve PY değerlerinin net bir şekilde anlaşılmasını ve olası iş birliklerinin ortaya çıkartılmasını amaçlamaktadır. Bu makale, KM ve PY kavramlarının kökeninin derinlemesine incelenmesiyle ile başlar. Daha sonra, KM ve PY yaklaşımlarının ilişkilerini analiz ederek tartışır. Son olarak ise, bu etkileşimden doğan güç çatışmalarının engellenmesi ve iş birliği oluşturarak kurum çıkarlarının üst seviyeye taşınmasıyla ilgili tavsiyelerle sona ermektedir.

2. YÖNTEM

Bu çalışma, Bilgi Teknolojileri projerlerinde iki önemli rol sahibi olan Proje Yönetimi ve Kurumsal Mimari disiplinleri arasındaki etkileşimlerin incelenmesini ve irdelenmesini kapsamaktadır. Bu yönüyle çalışmda Proje Yönetimi kavramı bütünsel olarak ele
alınmayıp, Bilgi Teknolojileri projeleri kapsamıyla sınırlandırılmıştır. Çalışmada “Derleme Yöntemi” kullanılmış, bu yöntemle, alanında uzman kişiler tarafından araştırma konusuyla doğrudan ilişkili çalışmaların sınıflandırılması ve değerlendirilmesinin yapılarak konuya özel sentezlere ulaşılması amaçlanmıştır. Araştırma yönteminin e-yayın literatür tarama aşaması, internet veri tabanlarında ve Google Akademik, Microsoft Akademik ve ScienceOpen arama motorunda ilgili anahtar kelimeler ile sorgulama yapılarak gerçekleştirilmiştir. Tarama sonucunda elde edilen çalışmalarda konu üzerindeki tartışmalı noktalar ve analizler yeniden yorumlanmıştır.

3. KURUMSAL MİMARİ

Bilgi ve iletişim teknolojilerindeki gelişmeler bilginin paylaşılması, verilerin depolanması ve işlenmesi, haberleşmenin sağlanması, servis, uygulamalar ve altyapının yönetilmesinde hem süreçleri hem de yöntemleri değiştirmektedir. Bu değişimler iş yapma yöntem ve süreçlerini etkilemekte ve değişimler iyi yönetilemediği zaman sistem karmaşıklığı artmaktadır. Kurumsal mimari (KM, Enterprise Architecture) organizasyonların, kurumların karmaşıklığını azaltarak düzenli bir sistem ortaya koymak, birbirini tekrar eden gereksiz süreçlerin oluşmasını önlemek, birimler arasındaki iletişimi artırarak işbirliği sağlamak, iş birimleri ile bilgi teknolojileri arasındaki bağlantıyı kurmak ve organizasyonel değişimleri yönetmek için kullanılan bir yöntemdir. Uluslararası çalışmalara bakacak olursak kurumsal mimari kavramı ilk olarak Dr. Steven H. Spewak’ın “Enterprise Architecture Planning” adlı kitabında 1992 yılında ortaya konulmuştur. John Zachman kurumsal mimari çerçeve yapısı 1987 yılında “Bilgi Sistem Mimari Çerçeve Yapısı” olarak oluşturulmuş ve 1996 yılına kadar da bu adla anılmıştır.
Kurumsal mimari, kurumun hedef ve stratejileri ile BT (Bilgi Teknolojileri) sistemleri arasındaki ilişkiyi yöneten ve kurumda kullanılması gereken teknolojilere yön veren bir modelleme yaklaşımıdır. Kurumsal mimarinin temel işlevi; kurumun hedefleri, yapısı, işleyişi, kullandığı sistemler ve sistemlerde kullanılan teknolojiler hakkında bilgi vermek ve bunları yönetmektir. Bu kapsamda, yalnızca mevcut yapıyı yönetmekle kalmayıp, kurumun gelecek planlarını destekleyecek BT altyapısını belirlemekten ve projeksiyon oluşturmaktan da sorumludur. Yani özetle, büyük resme bakarak iş ve teknoloji öncelikleri arasındaki uyumu sağlamayı ve daima daha fazla değer elde etmeyi amaçlayan bir felsefeye sahiptir (kurumsalmimari.org, 2015).

  • Kurumsal mimarinin temel hedeflerini ve bunlara bağlı olarak elde edilecek faydalar aşağıdaki şekilde sıralanmaktadır :
  • BT karar alma sürecine katkı sağlama
  • Kurum içerisine manuel veya otomatikleştirme olarak dağılmış iş süreçlerini, değişikliklere hızlı yanıt veren ve stratejileri hayata geçirmeyi destekleyen, entegre ve standartlara uygun bir ortam haline getirme
  • BT verimliliği ve iş süreçlerindeki yenilikler arasındaki dengeyi sağlama
  • BT envanterini oluşturmak ve devamlılığını sağlama
  • Bağımsız iş birimlerine, kendi hedefleri dahilinde oyun alanı ve rekabet avantajı sunma
  • İş birimleri arasında sinerji oluşmasına altyapı sağlama

Kurumsal Mimari ile ilgili bir çok çerçeve iş yapış şekli mevcuttur, ancak bunlardan en kabul görmüş olan The Open Group tarafından yayımlanan TOGAF (The Open Group Architecture Framework)’dır. TOGAF’ın en önemli bileşeni ise ADM (Architecture Development Method, Mimari Geliştirme Metodu) olarak belirtilmektedir. Proje Yönetimi için Project Management Institute tarafından yayınlanan PMBOK (Project Management Body of Knowledge)’da olduğu gibi, TOGAF ADM’de de uçtan uca bir Kurumsal Mimari süreci işletilmesi için gerekli adımlar ve bu adımların birbirleriyle etkileşimleri açıklanmaktadır. ADM, bir kuruluşun iş ve BT ihtiyaçlarını karşılamak için gerekli TOGAF unsurlarını ve diğer mevcut mimari varlıkları birleştirir (TOGAF v9.1, The Open Group).

Şekil-1: TOGAF Mimari Geliştirme Metodu (The Open Group)

Dikkat edilmesi gereken en önemli nokta, kurumsal mimarinin varlık nedeninin aslında kurum stratejilerine daha kolay ulaşılmasını sağlamak, yani iş süreçlerine hizmet etmek olduğudur. Bu kapsamda, kurumsal mimarinin en önemli katkısı, kuruma ait BT (Bilgi Teknolojileri) kabiliyetlerini ve fonksiyonlarını net bir biçimde tanımlamasıdır. BT uygulama envanterini yönetmek ve altyapı katmanı ile aralarındaki ilişkileri görünür hale getirmek, kurumsal mimarinin asıl amacı olmaktan ziyade; iş süreçlerinin etkin bir biçimde işletilebilmesi için yürüttüğü destek faaliyetleridir.

4. PROJE YÖNETİMİ

Proje yönetimi metodolojisi; Project Management Institute tarafından bir projede kullanılan yöntemler, teknikler, prosedürler, kurallar, şablonlar ve en iyi uygulamalar kümesi olarak tanımlanır (Project Management Institute, 2008). Charvat (2003), proje yönetimi metodolojisini, belirli bir duruma uyarlanabilecek ve uygulanabilecek ve çoğu zaman görev listeleri kadar basit şekilde yönetilebilecek bir dizi kılavuz ve ilke olarak tanımlamaktadır. Benzer şekilde, Gane (2001), proje yönetimi metodolojisini bilgi perspektifinden, proje süresince kullanılan görevler, teknikler, teslimatlar, roller ve araçlar hakkında bilgi seti olarak tanımlamaktadır. Introna and Whitley (1997) ise proje yönetimi metodolojisini, belirli bir problemi çözmek için kullanılan yapısal teknik ve araçlar kümesi olarak tanımlamaktadır. Proje yönetimi metodolojisinin en kapsamlı tanımı Cockburn (2003) tarafından, proje sonucunu başarılı bir şekilde sunmak için proje yönetim ekibinin dayandığı herhangi bir prensip olarak yapılmıştır.
Projeler tanımı gereği birbirinden farklıdır; ancak yönetim süreçleri tüm projeler için aynıdır (Newell ve Grashina, 2004: 5). Proje yönetim süreçleri başlatma, planlama, yürütme, izleme ve denetim, bitirme olmak üzere beş gruptur ve bu beş yönetim süreç grubu genellikle her projede aynı sırayla yerine getirilmektedir. Süreçler uygulama alanlarından ve sektörlerden bağımsızdır. Bir süreç grubu, bir sürecin sonucunun ya da çıktısının bir diğerinin girdisi olduğu karşılıklı girdi ve çıktılarla birbirine bağlanmış proje yönetimi süreçlerinden oluşmaktadır. (Project Management Institute, 2008a: 19) Her bir süreç grubu ve bunları oluşturan süreçler proje tamamlanıncaya kadar birkaç kez tekrarlanabilir. Proje yönetiminin öncelikli görevi, tüm proje hedeflerine, amaçlarına ve kısıtlamalarına ulaşmaktır. Bu bilgiler genellikle, projenin başında oluşturulan canlı bir belge olan bir kullanıcı veya proje kılavuzunda açıklanmaktadır. Başlıca kısıtlamalar; kapsam, zaman, kalite ve bütçedir (Wikipedia).

Şekil-2: Proje Yönetimi Süreç Grupları (Project Management Institute)

Yüksek kaliteli projeler ortaya koyabilmek için gereken proje yönetiminin karakteristik özellikleri şunlardır (Cleland ve King, 1983):

  • Proje yönetimiyle işletmedeki olağan örgüt yapısının dışına çıkılarak yatay bir hiyerarşi dâhilinde fonksiyonlar arası kaynaklar tek bir amaç doğrultusunda yönlendirilir.
  • Proje yönetimiyle fonksiyonel ve yönetim birimleri arasında ağ iletişimi kurulur.
  • Proje yöneticisi bir anlamda genel müdür sorumluluklarına sahip olsa da tek bir amaca odaklandığından etkinliği ve hâkimiyeti daha yüksektir.
  • Proje doğası gereği sınırlı sürede tamamlanır; ancak sağlıklı bir örgütte projeler birbirini takip eder.
  • Bir projede örgütün birden fazla alt birimi, genellikle de tüm örgüt birimleri işbirliği içinde çalışır.
  • Proje, işletmenin herhangi bir biriminden kaynaklanabilir. Örneğin teknoloji ağırlıklı bir proje Ar-Ge Departmanı’ndan, pazarlama ağırlıklı bir proje ise Pazarlama Departmanı’ndan doğabilir.
  • Proje yönetiminde çalışanların hem proje hem de fonksiyonel yöneticisine rapor verdiği ikili bir zincir söz konusudur.
  • Projelerde farklı disiplinlerden çalışanlar bir araya gelir ve bu ekipler proje amaçlarına proje yöneticisi tarafından yönlendirilirler.

Proje yönetim olgunluğunun ilk seviyesinde ortak bir dil oluşturulmaktadır. Proje yönetimi alanında PMBOK ortak terminoloji kaynağı olarak kullanılmaktadır. Sonraki seviyede işletme bir projede kazandığı deneyimi diğer projelere aktarmak üzere ortak süreçler tanımlamaktadır. Üçüncü düzeyde işletmeler tüm metodolojilerin bir araya gelmesi ile proje yönetiminin özünü oluşturan tek bir metodolojiyi benimsemektedir. Sonraki düzeyde işletme sürdürülebilir rekabet için kıyaslama yapmaya başlamaktadır. Son düzeyde ise sürekli iyileşme amaçlanmaktadır. Bu düzeylerin sırayla ayrı ayrı yaşanması gerekmemektedir. Örneğin işletme ortak bir dil oluştururken süreçlerini tanımlayabilir veya metodoloji oluştururken kıyaslama da yapabilir (Kerzner, 2005).

5. KURUMSAL MİMARİ’NİN DİĞER DİSİPLİNLERLE ETKİLEŞİMİ

Kurumsal Mimari izole edilmiş ve faaliyetlerini tek başına yürüten bir disiplin değildir, başarıya ulaşması için diğer disiplinlerin yardımı olmadan başarıya ulaşması mümkün değildir. Ayrıca, temel yönetim disiplinlerinin arasındaki uyum ve iş birliğininin yüksek olması, kurumun hedeflerine ulaşmada önem taşımaktadır. Kurumsal Mimari bu noktada devreye girerek merkezi bir rol oynamaktadır.
Mark Lankhorst’a göre kurumların, aynı hedeflerle iş yapmak için aynı disiplinleri aynı istenen sonuçlarla aynı hizaya getirerek, aynı yöne işaret etmeleri için tutarlı bir iş dönüşüm yönetimi (business transformation management) yeteneği geliştirmeleri gerekir. Bu yetenek, ilgili disiplinler arasındaki değişim çabalarını koordine eder ve uyumlu hale getirir. Bu, kurumun yapısının ve gelişiminin farklı bakış açılarından net bir görüntüsünü gerektirir. Bu kapsamda iş dönüşüm yönetimi çerçevesinde, kurumsal mimari ile doğrudan etkileşimi bulunan aşağıdaki disiplinler karşımıza çıkmaktadır :

  • Strateji geliştirme
  • Yetenek tabanlı planlama
  • Kurumsal portföy yönetimi
  • Program ve proje yönetimi
  • Sürekli teslimat
  • Servis yönetimi
  • Süreç, kural ve veri yönetimi
  • Yönetim, risk ve uyum
Şekil-3: Kurumsal Mimari’nin Diğer Disiplinlerle Etkileşimleri (Oord, 2015)

Herhangi bir organizasyonda piramidin tepesindeki yönetim disiplini stratejik planlamadır. Stratejik planlama, “istenen bir geleceği öngörmek ve bu vizyonu geniş bir şekilde tanımlanmış hedeflere veya hedeflere ve bu hedeflere ulaşmak için bir dizi adımlara dönüştürmek” için sistematik bir süreç olarak tanımlanabilir (businessdictionary.com). Bu nedenle stratejik planlamanın önemi, kurumsal mimariyi ana organizasyon amaçları ve stratejilerle birlikte sağlamaktır.(Oord, 2015).

Şekil-4: Kurumsal Mimari ve Proje Yönetimi’nin Strateji Yürütmede Rolleri (Khan, 2016)

Stratejik planlama kurumsal mimariden gelen girdilere dayanır. Yeni fırsatlar yaratan iş dünyası, teknolojik eğilimler ve mevcut iş ve BT ortamından kaynaklanan sınırlamalar hakkında bilgi sahibi olmadan, stratejik planlama gelecekteki işi yönlendirecek zorlu ama gerçekçi hedeflerin tanımlanmasında gerekli olan girdilerden yoksundur.

Şekil-5: Disiplinlerin Karmaşası (Martin, 2015)

Çözüm mimarları ve kurumsal mimarlar bir kuruluşun teknolojik çerçevesini iyileştirmek için yollar oluşturur ve uygular. Bir çözüm mimarı, bir organizasyon için en iyi uygulamaları ve entegrasyon modellerini geliştirmeye odaklanır. Buna karşılık, bir kurumsal mimar, uygulama, veri ve teknoloji gibi mimarlık alanlarını denetler ve kuruluşun standartlarına uymalarını sağlar. Wikipedia’ya göre çözüm mimarı, tipik olarak çözüm geliştirme ekibinin bir parçasıdır, işlevsel analistler tarafından yaratılan gereksinimleri çözüm için mimariye dönüştürür ve bunu mimari ve tasarım eserleri aracılığıyla açıklar. Geliştirme ekibinin daha sonra çözümü kullanmak için bu varlıkları kullanır.

6. KURUMSAL MİMARİ VE PROJE & PORTFÖY YÖNETİMİ ETKİLEŞİMİ

Kurumsal Mimari (KM) ve Proje Yönetimi (PY), Kurumsal Proje Portföyü’nde çeşitli noktalarda kesişirler. Organizasyona bağlı olarak kesişme, KM’nın prensiplere, standartlara ve kavramsal tasarımlara uygunluğu sağlayacağı gözden geçirme noktaları şeklinde veya bir Mimari İnceleme Kurulu aracılığıyla, mimari açıdan önemli olan ve belirlenmiş kriterleri karşılayan projeler ve programlar için, Proje Yaşam Döngüsünden ayrı olarak işletilir. Hem KM hem de PY, yönetişim organları olarak faaliyet göstermektedir. PY, KM tarafından tanımlandığı şekilde kapsam ve gereksinimler üzerinde veya Mimari İnceleme Kurulu tarafından kararlaştırılan ilkelere, standartlara ve kavramsal tasarımlara bağlı kalarak yürütülmektedir.
Kurumsal Mimari ve Proje Yönetimi’ni, temel olarak altı bileşenden oluşacak şekilde gruplanmaktadır :

Kurumsal Mimari BileşenleriProje Yönetimi Bileşenleri
KabiliyetlerStrateji
İş süreçleriKaynaklar
UyumÜrünler
Yazılımlarİnsiyatifler
BT ServisleriProgramlar
TeknolojiProjeler

Tablo-1: Kurumsal Mimari ve Proje Yönetimi Bileşenleri

Proje Portföy Yönetimi, önerilen projelere öncelik veren ve onaylayan, bütçe ve insan gibi kaynakları bu projelere atayan yönetim disiplinidir. Proje Portföy Yönetimi, projeler arasındaki bağımlılıklar (sağlam bir önceliklendirme için), stratejik hedeflere proje katkısı (onay için) ve projenin etkisi (uygun kaynak tahsisi için) hakkında bilgi sağlamak için kurumsal mimariye güvenir. Bu tek seferlik bir uygulama değildir; gerekmesi durumunda projeler sık sık değerlendirilmeli, değiştirilmeli ya da durdurulmalıdır.
Buna karşılık, Proje Portföy Yönetimi Kurumsal Mimari’ye kurumsal mimarlarının öngördüğü mimari değişiklikleri uygulamak için gereken iş önceliklerini ve kaynaklarını sağlar. Bu önemlidir, çünkü hiçbir kurum ticari önceliklerden bağımsız olarak mimari değişimler gerçekleştiremez, kurumların öncelikleri maddi çıkarlardır.
Kurumsal mimari ile ilgili üçüncü yönetim disiplini Proje Yönetimi’dir. Projeler, Kurumsal Mimari’nin ilkeler, standartlar ve modeller açısından tanımladığı yönergeleri takip etmelidir. Tasarım kararlarının verilmesi gereken yerlerde, mimarlar hangi yöne gideceğini önerir. Bazen mimari direktifler ve tavsiyeler, bireysel bir projeye verilen rahatlamadan daha fazla bir yük gibi görünse de, bir mimari amacı proje maliyetlerini düşürmek ve kurum seviyesinden bakıldığında proje teslim sürelerini azaltmaktır.

Şekil-6: Kurumsal Mimari ve Proje Yönetimi Adımlarının İlişkisi (Khan, 2016)

Buna karşılık, proje yönetimi aslında değişim sağlayan tek disiplindir. Proje yönetimi olmadan, kurumsal mimari asla gerçekleşmeyecek bir rüyadan başka bir şey değildir. Proje yönetimi, stratejik planlama tarafından belirlenen hedeflere katkıda bulunan organizasyonel çevreye yönelik mimari iyileştirmeler sunar.

McIlree’a göre KM ve PY disiplinleri arasındaki farkı niteleyen dört farklı prensip bulunmaktadır :
1- Kurumsal Mimarisi bir proje bileşeni değildir :
Bağımsız bir KM kuruluşunun belirli işlevleri proje bazında değildir, çünkü bazı diğer iş ve teknoloji işlevleri (örneğin muhasebe ve ağ operasyonları) proje değil, devam eden süreçlerdir.

2- Kurumsal Mimarlar BT proje ekiplerine dahil değildir :
Kurumsal Mimari’nin BT proje ekiplerinden uzaklaşması nedeniyle için, bu ekiplere üye olmasına gerek duyulmamaktadır. Bununla birlikte, BT proje ekiplerinin Kurumsal Mimarları konu uzmanları olarak kullanmaları anlamlı olabilir. Mimarlar belirli projelere rehberlik ve danışmanlık ederler, ancak bu ekiplerin üyeleri değildir ve kapsamlarından, zaman çizelgelerinden veya teslim edilmelerinden sorumlu değillerdir.

3- Kurumsal Mimarlar KM çalışmasının kapsam, teslimatlar ve zaman çizelgeleri için sorumludur :

KM departmanı veya grubu kalıcı olsa da, kapsamı ve müteakip iş faaliyetleri ve çıktıları değildir. Çoğu zaman, bu faaliyetler ve çıktılar hem yapılan işlerin türü hem de elde edilen sonuçlar açısından benzersizdir. Diğer iş fonksiyonlarında olduğu gibi, KM de organizasyon için değerini kanıtlamalıdır. KM faaliyetlerinin sponsorları, ilerlemenin sürdüğü ve çabanın finanse edilmesi için tedbirli bir şekilde harcandığı konusunda sürekli olarak güvence altına alınmalıdır. Bu güvenceler genellikle geçici, sözlü olarak çok uzun süre yapılamaz.

4- Bazı KM faaliyetleri proje olarak yönetilir
Proje özelliklerine sahip tüm KM faaliyetleri (süreli geçici işler, benzersiz ürün çıktıları, önemli finansal harcamalar ve riskler) en iyi şekilde bir proje şeklinde ve bir proje yöneticisi tarafından yönetilebilir.

SüreçKurumsal Mimari RolüProje Yönetimi Rolü
Stratejiİşletme ve BT Stratejisinin uyumunu sağlarStratejik planlamayı destekler
YatırımYatırım kararlarını ve BT bütçesi formülasyonunu etkilerBütçe oluşturma sürecini destekler ve yatırımları izler
Yatırım Desteğiİş vakası ve çözümü geliştiren entegre proje ekibinin ayrılmaz üyesiStandartlar, araçlar sunar; kapsam, programlar, bütçe, riskler ve iletişim konularında yardımcı olur
Yatırım Gözden GeçirmeGözden geçirme kurulu üyesidir. Kapsam, zamanlama, maliyetler, riskler vs. gibi konularda proje ve portföy performansını izlerGözden geçirme sürecine liderlik eder. Portföylere yeni projeler ekler, talep, risk / sorun ve performans sorunlarını izler ve raporlar
Satın Alım GözetimiBT satın alımlarının hedef mimariler ve teknoloji standartları yaşam döngüsü ile uyumlu olmasını sağlar. Yeniden kullanım teşvik eder. Satın alma desteği sağlarSatın alma paketinin gelişimini sağlar (alternatif analizi, maliyet tahminleri, RFP’ler ve seçim planı)

Tablo-2: Kurumsal Mimari ve Proje Yönetimi Rolleri Karşılaştırma Tablosu (Khan, 2016)

KM, iş birimlerine veya PY’ye ne yapacaklarını söylemez. KM tartışmayı kolaylaştırır ve nihai vizyonun elde edilmesini sağlamak için uygulanabilir bir iş kırılım yapısı oluşturmak için PY ile iş birimleri arasında bir köprü görevi görür. Doğrudan iş birimleri için çalışan KM; amaç, vizyon, görev, yetenekler, iş hedefleri, kapsam, süreç, fonksiyonel ihtiyaçlar, başarı faktörleri (hedefler) ve iş mimarisini tamamlamak ve diğer teknik gereksinimler gibi iş gereksinimlerini karşılamak için bir mimari oluşturur. BT proje yönetimi ise, iş planlamasını (plan geliştirme, sözleşme yapma, kaynak ihtiyaçlarını koordine etme, planlama, dış kaynak sağlama stratejileri vb.) planlamak için iş mimarisini kullanır. BT proje yönetimi, iş mimarisinde yapılması muhtemel değişiklikleri belirlediğinde, teknoloji kaygıları, stratejiler vb. nedeniyle, iş paydaşının onayladığı düzeltmeleri veya güncellemeleri yapmak için KM ile koordineli olarak çalışır. (Texas Austin Şehri Kurumsal Mimari Ofisi)
Yukarıdakilerden yola çıkarak, kurumsal mimari sadece stratejik planlama, proje portföy yönetimi ve proje yönetimi ile etkileşimde bulunmakla kalmamakta, aynı zamanda bu üç temel yönetim disiplinini birbirine bağlayan merkezi bir merkezdir. Özetle; kurumsal mimari olmadan, proje yönetimi vizyonsuz, proje portföy yönetimi görüş alansız ve stratejik planlama sonuçsuz kalacaktır.

Şekil-7: Planlama ve Mimariye İnsan Merkezli Bir Yaklaşım Getirilmesi (Martin, 2015)

Oja-Gillam’a göre Kurumsal Mimari ve Proje Yönetimi’nin birlikte daha uyumlu çalışabilmesi için öneriler şu şekilde sıralanabilir :

  1. Stratejik Planlama, Proje Portföyü Yönetimi, Kurumsal Mimari Yönetimi, Proje Yönetimi ve Değişim Yönetimi için güçlü bir birleşik yönetim metodu geliştirilmesi.
  2. Mümkün olan yerlerde basitleştirmek için, kuruluş içindeki tüm yönetişim grupları arasında ortak yönetişim noktalarınının belirlenmesi.
  3. Kurumda işbirliği yapmak için Kurumsal Mimari ve Proje Yönetimi’ni destekleyecek belirli bir amaç ve yapıya sahip panolar veya gruplar oluşturulması.
  4. Organizasyonun Proje Portföyü, Değişim Yönetimi, Proje Yönetimi ve Kurumsal Mimari süreçleri ve süreç temas noktaları hakkında incelenmesi, belgelenmesi ve eğitilmesi.
    Zorunlu ve isteğe bağlı teslimatların; kontrol listeleri, şablonlar, temel belgeler ve proje planları / programları içine yerleştirilmesi.
    Proje Portföyü, Kurumsal Mimari, Proje Yönetimi ve Değişim Yönetimi’nin mevcut ve gelecekteki durumu için, standartlar ve yönetişim referans kitaplığının oluşturulması ve güncel tutulması.
    Yönetişim faaliyetlerine uyumsuzluğun sonuçlarının ortaya konulması, gerektiğinde, kuruluş içinde esnekliği sağlamak için bir İstisna Yönetimi sürecinin oluşturulması.

7. SONUÇ VE ÖNERİLER

Bu çalışma, şirket stratejilerinin işletilebilmesi için KM’nin doğru bir yöntem olduğunu göstermektedir, bunun nedeni ise bilgi sistemleri mimarisinin yetenekleri ile işletme mimarisinin sürekli değişen talepleri arasında güçlü bir uyum sağlamasıdır. Önümüzdeki yıllarda şirketlerin hızla değişen teknoloji çağında büyük zorluklarla karşı karşıya kalması kaçınılmaz olarak görülmektedir. Başarılı olanlar, BT faaliyetlerinin şirket hedeflerini desteklediğinden emin olmak için organizasyonlarını, önceliklerini ve geliştirme süreçlerini şirket stratejileriyle sistematik bir şekilde nasıl eşdeğer hale getireceğini bulmak zorundadır. Strateji ile kurumsal planlama ve BT planlama ve proje yönetimi arasında köprü kuran bir kurumsal mimari kullanmak bunu başarmanın önemli bir adımı olarak görülmektedir.

Mark Mcgregor’a göre PMO ve KM arasındaki işbirliğini artırmak ve sürtünmeyi azaltmak için üç eylem planı bulunmaktadır :

  1. Ortak paylaşımların belirlenmesi :
    Üst yönetim yöneticilerin birbirleriyle ne zaman rekabet etmesi gerektiğine karar verirken zorlanmaktadır. İki grup bir sorumluluk için rekabet ettiğinde, bu durum genellikle sorumluluk üçüncü bir gruba verilmesiyle sonuçlanır ve bu her iki ekip için de başarısızlık anlamı taşımaktadır. BT içerisinde hiç kimse projelerin nasıl yürütüleceğini ve avantajların nasıl elde edilebileceğini PY ekibi gibi bilemez, bu nedenle KM proje işinden çıkmalı ve uzmanların bu konuda devam etmesine izin vermelidir. Sonuç olarak projelerin beklenildiği gibi devreye alımı KM’nin itibarının artmasıyla sonuçlanacaktır. Bununla birlikte, PY eğer daha geniş bir programın parçası değilse öncelikli olarak hangi projelerin öncelikli olarak ele alınması gerektiğine karar vermek için doğru bir adres değildir. KM, stratejiye karşı önceliklerin nasıl değişmesi gerektiğini ve neye ihtiyaç duyulduğunu belirlemede öncü olması gereken gruptur (talebin bir süreç değişikliği mi, bir sistem değişikliği mi olduğu vb.) Değişimin yol haritası KM tarafından oluşturulduktan sonra, PY projelerin en iyi şekilde hayata nasıl geçirileceğini değerlendirebilir. Özetle dikkat edilmesi gereken husus; kimin ne zaman aktif sorumluluk alacağını, kiminse beklemede kalacağının net olarak belirlenmesidir. Her iki rol de gerektiğinde sorumluluk alarak sürecin yönetimini üstlenmekten kaçınmamalıdır.
  2. Bütünleşik bir takım olarak hareket edilmesi :
    Potansiyel sonuçlar konusunda ekiplerin ortak görüşler sunması, projelerin finansman aşamasında üst yönetimin kendini daha iyi hissetmesi için önemlidir. Gerekmesi durumunda kötü haberlerin de verilmesi kaçınılmazdır. Eylem detayı ve gerekçeleri olan bir plan sunulduğunda, özellikle de kurumun genel hedeflerinin ne olduğunu ve alınacak kararın bu hedelere ulaşmayı nasıl kolaylaştıracağını gösteren bir yol haritası kapsamında yapıldığında, üst yönetimin insanları görmezden gelmesi daha zor olmaktadır.
  3. Verilerin anlaşılabilir bir hale getirilmesi ve yaygınlaştırılması :
    Birlikte çalışmanın temel unsurlarından biri, iki grubun paylaşılabilir bilgiyi açık, anlaşılabilir ve diğer grup için erişilebilir hale getirmesidir. Çoğunlukla paylaşılması gereken üç bilgi türü: yol haritaları, yetenek modelleri ve portföylerdir. Bu ekosistemde grupların diğer grubun sistemini öğrenmesine gerek olmamalıdır; ideali paylaşılan bu üç türün ve daha fazlasının, grupların birlikte çalıştıkları ortam veya araçlarda tutulmasıdır. Ortak bir anlayış ve referans noktası oluşturma, birçok sorunu ortadan kaldırmak için yeterli olacaktır.

KAYNAKLAR

  1. Ulus M. (2015). Etkin Sonuçlar İçin Yukarıdan Bir Bakış: Kurumsal Mimari Yaklaşımı. Bilgisayar Mühendisleri Odası Dergisi – Sayı 5
  2. Kurumsal Mimari Platformu (2015), Kurumsal Mimari Nedir?
  3. Jonkers H. & Lankhorst M. (2006). Enterprise architecture: Management tool and blueprint for the organisation
  4. Špundak M. (2014). Mixed agile/traditional project management methodology – reality or illusion?. 27th IPMA World Congress
  5. Lankhorst M. (2014), Driving Business Outcomes with Enterprise Architecture as a Knowedge Hub
  6. PMI – Project Management Institute (2017). PMBOK -Project Management Body of Knowledge
  7. Charvat, J. (2003). Project Management Methodologies: Selecting, Implementing, and Supporting Methodologies and Processes for Projects.
  8. Gane, C. (2001). Process Management: Integrating Project Management and Development. In Tinirello, P.C. (Ed.) New Directions in Project Management.
  9. Introna, L. D. & Whitley, E. A. (1997). Against method–ism: Exlopring the limits of method. Information Technology & People
  10. Zachman J. (1987). A framework for information systems architecture. IBM Systems Journal, Vol. 26. No. 3
  11. Oord E. (2015). How enterprise architecture interrelates essential management disciplines
  12. Project Management, Wikipedia
  13. Khan R. (2016) Enterprise Architecture, Project Management & Business Transformation
  14. Understanding Roles between Enterprise Architecture and the Project Management Office, City of Austin Enterprise Architecture Department White Paper (http://www.austintexas.gov/austinea)
  15. Oja-Gillam J. (2016), How Enterprise Architecture and Project Execution Are Linked
  16. Cleland, I. David, W. R. King, (1983). Systems Analysis and Project Management. U.S.A.: McGraw-Hill
  17. Gökçe, S. (2014). Proje Yönetim Bileşenleri ile Belirsizlikten Kaçınma Eğitilimi Arasındaki İlişkiyi Belirlemeye Yönelik TRB1 Bölgesinde Bir Araştırma
  18. TOGAF v9.1, The Open Group
  19. Martin, C. (2015). Re-Positioning the Value of the Architecture Practice. The Open Group
  20. Solutin Architecture, Wikipedia
  21. Brandal, B. How to Move from Business Analyst to Business Architect Read
  22. Kerzner, H. (2005). Using the Project Management Maturity Model, U.S.A.: John Wiley & Sons
  23. Newell, W., Grashina N. (2004), The Project Management Question and Answer Book, U.S.A.: AMACOM Books.
  24. Snel M. (2016), Enterprise Architecture vs Solution Architecture, Knotion Consulting
  25. Mcgregor M. (2018), Why and How Enterprise Architecture and the PMO Should Work Together Better
  26. Gürpınar H. (2012), Bilişim Teknolojilerinde Proje Yönetimi, Radyo ve Televizyon Üst Kurumu Uzmanlık Tezi
  27. Ertaş E. (2011), Bilgi Teknolojileri Tabanlı Proje Yönetim Sistemi ve Uygulaması, Dokuz Eylül Üniversitesi
  28. Gong, Y., Janssen M. (2019), The value of and myths about enterprise architecture, International Journal of Information Management
  29. Rodrigues, L. S., & Amaral, L. (2010). Issues in enterprise architecture value. Journal of Enterprise Architecture
  30. Kaisler, S. H., & Armour, F. (2017). 15 years of Enterprise architecting at HICSS: Revisiting the critical problems. Paper Presented at the 50th Hawaii International Conference on System Sciences.
  31. Niemi, E. I., & Pekkola, S. (2016). Enterprise architecture benefit realization: Review of
  32. the models and a case study of a public organization. The Data Base for Advances in Information Systems, 47(3), 55–80
  33. Tamm, T., Seddon, P. B., Shanks, G., & Reynolds, P. (2011). How does enterprise architecture add value to organisations? Communications of the Association for Information Systems
  34. Meyer, J. W., & Rowan, B. (1977). Institutionalized organizations: Formal structure as myth and ceremony. The American Journal of Sociology
  35. McIlree R. (2011), Where Enterprise Architecture and Project Management Intersect, Agile Zone
  36. Rodrigues, L. S., & Amaral, L. (2010). Issues in enterprise architecture value. Journal of Enterprise Architecture
  37. Buchanan R., Soley R. M. (2002), Aligning Enterprise Architecture and IT Investments with Corporate Goals, Object Management Group Whitepaper
  38. Pessi K. (2012), Enterprise Architecture Principles and their impact on the Management of IT Investments, IT University of Göteborg, Sweden
  39. Pessi K., Magoulas T., Hugoson M. (2011), Enterprise Architecture Principles and their impact on the Management of IT Investments

Yazının orjinali :  http://mustafaulus.com/2019/02/11/bilgi-teknolojileri-projelerinde-kurumsal-mimari-ve-proje-yonetimi-yaklasimlarinin-etkilesimleri-uzerine-bir-literatur-arastirmasi/

Kurumsal Mimari Karar Defteri

Bu yazıda, Yazılım Mimarisi’nde 1990’lardan beri kullanılan Architectural Decision Records (ADR) metodunun Kurumsal Mimari’ye nasıl uyarlanabileceği konusuna değineceğiz..

Yazılım geliştirme süreçlerinde _özellikle orta ve büyük ölçekli projelerde_ uygulamanın yapısı ve bileşenleriyle ilgili mimari kararlar sıklıkla alınmakta. Projenin başlangıç evresinde daha yoğun olarak alınan bu kararlar, genellikle bütün takımı etkiliyor ve tüm üyeler tarafından bilinmesi ve uygulanması büyük önem taşıyor. Projenin sonlarına doğru ise alınan yeni karar sayısı azalırken, daha önce alınan kararların yürürlükten kalkması veya düzenlemeye gidilmesi gündeme geliyor.

ADR burada imdada yetişerek, fazla detaya boğulmadan kararların kolay ve anlaşılır bir dil ile kayıt altında alınmasını ve herkes tarafından kolaylıkla erişilebilmesini sağlıyor. Yazılım projelerinde bu kararlar genellikle ekip içerisinde alınarak, kaynak kodların tutulduğu ortamda (GitLab, TFS vb) saklanıyor. Özellikle son yllarda kurumların girdiği çevik (agile) dönüşümler, süreçlerde oluşturulan “gereksiz” dokümanların ortadan kalkması gibi faydalı bir sonuç doğurdu (çoğu kurumun bunu “sıfır dokümantasyon” olarak biraz yanlış yorumlaması ise ayrı bir yazı konusu). Dolayısıyla ADR gibi gerçekten basit ve kullanışlı bir yöntem daha da değer kazanmaya başladı.

Kurumsal Mimari süreçlerinde de, Yazılım Mimarisi’nde bahsettiğimize benzer bir ihtiyaç mevcut. Genellikle üyeleri Kurumsal Mimari Ekibi ve IT Yönetimi’nden oluşan Mimari Komite tarafından alınan bu kararların (yeni bir uygulamanın satın alınması, bir uygulamanın hayatına son verilmesi, yeni bir teknolojinin veya tekniğin benimsenmesi, network ve donanım altyapısı değişiklikleri vb), kapsama alanı bir yazılım/proje ekibi değil, tüm IT birimleri ve hatta iş birimlerini de kapsayarak kurumun tamamı. Dolayısıyla kararların bir Mimari Karar Defteri’nde kayıt altına alınması daha büyük önem taşıyor.

Karar defteri kullanmamızdaki temel gerekçeleri kısaca listeleyecek olursak :

  1. “Neden?” sorularının kolaylıkla yanıtlayabilmek
  2. Kurumsal hafıza oluşturabilmek ve tarihçeyi görebilmek
  3. Bilgi paylaşımını ve şeffaflığı artırabilmek
  4. Olası tartışma ve anlaşmazlıkların önüne geçebilmek

Peki karar defterimizi tutarken nelere dikkat etmeliyiz?

  1. Kararlar belirli bir şablon ile metin bazlı olarak kayıt altına alınmalıdır (Confluence gibi wiki uygulamalardaki şablon yapıları kullanılabileceği gibi, bir Word dokümanı da iş görecektir)
  2. Her karar, ilgili konu üzerindeki tartışmaları değil, nihai hükmü belirtmelidir (Kaynaklar tartışmaya açılan konuların da bu ortamda kayıt altına alınmasını tavsiye etse de, bu “fikirlerin” başka bir ortamda yönetilmesi gerektiği düşüncesindeyim)
  3. Kararlar tüm çalışanların kolaylıkla erişebileceği bir ortamda bulunmalıdır (Kurumsal Mimari uygulaması, şirket wiki’si, intranet portal, ortak alanda bir klasör vb)
  4. Her karar birkaç sayfayı geçmeyecek yapıda olmalı ve gereksiz bilgi içermemelidir
  5. Her kararın tekil bir karar numarası olmalıdır
  6. Kararlar birbirlerine yaptıkları referansları, karar numaraları üzerinden yapmalıdır
  7. Kararlar yoruma ve olası değişiklik önerilerine açık olmalıdır

Örnek bir mimari karar şablonu :

Karar No: Tekil karar numarası
Tarih : Kararın geçerlilik tarihi
Karar Başlığı : Bir cümle ile kararın kısa ifadesi
Durum : Kabul – İptal – Revizyon
Karar Vericiler : Mimari ekip ve yönetimden ilgili isimler
Karar Kategorisi : Eğer varsa tasnif için bir kategorizasyon
Kararın Gerekçesi : Kararın alınmasındaki nedenler
Karar Metni : Birkaç paragraf ile kararın detayı
Etkileri : Karar sonrasında hayatınızda nelerin değişeceği, yani olumlu ve olumsuz yan etkileri

.
Kaynaklar :
• https://resources.sei.cmu.edu/asset_files/Presentation/2017_017_001_497746.pdf
• http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions
• https://dev9.com/blog-posts/2017/5/increasing-software-transparency-with-lightweight-architectural-decision-records
• https://www.utdallas.edu/~chung/SA/zz-Impreso-architecture_decisions-tyree-05.pdf

Archimate ile Modellemeye Giriş

Daha önceki yazılarda Kurumsal Mimari konusunda bazı kavramsal bilgiler edindik, artık işe koyulmanın zamanı geldi: Archimate ile mimarimizi modellemeye başlıyoruz.

Archimate, Open Group tarafından yayınlanan bir Kurumsal Mimari modelleme dilidir. Görsel modelleme yapmaya olanak veren Archimate, içerisinde modelde kullanılmak üzere bir dizi grafik öğe ve bunlar arasında kurulabilecek olası bağlantı setini içerir.

Archimate 3.0’a genel bakış

1.0 versiyonu 2009 yılında yayınlanan dil, 2016 yılında yayınlanan 3.0 versiyonu ile gelişimine devam etmekte. Kurumsal Mimari’nin dört temel katmanı olan iş, uygulama, veri ve teknoloji katmanlarını yanı sıra; değişim yönetimi, strateji ve motivasyon yapılarını da modellemeye olanak sunuyor. Yani aslında model, tüm ilişkileriyle birlikte uçtan uca kurumun kendisini ifade etmiş oluyor. Bu çeşitlilik sayesinde oluşturacağımız modelde, fiziksel bir sunucunun şirket stratejilerinden hangilerine hizmet ettiği ilişkisini bile net bir şekilde görebilmiş oluyoruz.

Archimate – Togaf ADM etkileşimleri

Her katman üç farklı tipte öğenin birleşiminden oluşuyor; bunlar: aktif, pasif ve davranışsal yapılar. Aktif yapılar (active structures) etken ve ilgili fonksiyonu icra edenler, pasif yapılar (passive structures) edilgen ve bu fonksiyon tarafından kullanılanlar, davranışsal (behavioral) yapılar ise bu icranın nasıl gerçekleştiğini anlatan etkileşimleri ifade ediyor.

Archimate kütüphanesindeki ilişki seti, iki öğe arasındaki etkileşimi ifade eden bağlantılardan oluşuyor. Bunlar yapısal (structural), ilişkisel (dependency), dinamik (dynamic) ve diğerleri (others) olmak üzere dört farklı tipte gruplanıyorlar.

Archimate 3.0 model örneği

Archimate yalnızca bir dil ve görsel notasyondan ibaret olduğu için, Archimate kullanarak modelleme yapabilmek için doğrudan özel bir kurumsal mimari aracına ihtiyacımız bulunmuyor. Microsoft Visio gibi çizim araçlarında da, Archimate şablonlarını kullanarak modelleme yapabiliriz. Kurumsal Mimari araçlarının asıl faydası; modelleme kabiliyetlerinden ziyade, merkezi bir depo (repository) oluşturmaya olanak vermeleri. Yani modeller üzerinde oluşturduğumuz tüm verileri, erişilebilir ve tekrar kullanılabilir birer envanter haline getirebilmeleri. Bu nedenle, en güncel Archimate versiyonunu destekleyen bir mimari araca sahip olmak büyük fayda sağlayacaktır.

Archimate neden gerekli?

1- Görünürlük

Stratejiden fiziksel katmana kadar olan tüm mimarimizi net ve anlaşılabilir bir şekilde ifade etmeye olanak verir. Farklı kaynaklarda bulunan ve farklı formatlarda oluşturulan ve genelde erişmek için çaba sarf etmek gereken tüm yapıları görünür hale getirir.

2- Ortak dil

Modellediğimiz tüm katmanlarda, farklı disiplinlerden gelen kişilerin aynı çıkarımı yapabilmesini sağlar ve yanlış anlaşılmaların önüne geçer. Bu sayede organizasyonun tüm kademelerinde ortak bir dil kullanılmaya başlanmış olur.

3- Etki analizi yapabilme

Strateji öğelerine bağlı iş süreçleri, bunlara bağlı uygulamalar, uygulamalara bağlı veri yapıları ve fiziksel öğeleri görebileceğimiz bir modelde, herhangi bir öğenin değiştirilmesi veya fonksiyonunu yerine getirmemesi durumunda nelerin etkileneceğini net olarak görebiliriz.

4- Çeviklik

Modele ait detaylara tamamıyla hakim olmamız ve etki analizi yapabilmemiz sayesinde, değişiklik taleplerine vakit kaybetmeden yanıt verebiliriz. Bu da kuruma, bulunduğu pazarda hızlı hareket edebilme kabiliyeti sağlayacaktır.

5- Basit ve anlaşılabilir ifade

Sağlanan görsel ve kolay ifade şekli ile, sayfalarca doküman ile anlatacağımız bir konuyu, tek sayfalık bir diyagramda net olarak gösterebilme şansına sahip oluruz.

6- Kolay ve etkin planlama

Mevcut ve gelecekteki mimarinin doğru modellendiği bir yapıda, transformasyon ve geçiş planları kolaylıkla yönetebiliriz. Bunun için Archimate içerisinde bulunan değişim yönetimi (implementation) katmanından faydalanabiliriz.

Bazı başvuru kaynakları :

  1. Open Group Archimate 3.0 dokümantasyonu
  2. Mastering Archimate web sitesi
  3. Archimate 3.0 referans kartı
  4. Ücretsiz bir Archimate modelleme aracı: Archi
  5. Archimate 3.0 Visio şablonları

Yazının orjinali : http://mustafaulus.com/2017/05/21/archimate-ile-modellemeye-giris/

Uygulama Portföy Optimizasyonu ile BT Değer Artışı

accelerateBir önceki yazımızda, uygulama portföyümüzü neden ve nasıl yönetmemiz gerektiğinden bahsetmiştik. Yönetmeye başlayarak görünür hale getirdiğimiz ve hakkında detaylı bilgilere sahip olduğumuz portföyümüz üzerinde, iyileştirme çalışmalarına artık başlayabiliriz. Bu sayede BT verimliliğinde artış sağlarken, maliyetlerde ise ciddi oranda azalma elde edeceğiz.

Kontrol altına alınmamış ve karmaşıklık seviyesi yüksek olan portföylerde, aşağıdaki durumlarla karşılaşılma ihtimali yüksektir :

  1. Kabiliyet çakışmaları nedeniyle, aynı işi yapan birden fazla uygulama olması
  2. Bakım-destek verilemeyen COTS veya özel geliştirilmiş uygulamalar
  3. Yüksek maliyet ve/ya risk oluşturan uygulamalar
  4. İş ihtiyacı kalmaması nedeniyle işlevsiz hale gelmiş (pasif) uygulamalar

Şirketinizde bu kategorilere giren uygulamalara sahip değilseniz şanslısınız, zira Capgemini’nin yaptığı araştırmaya göre ortalama büyüklükteki bir şirketin uygulamalarının %20’si tekrar eden kabiliyetlere sahipken, %50’sinin artık emekliye ayrılması gerekiyor.

Bu uygulamaların hayatlarını, _eğer çalışmaya devam etmeleri konusunda kurum için stratejik gerekçeler yoksa_sonlandırmak gerekir. Aksi durumda, bahsettiğimiz dezavantajların yanında; yeni iş ihtiyaçlarının karşılanması da imkansız hale gelebilir. Yani özetle, ne kadar sade bir portföye sahip olursak, yönetimi de o kadar kolay olacaktır. Bu nedenle, elimizdeki uygulamaların akibetlerinin ne olacağının belirlenmesi için, bir optimizasyon çalışması yapılmalıdır.

Portföy optimizasyonu yöntemleri arasında en çok benimsenenlerden biri, Gartner tarafından oluşturulmuş TIME yöntemidir. Özet olarak TIME, her uygulama için nihai olarak aşağıdaki dört karardan birini vermeyi amaçlar :

  • Tolerate : Uygulamanın sahip olduğu kabiliyetler gereklidir ve memnuniyet düzeyi yeterlidir. Mevcutta olduğu gibi kalabilir.
  • Invest : Uygulama hayatına devam etmelidir, fakat üzerinde bazı yatırımlar ve iyileştirmeler yapılmalıdır.
  • Migrate : Uygulamanın kabiliyetleri gereklidir, fakat teknoloji ve bakım-destek gibi nedenlerden ötürü memnuniyet düzeyi düşüktür. Farklı bir uygulamaya taşınarak hayatına son verilebilir.
  • Eliminate : Uygulamaya ihtiyaç bulunmamaktadır ya da aynı kabiliyete sahip farklı bir uygulama bulunmaktadır. Emekliye ayrılmasında sakınca yoktur.

Bu kararı verirken en önemli kural, tamamen nesnel ve kanıta dayalı olunması gerektiğidir. Bu dayanaklara sahip olmayan bir çalışmanın çıktıları konusunda, kurum içerisinde fikir birliğine (ya da en azından çokluğuna) varılması mümkün olmayacaktır. Böyle bir ortamda ise iyileştirme sağlamak yerine; mevcut yapıda aksak da olsa çalışan bir yapıyı çalışmaz hale getirme riski bulunmaktadır.

Bu çalışma kapsamında, her uygulamanın kurum için önemini detaylı olarak görebileceğimiz bir “stratejik karne” oluşturmamız gerekir. Stratejik karne oluşturma süreciyle ilgili farklı yaklaşımlar bulunsa da, genel hatlarıyla içerisinde aşağıdaki başlıklarda (yani bakış açılarında) maddeler bulunur :

  • Teknik (Mimari) Değerlendirme
  • İş Kabiliyetleri Değerlendirmesi
  • Finansal Değerlendirme

time_apm

Uygulama portföyü TIME haritası örneği

Bu ana başlıkların altında, kurumun önceliklerine göre belirlenen kriterler yer alır ve değerlendirme sürecinde, katılımcıların bu başlıklara belirli ölçekler çerçevesinde puan vermeleri beklenir. Çalışmaya uygulamalarla ilgili bilgi sahibi olan ne kadar çok katılımcı dahil olursa, o kadar sağlıklı çıktılar elde edilecektir.

Çalışmanın sonunda, toplanan puanların ortalamaları alınarak uygulamanın yukarıda bahsi geçen kırılımlar için karnesi oluşturulur. Her başlık, karar vericilerin önceliklerine göre ağırlıklara sahiptir ve her uygulama için bu bakış açılarına ait genel görünümler elde edilir. Son adımda ise eldeki işlenmiş veriler kullanılarak tüm uygulamaları içeren görsel bir TIME haritası oluşturulur ve portföyün genel görünümü elde edilir. Bundan sonrası, optimizasyon çalışmasındaki çıktıları aksiyona dönüştürecek projelerin başlatılması şeklinde olacaktır.

Kurumsal mimari süreçleri etkin olarak işletilen ve portföy yönetimi yapılan kurumlarda, uygulamaların çoğunluğunun “Tolerate” veya “Invest” alanı altında yer alacağını ve portföyün herhangi bir t anında optimize halde bulunacağını belirtmekte fayda var.

Optimizasyon çalışmasını kurumsal mimari uygulamaları üzerinde kolaylıkla yürütebileceğimiz gibi, henüz böyle bir yatırım yapmadıysak Excel’in her zaman elimizin altında hazırda beklediğini hatırlatarak yazımıza burada son veriyoruz.

Karmaşadan Sadeliğe Giden Yol : Uygulama Portföy Yönetimi

Robotların dünyayı ele geçirmesinden önceki evre olan, yazılımların hayatımıza yön verdiği evreyi yaşıyoruz. Gündelik hayatımızda, gerek bilgisayarlar gerekse mobil cihazlarda aktif olarak kullandığımız onlarca farklı yazılım varken, iş hayatında bu sayının yüzler mertebesine ulaşmasına şaşırmamak gerekiyor.

Özellikle orta ve büyük ölçekli kurumlarda; finans, faturalama, müşteri yönetimi gibi büyük sistemlerden tutun; çizim, raporlama, anket gibi daha ufak olanlara kadar bir çok uygulama, bir çok birim tarafından kullanılıyor. Yalnızca uygulamalar değil; işletim sistemleri, geliştirme platformları, komponentler gibi yazılımlar da bu kapsamda ele alınabilir. Sayılar dramatik ve kontrolü zor boyutlara ulaştığı için, bu konuda Bilgi Teknolojileri (BT) birimlerine yardım etmeyi amaçlayan uygulama portföy yönetimi (application portfolio management) adında bir uzmanlık mevcut.

upm1-768x385

Uygulama portföy yönetimi (UPY) sayesinde, en basit ifade ile BT uygulama portföyümüzü görünür kılarak, geniş bir bakış açısı yakalamış oluyoruz. Bu iş temelde uygulamaların bir listesini tutmak gibi anlaşılsa da, biraz detaya inildiğinde; aslında aşağıdaki sorulara yanıt arayan bir uğraş olduğunu fark ediyoruz :

  • Kurumda hangi uygulamalara sahibiz?
  • Uygulamaların tür, sahiplik, lisans, altyapı gibi temel bilgileri neler?
  • Uygulamaların iş kabiliyetleri ve kapasiteleri neler?
  • Mevcut uygulama mimarimiz nasıl?

UPY Kurumsal Mimari‘nin bir parçası olmakla birlikte, kurum genelinin faydasına sunulan çıktılara sahiptir. Üst yönetimden yazılım uzmanına kadar tüm kademeler, ihtiyaçları olan ölçüde ve istedikleri bakış açıları ile bu değerli bilgiden faydalanabilir. Yani UPY; hem operasyonel işleri kolaylaştıran bir bilgi envanteri üretir, hem de yönetime yol veren bir karar destek faaliyeti sağlar.

Doğru bir UPY süreci işletmeye başladığımızda, aşağıdaki soruların yanıtlarını verebileceğimiz veri setine de sahip oluruz :

  • Gelecekteki uygulama mimarimiz nasıl olacak?
  • Geçmiş yıllarda capex ve opex için harcanan tutarlar ne kadar?
  • Önümüzdeki yıl hangi uygulamaya ne kadar bütçe ayırmalıyız?
  • Kurumun iş stratejileri ile ne kadar uyumlu bir uygulama portföyüne sahibiz?
  • Karşılayamadığımız iş kabiliyetleri neler?
  • Birden fazla uygulama tarafından karşılanan iş kabiliyetleri neler?
  • Uygulamaların olgunluk seviyeleri ne durumda?
  • Uygulama yaşam döngülerini nasıl yönetmeliyiz?

Uygulama portföy yönetimi nasıl yapılır?

Doğru adımlar uygun sırada gerçekleştirildiği sürece, UPY zor değildir.

1- Paydaşları, bilgiyi toplayacak ve bilgi alınacak ekipleri belirleyin. Aksi durumda, sağlıklı bir portföy elde etmek yerine, eksik ve hatalı bilgilerle dolu göstermelik bir uygulama listesi elde edilmiş olur.

2- Hedeflerinizi belirleyin. Bu iş tamamlandığında hangi çıktı ve kazanımları elde etmeyi planladığınızı, kendinize ve tüm paydaşlarınıza net olarak ifade edin.

3- Uygulama portföyünde bulunacak bilgi çeşitliliğini ve derinliğini belirleyin. Aksi durumda her yeni bilgi eklendiğinde, bilgi toplama sürecinin tekrarlanması zaman kayıpları yaşatacaktır.

4- Uygulamaların mevcut ve eksik iş kabiliyetlerini görünür hale getirebilmek için, bir referans mimariden faydalanın (örneğin Telco sektörü için Tm Forum tarafından oluşturulan TAM’ı (Telecom Application Map) kullanarak, hangi uygulamanızın TAM’da hangi kabiliyetleri karşıladığını bulun). Böylece mevcut mimarinizi kolaylıkla belirlerken, hedef mimarinizi de oluşturmuş olursunuz.

5- UPY tek sefere mahsus bir çalışma olmadığı için, portföyün yaşatılması ve sürekli olarak güncel tutulması gerekir. Bu nedenle kurum içerisinde, uygulama portföyünde değişikliğe neden olabilecek tüm süreçlere (SDLC, agile, RFP, phase-out vb) portföy güncelleme adımlarını ekleyin.

6- Son olarak, bir zorunluluk olmamakla birlikte UPY çalışması için bir metodoloji belirlemenizde ve eğer bu deneyimde bir çalışanınız yoksa, işinin ehli kişilerden danışmanlık almanızda fayda olduğunu unutmayın.

Portföyümüzü nerede yönetmeliyiz?

Bu sorunun akla gelen ilk yanıtı, diğer tüm benzer işlerde olduğu gibi Excel’dir. Excel ilk bakışta bu işi basit ve hızlı olarak yürütmek için uygun bir araç gibi görünse de, işler karmaşıklaştığında UPY için en büyük riski teşkil etmeye başlar. Versiyonlama, ortak çalışma, ilişki kurabilme, görselleştirme gibi bir çok konuda sıkıntı çekmek yerine; bu amaca uygun olarak geliştirilmiş BT portföy yönetim uygulamaları ya da işi daha geniş anlamda ele alan ve kurumsal mimarinizi de yönetebileceğiniz uygulamalara yönelmekte büyük fayda var. Bu alanda büyük oyuncuların pahalı çözümlerinin yanında, birkaç bin dolara lisansını alarak kullanabileceğiniz ürünler ve hatta açık kaynak uygulamaları barındıran geniş bir alternatif seti bulunuyor.

ITIL Türkçe Sözlüğü

İş hayatında sıkça kullandığımız IT terimleriyle ilgili ITIL tarafından yürütülen bir terim ve tanımlar sözlüğü projesi mevcut. Projenin Türkçe kısmı için, ülkemizin önde gelen firmalarının katılımıyla yürütülen ve 1.0 versiyon numarası ile aşağıdaki linkte yayınlanan güzel bir çıktı bulunuyor. 128 sayfalık bu dokümanda, her IT terimi için detaylı açıklamalar mevcut. İstifadenize sunarız.

https://www.axelos.com/Corporate/media/Files/Glossaries/ITIL_2011_Glossary_TR-v1-0.pdf

Neden Olmasın? : Merkezi Veri Modeli

database-partsNeden Olmasın? serisinin bu ikinci yazısında, farklı uygulamaların ortak bir fiziksel veritabanı ve veri modeli kullanmasını konu alan, kavramsal bir projemden bahsetmek istiyorum.

1940’lardan bu güne kadar programlama dilleri ve yaklaşımları ciddi bir evrim geçirdi. Makine dili ile başlayan bu serüven, yapay zeka kullanarak kodlamanın bilgisayarlar tarafından yaptırılmasına kadar devam eden bir olgunlaşma sürecine girdi. Gelinen son noktada ise; nesne odaklı programlama, servis odaklı mimari, BPEL gibi yazılımların karmaşıklığını azaltmayı ve işletilebilirliğini kolaylaştırmayı amaçlayan yöntemlerle ilgili tartışmalar, yerlerini verinin nasıl modellenmesi gerektiği tartışmalarına bırakmaya başladı. Bu durum ise yazılım dünyasında trendlerin, uygulama katmanı seviyesinden, veri katmanı seviyesine doğru kaymasına neden oldu.

Bilindiği üzere Büyük Hacimli Veri (Big Data) ve İş Zekası (Business Intelligence) gibi alanlar IT dünyasının parlayan yıldızı konumunda. Bu kavramların öne çıkması, verinin değerinin geç de olsa anlaşıldığının, asıl olanın uygulamanın kendisinin değil, sahip olduğu veri olduğunun güzel birer kanıtı.  (bkz: Harvey Nash CIO Anketi 2015)

data-flowİş uygulamalarının görevlerini yerine getirerek veri üretmesi, uçtan uca bakıldığında büyük resmin yalnızca küçük bir parçasını oluşturuyor. Asıl süreç şöyle devam ediyor: bu veriyi toplayan ETL (Extract-Transform-Load) uygulamaları ODS (Operational Data Source) katmanlarına veriyi taşır, buradan belirli biçimlendirme ve hesaplamalar yapılan veri, DWH (Data Warehouse) üzerinde tutulan özet tablolara (Data Mart) aktarılır. Son adım olarak raporlama uygulamaları üzerinden, son kullanıcılara basit arayüzler yardımıyla sunum yapılır. Bu uzun ve yorucu süreç, IT dünyasında aslında veri odaklı düşünmenin ne kadar önemli olduğunu ve eğer süreçleri kolaylaştırıp maliyetleri düşürmek istiyorsak, bu kısıma odaklanmamız gerektiğini gösteriyor.

bb887608-figure4en-usGeçmişe dönüp baktığımızda, şimdiye kadar kurgulanan mimarilerin, genelde iki farklı şekilde karşımıza çıktığını görüyoruz :

1- Aynı uygulamanın farklı arabirimleri (masaüstü, web, mobil vb) için bağımsız veritabanlarında tutulan verilerin, ortak bir merkezde toplanması. Bu çözüm ciddi bir replikasyon yükünü beraberinde getirse de, zamanın teknolojik kısıtları nedeniyle (düşük network hızları, sunucu donanımı yetersizlikleri vb) fazla alternatifi bulunmuyordu. Bu da, her ara birim için bağımsız olarak geliştirilen uygulamalara ait verileri, merkezi bir veri katmanında birleştirirken ciddi zorluklar yaşanmasına neden oluyordu.

2- Farklı ara birimlerin, fiziksel olarak bağımsız veritabanları tutmayıp, merkezi bir konumda bulunan ortak veritabanını kullanması. Java, .Net gibi yazılım dilleri sayesinde platformdan bağımsız uygulama geliştirme kolaylığı ve network altyapısındaki iyileşmeler bu modeli olgunlaştırsa da, mimariye bambaşka uygulamalar dahil olması durumunda ilk çözümdekine benzer sorunlar gözlemlenebiliyor. Ayrıca, bağımsız uygulamaların birbirleriyle iletişim kurmasını gerektiren bir entegrasyon mimarisinde, n * (n-1) adet bağlantıyı barındıran bir örümcek ağı ortaya çıkıyor.

Peki Çözüm Ne?

merkezi_veritabani1Değindiğimiz sorunların en büyük nedeni, ekosistemde bulunan uygulamaların farklı veritabanlarına sahip olmaları. Eğer bütün uygulamalar ortak bir fiziksel veritabanını (ve tabi ki ortak bir şemayı) kullanıyor olsaydı; hem verinin yönetilmesi, hem de uygulamaların birbirleriyle konuşması için çok daha az efora ihtiyaç olacaktı.

Bu konuda bazı çalışmalar yürütülüyor ve SAP Hana gibi platformlar da mevcut. Uygulamaların ortak veritabanı olarak kullanabildiği, in-memory olarak ışık hızında çalışan ve bir OLAP (On-Line Analytical Processing) – OLTP (On-Line Transaction Processing) ortamı sunan bu platformların dezavantajları ise; lisans maliyetleri, donanım bağımlılıkları, firma tekeli oluşması ve aslında arkasında bir iş modeli değil teknoloji sunmaları.

Sonuç olarak, özellikle bünyesinde hatırı sayılır uygulama barındıran orta ve büyük ölçekli işletmelerde, bu tarz bir mimariyi benimsemenin çok fazla faydası olacaktır. Zira günümüzde ulaşılan network bant genişlikleri, sunucu donanım seviyeleri ve sanallaştırma imkanları; tüm uygulamalara hizmet veren ortak veritabanları kullanılabilmesi için uygun altyapılar sunmaya başladı. Bu fiziksel katmana iş modelini de ekleyerek, bütün işletmenin kullanımına açık merkezi veri modelleri oluşturmamak için çok fazla geçerli nedenimiz bulunmuyor.

Bu konuyu bir sonraki yazımızda detaylandırarak incelemeye devam edeceğiz..

Neden Olmasın? : “TAM Türkiye”

tmforumBaşlık her ne kadar siyasi bir sloganı andırsa da, bahsettiğim aslında TmForum TAM‘dan (Telecom Appication Map) başka bir şey değil.

Faruk Selman’ın Yerli Silikon Vadileri Nasıl Modellenmeli? başlıklı ve belirli bir sektöre odaklanan yerli firmaları, sektörel silikon vadileri çatısı altında bir arada toplamayı konu alan makalesini okuduğumda; uzun süredir aklımda olan ve bu fikritelekom sektörü özelinde destekleyen bir projeyi paylaşmak istedim.

Bilindiği üzere TmForum organizasyonu, dünya çapında telekom sektöründe faaliyet gösteren 900’den fazla servis sağlayıcı, altyapı sağlayıcı ve sistem entegratöründen oluşan devasa bir yapı.  Belirlediği standartlar, yürütülen ar-ge faaliyetleri, yapılan ortak çalışmalar ile üyelerinin dijital dönüşümüne katkıda bulunmayı amaç edinen TmForum, telekom sektörünün lokomotifi olmuş durumda.

TmForum’un ortaya koyduğu standartların bütünü olan Frameworx çatısı altında, dört farklı alt bileşen bulunuyor :

Değinmek istediğim konu olan TAM içerisinde ise, bir telekom şirketinde bulunabilecek tüm uygulamalar, belirli sanal gruplar çerçevesinde listelenerek, her birinde olması gereken yetkinlikler ve fonksiyonlar detaylı olarak belirtiliyor. Yani, eğer bir uygulamanın TAMeşleşmesi yapılmışsa, o uygulamanın gerçekte hangi iş ihtiyaçlarına karşılık verdiği kolaylıkla görülebiliyor.

tam_v45

Peki TAM’ın konumuzla ne ilgisi var?

Telekom sektörüne hizmet veren yerli yazılım şirketleri, geliştirdikleri uygulamalarda TmForum standartlarına uymaya çalışsalar da; bunlar, birbirinden tamamen bağımsız olarak yürüyen faaliyetlerle sağlanıyor. Yani hem sahip olunan iş ihtiyaçlarına hitap eden yerli yazılımları bulmak için bütün bu firmaların kapısını teker teker çalmak gerekiyor, hem de bu ürünler bir arada kullanılmak istendiğinde çeşitli entegrasyon problemleri ve fonksiyonel çakışmalar ile karşı karşıya kalınıyor.

HP, IBM, Oracle, Ericsson, Microsoft gibi dünya devleri, benzer çalışmaları kendi ürün gamları için şirketleri bünyesinde yapıyorlar. İlgili firmaya ihtiyaçlar anlatıldığında, gerekli fonksiyonlar için ürün ailesi içerisinde hangi ürün ve modüllerin gerektiği kolaylıkla belirlenip, doğru çözüme hızlıca ulaşılması sağlanabiliyor. Üstelik bunu, aynı aile içerisinde bulunan bu ürünlerin, birbirleriyle uyumlu bir şekilde çalışmasını garanti ederek yapıyorlar.

Hal böyle iken, kısıtlı fonksiyon setlerine sahip yerli ürünler ne kadar başarılı olursa olsun, dünya devleriyle mücadele ederken ciddi zorluklarla karşı karşıya kalıyorlar. Örneğin müşteriler, ihtiyaçları olan on fonksiyondan üçünü çok iyi bir şekilde karşılayan yerli bir ürün alıp, diğer yedisi için başka çözümler aramak yerine; daha kısıtlı da olsa elinde on ihtiyacın tamamına karşılık veren çözümler bulunduran global bir oyuncu ile çalışmayı tercih ediyorlar.

puzzleÇözüm için bir TAM Türkiye haritası hayal ediyorum: Telekom Silikon Vadisi tarafından yönetilen ve vadide faaliyet gösteren tüm yerli firmaların ürünlerini içererek, ihtiyaca karşılık gelen çözümlere hızlıca ulaşmaya olanak veren bir harita bu. Başka bir deyişle, büyük resmi oluşturacak yapboz parçalarını, doğru bir şekilde oluşturmanıza yol gösterecek faydalı bir yönerge.

Bu harita :

  • Yerli yazılım şirketlerinin bilinirliğinin artması,
  • Ürün yetkinliklerinin net olarak anlaşılabilmesi,
  • Farklı firmalara ait ürünler arasında tamamlayıcı bir platform oluşması,
  • Firmalar arası iş birliklerinin sağlanması,
  • Ürün kıyaslamanın belirli metriklere oturtulması,
  • Pazarlama & reklam faaliyetlerinin etkin olarak yürütülmesi,
  • Türkiye ve dünya pazarına birlikte açılabilme avantajı sağlanması,
  • Rekabet ortamını belirgin hale getirerek, kalite artışının sağlanması,
  • Büyük şehirlerin tekelinde olan yazılım piyasasının, Anadolu’da belirlenecek merkezlerde konuşlanması

gibi daha bir çok fayda sağlarken, “birlikten kuvvet doğar” ilkesinin ne kadar doğru olduğunu bizlere bir kez daha gösterecek ve dünya yazılım pazarında teker teker yer bulamayan bir çok yerli firmaya kendini gösterme imkanı sunacaktır.

Bu noktada; Bilim, Sanayi ve Teknoloji Bakanlığı‘nın silikon vadilerini oluştururken benzer modeller üzerinde kafa yorması, yazılım firmalarının ise istekli olduklarını belirterek yapılacak çalışmaları desteklemesi gerekiyor. Aksi durumda, silikon vadisi modelleri ne yazık ki birer inşaat projesinden daha fazlası olmayacaktır.

Bilişim Sektörü e-Beceriler / e-Yeterlilikler Araştırması

e-skills-what-are-they2“Bilişim Sektörü e-Becerileri ve e-Yeterlilikleri Araştırması” 2011-2013 yılları arasında Mesleki Yeterlilik Kurumu (MYK) Sınav ve Belgelendirme çalışmaları sürecinde toplanan veriler, anket sonuçları, birebir görüşmeler, İK siteleri bilgileri ve saha analizleri ile hazırlanmıştır.

Araştırmanın amacı Bilişim ve İletişim Teknolojilerinin (BİT) sektöründe çalışmak ve/veya girişimci olmayı hedefleyen birçok genç için sektördeki istihdam ve iş açığını göstermek ve bu alanlara talip olabilmeleri için gereken eyeterlilikleri taslak olarak belirlemektir.

AB ülkelerinde “e-skills” (e-beceriler) konusunda birçok makale, araştırma ve rapor bulunmaktadır. Bunların çoğu akademik anlamda olup sadece belirli bölümleri konuyu açıklamak amacıyla makalemizde özetlenmiştir. Araştırma sonuçları yalnız AB ülke standartlarını baz alarak değil, Türkiye sektörel gerçekleri ile de yoğurularak belirlenmiştir.

http://transfer.cizgi.com.tr/nsaral/e-skillsTR/Bilisim%20Sektoru%20e-Beceriler.pdf