مقاله ترجمه موردی برای یک معماری شرکتی جاری در یک بانک خصوصی

بخشی از مقاله

موردی برای یک معماری شرکتی جاری در یک بانک خصوصی

پدرو سوزا، آندره سامپیائو، و ریکاردو لیل

چکیده
این مقاله موردی را برای توسعه معماری شرکتی (EA) در یک بانک خصوصی معرفی میکند. طرح های اولیه ساختاری جاری بر مبنای اطلاعات جمع آوری شده از منابع اطلاعاتی مختلف ایجاد می گردند. این طرح های اولیه در اینترنت داخلی بانک ترکیب می گردند و نقطه ورودی نه تنها برای ثبت فنی تکنولوژی اطلاعات بانک، بلکه برای یک پایگاه داده دانش با پشتیبانی ویکی هایی (سایت های قابل ویرایش) نیز هستند که تیم های توسعه میتوانند آنها را بروزرسانی کنند و از آنها برای افزایش

کارایی استفاده کنند. بنابراین EA یک دارائی جاری مورد استفاده در کارهای روزمره تیم تکنولوژی اطلاعات بانک است. در حال حاضر، بانک در حال پیشرفت بیشتر است و میخواهد EA را با فرآیند توسعه Agile (سریع الانتقال) خود ترکیب کند، و نتایج فعالیت ها در EA را نیز در دسترس همه افراد قرار دهد. ابزار EAMS نه تنها توسط پشتیبانی از نسل اتوماتیک طرح های اولیه، بلکه با فراهم سازی یک نمودار سفر زمانی نیز از این EA جاری پشتیبانی میکند که امکان حرکت بین وضعیت های گذشته، حال و آینده را امکان پذیر می سازد.

کلمات کلیدی: معماری شرکتی، نقشه نگاری شرکتی، مجسم کننده EAM ، EAMS.

1- در مورد مراجع
مراجع در این مطالعه موردی، یک بانک خصوصی است که در شبه جزیره ایبری واقع است و فعالیت های بانکداری سرمایه گذاری (دارائی خالص، مالیه شرکتی و بانکداری خصوصی) را انجام میدهد. این بانک از طریق شبکه توزیع چند کانالی خود (که از حدود 650 شعبه تشکیل شده است و شبکه ای از توسعه دهندگان خارجی، ساختارهای مختص به مشتریان شرکتی و سازمانی، بانکداری تلفنی، و خدمات بانکداری خانگی است) به حدود 2 میلیون مشتری ارائه خدمات میکند. در مدیریت دارائی، این بانک هر موقعیت مربوطه ای را در مدیریت وجوه مؤسسات سرمایه گذار، وجوه بازنشستگی، و بیمه های عمر دارد.
2- محتوا
در سال 2012، بانک گزارش داد که طرح بندی شکل و حیطه پروژه EA را بعنوان ابزاری برای پشتیبانی موثرتر از تجارت، کاهش هزینه های توسعه و زمان بازاریابی آغاز کرده است. از بین مسائل مربوطه، مسائل زیر مهم تر هستند که آنها را بیان میکنیم:
- بانک قبلاً در EA تجربه داشت، چون مجبور بود که از ابزار مدلسازی برای ایجاد نمونه ها و مدل های ساختار ITاستفاده کند. این راهکار بر مبنای یک منبع مرکزی بود که همه مدل ها در آن قرار داشتند، و هر کدام از آنها بصورت دستی با ابزار EA طراحی میشد. این راهکار نیازمند تلاش اساسی برای بروزرسانی بود، خصوصاً اگر مدلهای تولید شده در پروژه های مختلف در یک دیدگاه واحد و شرکتی از منظره IT با هم ترکیب می شدند. بنابراین تلاش برای نگهداری نمونه های EA یک مسئله کلیدی برای این پروژه بود.

- بانک یک زیرساخت خدمات ساختار-محور (SOA) را بعنوان راهی برای تفسیر یکپارچگی کاربرد و ساختار IT آن ایجاد کرده بود. بنابراین، نمایش خدمات و مفاهیم مربوطه نیز مسئله اصلی در این پروژه به شمار می رفت.

- و در نهایت اینکه، این بانک در حال توسعه انتشار فرآیند توسعه سریع الانتقال بود. این فرآیند در سال 2010 با استفاده از SCRUM آغاز شد. در سال 2012 تعداد تیم ها به 30 تیم (220 نفر) و در سال 2013 به 50 تیم (320 نفر) افزایش یافت که در SCRUM کار میکردند.

