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

توجه : به همراه فایل word این محصول فایل پاورپوینت (PowerPoint) و اسلاید های آن به صورت هدیه ارائه خواهد شد

 مقاله ترجمه شده موردی برای یک معماری شرکتی جاری در یک بانک خصوصی دارای ۱۶ صفحه می باشد و دارای تنظیمات در microsoft word می باشد و آماده پرینت یا چاپ است

فایل ورد مقاله ترجمه شده موردی برای یک معماری شرکتی جاری در یک بانک خصوصی  کاملا فرمت بندی و تنظیم شده در استاندارد دانشگاه  و مراکز دولتی می باشد.

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

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

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

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

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

۱- در مورد مراجع
مراجع در این مطالعه موردی، یک بانک خصوصی است که در شبه جزیره ایبری واقع است و فعالیت های بانکداری سرمایه گذاری (دارائی خالص، مالیه شرکتی و بانکداری خصوصی) را انجام میدهد. این بانک از طریق شبکه توزیع چند کانالی خود (که از حدود ۶۵۰ شعبه تشکیل شده است و شبکه ای از توسعه دهندگان خارجی، ساختارهای مختص به مشتریان شرکتی و سازمانی، بانکداری تلفنی، و خدمات بانکداری خانگی است) به حدود ۲ میلیون مشتری ارائه خدمات میکند. در مدیریت دارائی، این بانک هر موقعیت مربوطه ای را در مدیریت وجوه مؤسسات سرمایه گذار، وجوه بازنشستگی، و بیمه های عمر دارد.
۲- محتوا
در سال ۲۰۱۲، بانک گزارش داد که طرح بندی شکل و حیطه پروژه EA را بعنوان ابزاری برای پشتیبانی موثرتر از تجارت، کاهش هزینه های توسعه و زمان بازاریابی آغاز کرده است. از بین مسائل مربوطه، مسائل زیر مهم تر هستند که آنها را بیان میکنیم:

– بانک قبلاً در EA تجربه داشت، چون مجبور بود که از ابزار مدلسازی برای ایجاد نمونه ها و مدل های ساختار ITاستفاده کند. این راهکار بر مبنای یک منبع مرکزی بود که همه مدل ها در آن قرار داشتند، و هر کدام از آنها بصورت دستی با ابزار EA طراحی میشد. این راهکار نیازمند تلاش اساسی برای بروزرسانی بود، خصوصاً اگر مدلهای تولید شده در پروژه های مختلف در یک دیدگاه واحد و شرکتی از منظره IT با هم ترکیب می شدند. بنابراین تلاش برای نگهداری نمونه های EA یک مسئله کلیدی برای این پروژه بود.
– بانک یک زیرساخت خدمات ساختار-محور (SOA) را بعنوان راهی برای تفسیر یکپارچگی کاربرد و ساختار IT آن ایجاد کرده بود. بنابراین، نمایش خدمات و مفاهیم مربوطه نیز مسئله اصلی در این پروژه به شمار می رفت.
– و در نهایت اینکه، این بانک در حال توسعه انتشار فرآیند توسعه سریع الانتقال بود. این فرآیند در سال ۲۰۱۰ با استفاده از SCRUM آغاز شد. در سال ۲۰۱۲ تعداد تیم ها به ۳۰ تیم (۲۲۰ نفر) و در سال ۲۰۱۳ به ۵۰ تیم (۳۲۰ نفر) افزایش یافت که در SCRUM کار میکردند.
این بانک علاوه بر مسائل بالا یک پورتالEA را نیز در اینترنت داخلی ایجاد کرده بود که از ثبت اطلاعات مربوط به ساختارهای کاربرد و تکنولوژی پشتیبانی می کرد. پورتال اینترنت داخلی شامل تعداد زیادی از ویژگی ها (مانند ویکی ها) با مقدار قابل توجهی از مقالات بود که فرآیند ها و ساختار سیستم را توصیف می کرد و یک نقطه ورودی را برای همه ثبت های فنی ایجاد می کرد.
پورتال اینترنت داخلی EA به جمع آوری و نمایش اطلاعات ساختاری در مورد بانک کمک میکرد که بصورت لیست معرفی می شد و یا در موارد ساده تر، به شکل نقشه های سلسله مرتبه ای ساده نمایش داده می شد که بصورت اتوماتیک از اطلاعات متنی ایجاد می شد. مردم بعضی از فرم هایی را پر کنند که ورودی برای پورتال اینترنت داخلی بودند و سپس برای ایجاد بعضی از نقشه استفاده می شدند.

