A report on the SOA process by Paul Allen and Paul C. Brown has been published in the CBDI Journal for November 2007. This is a sequel to an earlier report by Paul Allen from February 2007. PDF copies are available for download (for a limited time only).
- Architected Solution Delivery: Enhancing the Service Oriented Process (PDF: November 2007)
- The Service Oriented Process (PDF: February 2007)
These reports are also available on the CBDI Forum website.
- Architected Solution Delivery: Enhancing the Service Oriented Process (November 2007, available to all )
- The Service Oriented Process (February 2007, available to all)
Paul Brown is the author of Succeeding with SOA and SOA in Practice. Paul Allen's most recent book is Service Orientation: Winning Strategies and Best Practices. For details of all their books, please visit the SOA Process bookstore.
Posts
2 comments:
I probably have to read 2 or 3 more times -- but I like to drop some early comments. Getting this part of the process right is imho one of the key area for SOA success. The other one getting hold on a proper baseline for decomposing a problem domain (like an enterprise) into services that ensure enduring agility.
I would suggest spending some time on first explaing the essential mental model, principles if you like, underpinning all this work. Although I believe I am pretty much an insider on the subject, I found it pretty hard to read/digest.
It seems to be very much project oriented.
1) I believe effective SOA essentially starts with a business-2-business collaboration (if it is clear that this collaboration is not clear -- don't start an IT project yet). It seems this required collaboration is being addressed in the middle of the second column on p-8 -- but only as part of a 'refinement' step. For me it should be the starting point. With b2b I either mean domain-, process- or 'object/entity' boundaries. (the other essential key area for success)
2) The SOA demand-supply model should imho be executed over the top of multiple projects. You are very right that it is a constant refinement based on learning and constraints found along the way.
3) The model doesn't seem to cater for the fact that might be multiple solutions might request for the same service. Having more than one use case in vision greatly enhances the chance to find good, reusable, stable services.
4) In real life budget-level governance is very importance as well. Getting a service provider (owner/LOB responsible) to invest for (initially) the benefit of others is usually not something that can be arranged for in the scope of a project. This should be done (prepared for) in business(case) planning and indeed a service portfolio process that spans indifvidual projects.
Not the essence of this article, but the notion of architecture is being used very incosistent.
On the provide side the notion of service versioning (and deprecation) could receive more attention. It is a provisioning responsability to decide if a new service should be provide as the result of a specific demand or that an existing service need to be extended (ensure compatability existing consumers) and whether/when a specific service should be taken out of production (including the separate responsability of a consumer to switch over to a newer version).
Separate consumer from provider as an architecture principle seems to be well adhered to for the consume and provide processes. In the enable process this distincition seem to be blurred however. In my experience this quickly leads to the Enterprise Spaghetti Box.
In real life budget-level governance is very important as well.
Small point. In figure-3 security is being mentioned as a provide item only. I believe this is/should be equally true for the consume side of the equation.
Nevertheless -- keep on the good work!
On Basic Principles: While we did think about =providing introductory coverage, we felt we had trod that ground pretty well before in the cited references to previous material and didn’t want readers to feel we were just repeating things they already knew. However on reflection I think this is a fair point, so we have added appropriate information and links on this site.
On Decomposition/Composition: These are techniques that are important in both consume and provide tracks. However, like all techniques, they have their limitations (“If your only tool is a hammer, the whole world looks like a nail). The SAE process defines techniques as first class citizens that can be usable in different tasks and disciplines.
On Project Orientation: This is correct in so far as the Total Architecture approach (overlaid here on to the SAE process) is pretty much project oriented, though I would say oriented toward “large projects”. Of course you have to (ideally at least) start things off in the right business context, which is what SO Business Requirements Planning is all about. However this article focuses very much on the Architected Solution Process, without going into – albeit important – surrounding areas. In addition, we have covered the relationship between enterprise and project processes at a high level (in my February journal article on SO Process) and also between program and project management (in the Sept and Oct journals on SOA Project Management). Finally, a lot depends on how large the project scope is, and in this particular context we are talking large enough to cross different business processes (for example a breadth first inventory across business processes is conducted as part of the Solution Architecture and Design work). I’m sure Paul Brown could expand, but it is important to realize that Synthesize Solution Architecture “begins with an initial breadth-first inventory of all the business processes that appear to be impacted by the project. This inventory is based on the business goals set forth in the project charter (an output from SO Business Requirements Planning)” and to note the section “Assessing the Wider View”.
Post a Comment