این بانک علاوه بر مسائل بالا یک پورتالEA را نیز در اینترنت داخلی ایجاد کرده بود که از ثبت اطلاعات مربوط به ساختارهای کاربرد و تکنولوژی پشتیبانی می کرد. پورتال اینترنت داخلی شامل تعداد زیادی از ویژگی ها (مانند ویکی ها) با مقدار قابل توجهی از مقالات بود که فرآیند ها و ساختار سیستم را توصیف می کرد و یک نقطه ورودی را برای همه ثبت های فنی ایجاد می کرد.

پورتال اینترنت داخلی EA به جمع آوری و نمایش اطلاعات ساختاری در مورد بانک کمک میکرد که بصورت لیست معرفی می شد و یا در موارد ساده تر، به شکل نقشه های سلسله مرتبه ای ساده نمایش داده می شد که بصورت اتوماتیک از اطلاعات متنی ایجاد می شد. مردم بعضی از فرم هایی را پر کنند که ورودی برای پورتال اینترنت داخلی بودند و سپس برای ایجاد بعضی از نقشه استفاده می شدند.

خودکار سازی دیدگاه های ساختاری ساده تر یک مرحله اساسی در تعیین نگرش های بانک برای دنبال کردن این ایده است که همه این دیدگاه های ساختاری (هم برای کاهش تلاش و هم برای افزایش سطح اطمینان مردم) مربوط به این نمونه ها بود.

جنبه مهم دیگر این بود که پورتالEA را بعنوان یک نقطه منفرد برای دسترسی به اطلاعات ثبت شده، آموزش و تقویت اطلاعات IT تصور کنیم.

صرفنظر از این دیدگاه واضح، چندین مسئله نیز وجود داشت که نیازمند بحث و توضیح بیشتر بود، بعنوان مثال اینکه کدام ساختارها باید بررسی شوند، چطور باید هر یک از آنها را مدیریت کرد، و چطور می توانیم اطمینان حاصل کنیم که آنها بصورت نهادهای جاری در سازمان در می آیند (بجای اینکه پس از آغاز کار خود منسوخ و قدیمی شوند).
بنابراین در اوایل سال 2013، بانک ایده عالی در مورد پروژه EA داشت که مد نظر آنها بود. البته چالش هایی که معرفی شدند چالش های ساده ای نبودند.
3- چالش ها
چالش اول این بود که تکنیک EA بانک توسط بهبود پورتال اینترنت داخلی EA بهتر شود تا از ارتباط و آگاهی ساختار بین همه سهامداران پشتیبانی کند که این شامل تیم های زیرساخت، تیم های توسعه و حیطه های تجاری بود. آنها تصمیم گرفتند که قسمت IT باید از این قانون پیروی کند: اگر موجود باشد پس در اینترنت داخلی موجود است. برای رسیدن به این سطح از پیشرفت، بانک می بایست:
- توانایی کلی پورتالEA برای پشتیبانی از دیدگاه های مختلف مطابق با پروفایل کاربر را افزایش دهد. اینکار استفاده از نقطه مرکزی ارتباط برای مخاطبان غیر یکنواخت از تجارت به دامنه های IT را امکان پذیر می سازد.
- رشد اطلاعات در پورتالEA را توسط کاهش تلاش مورد نیاز برای ایجاد و نگهداری گزارشات، نمونه ها و اطلاعات منبع شرکتی افزایش دهد.

- تکامل دارائی ها را در سراسر طول دوره آنها بدست آورد (از لحظه ای که مشاهده می شدند تا زمانیکه لغو می شدند).
تکامل پورتال باید از یک دیدگاه یکپارچه حمایت کند و در عین حال به کاربران اجازه دهد تا از نمونه های ساختاری، ویکی ها، انجمن های بحث و همه محیط ها و ابزارهای همکاری مربوطه استفاده کنند.

چالش دوم نیاز به نگهداری نمونه های ساختاری به شیوه آسان بود. بانک قانون دوم را بیان کرد: "اگر یک دیدگاه ساختاری را نتوانیم بصورت اتوماتیک با اطلاعات بروزرسانی شده ایجاد کنیم، پس نمی توانیم آنرا در پورتالEA نشان دهیم". این اطلاعات باید از منابع مختلفی مانند Microsoft SharePoint، یا Oracle Enterprise Repository بدست می آمد. اطلاعات موجود از منابع مختلف در یک منبع مرکزی که مطابق با مدل متای موجود ساختاربندی شده بود با هم ترکیب می شدند. این مدل باید مطابق با بهترین تکنیک های بازار تکامل پیدا می کرد و باید قادر می بود که همه ویژگی ها، روابط و خصوصیاتی را با هم مطابقت دهد که مفاهیم ساختارهای مختلف را توصیف می کرد.