خودکار سازی دیدگاه های ساختاری ساده تر یک مرحله اساسی در تعیین نگرش های بانک

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

ی کند: اگر موجود باشد پس در اینترنت داخلی موجود است. برای رسیدن به این سطح از پیشرفت، بانک می بایست:
– توانایی کلی پورتالEA برای پشتیبانی از دیدگاه های مختلف مطابق با پروفایل کاربر را افزایش دهد. اینکار استفاده از نقطه مرکزی ارتباط برای مخاطبان غیر یکنواخت از تجارت به دامنه های IT را امکان پذیر می سازد.
– رشد اطلاعات در پورتالEA را توسط کاهش تلاش مورد نیاز برای ایجاد و نگهداری گزارشات، نمونه ها و اطلاعات منبع شرکتی افزایش دهد.
– تکامل دارائی ها را در سراسر طول دوره آنها بدست آورد (از لحظه ای که مشاهده می شدند تا زمانیکه لغو می شدند).
تکامل پورتال باید از یک دیدگاه یکپارچه حمایت کند و در عین حال به کاربران اجازه دهد تا از نمونه های ساختاری، ویکی ها، انجمن های بحث و همه محیط ها و ابزارهای همکاری مربوطه استفاده کنند.
چالش دوم نیاز به نگهداری نمونه های ساختاری به شیوه آسان بود. بانک قانون دوم را بیان کرد: “اگر یک دیدگاه ساختاری را نتوانیم بصورت اتوماتیک با اطلاعات بروزرسانی شده ایجاد کنیم، پس نمی توانیم آنرا در پورتالEA نشان دهیم”. این اطلاعات باید از منابع مختلفی مانند Microsoft SharePoint، یا Oracle Enterprise Repository بدست می آمد. اطلاعات موجود از منابع مختلف در یک منبع مرکزی که مطابق با مدل متای موجود ساختاربندی شده بود با هم ترکیب می شدند. این مدل باید مطابق با بهترین تکنیک های بازار تکامل پیدا می کرد و باید قادر می بود که همه ویژگی ها، روابط و خصوصیاتی را با هم مطابقت دهد که مفاهیم ساختارهای مختلف را توصیف می کرد.
چالش سوم نیاز به تداوم استفاده مخاطبان از منحنی یادگیری پورتال اینترنت داخلی ساختار بود. مخاطب باید قادر می بود که به آسانی محتوا و نمونه ها را بررسی و جستجو کند. اطلاعات باید به شیوه ساده و خود اکتشافی نمایش داده می شدند، و همچنین به کاربران اجازه میدادند که جزئیات را مشاهده کنند و در صورت لزوم نمونه ها را بصورت کامل دریافت کنند. پورتال و دیدگاه های ساختاری به این صورت صرفنظر از سطح مهارت کاربر در دامنه ها یا لایه های ساختاری خاص، بصورت ابزار ارتباطی مناسبی عمل می کنند.
چالش چهارم ترکیب ابتکارات SOA در ابتکارات معماری شرکتی بود. SOA در انبار شرکتی Oracle با مدل متای خود با بیش از ۶۰ نهاد ایجاد شده بود. بنابراین بانک باید تصمیم می گرفت که این مفاهیم SOA باید در چه حدودی در مدل متای معماری شرکتی نشان داده شوند.
OER نیز مانند انبار SOA میتواند دیدگاه های اطلاعات خارجی را فراهم سازد اما با دو مشکل اصلی روبرو بود:
– دانش کامل مدل متای OER را تفهیم کند و بنابراین فقط برای افراد فنی مناسب است. برای مثال، برای جستجو در بین خدمات تولیدی و مصرفی باید با مفاهیم زیادی مانند سطح های مشترک، پروتکل ها و غیره آشنا باشیم.
– با مفاهیم ساختارهای دیگر ترکیب نگردد و بنابراین از جستجوی یکپارچه برای معماران و تحلیل گران در پورتالEA جلوگیری کند.
و در نهایت، چالش پنجم این بود که مصالحه فرآیند توسعه سریع الانتقال را در عمل و در بانک با EA پیش بینی کند. این چالش به این صورت بود که راهی را برای نشان دادن نتایج فعالیت های آینده تصور کند و قبل از آغاز توسعه، برای همه تیم ها در دسترس باشد. این یکپارچه سازی در حیطه پروژه اولیه نبود بلکه در زمان نوشتن این مقاله بود و بعضی اوقات خود بانک قادر است که با استفاده از EAMS عملکرد خوبی داشته باشد.
۴- پروژه
پروژه در اوایل سال ۲۰۱۳ آغاز شد و در آگوست ۲۰۱۳ به پایان رسید. Link Consulting خدمات مشاوره EA را ارائه میداد و سری ابزار مورد استفاده در پروژه را فراهم می ساخت. این پروژه نیازمند ۳ نفر از Link Consulting و یک تیم ۱۰ نفره از مراجع ها بودند که مسئول ساختار، اطلاعات، راه حل ها، سکوها، زیرساخت، تجربه کاربرد و همچنین مدیر انبار EA بودند.
هدف این پروژه اجرا و توسعه یک راه حل EA بود که بطور کامل در اینترنت داخلی موجود ترکیب می شود، بطوریکه همه فعالیت های اداره خانه را بتوان به شیوه یکپارچه ای در اینترنت داخلی بانک انجام داد.

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

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

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

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

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

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

