In the June 2008 editorial for the CBDI Journal, David Sprott talks about learning from other architectural disciplines - from the open plan building style and organic architecture principles pioneered by Frank Lloyd Wright to the incredibly innovative design of the Sydney Opera House.

David's editorial focuses on architectural style and patterns, but we can also learn lessons about process, and about the relationship between architecture and engineering. The Sydney Opera House is an amazing building, but its development was costly and troubled, and the relationship between the architect (Jørn Utzon, who had worked for Frank Lloyd Wright) and the engineering firm (Ove Arup) was a difficult one.

With SOA, we are not just interested in producing innovative structures (loosely coupled enterprise, layered service architecture, and so on) but producing these structures in an agile and cost-effective way. Architecture is not a stand-alone activity, but must be integrated into the engineering process. That's why we call the CBDI process Service Architecture AND Engineering.

At CBDI we have always advocated that governance needs to be rooted in clear policy definition and in fact devoted an article to this. Since that time we have been busy assisting organizations improve SOA governance approaches based on an underlying foundation of clear policy definition. One thing that has emerged vividly from this work is that organizations must move forward at their own pace and in a way that is realistic in terms of their current SOA adoption level.

Moreover the approach taken to SOA governance must be in tune with the overall governance requirements and political climate. We have therefore distilled these experiences into an SOA Governance Framework - embracing policy, process, infrastructure and capability maturity - that can be tailored to each organization's specific needs.

The basics of the CBDI SOA Governance Framework are now publicly available without requiring registration

An overview of the process of creating a SOA Governance Framework is presented in this slide show

In my time in the IT industry - longer than I care to admit - I have generally worked at the leading edge of new software technology - including relational databases, fourth-generation languages, CASE tools, business intelligence, open distributed processing (ODP) and component-based development.

There were difficulties with all of these technologies - both practical (people simply didn't know how to use them effectively, or were reluctant to make the necessary organizational changes) and rhetorical (vendors making wildly optimistic claims, provoking equally wild counter claims).

I sometimes wonder whether there really is more nonsense spoken about SOA than all of these previous technologies put together, or whether it is simply that the nonsense gets greater exposure nowadays (thank-you Internet, thank-you Google, thank-you Blogger).

Even on Wikipedia - often a surprisingly good source of simple information - the articles on SOA and related topics are complicated and confusing. See Wikipedia Category: Service-oriented (business computing). There are some industry models and standards emerging, but most of these are focused on the web services technology stack.

At CBDI, we have always regarded the process as more important than the technology. It isn't what you have that matters most, but what you do with what you have. I had another opportunity to argue this point recently in the pages of IEEE Software, in a debate with Donald Ferguson of Microsoft (formerly Chief Architect of IBM Websphere).

So what is the right process for SOA? We've been working on this for a good while now, and we've decided to make some of this material available through this blog, as a basis for broader collaboration across the industry. What we're hoping to do is open up a wide-ranging discussion about process - what are the problems that an SOA process needs to address, where does an SOA process need to direct the attention of SOA practitioners, and what is the body of knowledge and experience that an SOA process can draw upon?

I intend to return to these broad questions in future posts, and I expect other bloggers will have something to say as well.

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.

In this blog we are making available a piece of work that CBDI has just completed together with TIBCO. The two parties have collaborated on developing a SOA Process Framework – which extends earlier CBDI original work to integrate solution and service architecture processes.

We are placing this work in the public domain and inviting comment and feedback. At this stage we have no particular agenda for standardization, but would welcome your feedback and thoughts a) on the process framework as a basis for better collaboration between parties in a service oriented federation – i.e eventually everyone, and b) the need for common understanding in the industry, and possible standardization.

I just received a private email with a suggestion to improve the SAE metamodel.

"I am approaching information management from the Information Engineering perspective. I am suggesting that the metamodel indicate the different users views or levels of data oriented models (Mission, Subject Area, Conceptual Logical and Design). These models serve different purposes in the Enterprise Architecture stack."

It's an interesting idea, and we shall consider it. However, we are conscious of the need not to overload the metamodel, so it may get excluded on those grounds. We are also keen to keep the metamodel as uncontroversial as possible. I am sure there will always be room for people (including ourselves) to differentiate themselves by adding local refinements.

A UML Profile is a mechanism that allows existing UML tools such as Sparx Systems Enterprise Architect, No Magic's MagicDraw and Rational Software's Rational Software Modeler to immediately begin using a language that extends the UML with additional semantics and notation in a standard, shareable manner.

The OMG is working towards a UML Profile and Metamodel for Services (UPMS). Meanwhile, here are some other UML Profiles of potential interest to the SOA and EA communities.

• CBDI-SAE Meta Model for SOA
• COMET - UML profile for service architecture model
• UML Profile for Software Services (IBM)
• UML4JEA - An experimental UML Profile for Japanese Gov ’ s EA initiative (pdf)
• UML4ODP - UML Profile for Open Distributed Processing
• UN/CEFACT’s Modeling Methodology (UMM)
• UPDM - UML Profile for DoDAF and MoDAF