چالش سوم نیاز به تداوم استفاده مخاطبان از منحنی یادگیری پورتال اینترنت داخلی ساختار بود. مخاطب باید قادر می بود که به آسانی محتوا و نمونه ها را بررسی و جستجو کند. اطلاعات باید به شیوه ساده و خود اکتشافی نمایش داده می شدند، و همچنین به کاربران اجازه میدادند که جزئیات را مشاهده کنند و در صورت لزوم نمونه ها را بصورت کامل دریافت کنند. پورتال و دیدگاه های ساختاری به این صورت صرفنظر از سطح مهارت کاربر در دامنه ها یا لایه های ساختاری خاص، بصورت ابزار ارتباطی مناسبی عمل می کنند.

چالش چهارم ترکیب ابتکارات SOA در ابتکارات معماری شرکتی بود. SOA در انبار شرکتی Oracle با مدل متای خود با بیش از 60 نهاد ایجاد شده بود. بنابراین بانک باید تصمیم می گرفت که این مفاهیم SOA باید در چه حدودی در مدل متای معماری شرکتی نشان داده شوند.
OER نیز مانند انبار SOA میتواند دیدگاه های اطلاعات خارجی را فراهم سازد اما با دو مشکل اصلی روبرو بود:
- دانش کامل مدل متای OER را تفهیم کند و بنابراین فقط برای افراد فنی مناسب است. برای مثال، برای جستجو در بین خدمات تولیدی و مصرفی باید با مفاهیم زیادی مانند سطح های مشترک، پروتکل ها و غیره آشنا باشیم.
- با مفاهیم ساختارهای دیگر ترکیب نگردد و بنابراین از جستجوی یکپارچه برای معماران و تحلیل گران در پورتالEA جلوگیری کند.
و در نهایت، چالش پنجم این بود که مصالحه فرآیند توسعه سریع الانتقال را در عمل و در بانک با EA پیش بینی کند. این چالش به این صورت بود که راهی را برای نشان دادن نتایج فعالیت های آینده تصور کند و قبل از آغاز توسعه، برای همه تیم ها در دسترس باشد. این یکپارچه سازی در حیطه پروژه اولیه نبود بلکه در زمان نوشتن این مقاله بود و بعضی اوقات خود بانک قادر است که با استفاده از EAMS عملکرد خوبی داشته باشد.

4- پروژه
پروژه در اوایل سال 2013 آغاز شد و در آگوست 2013 به پایان رسید. Link Consulting خدمات مشاوره EA را ارائه میداد و سری ابزار مورد استفاده در پروژه را فراهم می ساخت. این پروژه نیازمند 3 نفر از Link Consulting و یک تیم 10 نفره از مراجع ها بودند که مسئول ساختار، اطلاعات، راه حل ها، سکوها، زیرساخت، تجربه کاربرد و همچنین مدیر انبار EA بودند.
هدف این پروژه اجرا و توسعه یک راه حل EA بود که بطور کامل در اینترنت داخلی موجود ترکیب می شود، بطوریکه همه فعالیت های اداره خانه را بتوان به شیوه یکپارچه ای در اینترنت داخلی بانک انجام داد.

ایده مبنا به این صورت است که هر دیدگاه ساختاری باید یک URL داشته باشد که بتوان آنرا در هر صفحه ای در اینترنت داخلی قرار داد، و هر موقع دسترسی به آن ایجاد گردد، دیدگاه ساختاری مطابق را نشان میدهد. جستجو در دیدگاه های ساختاری در صفحات وب و اسناد باید امکان پذیر باشد. ابزار EAMS موتوری برای ایجاد کننده دیدگاه ساختاری بود.

EAMS طرح های اولیه ساختاری را بر مبنای اطلاعات موجود در معماری سیستم منطقی IBM(IBM-SA) ایجاد میکند که ابزار انتخاب شده برای انبار EA اصلی بود و داده های مربوط به اطلاعات، راه حل ها، سکوها و معماری های زیرساخت ها را در خود داشت. بانک از قبل اطلاعات زیادی در مورد این ساختارها (هم در اینترنت داخلی اولیه و هم در منابع دیگر) داشت. تلاش مهم تیم پروژه به ساختاربندی این اطلاعات اختصاص داده شده بود، بطوریکه بتوان آنرا به EAMS وارد کرد.
ما در اینجا دیدگاهی از طرح اولیه EAMS را نشان میدهیم که در اینترنت داخلی قرار دارد.

شکل 1 – دیدگاهی از طرح اولیه وارد شده در پورتال اینترنت داخلی EA

