می توان از مستندات معماری مرجع بصورت آنلاین برای آموزش دیگران استفاده کرد . با استفاده از یک وب سرویس درون سازمانی ،wiki یا پورتالی که قسمتی ورودی را در blueprint معماری قرار می دهد.
یک معماری مرجع مجموعه ای از الگوهای معماری از پیش تعریف شده است. در حالیکه برای استفاده در بافت تکنیکی و تجاری مشخصی طراحی شده اند، همه با مستندات پشتیبانی که استفاده اشان را عملی می کنند. این مستندات می توانند از مستندات معماری، استانداردها و قواعد وضع شده بوجود آیند. درحالیکه برای SOA بدرستی اتصال دادن آنها مفید خواهد بود.
معماری مرجع در پروژه های یک یا چند گانه بعنوان یک Blueprint بکار گرفته خواهد شد. بدین ترتیب معماران و برنامه نویسان می توانند ناظر به اجرای رویدادها باشند که آیا آن رویداد با راهنماهای ایجاد هماهنگ می باشد و ما را به اهداف تجاری نزدیک تر می سازد یا نه؟
اهداف معماری مرجع
معماری مرجع به طرق زیر میتواند به شما اطمینان دهد که تلاش های معماری موفقیت آمیز بوده است:
عمل کردن بعنوان محصول نهایی معماری (blueprint)
معماری مرجع میتواند چارچوب زیرساختIT ، کدها و مدل ها را در برگیرد. به این دلیل که این کدها و مدل های متفاوت، با تیم های متفاوتی ایجاد شده اند ممکن است در انزوا عمل کنند که برای سازمان مشکل زا خواهد بود.
Blueprint به معماری این امکان را می دهد که با نگاهی کلان تر به SOA بنگرد ، و این نگاه کلی برای اطمینان یافتن از مراحل کیفیت سرویس مورد نیاز است.

معماری مرجع SOA باید به دیگر مستندات معماری سازمان های موجود بپیوندد، مثل شبکه و IT سخت افزاری ، و لایه های سرویس را به این ایده اضافه کند.
برای مثال اگر معماری مرجع SOA با ORACLE/BEA تعریف شود شامل لایه های زیر است:
سرویس های اتصال و سرویس های داده : امکان دسترسی انعطاف پذیر به سایر داده های اصلی و برنامه های کاربردی سازمان.
سرویس های مبتنی بر کسب و کار: لایه ای منطقی در بالای لایه سرویس های داده که در آن فرایندهای کسب و کار اداره می شوند.
سرویس های نمایش : بسته ی سرویس های توانمند در کسب و کار ، قابل استفاده برای کانال های مختلف.
وقتی ORACLE/BEA تعریف نشود (که در این صورت ممکن است سرویس های اتصال یا نمایش حذف شوند ویا حتی یک لایه جدید اضافه شود) ،بهتر است در همین مرحله به درک سرویس بپردازید نه در مرحله موجودیت ،فرایند یا کارکرد.

• ایجاد نمونه های موفق

توسط RA، سرویس ها و client ها با پیروی از راهنما های معینی ساخته شده و بکارمی روند. مثلاً شاید روش های قابل قبولی برای ساخت سرویس ،انتقال پیام،رمز گذاری و ... مورد نظر باشد.
با اعلان کردن راهنما ها ،استانداردها و قراردادها ، معماری مرجع در مدت اجرا ،به همه و در همه جای سازمان اطمینان می دهد که کار بدرستی در حال انجام است. بدین ترتیب کار برنامه نویسان ومعماران ساده تر خواهد شد و زمانی که همه برای اجرای سرویس بطرق تعیین شده پیش روند زمان عرضه به بازار سرعت می گیرد.
معماری مرجع باید چگونگی حل مشکلات دوجانبه مثل موتور های قوانین (Rules Engins) و امنیت را بیان کند (که گاهی حتی خود این موتورها بعنوان سرویس اجرا می شوند).
Clarify trade-offs (سبک سنگین کردن)
نمی توان هر کاری انجام داد زیرا نیازمندی های معین همیشه در تقابل یکدیگر ظاهر می شوند. همان طورکه کارایی بالا همراه با امنیت بالا بصورت منازعه ای همیشگی باقی مانده است.

• امکان پذیر کردن حاکمیت

حاکمیت SOA شدیداً به ساخت معماری مرجع وابسته است. معماری مرجع به عنوان اساس قسمت های SOA COE یا Governance board to follow بکار می رود.
محل معماری مرجع
معماری مرجع SOA می تواند قابل انتقال و مجموعه ای از منابع (که می توانند برای اهداف مختلف استفاده شوند) باشد و نه صرفاً مستنداتی که با کدها همرا شده اند.و زمانی یک سرویس قابل حمل بدرستی کار خواهد کردکه با وب سرویسی اجرا شود که براحتی بروز رسانی می شود(مثل wiki). اعضای تیم معماری سرویس گرا ،هیئت حاکمیت یا معمارانی که در سازمانی مشغول هستند ، مسئول ساخت سایتی برای آموزش و اطلاع رسانی، شامل مدل های معماری ،استانداردها ، منابع و مستندات قراردادها هستند.