The Service-Oriented Analysis Process
|
|
Service-Oriented Design Processes
|
|
|
|
One of the greatest challenges to carrying out successful SOA projects is in understanding how they should be carried out. Without being able to rely on proven processes and practices, an SOA initiative can turn into a high-risk venture because you simply may not know what to expect. A sound methodology can alleviate this risk by providing a solid foundation from where you can shape a delivery approach that accommodates your goals and requirements while also laying out a path to realizing the benefits of SOA and service-oriented computing.
|
by Thomas Erl
|
The concepts, processes, and strategies briefly described on this site are part of a larger SOA methodology developed by SOA Systems based on years of industry research and a great deal of experience with service conceptualization, design, and delivery. Note that all parts of the methodology always have and always will undergo community audits by dozens of IT professionals that participate in the review of published works, including the books in this series. In fact, the content on this site was reviewed by senior members of IBM, Microsoft, Oracle, BEA, Sun, SAP, and HP.

I’ve been reluctant to add to an already over-populated world of acronyms, but we’re getting to a point where it is becoming unavoidable for us to assign an acronym to refer to this body of work. Therefore, we will soon be re-branding some of our documentation with "MSOAM", the "Mainstream SOA Methodology".

This methodology is classified as "mainstream" because it really does just provide a set of generic processes and practices that almost always require further customization when incorporated into enterprise environments. It is therefore best viewed as a starting point. The steps within the processes raise issues and considerations and further propose sequences and priorities, all related to the analysis and design of services. Take from this what you need and add to it anything more that may pertain to your specific requirements.

First and foremost, this methodology is designed to help you address key decision points related to weighing the attainable strategic benefits of SOA via top-down strategies against the tactical preferences of bottom-up approaches. As illustrated in the diagram on the Top Down vs. Bottom Up page, cutting short the needed up-front analysis will tend to shift the burden to subsequent governance stages. This is an important message that you should fully comprehend before deciding on how your project will proceed.

The primary reason this site is here is to support readers of the Prentice Hall Service-Oriented Computing Series from Thomas Erl. Because this a mainstream and vendor-agnostic methodology it is partially documented in some of the series titles and referenced in others. I periodically make revisions and refinements to parts of the methodology, and having a central place to publish this will allow readers to always check for the latest changes.

The initial content of this site was originally published in an appendix in SOA: Principles of Service Design primarily for reference purposes. While you may notice the repeated footers indicating that you are reading excerpts from this book, please note that this is not a book about SOA methodology. The service-oriented analysis, service modeling, and service-oriented design processes mentioned throughout this site are actually documented in detail within Chapters 10 to 16 of Service-Oriented Architecture: Concepts, Technology, and Design.

Note that if you’d like to be notified of changes to this site, the launch of the new sites, and other events related to this book series and the associated SOA Magazine, send a blank e-mail to: notify@soasystems.com
|
|
|
|
|