OER با توجه به SOA ، اطلاعاتی را در مورد خدمات فراهم می سازد که آنها را از اطلاعات فنی از Oracle Service Bus، UDDI، و Service Contracts می گیرد. سپس اطلاعات کنترل شده از OER بر یک مبنای روزانه با استفاده از مرتبط کننده های EAMS، مشاغل و دسته ها به منبع EA انتقال داده میشود.
منابع باقیمانده اطلاعات اغلب با داده هایی با پویایی کمتر (مانند ساختار سازمانی بانک) مطابقت دارند. این اطلاعات پردازش می گردد و مستقیماً به منبع EA وارد می شود.

شکل 2 – مؤلفه های SW کلیدی راه حل

یک مسئله مهم که باید در پروژه بررسی گردد مسئله نام مستعار است که بعضی از مفاهیم نام های مختلفی در منابع اطلاعاتی مختلف دارند. این کار و تلاش زیادی لازم نداشت، اما برای برای پردازش اسامی طبقات و همچنین اسامی خصوصیات ضروری بود. این مسئله بصورت دستی در حین پروژه انجام داده شد، اما بعداً بصورت یک چارچوب یکپارچه در دسترس بانک قرار گرفت که امکان اجرای اتوماتیک قوانین تبدیل برای هر ورودی را فراهم می ساخت.

بانک نیز می خواست که به ساختارهای دیگر در دامنه هایی بپردازد که تصور می شد با موضوع مرتبط است، حتی با اینکه آنها اطلاعات زیادی برای آغاز کردن کار نداشتند، بعنوان مثال: تجارت، اطلاعات، تجربه کاربر و ساختارهای قانونی.

اطلاعات و ساختارهای تجاری دامنه هایی بودند که بانک برنامه ریزی کرده بود که در پروژه آنها را بررسی کند، که با تعریف مدل متا آغاز می شد، و در آنجا سطح جزئیات مورد نیاز مشخص می شد و اینکه روابط با ساختارهای دیگر را چطور میتوان به بهترین شکل ایجاد کرد.

با توجه به ساختار تجربه، این مسئله مربوط به تعریف الگوهایی می باشد که به همان مفهوم اجازه میدهند تا صرفنظر از سطح مشترک و کاربردی که هر تجربه داشت) با همان نمونه ها برای کاربر نمایش داده شوند. این مسئله یک جنبه مهم در بانک به شمار می آمد چون تجارت و عملیات به سطح مشترک های الکترونیک وارد می شوند و ادراک یکپارچه مفاهیم بین سطح مشترک های مختلف بعنوان یک جنبه اساسی برای افزایش تجربه کاربر در نظر گرفته می شود.

و در نهایت، معماری قانونی همه اطلاعات مربوط به اصول معماری، قوانین، بهترین تکنیک ها و مقالات تخصصی را ساختاربندی میکند. مقالات مبنای اطلاعاتی صحیحی را نشان میدهند و سکوی ویکی امکان ارتباط زنده با کاربران حرفه ای را فراهم می سازد. تعریف الگوها برای ساختاربندی و مرتب سازی این اطلاعات یک دارائی مربوطه برای تسهیل دسترسی به آن تصور می گردد.

5- راهکار
راهکاری که ما استفاده کرده ایم در پروژه های قبلی موفقیت آمیز بوده است و برای کاهش ریسک های پروژه اصلی طراحی شده بود که شامل موارد زیر است:
- زمان زیاد صرف شده برای تعریف مدل متای منبع EA.

- نابسندگی سطح مدل متا در مورد منابع اطلاعات مطابق و جزئیات. پیچیدگی مدل متای مبنای دانش باید برای نیازهای فوری و منابع اطلاعاتی موجود مناسب باشد.
- افرادی که اعتماد خود را به پروژه از دست می دهند اگر نتایج کوتاه مدت آنرا مشاهده نکنند.
- اطمینان از اینکه کاربران به اطلاعات معرفی شده در دیدگاه های ساختاری اعتماد دارند.
بنابراین ما یک راهکار عملی را اتخاذ کردیم، که بر طراحی یک مدل متا تمرکز دارد که برای اطلاعاتی که بانک در آغاز پروژه داشت امکان پذیر است، اما قوانین وابستگی مبنای مربوط به جداسازی لایه را حفظ میکند و این اطمینان را ایجاد میکند که هر لایه از ساختار توسط خدمات یا امکانات فراهم شده توسط لایه پایینی پشتیبانی می گردد.
اینکار امکان استقلال لایه های ساختاری را فراهم می سازد و تحلیل های تأثیر پایین-بالا و بالا-پایین عناصر ساختاری را ساده تر می سازد. البته چون همه لایه ها لیستی از خدماتی ندارند که ارائه میدهند و مصرف میکنند، مهم بود که امکان ارتباط لایه ها با را فراهم سازیم که این خدمات در بین آنها مبادله میشود. در غیر اینصورت، کل پروژه میتواند منتظر اطلاعات باشد و هیچ نتیجه کوتاه مدتی مشاهده نگردد.

