Lately, every time I start a post on an interesting SOA paper, Joe gets there first! Not so this time...
During BEAWorld San Francisco, BEA released a practitioner written and reviewed SOA Practitioner's Guide:
"To help develop a shared language and collective body of knowledge about SOA, a group of SOA practitioners created this SOA Practitioners’ Guide series of documents. In it, these SOA experts describe and document best practices and key learnings relating to SOA, to help other companies address the challenges of SOA. The SOA Practitioners’ Guide is envisioned as a multi-part collection of publications that can act as a standard reference encyclopedia for all SOA stakeholders."
The guide has three chapters, each a standalone document: Why SOA?, SOA Reference Architecture, and Introduction to Services Lifecycle.
When I reviewed the guide, pre-publication, I commented back to the authors that I found the Services Lifecycle chapter most interesting, because it focuses on "How" (not "What"), and its obvious the advice came from practitioners, in large environments, with active enterprise architecture practices and a slew of technology and applications.
"Chapter 3: Introduction to Services Lifecycle. It provides a detailed process for services management though the service lifecycle, from inception through to retirement or repurposing of the services. It also contains an appendix that includes organization and governance best practices, templates, comments on key SOA standards, and recommended links for more information."
While you might not agree with all of the answers presented in the SOA Practitioner Guide, the guide is of tremendous value in that it raises many relevant questions. I know from my own experience in leading IT transformation, one of the hardest things to do, is figure out all the things you have to do. And for that reason alone, I recommend taking a look at this guide.
Two comments on the content itself. First, the SOA Reference Architecture is extremely BEA (JEE, Portal, ESB) heavy. But, as Yogish Pai pointed out in a conversation, and in the guide, the Reference Architecture is presented as "an" SOA reference architecture, not "the" SOA reference architecture.
Second, in the "requirements and analysis" phase of the service lifecycle, the guide (correctly) identifies business centric activities, such as business modeling and capturing business motivation, but then lists architects as 'optional' participants in this phase. I disagree. I think architects should take every possible opportunity to interact with "business" folks and a business modeling session is a great place to start.
The more architects can learn about, think about, and converse about their business, the greater the likelihood architecture will be seen (funded) as a business enabler (think innovation), rather than an IT enabler (think TCO containment). Perhaps this falls into the role of the business architect?
Hey Brenda!
One sign that the paper has value is that you can be critical of the "tools" and not the "technique". Any lessons learned are valuable.
Like you I strongly agree that architects (especially Business Architects) should have a strong relationship with business constituents. Done well the Business resources should ask themselves why s/he does not work for them.
The earlier architects get on projects, the better. Perception of value is in the eyes of the beholder. Financially this could be via a strong CBA/ROI because the solution delivers no more code than is required. Software economics must be just as scientific as authoring code. Functionally the solution leaves the end-user with a rich, memorable experience. From a portfolio perspective building enhanced, orthogonal assets is just as critical as reusing existing services and components.
-JT
I am actually stunned by your comment "The more architects can learn about, think about, and converse about their business, the greater the likelihood architecture will be seen (funded) as a business enabler (think innovation), rather than an IT enabler (think TCO containment). Perhaps this falls into the role of the business architect?"
We all know that "business" is intuitively obvious to those lucky enough to have acquired the IT gene, particularly the "architects." The idea that architects would have to interact with mere business folks to get an understanding of the business is outrageous.
JT is onto something. Business Architecture in of itself doesn't create innovation, it does figure out what to do with it though...