Solution Architect Anti-patterns

16 Solution Architect Anti-patterns

by John Spacey

A few common anti-patterns that every solution architect should know.

1. Re-inventing the wheel - Needlessly engineering a proprietary solution to a problem that already has a standard solution.

Example: Building your own web server.

2. Technology Proliferation - Needlessly increasing the complexity of the technology stack.

Example:The organization uses three web server products and you introduce another.

3.Over Engineering - Building complex functionality when a simple solution would suffice.

Example: Introducing a complex workflow product to handle simple approvals.

4. Under Engineering - When the architecture can not support the business requirements.

Example: A solution that can not support business volumes (performance requirements).

5. Stubborn Silo - Refusing to use common solutions without a good reason.

Example: Building point to point integrations instead of using the enterprise ESB.

6. Bleeding Edge - Using the latest hype technology before all the bugs have been worked out.

Example: Expensive hardware that is marginally faster than slightly older models.

7. Silver Bullet - When architects use a single technology for all projects.

Example: Using SOA for everything — even when there is zero chance of service reuse.

8. Ivory Tower - A highbrow or ascetically pleasing design that is not practical.

Example: Spending excessive time designing a elaborate solution to a simple problem.

9. Garden in the Desert - Building a solution on the wrong platform.

Example: Building a complex business application with office productivity software.

10. Vendor Lock-in - Building too much functionality on a proprietary platform.

Example: Using one large vendor for all your systems.

11. Gold Plating - Adding bells and whistles to a system that don't add value.

Example: Optimizing a mobile website for devices that few of your customers own.

12. Politics Oriented Architecture - Allowing office politics to interfere with design decisions.

Example: The CRM has the data you need but your boss has a bad relationship with the CRM team — so you get the data from some downstream system that has stale data.

13. Path Of Least Resistance - A lazy architecture that fails to plan for change — choosing the cheapest implementation.

Example: Choosing point to point integration over ESB because it is easier.

14. Over the Head - Ignoring requirements that the architect fails to understand — assuming they have no impact.

Example: Business requirements specify compliance with a set of regulations — architects ignore the requirement because they don't understand it.

15.Perception Mismanagement - When the solution architect makes promises and then can't deliver.

Example: Promising real time calculations that are almost impossible to calculate in real time.

16. Pattern Happy - Overuse of patterns.

Example: Designs that have factories that do nothing.

Proof of Concept - PoC

 

فردا 15 نفر مهمان دارید و می خواهید برای آنها غذایی را آماده کنید که برای اولین بار می خواهید پخت آن را تجربه کنید. فرض کنید خورش فسنجان

مواد اولیه خورش شامل مقدار زیادی گردو، رب انار، مرغ، برنج و دیگر مواد لازم را تهیه کرده اید و دستور پخت را هم در اختیار دارید. حال چه می کنید؟

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

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

هر چند این رویکرد زمان بیشتری طلب می کند اما ریسک پخت غذای اصلی به میزان قابل توجهی کمتر بوده و نتیجه نهایی بسیار قابل پیش بینی تر و نزدیکتر به آنچه مطلوب است خواهد بود.

معماری سرویس گرا (بخش هفتم) – دسته بندی سرویس ها

هنگام تولید یک سرویس، موارد زیر با توجه به کاربرد این سرویس مورد توجه قرار می گیرد:

- نوع خدمتی که که سرویس ارایه می دهد (Type of Logic)

- میزان قابلیت استفاده مجدد از آن سرویس (Reusability)

- سرویس در چه حوزه و دامنه ای (Domain) از سازمان دسته بندی می شود

 

با توجه به موارد بیان شده، سرویس ها را می توان به سه دسته زیر تقسیم بندی کرد:

- Entity Services

- Task Services

- Utility Services

 

در نتیجه این دسته بندی، لایه های زیر ایجاد می گردد:

 

Entity Services:

در هر سازمان با توجه به حوزه خدمات و نوع تجارت آن، موجودیتهای مختلفی وجود دارند. به عنوان مثال، تقریبا در همه سازمانهای موجودیت "پرسنل" (Employee) وجود دارد. سرویس هایی که بر اساس موجودیتهای (Entities) مورد نیاز سازمان ایجاد می شوند در دسته بندی Entity Services قرار می گیرند. این دسته از سرویس ها دارای قابلیت استفاده مجدد (Reusability) بالایی هستند چرا که وابسته به یک وظیفه (Task) یا پروسه خاص سازمانی نبوده و مستفل از عملیات سازمانی با حیات خود ادامه می دهند.