برای اطمینان از اینکه کاربران به اطلاعات معرفی شده در دیدگاه های ساختاری ایجاد شده اعتماد دارند، باید بصورت بروزرسانی شده نگه داشته شوند. برای بدست آوردن این بروزرانس ما از راهکار متمرکز بر دو لحظه بحرانی استفاده کردیم: (1) اطلاعات بارگذاری شده در طی اجرای پروژه، که بصورت خط مبنایی برای بررسی اولیه ساختارها مشاهده می شوند، و (2) تغییراتی که هر پروژه و فعالیت های نگهداری مد نظر دارند.

خط مبنای اولیه اغلب درست بود، چون اطلاعاتی که در ابتدا بارگذاری می شدند مربوط به ساختارهایی بودند که بانک قبلاً اطلاعات مربوط به آنها را در اینترنت داخلی داشت. با این وجود، بار دیگر توسط هر ساختار تأیید شد.

تغییرات ناشی از پروژه های مداوم و فعالیت های نگهداری، در فرآیند توسعه و نگهداری سریع الانتقال ترکیب شدند، که کار آن بصورت ماهیانه برنامه ریزی و اجرا می شد. این یکپارچگی بر مبنای دو لحظه کلیدی انجام شد: وقتی که فعالیت های شدید آغاز شد و وقتی که این فعالیت ها به پایان رسید.

