Yazar Arşivi: Mustafa Ulus

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