در حال حاضر بانک بصورت داخلی جریان کاری را ایجاد کرده است تا فایل های XML را ایجاد کند که بر اسا اطلاعات موجود در فرم های اینترنت داخلی، با سناریوهای ساختاری EAMS مطابقت دارند، که تلاش صرف شده برای بروزرسانی را تقریباً به صفر کاهش میداد. در نتیجه، تغییرات پیش بینی شده برای ساختار در برنامه ریزی هر فعالیت در اول هر ماه بروزرسانی می گردد و در همان لحظه برای همه تیم ها قابل مشاهده خواهد بود، بطوریکه آنها بتوانند اطلاعات بروزرسانی شده ای را برای برنامه ریزی فعالیت بعدی داشته باشند.
در پایان هر فعالیت، هر گونه تغییر بین تغییرات برنامه ریزی شده و واقعی در ساختار نیز در منبع EA بروزرسانی می گردد. بنابراین از دیدگاه منبع EA هر فعالیت دارای یک تاریخ آغاز، یک تاریخ پایان، و دو لیست با رجوع به عناصر ساختار می باشد. لیست زنده مربوط به عناصری است که در هنگام تکمیل فعالیت وارد تولید می شوند، و لیست مرده مربوط به عناصری است که پس از پایان فعالیت لغو می گردد. ما با استفاده از تاریخ آغاز فعالیت ها و تاریخ پایان فعالیت ها، هر یک از عناصر ساختار را در مبنای دانش با اثرات زمانی تگ بندی میکنیم:
– ذهنی، وقتی که در یک فعالیت مشخص برنامه ریزی، طراحی یا ایجاد می گردد. تگ (اطلاعات کوچک برای طبقه بندی) اثرات زمانی مطابق با تاریخ آغاز فعالیت تعیین می گردد.
– زنده، وقتی که آنها بعنوان نتیجه یک فعالیت در سازمان وارد می گردند. تگ اثرات زمانی مطابق با تاریخ پایان فعالیت تعیین می گردد.
– مرده، وقتی که آنها دیگر در سازمان استفاده نمی شوند، که این هم نتیجه بعضی از فعالیت ها است. تگ اثرات زمانی مطابق با تاریخ پایان فعالیت تعیین می گردد.
این اثرات زمانی برای ردیابی طول دوره عناصر ساختار، و آگاهی از محتوای دیدگاه های مربوط به هر زمان در گذشته، حال یا آینده کافی هستند.