Task Services:

سرویسی که عملکرد آن به طور مستفیم با کار یا وظیفه ای (Task) در سازمان مرتبط باشد در این دسته بندی قرار می گیرد. مثلا سرویس "تولید گزارشات مالی" در این دسته بندی قرار می گیرد. با توجه به ماهیت این نوع از سرویس ها، قابلیت استفاده مجدد این سرویس ها کم است.

Utility Services:

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

 Service Abstraction Layers

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

 

Short Description

Example

Best Practices / Characteristics

Task Service

A business service directly associated with a specific parent business task or process.

- AnalyzeRevenue

- GenerateReport

- HandleOrder

- Naming convention: [verb][noun]

- Low reusability

- Business Centric

- aka: “Task-centric Business Services” or “Business Process Services”

Entity Service

A business centric service based on one or more business entities.

- Employee

- Invoice

- Customer

- Naming convention: [noun]

- Highly reusable

- Business Centric

- aka: “Entity-centric Business Services” or “Business Entity Services”

Utility Service

Cross-cutting, non-business centric service providing utility functionality

- Logging

-Exception Handling

- Highly reusable

- Non-Business Centric

- aka: “Application Services”, “Infrastructure Services” or “Technology Services

 

 توجه شود که با توجه به تصمیم معماران محیط سرویس گرایی سازمان، می توان دسته بندی ها (لایه ها) ی دیگری نیز تعریف کرد. اما به نظر می رسد که سه دسته بندی بالا، تقریبا برای هر سازمانی قابل گسترش است.

 

دسته بندی سرویس ها در شرکت کالایاب

پس از تحلیل نیازمندیهای شرکت و برگزاری چندین جلسه با حضور معمار سازمانی (Enterprise Architect)، معمار راه حلها (Solutions Architect)، معمار اطلاعات سازمانی (Information Architect) و همچنین چند نماینده از بخش های مختلف سازمان (Subject Matter Experts)، تصمیم گیری شد که لایه های زیر برای دسته بندی سرویس ها در شرکت کالایاب مورد استفاده قرار گیرد:

- Task Service Layer

- Entity Service Layer

- Utility Service Layer

- External Partners Service Layer

دسته بندی چهارم (External Partners Service Layer) به این منظور پیشنهاد شده است که شرکت کالایاب از بسیاری از خدمات دهندگان خارج از سازمان برای پیشبرد اهداف سازمانی خود استفاده خواهد کرد. به عنوان مثال، هنگامی که درخواست مشتری برای استعلام قیمت در مورد نوع خاصی شکلات به شرکت می رسد، شرکت باید از تامین کنندگان شکلات استعلام قیمت کرده و پایین ترین قیمت را به مشتری پیشنهاد دهد (برای اطلاعات بیشتر در مورد شرکت تخیلی کالایاب به اینجا مراجعه کنید).

به این منظور، شرکت کالایاب برای اتصال به Web Service های تامین کنندگان، سرویسی خاص طراحی و اجرا خواهد کرد که وظیفه آن صدا زدن (Service Call-out) سرویس های خارجی است. هرچند می توان این سرویس را در دسته بندی Task Services قرار داد، تیم تصمیم گیرنده برای شفافیت بیشتر و جداسازی بهتر لایه ها از نظر کاربرد، تصمیم بر ایجاد لایه چهارم External Partners Service Layer گرفت.

جدول زیر نمونه ای از دسته بندی ها و سرویس های موجود در هر دسته بندی را در شرکت کالایاب نمایش می دهد:

Service Layer

Service Name

Service Description

Task Service Layer

ManageOrder

This service handles orders from the point it is made by customer, up to the point the order is fulfilled.

GenerateFiscalReport

Responsible to generate financial reports

...

...

Entity Service Layer

Supplier

External Supplier

Employee

Company’s internal employee

Product

A particular product (e.g. X Chocolate, Y Flower, etc.)

Order

An order made by a customer

Customer

A customer making an order