در آغاز هر فعالیت، تیم ها از کمک پورتال اینترنت داخلی ساختار برای بدست آوردن اطلاعاتی که برای طراحی و برنامه ریزی فعالیت های بعدی نیاز داشتند استفاده می کردند. وقتی که یک فعالیت باعث تغییراتی در بعضی از ساختارها می شد، این تغییرات به فرد مسئول ساختار ربط داده می شد و فوراً در منبع EA وارد می شد. این بروزرسانی منبع EA میتواند بصورت مستقیم با استفاده از IBM-SA و یا با استفاده از سطح مشترک تعریف سناریوی ساختاری EAMS، و یا بصورت غیر مستقیم با وارد سازی صفحات اکسل با تغییرات طرح های اولیه با استفاده از سطح مشترک های ورودی EAMS باشد. این همان سناریو در حیطه پروژه بود.
در حال حاضر بانک بصورت داخلی جریان کاری را ایجاد کرده است تا فایل های XML را ایجاد کند که بر اسا اطلاعات موجود در فرم های اینترنت داخلی، با سناریوهای ساختاری EAMS مطابقت دارند، که تلاش صرف شده برای بروزرسانی را تقریباً به صفر کاهش میداد. در نتیجه، تغییرات پیش بینی شده برای ساختار در برنامه ریزی هر فعالیت در اول هر ماه بروزرسانی می گردد و در همان لحظه برای همه تیم ها قابل مشاهده خواهد بود، بطوریکه آنها بتوانند اطلاعات بروزرسانی شده ای را برای برنامه ریزی فعالیت بعدی داشته باشند.
در پایان هر فعالیت، هر گونه تغییر بین تغییرات برنامه ریزی شده و واقعی در ساختار نیز در منبع EA بروزرسانی می گردد. بنابراین از دیدگاه منبع EA هر فعالیت دارای یک تاریخ آغاز، یک تاریخ پایان، و دو لیست با رجوع به عناصر ساختار می باشد. لیست زنده مربوط به عناصری است که در هنگام تکمیل فعالیت وارد تولید می شوند، و لیست مرده مربوط به عناصری است که پس از پایان فعالیت لغو می گردد. ما با استفاده از تاریخ آغاز فعالیت ها و تاریخ پایان فعالیت ها، هر یک از عناصر ساختار را در مبنای دانش با اثرات زمانی تگ بندی میکنیم:
- ذهنی، وقتی که در یک فعالیت مشخص برنامه ریزی، طراحی یا ایجاد می گردد. تگ (اطلاعات کوچک برای طبقه بندی) اثرات زمانی مطابق با تاریخ آغاز فعالیت تعیین می گردد.
- زنده، وقتی که آنها بعنوان نتیجه یک فعالیت در سازمان وارد می گردند. تگ اثرات زمانی مطابق با تاریخ پایان فعالیت تعیین می گردد.
- مرده، وقتی که آنها دیگر در سازمان استفاده نمی شوند، که این هم نتیجه بعضی از فعالیت ها است. تگ اثرات زمانی مطابق با تاریخ پایان فعالیت تعیین می گردد.
این اثرات زمانی برای ردیابی طول دوره عناصر ساختار، و آگاهی از محتوای دیدگاه های مربوط به هر زمان در گذشته، حال یا آینده کافی هستند.
این بدین معناست که این راهکار در واقع به این خاطر استفاده شده است تا ساختار را بصورت بروزرسانی شده نگه دارد و بر مبنای آپلود وضعیت های To-BE سازمان بصورت پیش بینی در طرح های هر یک از 50 تیم سریع الانتقال است که در بانک عمل میکنند.
این راهکار باید توسط ابزار مورد استفاده با دو ویژگی اصلی پشتیبانی گردد:
- منبع EA باید قادر باشد که اطلاعات مربوط به وضعیت های آینده عناصر ساختار را نگه دارد. اینکار توسط همراه سازی تگ های ذهنی، زنده و مرده بعنوان خصوصیات پیش فرض در هر عنصر ساختار انجام می شود که مکان انتشار طول دوره آنها را فراهم می سازد.
- ایجاد کننده طرح اولیه باید قادر باشد که طرح های اولیه ای را ایجاد کند که وضعیت های جاری و آینده را برای ساختار نشان میدهند. این یک ویژگی فطری EAMSاست. همه دیدگاه های ساختاری دارای یک اسلاید زمانی همراه خود هستند که با لحظه های زمانی مشخص می گردد و در آن، پکیج های کاری وجود دارد که تغییراتی را در دیدگاه ساختاری ایجاد میکنند. وقتی که وقتی که دسته در امتداد اسلاید حرکت میکند، و از یک علامت عبور میکند، نام پکیج کاری که باعث این تغییرات شده است در سمت چپ و محتوای تغییرات دیدگاه ساختاری نمایش داده می شود.
6- مزایا
راه حل به این صورت تشخیص داده شده است که باید مزایای زیر را نگه دارد، که توصیف مراجع از آن بصورت زیر است:
نقطه متمرکز ارتباط.
- سهامداران و پروفایل های مختلف به آسانی اطلاعات را مطابق نیازهای خود جستجو و بررسی میکنند.
ساختارهای وابسته
- دامنه های ساختاری تنظیم شده: تجارت، داده ها، کاربرد و تکنولوژی.
- توانایی ادامه با مؤلفه های فردی در IT شرکتی و درک همه وابستگی ها در دارائی ها و بین آنها.
- تحلیل ها و نمونه ها به هم مرتبط می گردند و کامل تر می شوند.
غنی سازی نمونه های ساختاری
- گزارشات و طرح های اولیه که بصورت اتوماتیک ایجاد می گردند.
- سفر زمانی از طریق AS-WAS، AS-IS و TO-BE، برای شناسایی شکاف های بین ساختارهای جاری و هدف.
- ارزیابی هزینه های موجودی اوراق بهادار و مقایسه سناریوهای تبدیل.
رشد ثابت معماری شرکتی
- کاهش تلاش مورد نیاز برای ایجاد و حفظ اطلاعات منبع شرکتی، منجر شونده به یک منبع یکپارچه
- راهنمایی، بطوریکه مراجع بداند که به چه چیزی نیاز دارد و چطور میتواند آنرا تحویل دهد:
معماری شرکتی برای درک آنچه که بانک دارد.
برنامه ریزی IT استراتژیکی برای درک آنچه که بانک به آن نیاز دارد.
مدیریت اطلاعات برای دانستن اینکه چطور باید آنرا ارائه داد.
- مدیریت معماری شرکتی در مراحل توسعه مختلف: برنامه ریزی، طراحی، ساختمان و توسعه.
7- بازتاب های روی مورد
مورد معرفی شده بیشتر بدین خاطر است که EA از نظر صدها کاربر در بانک در واقع بصورت یک دارائی جاری در بانک مشاهده می گردد، که هر روز در بانک بعنوان مبنای استفاده می گردد که تصمیمات از روی آن گرفته می شود. بنابراین ما میگوییم که این راهکار مبنایی برای نمایش دینامیک سازمان ها بر مبنای مدارک ساختاری واقعی، و بنابراین نسبت به دستگاهی است تا امکان مدیریت سازمان ها بر مبنای نمایش وضعیت های پیش بینی شده آنها را ایجاد کند.
ما میخواهیم که تأیید کنیم که در مورد معرفی شده، دیدگاه های ساختار به شیوه یکپارچه ای با ابزار همکاری و دانش بانک (پورتال اینترنت داخلی) ادغام می گردد. دیدگاه های ساختاری نقطه ورودی برای دسترسی به هر گوننه ثبت IT و دانش نگه داشته شده در ویکی ها است.
این راهکار نه تنها نقش دیدگاه های ساختار را در درک پیچیدگی های تجارت و IT زیرین ممکن می سازد، بلکه همکاری بهتر و موثرتری را نیز بین سهامداران مختلف ایجاد میکند. این یک بازتاب مثبت در استفاده از پورتال اینترنتی EA بعنوان یک سکوی ارتباط و همکاری دارد. ساختار جاری نقش اساسی را در همکاری و ارتباط بین مردم ایفا میکند.
ما اکنون توضیح میدهیم که ابزار و راهکار ما چطور بر موانع کلیدی غلبه میکنند که در غیر اینصورت از اجرای یک ساختار دینامیک و جاری جلوگیری میکنند.
7.1 مانع 1 – تلاش زیاد برای بروزرسانی نمونه ها و مدل های EA
ما می گوییم که هر موقع این مدل های گرافیکی بصورت دستی ایجاد شوند، باید بصورت دستی نیز نگه داشته شوند. بنابراین نمونه ها و مدل های EA باید بصورت اتوماتیک ایجاد گردند. این نظریه کلی پشت ایده نقشه نگاری شرکتی است و نیازمند ابزار خاصی است. در EAMS ، نمونه های ساختار بر مبنای اطلاعات متنی جمع آوری شده از منابع مختلف ایجاد می گردند.
7.2 مانع 2 – انتقال از سناریوهای AS-IS به TO-BE همیشه نیازمند تلاش زیاد و متوقف سازی و دنیاهای غیر مرتبط است
ما می گوییم که توانایی داشتن نقشه های مجزا برای مدیریت لحظه های مجزا در زمان برای بررسی پیچیدگی مسائل واقعی خوب نیست. دلیل وضعیت های موجود در بین AS-IS و TO-BE مشخص نیست و بنابراین نمیتوان سازمان بین آنها را مدیریت کرد.
با EAMS ، نمایش های ساختار دارای اسلایدر زمانی هستند و محتوای آنها بصورت پویا مطابق با تاریخ نشان داده شده بر روی اسلایدر زمانی همراه با شناسایی پروژه های مسئول این تغییرات، تغییر میکند. اینکار امکان دسترسی آسان به دیدگاه های ساختاری ار تاریخ های گذشته (AS-WAS)، حال (AS-IS) و آینده (TO-BE) ، و نقشه های همراه آنها را فراهم می سازد. اینکار همچنین امکان آگاهی از وجود هر گونه وضعیت بین حالت های AS-IS و TO-BE را فراهم می سازد.
7.3 مانع 3 –EA فقط برای تعدادی از موارد روشن شده است
ما می گوییم که زبان های مورد استفاده برای طراحی ساختاری نمی توانند یک زبان کلی را بین همه سهامداران ساختار (خصوصاً مدیریت و کارکنان تجاری) ایجاد کنند، چون برای آنها خیلی پیچیده است و نمی تواند آنچه را که آنها نیاز دارند جستجو کند و نشان دهد. سهامداران علاوه بر پیچیدگی دیدگاه های ساختاری، باید با پیچیدگی ابزار EA نیز روبرو شوند، که برای درک و طراحی مناسب است، اما برای سهامداران غیر فنی مناسب نیست. بنابراین آنها تا حد زیادی به کارکنان فنی وابسته هستند تا پاسخ را برای آنها فراهم سازد.
با EAMS ، دیدگاه های ساختاری و مسیرهای هدایت بین آنها بصورت اتوماتیک مطابق با پروفایل کاربر آنها ایجاد می گردد. بعلاوه، کاربران حرفه ای به لاگین کردن در EAMS نیازی ندارند چون دیدگاه های ساختاری با پورتال اینترنت داخلی بانک ادغام شده است. این مسئله تضمین می کند که سهامداران با پیچیدگی هایی مطابق با نیازها و مهارت های خود روبرو می شوند، و بنابراین مدیریت را قادر می سازد تا دیدگاه های ساختاری را جستجو و بررسی کنند و پاسخ های خود را بدست آورند.
توجه داشته باشید که ایجاد اتوماتیک دیدگاه های ساختاری این تضمین را نیز ایجاد میکند که آنها بروزرسانی می گردند و با اطلاعات موجود مطابقت دارند. این مسئله اطمینان دیدگاه های ساختاری و همچنین کاربرد آنها در جامعه وسیع تری را افزایش میدهد.
7.4 مانع 4 – برنامه ریزی پروژه فقط نیازمند دانش دقیق وضعیت های TO-BE است، نه وضعیت های AS-IS
بطور کلی، برای برنامه ریزی پروژه ای که در یک دوره مشخص در آینده رخ میدهد، باید وضعیت پیش بینی شده در آن دوره زمانی را بدانیم. بعنوان یک مثال، بگذارید سازمانی را تصور کنیم که میخواهد یک سیستم قانونی موجود را در مدت 6 ماه جایگزین کند، و میخواهد که برنامه ریزی این پروژه را امروز شروع کند. مراحل آماده سازی و برنامه ریزی پروژه باید درک واضحی از همه وابستگی های این سیستم قانونی داشته باشد، هم از این لحاظ که آنچه که با یکپارچه سازی سیستم های دیگر و با فرآیند هایی تجاری که پشتیبانی میکند مرتبط است. اما جنبه مهم اینست که برای برنامه ریزی این پروژه، داشتن درک واضحی از همه وابستگی های سیستم قانونی کافی نیست. ما باید وابستگی های قانونی را در این مدت 6 ماه بدانیم چون تا آن موقع، ممکن است پروژه های مداومی وجود داشته باشد که وضعیت وابستگی های سیستم قانوین را تغییر دهند.
با EAMS ، فقط باید اسلاید میله زمانی را 6 ماه به جلو ببریم تا وابستگی های واقعی سیستم قانونی را پیدا کنیم، چون EAMS طرح اولیه ساختاری بر مبنای اطلاعات جمع آوری شده از پروژه های مداوم و برنامه ریزی شده را ایجاد میکند.
این مانع مربوط به مدلسازی مفهوم کاربردی در منبع EA است و مربوط به کارکردی بودن ابزار نیست. البته چون تأثیر زیادی بر روی این مسئله دارد که مردم در کار روزمره خود با هم ارتباط برقرار میکنند، ما معتقدیم که بهتر است در این مقاله آنرا مورد بحث قرار دهیم.
استانداردهایی مانند TOGAF دو نوع کاربرد را برای آن در نظر می گیرند: زیرساخت و کاربردهای تجاری. البته این یک طرح طبقه بندی خیلی ساده است که به مسائل اساسی در مدیریت IT نمی پردازد. از دیدگاه تطبیق تجاری و IT ، یک صفحه گسترده حاوی داده ها و قوانین تجاری یک کاربرد تجاری بصورت SAP ERP یا هر پکیج SW دیگر است. اما از مدیریت و عملیات IT روزانه آنها موارد مشترک کمی با هم دارند.
مثال دیگری از این حقیقت ناشی می گردد که کاربران تجاری اسم کاربردها را در بسیاری از محتواها میدانند و از آنها استفاده میکنند. این یک مشکل محسوب می شود چون یک عنصر نرم افزاری معین را با یک سری از کارکردپذیری ها و سطح های مشترک مرتبط می سازد، و درجه آزادی را از مدیریت IT حذف میکند. برای مثال، موردی را در نظر بگیرید که IT تصمیم می گیرد که دسترسی به برنامه ها را از طریق اینترنت داخلی فراهم سازد، و تجارت ها را وادار سازد تا در مورد اسناد و راهکارهای خود تجدید نظر کنند. این نوع تصمیمات نباید توسط اصول نامگذاری مشکل تر شوند. شرایط بدتر هم خواهد بود اگر برنامه مطابق با سکو یا بسته نرم افزاری مورد استفاده برای ایجاد برنامه نامگذاری شود.
بنابراین ما می گوییم که برنامه ها باید در سه دیدگاه مختلف مدلسازی شوند:
- در ساختار تجاری، IT بصورت یک فراهم کننده یکپارچگی منطقی عملکردهای تجارت مشاهده می گردد، و بنابراین عملکردهای تجاری و شرایط مورد نیاز بصورت مستقل از مؤلفه هایی مدیریت می گردند که آنها را اجرا میکنند.
- در ساختار راه حل، مفهوم برنامه بصورت یک اثر تصنعی است که عملکردهای تجاری را اجرا میکند و بنابراین انعطاف پذیری برای بهترین شیوه مهندسی این مؤلفه ها را فراهم می سازد.
- در ساختار سکو، مفهوم سکو بصورت یک محیط اجرایی از مؤلفه های برنامه است ومیتواند شامل انواع مختلفی از تکنولوژی ها باشد.