اختصاصی از
نیک فایل دانلود مقاله مقاله ترجمه شده موردی برای یک معماری شرکتی جاری دانلود با لینک مستقیم و پر سرعت .
مقاله ترجمه شده موردی برای یک معماری شرکتی جاری در یک بانک خصوصیچکیده
این مقاله موردی را برای توسعه معماری شرکتی (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.
- نابسندگی سطح مدل متا در مورد منابع اطلاعات مطابق و جزئیات. پیچیدگی مدل متای مبنای دانش باید برای نیازهای فوری و منابع اطلاعاتی موجود مناسب باشد.
- افرادی که اعتماد خود را به پروژه از دست می دهند اگر نتایج کوتاه مدت آنرا مشاهده نکنند.
- اطمینان از اینکه کاربران به اطلاعات معرفی شده در دیدگاه های ساختاری اعتماد دارند.
بنابراین ما یک راهکار عملی را اتخاذ کردیم، که بر طراحی یک مدل متا تمرکز دارد که برای اطلاعاتی که بانک در آغاز پروژه داشت امکان پذیر است، اما قوانین وابستگی مبنای مربوط به جداسازی لایه را حفظ میکند و این اطمینان را ایجاد میکند که هر لایه از ساختار توسط خدمات یا امکانات فراهم شده توسط لایه پایینی پشتیبانی می گردد.
اینکار امکان استقلال لایه های ساختاری را فراهم می سازد و تحلیل های تأثیر پایین-بالا و بالا-پایین عناصر ساختاری را ساده تر می سازد. البته چون همه لایه ها لیستی از خدماتی ندارند که ارائه میدهند و مصرف میکنند، مهم بود که امکان ارتباط لایه ها با را فراهم سازیم که این خدمات در بین آنها مبادله میشود. در غیر اینصورت، کل پروژه میتواند منتظر اطلاعات باشد و هیچ نتیجه کوتاه مدتی مشاهده نگردد.
فرمت این مقاله به صورت Word و با قابلیت ویرایش میباشد
تعداد صفحات این مقاله 12 صفحه
پس از پرداخت ، میتوانید مقاله را به صورت انلاین دانلود کنید
دانلود با لینک مستقیم
دانلود مقاله مقاله ترجمه شده موردی برای یک معماری شرکتی جاری 