...

...

Utility Service Layer

Exception Handling

Service handling exceptions

Logging

Service responsible for logging different activities

Notification

Responsible for notifying users (e.g. when an order cannot be fulfilled successfully, a notification email is sent to sales team to manually handle the situation

...

...

External Partners Service Layer

GetQuote

Send quote request to external suppliers and get the result

SendShipmentRequest

Send shipment request to successful supplier to send the product to the customer

...

...

 

<بخش قبل   بخش بعد>

 

Certified SOA Architect

سرانجام پس از گذراندن ۵ امتحان و صرف حدود یک سال٬ مدرک "معمار سرویس گرا" دریافت گردید!

SOA Certified Architect   SOA Certified Professional

برای اطلاعات بیشتر به اینجا مراجعه کنید.

معماری سرویس گرا (بخش ششم) – بزودی در این مکان کله پزی "اصغر کله پز" افتتاح خواهد شد!

در معماری سرویس گرا، هر سرویس از دو قسمت کلی تشکیل می شود: Contract و Logic

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

به پارچه نوشته سر در این مغازه توجه کنید:

به زودی در این مکان کله پزی "اصغر کله پز" افتتاح خواهد شد.

ساعت کار: همه روزه 5 صبح تا 11 صبح (به استثنای جمعه ها) – جمعه ها از 6 صبح تا 1 عصر

کله پاچه همه روزه – جمعه ها حلیم با گوشت بوقلمون

با ظرفیت پذیرایی از 50 نفر

 

اصغر آقا در این پارچه نوشته در واقع Contract First Design را رعایت کرده است!

کله پزی مزبور هنوز افتتاح نشده است (شاید حتی وسایل آن هم تهیه نشده باشد)، اما با دیدن این نوشته بسیاری از حقایق برای ما مشخص می شود:

هدف افتتاح مغازه (کله پزی)،  زمان فعالیت، غذای ارائه شده و حداکثر ظرفیت پذیرایی مشتری

 

Contract First Design در فرآیند حرکت سازمان به سوی سرویس گرایی و حتی پس از آن، هنگام ایجاد سرویس جدید برای سازمان یک رویکرد توصیه شده (Best Practice) است. به این شکل که پیش از ایجاد هر سرویس (یا مجموعه ای از سرویس ها)، ابتدا ساختار، قابلیت ها، داده های ورودی-خروجی و کیفیت آن سرویس در قالب Service Contract ارایه می شود.

Contract ایجاد شده برای یک سرویس به دو بخش Technical Contract (یا بخش قابل پروسس توسط کامپیوتر) و Non-Technical Contract (یا بخش قابل فهم برای انسان – Human Readable Contract) تقسیم می شود.

بخش اول با توجه به تکنولوژی انتخاب شده می تواند قالبهای مختلف داشته باشد (مثلا در صورتی که تکنولوژی مورد استفاده، Web Service باشد عموما فایلهای WSDL و XSD).

بخش دوم معمولا در قالب SLA – Service Level Agreement ارایه می شود که می تواند به شکل ساده، یک فایل متنی به زبان فارسی یا انگلیسی نگاشته شود. در این بخش معمولا کیفت سرویس مانند کارایی (Performance)، حداکثر تعدا کاربر، بار ترافیک پیشبینی شده، زمان قطع سرویس به منظور پشتیبانی و .. مورد توجه قرار می گیرد.

 

نکته قابل توجه اینجاست که استفاده کنندگان از سرویس (Service Consumers) می توانند تنها با در دست داشتن Service Contract برنامه خود را توسعه دهند، بدون نیاز به اینکه حتی پیاده سازی سرویس مورد نظر آغاز شده باشد.

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

 

<بخش قبل  بخش بعد>

معماری سرویس گرا (بخش پنجم) – تاثیر سرویس گرایی بر سازمان

۱. سرویس گرایی و مفهوم "برنامه کاربردی" (Application):

در دنیای غیر سرویس گرایی، سازمانها دارای تعدادی برنامه کاربردی (Applications) هستند. به عنوان مثال سیستم مدیریت مشتری (CRM) سازمان، سیستم حقوق و دستمزد و وب سایت سازمان به عنوان برنامه های کاربردی مستقل از یکدیگر (و یا در بهترین حالت تحت یک سیستم بزرگ ERP) وجود دارند.

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

در سازمانهای سرویس گرا اما، این مفهوم به طور کلی دستخوش تغییر می شود. کلیه قابلیت های لازم (Capabilities) به شکل سرویس های قابل استفاده مجدد و مستقل از یکدیگر ایجاد و نصب می گردد (که در پستهای آینده شرح داده خواهد شد که حوزه یا Scope این سرویس ها می تواند بخشی از سازمان یا کل سازمان باشد که در حالت اول تشکل Domain Inventory و در حالت دوم تشکیل Enterprise Inventory را می دهد).

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

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

 

۲. سرویس گرایی و مفهوم "یکپارچه سازی" (Integration):

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

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

The effect of SOA on the Enterprise

همانگونه که در بند پیشین بیان شد، سازمان سرویس گرا در حالت ایده آل، دارای Inventoryی مشتمل بر کلیه سرویس های سیستم مدیریت اطلاعات پرسنل داخلی و همچنین پیمانکاران است. در این شرایط، برای برآورده ساختن نیازمندی جدید (ایجاد گزارشی از هر دو سیستم)، تنها کار لازم ایجاد ترکیبی (Composition) از سرویس های موجود است. سرویس هایی که از پیش با فرض "قابلیت استفاده مجدد" (Reusability) طراحی شده اند و به دلیل رعایت استانداردهای تعریف شده، تا حد زیادی همگن بوده و به راحتی با یکدیگر ترکیب می شوند.

به این منظور، هنگامی که سرویسی در سازمان طراحی می شود، یکی از ویژگیهای ذاتی آن قابلیت استفاده مجدد خواهد بود، بدون اینکه نیازمندیهای احتمالی آینده لحاظ گردد.

SOA Effect on the Enterprise

 

در پست های آتی، استاندارد سازی سرویس ها (Service Standardisation) و حتی مدل های داده ای سازمان (Data Schema) مورد توجه قرار خواهد گرفت.

<بخش قبل  بخش بعد>

معماری سرویس گرا (بخش چهارم) – مزایای سرویس گرایی (ادامه)

(ادامه از پست پیشین)

 4. هم راستایی کسب و کار و فناوری (Increased Business and Technology Domain Alignment):

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

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

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

Silo Based Architecture

طراحی سرویس گرا به دلیل مجهز بودن به مفهوم Abstraction در لایه های مختلف این کمبود را کمینه می سازد. یکی از مهترین راههایی که معماری سرویس گرا برای هم راستایی و انعطاف بیشتر در مقابل تغییر در اختیار طراحان قرار می دهد وجود لایه هایی حاوی سرویس های با کاربردهای تجاری مستقل است.

در نتیجه در صورت تغییر صورت مساله تجاری، در بسیاری از اوقات می توان با تغییر پیکر بندی (Configuration) و ترکیب بندی (Combination) سرویس ها به صورت مساله جدید دست پیدا کرد (شکل زیر را ببینید).

Service Oriented Architecture

ارزش برای شرکت کالایاب:

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

5. افزایش بازگشت سرمایه (Increased Return on Investment):

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

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

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

ارزش برای شرکت کالایاب:

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

 

6. افزایش چابکی سازمان (Increased Organizational Agility)

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

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

ارزش برای شرکت کالایاب:

واضح است که این ویژگی برای شرکت کالایاب - مانند هر سازمان دیگری – مزیت بزرگی محسوب می شود.

 

7. کاهش حجم کاری و هزینه های فناوری اطلاعات سازمان (Reduced IT Burden)

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

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

ارزش برای شرکت کالایاب:

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

 

<بخش قبل  بخش بعد>

معماری سرویس گرا (بخش سوم) – مزایای سرویس گرایی

در این نوشتار شرکت تخیلی کالایاب به عنوان نمونه (Case Study) مورد اشاره قرار می گیرد.

 

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

شرکت مزبور پس از جلسات متعدد با مدیران شرکت تازه تاسیس کالایاب، گزارش پیشنهادی خود را ارایه می کند. در این گزارش، معماری پیشنهاد شده برای شرکت کالایاب، معماری سرویس گرا (SOA) انتخاب شده است.

مدیران شرکت کالایاب گزارشی تکمیلی در مورد علل انتخاب این معماری به عنوان معماری مرجع (Reference Architecture) درخواست می کنند. در گزارش دوم، علل انتخاب این معماری به این شرح بیان می شود:

۱. افزایش قابلیت تعامل ذاتی سیستم ها (Increased Intrinsic Interoperability):

هرچه سیستم ها بیشتر دارای قابلیت تعامل باشند، بهتر قادر خواهند بود که اطلاعات را بین خود جابجا کنند. برنامه های مختلف نرم افزاری که قابلیت تعامل (Interoperability) نداشته باشند، دیر یا زود به یکپارچه سازی (Integration) نیاز پیدا خواهند کرد. به عبارت دیگر، قابلیت تعامل ذاتی که در نتیجه اتخاذ سرویس گرایی برای سازمان است، نیاز سازمان را نسبت به یکپارچه سازی کمینه می سازد.

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

ارزش برای شرکت کالایاب:

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

۲. امکان انتخاب وسیع تر میان تولیدکنندگان نرم افزار (Increased Vendor Diversification Options):

این قابلیت به سازمانهایی که سرویس گرایی را به عنوان گزینه مورد نظر خود انتخاب کرده اند این امکان را می دهد که میان تولید کنندگان متعدد نرم افزارهای توسعه، قدرت انتخاب داشته باشند و حتی قادر باشند که همزمان از بیش از یک تولید کننده بهره گیرند. به عنوان مثال، سازمان قادر خواهد بود که برای توسعه همزمان از نرم افزارهای توسعه یافته توسط Microsoft، Sun Micro Systems و Oracle استفاده کند.

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

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

شکل های زیر را ببینید:

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

Silo Based Organization

در شکل زیر سازمانی دیده می شود که از معماری سرویس گرا بهره می برد. به دلایل گفته شده تغییر در تکنولوژی چالش کمتری به همراه خواهد داشت.

Service Oriented Organization

 

ارزش برای شرکت کالایاب:

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

۳. افزایش یکدستی (Increased Federation):

Federation به معنی ارایه منابع در قالبی یک دست و متحد در عین حفظ استقلال و خود گردانی آنهاست. به بیان دیگر، یک موجودیت در سیستم مانند مشتری همیشه به یک شکل و قالب و از طریق یک مرجع (Reference) قابل دسترسی خواهد بود.

استاندارد سازی یکی از مهمترین ویژگیهایی است که معماری سازمان را به سمت Federation پیش می برد.

ارزش برای شرکت کالایاب: با توجه به اینکه موجودیتهای مختلفی برای سیستمهای شرکت کالایاب در حال و آینده متصور است و نظر به اینکه نیاز است که این موجودیتها نه در یک سیستم، بلکه در سیستم های مختلف شرکت مورد استفاده قرار گیرد (Reuse شود)، افزایش Federation کمک به سزایی در رسیدن سازمان به یک دستی می کند. به عنوان مثال، موجودیت مشتری در سیستم تحت وب، سیستم مدیریت مشتری (CRM) و همچنین در سیستم مدیریت صورتحساب ها (Invoicing) وجود خواهد داشت و وجود یکدستی در استفاده از این موجودیت در سیستمهای مختلف بسیار سودمند خواهد بود.

(ادامه در پست بعدی)

پی نوشت: به منظور تکمیل این نوشتار و همچنین اطمینان از صحت مطلب، سوالی را از طریق Emailبرای Thomas Erl ارسال کردم که پاسخ آن را در زیر می خوانید (Thomas Erl موسس SOA School و SOA Systems Inc است. شاید بتوان وی را فعالترین محقق و نویسنده در زمینه Service Orientation دانست).

پرسش:

Interoperability و Federation هر دو از مزایایی به کار گیری سرویس گرایی است. با توجه به اینکه این دو ویژگی شباهتهایی با یکدیگر دارند، تفاوت آنها چیست؟

پاسخ:

Increased Federation is primarily about establishing a federated endpoint layer. Increased Interoperability is primarily about establishing inherent compatibility among services. Each goal supports and relies on the other, but each goal also represents a distinct part of the target state we look to achieve when adopting service-orientation.

 

<بخش قبل  بخش بعد>

معماری سرویس گرا (بخش دوم) – سرویس چیست؟

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


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


سرویس مجموعه ای است از قابلیت ها (Capabilities)
به یاد داشته باشید که یک سرویس دارای مجموعه ای از قابلیت ها است. این قابلیت ها به نوعی مرتبط با زمینه (Context) سرویس مورد نظر هستند. در مثال زیر سرویس ارایه شده توسط شرکت هواپیمایی شامل فروش بلیت، جابجایی مسافر، استخدام و غیره است. همین طور قابلیتهای ارایه شده توسط یک پزشک شامل معاینه، ارایه نسخه و .. است.

همانگونه که در مثال بالا دیده می شود، کلیه قابلیتهای ارایه شده، به شکلی مرتبط با سرویس مورد ارایه هستند.


برای تعریف دقیق سرویس اینجا را کلیک کنید.

References:
1. SOA - Principles of Service Design, Thomas Erl, Prentice Hall, 2008
2.
http://www.soaglossary.com/

 <بخش قبل   بخش بعد>

معماری سرویس گرا (بخش اول) – شرکت کالایاب

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

 پس از چندین روز گفتگو هر سه تصمیم به تاسیس یک شرکت خدماتی با شرح وظایف زیر می گیرند:

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

از میان پیشنهادات مختلف برای نام شرکت، "کالایاب" مورد تایید هر سه نفر قرار می گیرد.

برای شروع، تصمیم بر این گرفته می شود که کالاهای مورد نظر محدود به گل، کیک، شیرینی و شکلات و کارت تبریک باشد.

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

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

 

داستان تخیلی بیان شده، در قالب مثالهای کمکی در سری نوشتارهای پیرامون معماری سرویس گرا استفاده خواهد شد.

 

توجه: نمونه ارایه شده به طور کامل زاییده ذهن نویسنده بوده و هر گونه تشابه نام یا موضوع در این نوشتار و دیگر نوشتارهای مربوط به این مجموعه با نامها و نمونه های واقعی کاملا تصادفی است.

<بخش قبل   بخش بعد>

پیرامون معماری سرویس گرا (Service Oriented Architecture - SOA) - مقدمه

چندی است به دلیل ماهیت پروژه ای که به آن مشغول هستم و همچنین دریافت مدارک SOA Certification با این گونه از معماری (که البته به نظرم چیزی بیش از معماری است و بیشتر به یک روش تفکر می ماند) اصطکاک زیادی دارم.

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

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

لازم به ذکر است که مطالب نگارش شده دارای مشخصات زیر خواهد بود:

۱. مستقل از برند و تکنولوژی (Vendor & Technology Neutral): به این معنی که مبنای مطالب نگارش شده هیچ گونه وابستگی به برند یا فناوری خاصی ندارد. هرگونه مثال احتمالی بر مبنای تکنولوژی ها یا برندهای تجاری صرفا جهت درک بهتر مطلب خواهد بود.

۲. تکنولوژیها، زبانها و استاندارهای غیر تجاری مانند XML / WSDL / XSL و مانند آن که به عنوان استاندارهای شناخته شده غیر تجاری برای پیاده سازی سیستمهای سرویس گرا متداول هستند در جای خود شرح داده شده و استفاده خواهد شد.

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

۴. روش نگارش مطالب به صورت بالا به پایین (Top Down) خواهد بود. به این مفهوم که ابتدا کلیات مطلب و نگاه عام بر نگارش متن حاکم بوده و سپس - بسته به نیاز - مطالب به شکل جزیی تر ارایه می گردد.

۵. مطالب ارایه شده نیم نگاهی نیز به متدولوژیهای مرتبط خواهد داشت.

پیشاپیش از خوانندگان تقاضا دارم پیش، در خلال یا پس از اتمام این مجموعه در صورتی که نظری تکمیلی یا تجربه ای شخصی دارید و یا قسمتی از نوشته ها را مغایر با روشهای درست (Best Practice) نرم افزار می بینید آنرا به صورت عمومی یا خصوصی در وبلاگ ارسال نمایید. در صورت مرتبط بودن با موضوع و با تایید فرستنده، آنرا به عنوان نظرات تکمیلی در وبلاگ منتشر خواهم کرد.

بخش بعد>