این بدین معناست که این راهکار در واقع به این خاطر استفاده شده است تا ساختار را بصورت بروزرسانی شده نگه دارد و بر مبنای آپلود وضعیت های To-BE سازمان بصورت پیش بینی در طرح های هر یک از ۵۰ تیم سریع الانتقال است که در بانک عمل میکنند.
این راهکار باید توسط ابزار مورد استفاده با دو ویژگی اصلی پشتیبانی گردد:
– منبع EA باید قادر باشد که اطلاعات مربوط به وضعیت های آینده عناصر ساختار را نگه دارد. اینکار توسط همراه سازی تگ های ذهنی، زنده و مرده بعنوان خصوصیات پیش فرض در هر عنصر ساختار انجام می شود که مکان انتشار طول دوره آنها را فراهم می سازد.
– ایجاد کننده طرح اولیه باید قادر باشد که طرح های اولیه ای را ایجاد کند که وضعیت های جاری و آینده را برای ساختار نشان میدهند. این یک ویژگی فطری EAMSاست. همه دیدگاه های ساختاری دارای یک اسلاید زمانی همراه خود هستند که با لحظه های زمانی مشخص می گردد و در آن، پکیج های کاری وجود دارد که تغییراتی را در دیدگاه ساختاری ایجاد میکنند. وقتی که وقتی که دسته در امتداد اسلاید حرکت میکند، و از یک علامت عبور میکند، نام پکیج کاری که باعث این تغییرات شده است در سمت چپ و محتوای تغییرات دیدگاه ساختاری نمایش داده می شود.
۶- مزایا
راه حل به این صورت تشخیص داده شده است که باید مزایای زیر را نگه دارد، که توصیف مراجع از آن بصورت زیر است:
نقطه متمرکز ارتباط.
– سهامداران و پروفایل های مختلف به آسانی اطلاعات را مطابق نیازهای خود جستجو و بررسی میکنند.
ساختارهای وابسته
– دامنه های ساختاری تنظیم شده: تجارت، داده ها، کاربرد و تکنولوژی.
– توانایی ادامه با مؤلفه های فردی در IT شرکتی و درک همه وابستگی ها در دارائی ها و بین آنها.
– تحلیل ها و نمونه ها به هم مرتبط می گردند و کامل تر می شوند.
غنی سازی نمونه های ساختاری
– گزارشات و طرح های اولیه که بصورت اتوماتیک ایجاد می گردند.
– سفر زمانی از طریق AS-WAS، AS-IS و TO-BE، برای شناسایی شکاف های بین ساختارهای جاری و هدف.
– ارزیابی هزینه های موجودی اوراق بهادار و مقایسه سناریوهای تبدیل.
رشد ثابت معماری شرکتی
– کاهش تلاش مورد نیاز برای ایجاد و حفظ اطلاعات منبع شرکتی، منجر شونده به یک منبع یکپارچه
– راهنمایی، بطوریکه مراجع بداند که به چه چیزی نیاز دارد و چطور میتواند آنرا تحویل دهد:
معماری شرکتی برای درک آنچه که بانک دارد.

برنامه ریزی IT استراتژیکی برای درک آنچه که بانک به آن نیاز دارد.