بخش مهمی از مدرن‌سازی معماری، ایجاد چشم‌اندازی از معماریِ نوسازی شده است. این کار به شما امکان می‌دهد چالش‌ها و فرصت‌های هر بخش را شناسایی کرده و سفر خود را از وضعیت جاری به چشم‌انداز آینده برنامه‌ریزی کنید. برای این کار، به یک زبان نیاز دارید. این زبان شامل مجموعه‌ای از بلوک‌های ساختاری است که برای توصیف معماری خود، از نمای کلی تا برنامه‌های نرم‌افزاری منفرد را به کمک آن معرفی می‌کنید.
هیچ زبان جهان شمول پذیرفته‌شده‌ای برای توصیف معماری وجود ندارد. بنابراین باید زبانی را انتخاب یا ابداع کنید که برای کسب و کار شما مناسب باشد. من در این فصل، رویکردی به نام "طبقه‌بندی محصولات" را به شما معرفی خواهم کرد. این رویکرد مجموعه‌ای از بلوک‌های ساختاری است که برای توصیف معماری بر اساس محصولات شرکت و نتایج کسب و کار و مشتری که آنها را ممکن می‌سازد، استفاده می‌شود.
من رویکردی محصول‌محور را توصیه می‌کنم چون به شما کمک می‌کند تا معماری و ساختار سازمانی را برای تیم‌های محصول توانمندسازی‌شده با جریان سریع و پایدار که برای نتایج کلیدی کسب و کار بهینه‌سازی شده‌اند، طراحی کنید. اما برای بهره‌مند شدن از ایده‌های این نوشتار، نیازی به استفاده از بلوک‌های ساختاری ارائه‌شده در این قسمت ندارید. این فقط یک رویکرد ممکن است (هرچند پیش‌فرضی خوب و منطقی است). شما می‌توانید از بلوک‌های ساختاری ترجیحی خود استفاده کنید.
به خاطر داشته باشید که این فصل بر تعریف زبانی برای توصیف معماری شما تمرکز دارد. استفاده از این بلوک‌های ساختاری برای طراحی معماری در فصل‌های بعدی پوشش داده می‌شود.
به تعریف بلوک‌های ساختاری که برای سازمان شما بیشترین معنا را دارند خوش آمدید.تعریف بلوک‌های ساختاری اولین گام برای ساخت و استفاده از یک طبقه‌بندی محصول است. شما از این مفاهیم برای مدل‌سازی معماری و زبان مورد استفاده، برای توصیف کسب و کار خود استفاده خواهید کرد.
این بخش بلوک‌های ساختاری مثالی را ارائه می‌دهند که می‌توانید به عنوان نقطه شروع استفاده کنید. این بخش تلاش نمی‌کند که همه‌ی سناریوی‌های ممکن برای تمامی سازمان‌ها را پوشش دهد. شما باید بر اساس نیاز، آنها را تطبیق داده، گسترش دهید یا کاملاً جایگزین کنید. به عنوان مثال، همه‌ی محصولات و قابلیت‌ها دیجیتال نخواهند بود. بنابراین، می‌توانید مفاهیم غیر دیجیتال را نیز نشان دهید تا تصویر کامل را در هنگام اتخاذ تصمیمات طراحی در نظر داشته باشید. در حین خواندن این بخش، به خاطر داشته باشید که در قسمت‌های بعدی هر مفهوم را با جزئیات بیشتری پوشش خواهیم داد.
جریان‌های ارزش مستقل یک بلوک ساختاری حیاتی هستند زیرا شناسایی جریان‌های ارزش مستقل کلید دستیابی به جریان‌های سریع است. در این سلسله مطالب، به توالی فعالیت‌های تیمی، از شناسایی نیازهای برآورده نشده کاربران تا ارائه‌ی راه‌حل و اعتبارسنجی آنها، مانند اضافه کردن ویژگی‌های جدید به یک محصول، جریان ارزش مستقل می‌گوییم. معمولاً، جریانات شامل فعالیت‌های متعددی مانند جلسات کشف محصول، تعریف نیازمندی‌ها، برنامه‌ریزی، کدنویسی، بازبینی، آزمایش و استقرار خواهند بود.
ماهیت جریان‌های ارزش می‌توانند متنوع باشند. مثال‌های زیر را در نظر بگیرید:
چهار ویژگی مهم برای ایجاد یک جریان ارزش مستقل با جریان سریع وجود دارد:
زمانی که این جنبه‌ها در جای خود قرار گیرند و جریان‌های ارزش مستقل باشند، تیم‌ها انگیزه پیدا می‌کنند که به یک نتیجه‌ی کسب و کاری دست یابند و قدرت طراحی، پیاده‌سازی و تحویل راه‌حل‌هایی با حداقل وابستگی به افراد خارج از تیم را خواهند داشت. این جنبه‌ها به طور مفصل در طول این فصل و فصل‌های بعدی پوشش داده می‌شوند.
جریان‌های ارزش هرگز 100٪ مستقل نخواهند بود. قدرت سازمان‌ها در این است که از کار همزمان چندین تیم با هم توانمندی‌های سطح بالاتری را تولید می‌کنند که هیچ تیم واحدی به تنهایی قادر به ارائه آن نیست. بنابراین، لازم است جریان‌های ارزش را که به نتایج کسب و کاری سطح بالاتری کمک می‌کنند شناسایی کرده و آنها را گروه‌بندی کنیم تا تیم‌های مرتبط، هم‌راستا باقی بمانند، دانش خود را به اشتراک گذاشته و تا حد ممکن برای دستیابی به جریان سریع از ابتدا تا انتهای کار، همکاری کنند.
دامنه‌ها بلوک‌های ساختاری‌ای هستند که نمایانگر گروهی از زیردامنه‌های مرتبط هستند که شامل مفاهیم دامنه مشابه بوده و به اهداف سطح بالاتر مشابهی کمک می‌کنند. بنابراین، جریان‌های ارزش بر اساس رابطه‌ی بین زیردامنه‌ها و نتایج کسب و کارشان به دامنه‌ها سازماندهی می‌شوند.
شکل زیر نمونه‌ای از دو دامنه را نشان می‌دهد که یکی از آنها دامنه‌ی E-Comerce است که شامل چهار زیردامنه‌ی کارت، قیمت، محصول و جستجو است. برای هر زیردامنه یک جریان ارزش اختصاصی ایجاد شده است.
در سازمان‌های بزرگتر، دامنه‌ها ممکن است به صورت سلسله مراتبی در گستره‌های مختلف تعریف شوند تا گروه‌های مرتبط را هم‌راستا کرده و خطوط مسئولیت‌پذیری سطح بالاتر را ایجاد کنند. شکل زیر این مفهوم را بر اساس سطوح گسترهی معماری روت مالان و دانا بردمایر نشان می‌دهد.
تعداد محدوده‌ها به اندازه‌ی سازمان و پیچیدگی دامنه بستگی دارد. برخی سازمان‌ها بیش از سه محدوده و برخی دیگر کمتر از سه محدوده دارند.
همه‌ی دامنه‌ها در یک محده‌ی مشخص، اندازه و پیچیدگی یکسانی نخواهند داشت. شکل بالا یک ساده‌سازی برای بیان مفهومی کلی است و نه الگویی یکسان برای همه.
شناسایی جریان‌های ارزشی و حوزه‌های بهینه به یک سؤال مهم بستگی دارد: چه نتایج کسب‌وکاری را می‌خواهید بهینه کنید؟ پاسخ به این سؤال نیازمند ورودی‌های متعددی است (مانند جلسات گفت و گو و واردلی مپینگ و ...). یکی از گام‌های مهم، شناسایی محصولات سازمان و تعیین ارزش تجاری و مشتری آنها است. این مرحله برای درک نحوه‌ی تعریف مرزهای دامنه‌ها و تطبیق آنها برای دستیابی به اهداف استراتژیک کسب‌وکار ضروری است.
یک محصول موفق برای مشتریان و برای کسب‌وکار همزمان ارزش ایجاد می‌کند. محصولات باید برای مشتریان جذاب، برای سازمان قابل ساخت و از نظر استراتژیک قابل توجیه باشند. هنگام تعیین نتایج هر محصول، باید این اصول را در نظر داشت. برای مثال، افزایش بهره‌وری و افزایش فروش نمونه‌هایی از ارزش مشتری هستند، در حالی که پول و داده‌ها نمونه‌هایی از ارزش کسب‌وکار به‌شمار می‌روند. برخی از محصولات داخلی خواهند بود که ارزش آنها شامل افزایش بهره‌وری یا کاهش هزینه‌های عملیاتی می‌شود. شناسایی و انتخاب نتایج مناسب با استفاده از «ستاره‌های قطبی» در قسمت‌های قبل توضیح داده شده انجام می‌شود.
محصولات از نظر اندازه و پیچیدگی بسیار متنوع هستند. طبیعی است که کارها کوچک شروع شده و با اضافه شدن ویژگی‌های جدید در طول زمان پیچیده‌تر شوند. برخی از محصولات به اندازه‌ای کوچک هستند که یک تیم می‌تواند مالک چندین محصول باشد، در حالی که برخی دیگر نیازمند ده‌ها تیم هستند. بنابراین، هیچ نسبت یک‌به‌یکی بین محصولات و دامنه‌ها وجود ندارد. یک محصول ممکن است به‌طور کامل توسط جریان‌های ارزشی یک حوزه در سطح دوم پوشش داده شود یا در حوزه‌های متعددی در سطح سوم گسترش یابد. به تصویر زیر دقت کنید.
واژه «محصول» بسیار مبهم است. در انتهای این نوشته یک تعریف پیشنهادی ارائه خواهد شد.
سازمان‌هایی که چندین محصول دارند، اغلب باید استفاده مجدد و مقرون به صرفه بودن در مقیاس بالا را در نظر بگیرند. وقتی چندین محصول از قابلیت‌های مشابه استفاده می‌کنند، پلتفرم‌هایی برای متمرکز کردن این قابلیت‌های مشترک ایجاد می‌شوند.
پلتفرم‌ها همیشه یک چالش ظریف برای ایجاد تعادل هستند. از یک سو، آنها هزینه‌ها را کاهش داده و مقرون به صرفه بودن در مقیاس بالا فراهم می‌کنند، زیرا قابلیت‌ها یک‌بار ساخته شده و چندین‌بار استفاده می‌شوند. از سوی دیگر، پلتفرم‌ها به‌راحتی به گلوگاه‌هایی تبدیل می‌شوند که نمی‌توانند نیازهای تمامی مصرف‌کنندگان را پاسخ دهند یا قابلیت‌ها را به‌شکلی آسان برای مصرف ارائه کنند.
به‌طور کلی، دو نوع پلتفرم وجود دارد (شکل ۶.۶):
حوزه و محدوده‌ی پلتفرم‌ها متنوع است. برخی از آنها مربوط به یک یا چند محصول خاص می‌شود و برخی دیگر کلیه‌ی محصولات سازمان را در بر می‌گیرد. دسته‌ی اول مانند فریم‌ورک های توسعه به زبان و تکنولوژی خاص می‌شود که داخل تیم‌ها توصعه داده می‌شود و برای گروه دوم می‌توان یک Identity Provider در مقیاس سازمانی را نام برد که به همه‌ی تیم‌ها خدمات ارائه می‌کند.
هر دو نوع پلتفرم برای مدرن‌سازی معماری ضروری هستند. در ادامه دو مثال از دنیای واقعی را بررسی خواهیم کرد.
پلتفرم تحقق سفر اوبر، نمونه‌ای برجسته از یک پلتفرم افقی ارزشمند است که از چندین بخش عمودی (محصولات، خدمات، بازارها) را پشتیبانی می‌کند. این پلتفرم، قابلیت‌هایی را فراهم می‌کند که برای تمام بخش‌های عمودی‌ِ اوبر قابل استفاده هستند و باعث کاهش هزینه‌ها، بهبود زمان ارائه به بازار و افزایش حفظ مشتریان و رانندگان می‌شود.
وقتی Uber شروع به گسترش از شرکتی تک محصولی به یک شرکت چند محصولی کرد، نیازی به ایجاد قابلیت‌های کاملاً جدید برای هر خط کسب و کاری جدید نداشت. اوبر بخش مشترک را به صورت یک پلتفرم در مقیاس سازمان ارائه کرد که همه‌ی بخش‌های کسب و کاری می‌توانند مستقیماً از آن برای کاهش هزینه‌ها، بهبود زمان ورود به بازار و افزایش حفظ مشتریان و رانندگان استفاده کنند. پلتفرم Uber دارای سطح بسیار بالایی از قابلیت استفاده مجدد است، که این قابلیت همیشه برای همه پلتفرم‌ها صدق نمی‌کند. دیدن پلتفرم‌هایی که به دلیل درخواست ویژگی‌های منحصر به فرد هر تیمی که از پلتفرم استفاده می‌کند، به گلوگاه‌های سازمانی تبدیل شده‌اند، معمول است. استفاده مجدد همیشه یک شمشیر دولبه است که باید با در نظر گرفتن معیارهای دامنه کسب و کار، شرایط فنی و اجتماعی تیم‌ها به دقت اعمال شود.
سازمان کار و رفاه نروژ (NAV) بزرگ‌ترین سازمان عمومی این کشور است که خدمات متنوعی از جمله بازنشستگی، بیماری درمانی، و بیکاری به ۲.۵ میلیون شهروند ارائه می‌دهد. این سازمان برای بیش از ۱۰۰ تیم داخلی خود، یک پلتفرم فناوری داخلی (IDP) توسعه داده است که شامل زیرپلتفرم‌های مختلفی مانند پلتفرم زیرساخت و پلتفرم داده است.
تجزیه‌ی یک پلت فرم بزرگ به زیرپلتفرم ها یک الگوی رایج در سازمان هایی است که پلتفرم ها به بلوغ و مقیاس خاصی می رسند. این یک گام کلیدی برای جلوگیری از تبدیل شدن پلتفرم‌ها به گلوگاه است، زیرا به تیم‌های جداگانه اجازه می‌دهد تا مسئولیت بخش‌های خاصی از پلتفرم را بر عهده داشته باشند، نه اینکه هر عضو تیم از هر قسمت از پلتفرم مطلع باشد، رویکردی که مقیاس‌پذیر نیست و می‌تواند منجر به فرسودگی کارمندان شود.
نکته‌ی کلیدی از داستان پلتفرم NAV این است که اگرچه پلتفرم بزرگ و ماهیت متفاوتی دارد، اما بر اساس نیاز توسعه داده شده است. این یعنی موضوعات مختلف به طور کامل از قبل مشخص نشده بود که مثلا به عنوان یک پروژه بزرگ سه ساله تحویل داده شوند. این نوع پروژه‌های پلتفرم اغلب خطرناک و ناموفق هستند. یکی دیگر از نکات برجسته در رویکرد پلت فرم NAV این است که آنها با محصولات مرتبط با بخش‌های داخلی خود، با طرز فکری مشابه سایر محصولات رفتار می‌کنند. آنها کارکنان داخلی را به عنوان مشتری در نظر گرفته و سعی می کنند با کاهش بار شناختی، پلتفرم را تا حد امکان جذاب کنند و آنها را آزاد کنند تا کار خود را به طور موثرتر انجام دهند. این یک جنبه حیاتی در ساختن پلتفرم‌هایی است که به آن پلتفرم به عنوان محصول می‌گویند.
برای سازمان‌های بزرگ و بسیار بزرگ با ده‌ها هزار کارمند، پیچیدگی بیشتری در مقیاس بالاتری وجود دارد. در طبقه‌بندی محصول خود، راس کلانتون و همکاران اصطلاحات گروه محصول و پرتفوی محصول را برای این سطوح بالاتر پیشنهاد می‌دهند. گروه محصول مجموعه‌ای از محصولات است که به نتایج مرتبط کمک می‌کنند یا وابستگی‌های تحویلی دارند، و پرتفوی محصول مجموعه‌ای از گروه‌های محصول است که رابطه‌ای بین آنها وجود دارد. گروه پلتفرم و پرتفوی پلتفرم ساختارهای کلان متناظر برای پلتفرم‌ها هستند. در حالی که مدرن‌سازی ممکن است همیشه منجر به تغییرات در سطوح گروه محصول و پرتفوی محصول نشود، داشتن درک واضحی از آنها و اینکه چگونه تصمیمات نوسازی در سطوح پایین‌تر با تصویر بزرگتر هماهنگ می‌شوند، مفید است.
احمتالا Salesforce یک نمونه‌ی خوب از یک سازمان بزرگ با پرتفوی‌های مختلف محصول است. بررسی مربوط به سال 2017 می‌شود. در آن زمان، Salesforce حدود سی هزار کارمند در سطح جهانی داشت، در آن زمان این شرکت به‌طور مداوم از طریق رشد ارگانیک و خریدهای منظم در حال گسترش بود. در نتیجه، Salesforce یک محیط فناوری اطلاعات وسیع و ناهمگن داشت و فرهنگ‌های سازمانی مختلفی در چندین منطقه بین‌المللی در آن وجود داشت. در سطح بالاتر، معماری Salesforce به بیش از ده پرتفوی محصول تقسیم شده بود که به آنها "ابرها" (clouds) گفته می‌شد. نمونه‌هایی از این ابرها شامل Sales Cloud، Service Cloud، Marketing Cloud و Commerce Cloud بودند.
یکی از پرتفوهای محصول که Marketing Cloud نام داشت به‌طور مستقل درآمدی معادل ۹۳۳ میلیون دلار در سال ۲۰۱۷ داشت. این بخش مدیر ارشد فناوری (CTO) و مدیر عامل (CEO) اختصاصی خود را داشت که به ترتیب به CTO و CEO مرکزی گزارش می‌دادند. Marketing Cloud از چندین گروه محصول تشکیل شده بود که اغلب اما نه همیشه به‌عنوان استودیوها (studios) شناخته می‌شدند؛ به‌عنوان مثال، Social Studio، Mobile Studio، Email Studio و Advertising Studio. تصویر زیر را مشاهده کنید.
گروه محصول Advertising Studio شامل سه محصول بود: Advertising Campaigns برای ساخت و اجرای کمپین‌ها در شبکه‌های اجتماعی مانند فیس‌بوک و لینکدین، Advertising Audiences برای ایجاد مخاطبین مشابه بر اساس مشتریان موجود، و Lead Capture برای اتصال سرنخ‌ها از شبکه‌های اجتماعی به حساب Salesforce یک مشتری. هر یک از موارد بالا محصولاتی بودند که مشتریان می‌توانستند به‌صورت جداگانه خریداری کرده و هرکدام کدبیس و تیم‌های خود را برای توسعه داشتند. با این حال، این محصولات به دلایل مختلف به‌عنوان یک گروه محصول معماری شده بودند. از جنبه تجاری، این محصولات به مشتریان مشابهی هدف‌گذاری می‌شدند و شرکت سعی داشت آنها را در قالب قراردادهای B2B بسته بندی و ارائه کند. علاوه بر این، دانش دامنه برای این سه محصول بسیار مشابه بود، بنابراین منطقی بود که افراد درگیر به‌طور نزدیک با یکدیگر همکاری کنند.
هر محصول به‌طور فردی از اجزای نرم‌افزاری متعددی تشکیل شده بود که توسط تیم‌های مختلف مدیریت می‌شد. به‌عنوان مثال، Advertising Campaigns شامل مجموعه‌ای از اجزا بود، از جمله رابط کاربری مشتری، یک اپلیکیشن برای ایجاد کمپین‌ها، یک اپلیکیشن برای اجرای و پیگیری کمپین‌ها، و یک اپلیکیشن برای پیکربندی قوانین کمپین بر اساس محرک‌ها و شرایط.
چندین مفهوم در این بخش معرفی شده‌اند و ممکن است مدتی طول بکشد تا با آنها و نحوه ارتباطشان با یکدیگر آشنا شوید. شکل زیر یک راهنمای سریع است که می‌توانید به‌راحتی به آن مراجعه کنید.
به یاد داشته باشید،این ساختار صرفا یک ابداع است و شما می‌توانید با توجه به نیاز خود ساختار با اجزا و سطوح دلخواه خود را داشته باشید. این مدل سعی ندارد همه سناریوهای ممکن را در نظر بگیرد. به‌عنوان مثال، ممکن است نیاز باشد بلوک‌هایی برای محصولات و قابلیت‌های غیرنرم‌افزاری اضافه کنید.
مدل‌های زیادی برای توصیف مفاهیم معماری و روابط آنها در سطوح مختلف دامنه و با درجات مختلفی از جزئیات وجود دارند. برخی از این مدل‌ها عبارتند از: EDGY از Intersections، مدل Teams, Domains, and Verticals از Evan Bottcher و Architectural Levels of Scope از Ruth Malanو Value Stream Network از BVSSH. این‌ها نمونه‌هایی از مدل‌هایی هستند که می‌توانند برای تحلیل و طراحی معماری در سطوح مختلف به کار روند.
در قسمت بعد در مورد طراحی طبقه بندی محصولات و پیش‌برد اهداف متناسب با این طبقه بندی گفتگو خواهیم کرد.
