התחום של ארכיטקטורה ארגונית הוא תחום ותיק עם פוטנציאל רב אך נכון להיום לא התרומם בצורה משמעותית בישראל. התחום צמח מהעולם הטכנולוגיה אך כעת חותר לכיוון העולם העסקי כשעקרו יצירת נראות ושקיפות בין ה- IT ל- Business.
מצ"ב מספר דגשים שכתבנו בזמנו לגבי כניסה לפרוייקט בתחום מעניין זה. מדובר על דגשים הרלווטיים יותר לתחום המסורתי יותר של EA כאשר כיום ניתן להרחיב זאת יותר לכיוונים העסקיים.
מהם הכלים לשימוש בפרויקטי EA?
שימוש בכלים תלוי במטרה של ה- EA. האם הכוונה ב- EA להיות עזר לניהול התקציב או להיות לעזר בבניית אפליקציות על ידי הגדרה של patterns וכד'. אבל אם מדברים רק על EA בסיסי שאמור לתת inventory של הטכנולוגיות שבשימוש בארגון הרי שישנם ארגונים אשר מתחילים ב- Excel ואז ניתן להגדיר סטנדרטים של טכנולוגיות ולעקוב אחר יישומים. במקביל ישנם ארגונים רבים אחרים אשר בכל זאת מתחילים במודולים בסיסיים של כלי EA. דוגמה לכלי פופולארי היא TROUX שחקנים נוספים הם IBM , IDS SCHEER (כיום חלק מ- softwareAG), MEGA, METASTORM ואחרים.
הסיבה לשימוש בכלים בכל זאת היא הרצון להגדיר קשרים בצורה נוחה. הגדרה כזו תאפשר ל-EA לענות על שאלות מורכבות יותר כגון "לאיזה מערכות מהווה השרת X כ- fail over ומה המשמעות של עדכון גרסה של מערכת ההפעלה שלו". במקביל המענה של הכלים לשאלות בסיסיות כגון "במידה ומוציאים משרות את מערכת X כמה שרתים זה יחסוך" יהיה בהיר יותר ומתאים יותר למנהלים. כמו כן הכלים יאפשרו הזנת נתונים בצורה נוחה גם דרך ממשק WEB וגם דרך קבלת מידע ממקורות שכבר קיימים בארגון כגון מערכות שליטה ובקרה. הכלים מאפשרים גם להתייחס ל- roadmap טכנולוגיה ולבדוק מה הם הפערים בין המצב הנוכחי למצב הרצוי- כל זאת בצורה נוחה. לסיכום, במידה וה- EA הנה תוכנית חשובה של ה-IT אז מומלץ להתחיל בכלים. במידה ורוצים "לטעום" את מהות ה- EA ה- Excel מספיק בהחלט וניתן יהיה להעביר את המידע בעת הצורך לכלים.
עד איזה אמת פירוט צריכה להגיע תוכנת ה- EA?
בדרך כלל ה- inventory צריך לכלול מידע מפורט כולל רמת ה- Service Pack. אבל לגבי גרסאות DLL מקובל לשמור מידע ספציפי רק אם הם מיוחדות ומהוות שירות ספציפי. ניתן להתחיל בגרסאות ראשיות ולאחר מכן לרדת לפרטים במידה וצריך.
באיזה תהליכים בארגון ה- IT צוות ה- EA אמור להיות מעורב?
תלוי ברמת הבשלות (maturity level) של צוות ה- EA.
ברמה הבסיסית צוות ה- EA אחראי על התמונה הכוללת של הטכנולוגיות של הארגון. ולכן הוא צריך להיות אחראי על הסטנדרטים הטכנולוגיים ולהיות מעורב בהחלטות טכנולגיות של כל מערכת בשלב ה-design. כלומר בדרך כלל צוות ה-EA יהיה מעורב בשלב הקונספטואלי של ה- design ולאחר שיתבצע תכנון מפורט של המערכת על ידי צוות הפרוייקט, צוות ה- EA יאשר את התכנון.
עם הזמן כאשר תחום ה- EA מבשיל, מתגבשים בתוך צוות ה- EA מספר תפקידים או תחומי אחריות:
האם מקובל לכלול ב- EA מידע על תהליכי IT בארגון (לדוגמה "נוהל שחזור") ומידע על האנשים והפונקציות ב- IT (לדוגמה מי הם מתכנתי Natural)?
ישנם ארגונים אשר כוללים במסגרת ה- EA מידע זה אך ברוב המקרים אין התייחסות למידע זה מכיוון שמידע על תהלכים נמצא ברמה טובה בגופי התפעול השונים כולל התייחסות לאנשים. המידע שכן נכלל בדרך כל ב- EA ומתקבל מהתפעול הנו רמת השירות (Service Level)של המערכות וזאת בכדי שניתן יהיה לקבל מידע על מידת הזמינות של המערכות.
דוגמאות בהם ה- EA משפר את קבלת ההחלטות \ כיצד להצדיק EA \ דוגמאות לתוצרים של EA?
כבר הרמה הבסיסית של inventory חוסכת לארגונים כסף רב. לדוגמה, ארגון אשר הטמיע EA לאחרונה גילה שיש לו 250 (!!!) קומבינציות של Oracle (עם חומרה ומערכת הפעלה ספציפית) שמחייבות התייחסות תחזוקתית נפרדת והפעלת patches ומנגנוני בדיקה. ארגון זה הוריד את מספר הקומבינציות של Oracle בהדרגה תוך מהלכי עדכון מתוכננים ל- 12.
ארגון אשר הטמיע EA בסיסי גילה שיש לו מספר מערכות BEA אשר משמשות לצרכים שונים (LOB שונים) אשר יכולות לרוץ על אותו שרת ובכך הורידו את מספר השרתים בארגון.
ארגון פיננסי אשר הטמיע EA גילה שיש לו 3 אפליקציות אשר מבצעות את אותה פעולה -credit card validation ! החסכון במקרה זה היה מיידי.
כאשר מביאים אפליקציה חדשה לארגון הגוף היחיד בארגון שיכול לתת תשובה אמיתית ומהירה לשאלה "מה משמעות הטמעת המערכת החדשה" הוא גוף ה- EA. זאת מכיוון שגוף ה- EA הנו הגוף היחידי שמכיר את כל הטכנולוגיות בארגון וכיווני ההתפתחות שלהם וכמו כן את צורת ההתממשקות. ניתן לחילופין לשאול כל גוף טכנולוגי בארגון בנפרד – תשתיות, תקשורת, אינטגרציה, אבטחת מידע וכד'. אולם כל גוף זה יתן רק את הפרספטיבה שלו ללא ניתנה של סדר עדיפויות וגם תהליך כזה ייקח המון זמן.
במידה והארגון כבר מימש SOA ה-EA עוזר לזהות איזה שירותים כבר קיימים בארגון ואיך לבנות את השירותים כך שיתנו מענה לכמה שיותר צרכים.
במידה ויש EA בוגר אשר גם מכיל מידע אל האפליקציות ועל העלויות, אזי ה- EA משמש ככלי בניהול התקציב. ישנם מקרים רבים בהם ה-EA "גילה" לארגון שהוא משקיע תקציב רב במערכת שמשמשת למספר לא רב של משתמשים. בדרך כלל מצב כזה קורה כאשר פעם מערכת אכן הייתה קריטית אבל היא כבר הוחלפה ברוב הפונקציונליות שלה אבל בכל זאת משאירים אותה בשביל מספר פונקציות שאינן נתמכות במערכת החדשה וממשיכים לקצב את האפליקציה הישנה. במקרים כאלו ה- EA עזר לחשוף את העיוות.
כאשר ישנה תוכנית EA בוגרת, ישנו שיפור בתהליכים העסקיים ותיעול הזדמנויות עסקיות אשר מתגלות על ידי ה- EA. כמו גם הארגון מבצע שינויים בצורה מהירה יותר. כלומר יש תרומה ל- business agility.
כאשר ישנה תוכנית EA בוגרת שמממשת SOA, מראים להנהלה מדי פעם איזה אפליקציות חדשות הוקמו על בסיס שירותים שכבר קיימים.
מספר המלצות להתחלה של EA
במקרים רבים צוות ה-EA דואג לאיסוף המידע הראשוני בצורה ידנית וגם בצורה של גזירה מנתונים קיימים (דוגמה ממערכות שליטה ובקרה).
במידה ויש חלקים בארגון שמתנגדים במיוחד ל- EA – יש להשאיר אותם לסוף לאחר שכבר נאסף מידע בארגון.
ניתן גם לבצע pilot של EA – בנייה של EA אבל רק בכמה domains לדוגמה- שרתים ו- DBMS ואפילו APP SERVER. אם מוכיחים שה- pilot גילה דברים מעניינים – ההנהלה נותנת תקציב להמשך.
המידע שנאסף על ידי ה- EA חייב להיות פתוח לכל הארגון.
גם בשלבים הראשונים חייבים שיהיה executive sponsorship. ללא זה – לא ניתן להתקדם כלל.
מצ"ב מספר דגשים שכתבנו בזמנו לגבי כניסה לפרוייקט בתחום מעניין זה. מדובר על דגשים הרלווטיים יותר לתחום המסורתי יותר של EA כאשר כיום ניתן להרחיב זאת יותר לכיוונים העסקיים.
מהם הכלים לשימוש בפרויקטי EA?
שימוש בכלים תלוי במטרה של ה- EA. האם הכוונה ב- EA להיות עזר לניהול התקציב או להיות לעזר בבניית אפליקציות על ידי הגדרה של patterns וכד'. אבל אם מדברים רק על EA בסיסי שאמור לתת inventory של הטכנולוגיות שבשימוש בארגון הרי שישנם ארגונים אשר מתחילים ב- Excel ואז ניתן להגדיר סטנדרטים של טכנולוגיות ולעקוב אחר יישומים. במקביל ישנם ארגונים רבים אחרים אשר בכל זאת מתחילים במודולים בסיסיים של כלי EA. דוגמה לכלי פופולארי היא TROUX שחקנים נוספים הם IBM , IDS SCHEER (כיום חלק מ- softwareAG), MEGA, METASTORM ואחרים.
הסיבה לשימוש בכלים בכל זאת היא הרצון להגדיר קשרים בצורה נוחה. הגדרה כזו תאפשר ל-EA לענות על שאלות מורכבות יותר כגון "לאיזה מערכות מהווה השרת X כ- fail over ומה המשמעות של עדכון גרסה של מערכת ההפעלה שלו". במקביל המענה של הכלים לשאלות בסיסיות כגון "במידה ומוציאים משרות את מערכת X כמה שרתים זה יחסוך" יהיה בהיר יותר ומתאים יותר למנהלים. כמו כן הכלים יאפשרו הזנת נתונים בצורה נוחה גם דרך ממשק WEB וגם דרך קבלת מידע ממקורות שכבר קיימים בארגון כגון מערכות שליטה ובקרה. הכלים מאפשרים גם להתייחס ל- roadmap טכנולוגיה ולבדוק מה הם הפערים בין המצב הנוכחי למצב הרצוי- כל זאת בצורה נוחה. לסיכום, במידה וה- EA הנה תוכנית חשובה של ה-IT אז מומלץ להתחיל בכלים. במידה ורוצים "לטעום" את מהות ה- EA ה- Excel מספיק בהחלט וניתן יהיה להעביר את המידע בעת הצורך לכלים.
עד איזה אמת פירוט צריכה להגיע תוכנת ה- EA?
בדרך כלל ה- inventory צריך לכלול מידע מפורט כולל רמת ה- Service Pack. אבל לגבי גרסאות DLL מקובל לשמור מידע ספציפי רק אם הם מיוחדות ומהוות שירות ספציפי. ניתן להתחיל בגרסאות ראשיות ולאחר מכן לרדת לפרטים במידה וצריך.
באיזה תהליכים בארגון ה- IT צוות ה- EA אמור להיות מעורב?
תלוי ברמת הבשלות (maturity level) של צוות ה- EA.
ברמה הבסיסית צוות ה- EA אחראי על התמונה הכוללת של הטכנולוגיות של הארגון. ולכן הוא צריך להיות אחראי על הסטנדרטים הטכנולוגיים ולהיות מעורב בהחלטות טכנולגיות של כל מערכת בשלב ה-design. כלומר בדרך כלל צוות ה-EA יהיה מעורב בשלב הקונספטואלי של ה- design ולאחר שיתבצע תכנון מפורט של המערכת על ידי צוות הפרוייקט, צוות ה- EA יאשר את התכנון.
עם הזמן כאשר תחום ה- EA מבשיל, מתגבשים בתוך צוות ה- EA מספר תפקידים או תחומי אחריות:
- Business Architecture – אשר מחזיק מידע על תהליכים עסקיים בארגון והנו שותף לקביעת תהליכים עסקיים אלו תוך ראייה כוללת של תמיכת ה- IT בכלל התהליכים העסקיים.
- Information Architecture – אשר מחזיק מידע על פרטי המידע בארגון. הוא יכול לענות לדוגמה על השאלה "באיזה מערכות ואיפה נמצא המידע על הלקוחות של הארגון".
- Application Architecture – אשר מחזיק במידע יותר מפורט מה- Business Architecture על הטיפול של האפליקציות השונות בתהליכים העסקיים והממשקים בינהם.
- Technology Architecture – אשר מחזיק מידע על הטכנולוגיות השונות (שזה השלב ההתחלתי של ה- EA).
האם מקובל לכלול ב- EA מידע על תהליכי IT בארגון (לדוגמה "נוהל שחזור") ומידע על האנשים והפונקציות ב- IT (לדוגמה מי הם מתכנתי Natural)?
ישנם ארגונים אשר כוללים במסגרת ה- EA מידע זה אך ברוב המקרים אין התייחסות למידע זה מכיוון שמידע על תהלכים נמצא ברמה טובה בגופי התפעול השונים כולל התייחסות לאנשים. המידע שכן נכלל בדרך כל ב- EA ומתקבל מהתפעול הנו רמת השירות (Service Level)של המערכות וזאת בכדי שניתן יהיה לקבל מידע על מידת הזמינות של המערכות.
דוגמאות בהם ה- EA משפר את קבלת ההחלטות \ כיצד להצדיק EA \ דוגמאות לתוצרים של EA?
כבר הרמה הבסיסית של inventory חוסכת לארגונים כסף רב. לדוגמה, ארגון אשר הטמיע EA לאחרונה גילה שיש לו 250 (!!!) קומבינציות של Oracle (עם חומרה ומערכת הפעלה ספציפית) שמחייבות התייחסות תחזוקתית נפרדת והפעלת patches ומנגנוני בדיקה. ארגון זה הוריד את מספר הקומבינציות של Oracle בהדרגה תוך מהלכי עדכון מתוכננים ל- 12.
ארגון אשר הטמיע EA בסיסי גילה שיש לו מספר מערכות BEA אשר משמשות לצרכים שונים (LOB שונים) אשר יכולות לרוץ על אותו שרת ובכך הורידו את מספר השרתים בארגון.
ארגון פיננסי אשר הטמיע EA גילה שיש לו 3 אפליקציות אשר מבצעות את אותה פעולה -credit card validation ! החסכון במקרה זה היה מיידי.
כאשר מביאים אפליקציה חדשה לארגון הגוף היחיד בארגון שיכול לתת תשובה אמיתית ומהירה לשאלה "מה משמעות הטמעת המערכת החדשה" הוא גוף ה- EA. זאת מכיוון שגוף ה- EA הנו הגוף היחידי שמכיר את כל הטכנולוגיות בארגון וכיווני ההתפתחות שלהם וכמו כן את צורת ההתממשקות. ניתן לחילופין לשאול כל גוף טכנולוגי בארגון בנפרד – תשתיות, תקשורת, אינטגרציה, אבטחת מידע וכד'. אולם כל גוף זה יתן רק את הפרספטיבה שלו ללא ניתנה של סדר עדיפויות וגם תהליך כזה ייקח המון זמן.
במידה והארגון כבר מימש SOA ה-EA עוזר לזהות איזה שירותים כבר קיימים בארגון ואיך לבנות את השירותים כך שיתנו מענה לכמה שיותר צרכים.
במידה ויש EA בוגר אשר גם מכיל מידע אל האפליקציות ועל העלויות, אזי ה- EA משמש ככלי בניהול התקציב. ישנם מקרים רבים בהם ה-EA "גילה" לארגון שהוא משקיע תקציב רב במערכת שמשמשת למספר לא רב של משתמשים. בדרך כלל מצב כזה קורה כאשר פעם מערכת אכן הייתה קריטית אבל היא כבר הוחלפה ברוב הפונקציונליות שלה אבל בכל זאת משאירים אותה בשביל מספר פונקציות שאינן נתמכות במערכת החדשה וממשיכים לקצב את האפליקציה הישנה. במקרים כאלו ה- EA עזר לחשוף את העיוות.
כאשר ישנה תוכנית EA בוגרת, ישנו שיפור בתהליכים העסקיים ותיעול הזדמנויות עסקיות אשר מתגלות על ידי ה- EA. כמו גם הארגון מבצע שינויים בצורה מהירה יותר. כלומר יש תרומה ל- business agility.
כאשר ישנה תוכנית EA בוגרת שמממשת SOA, מראים להנהלה מדי פעם איזה אפליקציות חדשות הוקמו על בסיס שירותים שכבר קיימים.
מספר המלצות להתחלה של EA
במקרים רבים צוות ה-EA דואג לאיסוף המידע הראשוני בצורה ידנית וגם בצורה של גזירה מנתונים קיימים (דוגמה ממערכות שליטה ובקרה).
במידה ויש חלקים בארגון שמתנגדים במיוחד ל- EA – יש להשאיר אותם לסוף לאחר שכבר נאסף מידע בארגון.
ניתן גם לבצע pilot של EA – בנייה של EA אבל רק בכמה domains לדוגמה- שרתים ו- DBMS ואפילו APP SERVER. אם מוכיחים שה- pilot גילה דברים מעניינים – ההנהלה נותנת תקציב להמשך.
המידע שנאסף על ידי ה- EA חייב להיות פתוח לכל הארגון.
גם בשלבים הראשונים חייבים שיהיה executive sponsorship. ללא זה – לא ניתן להתקדם כלל.
אין תגובות:
הוסף רשומת תגובה