Updated 8.23.2006 at 11:04 to insert "DRAFT" into the post title, and add the following clarifying note:

The linked document is a "work in progress", and not (yet) an official RFI.  In other words, please review the RFI for content (additions, changes, deletions), not for submitting a response.  Thanks.

[The original post starts here]

For readers of elemental links, this is a duplicate post. I'm going for max reach!

The Object Management Group’s SOA SIG is looking for community (practitioner, vendor, researcher, observer) feedback on a draft request for information (RFI) on event-driven architecture (EDA) and its relationship with service-oriented architecture (SOA) & business-process management (BPM).

Here’s the RFI Summary:

The EDA Sub-group of the OMG SOA SIG seeks information from members of the EDA, BPM and SOA community as well as anyone interested in promoting standards in this area. Requested information will be evaluated by the EDA Sub-group, resulting in the development of Requests for Proposal(s) (RFP) for standardization of Event definition, relationship between EDA, BPM and SOA that will ultimately allow development of standards for Complete Life Cycle of Events -Ontology of Events, Sense and Respond Services, Events Metrics and processing of complex events. Please note that it is our intent to develop modeling standards for the EDA/SOA and EDA-Business Process interaction and provide standards for the implementation of that interaction as well.

For those (like me) not completely familiar with the OMG process, here’s the description of the RFI process taken from section 8 of The OMG Hitchhiker’s Guide, V7.3:

The intent of the Request for Information (RFI) is to gather information for the purpose of guiding a subgroup in its efforts to provide solutions to industry problems. The RFI is an optional process used by a subgroup to canvass a targeted industry segment for one or more of the following purposes:

• Acquiring general or specific information about industry requirements.
• Soliciting assistance in identifying potential technology sources.
• Soliciting input to and validate a subgroup’s roadmap.

Generally speaking, the RFI process determines which Request For Proposals (RFPs) get issued (and, based on negative feedback, which don't) or influences the way a particular RFP is constructed.

There are no restrictions on who may receive or respond to a RFI. Both OMG Members and non-members can respond. RFI Responses may include information about relevant technologies, products, standards, research, requirements, and other guidance for the subgroup.

If you are interested in EDA (simple, stream, complex), take a look at the RFI and provide comments to Dr. Harsh Sharma. The plan calls for a final review of the RFI at the OMG’s September Technical Meeting in Anaheim.

I suppose this is where I say “I’m going to Disneyland!” I am a guest contributor (no $ exchanged either way) to the EDA subgroup of the OMG SOA SIG.

Posted by brendamichelson in EDA • SOA • architecture strategies | Permalink | Comments (0) | TrackBacks (0)

SearchWebServices.com has a good, short, article by Rich Seeley covering Gregor Hohpe speaking on Agile & SOA as a powerful combination.  Gregor, now with Google, is probably best known for his excellent work on enterprise integration patterns (site, book).

The article opens talking about Agile and SOA as apples & oranges:

Talking about SOA and agile development in the same breath may seem like comparing apples and oranges, says Gregor Hohpe, software architect at Google Inc., but from his point of view the terms go together like Google and search.

"Agile and SOA pair up to improve the alignment between business and IT," Hohpe told attendees at the Burton Group Catalyst Conference in San Francisco this past week. He was not being theoretical. He was talking about how Web services and applications are being developed by his employer, "one of the largest civilian computing infrastructures in the world."

The apples and oranges view comes from looking at SOA as being "an architectural style" that emphasizes how systems interact, while "agile" encompasses "a development approach" that emphasizes how people interact, Hohpe said. But in his view agile practices can help developers move SOA beyond theory.

The article goes on to point out how Agile’s emphasis on evolution, iteration, testing, learning as you go, and close customer collaboration, can help bridge the gap from SOA theory to real world deliverables.

This makes sense to me.  I always advocate starting small with SOA – the project (measurable return, low business risk), the team (good technicians, follow standards, work smart, continuous learners, influencers) and the infrastructure investment (leverage what you have, invest incrementally).  So, Agile concepts are definitely appropriate, particularly dealing with the unknown:

He urged anyone planning to start their first SOA project to not only start small but accept that they really won't know what they are doing. He urged them to accept that Agile principle "that you will know more at the end than you did at the start."

I also speak (over and over) to the importance of the “A” (architecture) in SOA for sustainable success.  Many readers of the article, and this post, might argue that Agile and SOA aren’t ‘apples and oranges’, or ‘Google and search’, but rather ‘oil and water’, because Agile skips architecture, and jumps right into design-code-test increments.

So, an interesting question then, becomes how is that architecture aspect reconciled?  Especially as you move beyond early experimentation.  How can you leverage agile development practices to implement solutions centered on an architectural strategy?  Assuming your staff isn’t loaded like Google’s. 

Right now, I have more questions than answers.  Nevertheless, I can’t help but think a healthy SOA (service model, shared infrastructure, and assembly patterns) is the perfect feeding ground for business solution development (assembly) using agile practices.  As well, I agree with Gregor, that embracing agile concepts for early SOA experimentation is smart.

I’ll definitely be doing some research and thinking along these lines.  If my schedule works out, I might even sneak out to Agile2006 for a bit next week. 

I’m very interested to hear what others think.  Have/Would you use Agile and SOA together?  How do you reconcile the ‘architecture aspect’?  Which do you start with?  As the article points out:

For the managers in the audience, he also stressed that both SOA and agile development take time for programmers to learn. He warned against the sink or swim approach where coders unfamiliar with SOA or agile practices are asked to start doing both at the same time.

Posted by brendamichelson in SOA • agile • architecture strategies | Permalink | Comments (11) | TrackBacks (2)

Ugh!  That was my reaction when I first read about "SOA 2.0".  As Mark Little wrote "Giving an architectural approach a version number is crazy: it makes no sense at all!"

And please, do we need any more confusion on the relationship between SOA and EDA?  I think not.  And I'm not alone.  Neil Dutton-Ward at Macehiter Ward-Dutton has created an online petition to "Stop the Madness".  The petition reads as follows:

We've created this online petition because we're dumbfounded at the attempt by certain parts of the IT industry to create and give weight to the term "SOA 2.0".

We and others have blogged about this already: Joe McKendrick, Mark Little, and Duane Nickull to name but three.

As Duane said recently: "Normally, when someone comes out with a new buzzword that doesn't really have any substance, most people merely complain quietly and go about their business."

We would dearly love, just this once, for things to be different. Industry does not, at this point, need more confusion around SOA. SOA has real value, but industry at large is only just coming to terms with what it means and what it can do. Inventing terms like "SOA 2.0" might help some analysts and vendors make money, but overall, in the long run it damages us all.

In part, this petition is an experiment. Many people have discussed the power of the Web to aggregate and demonstrate the power of individuals: but it would be good to see if, through this simple web page, we could pressure the protagonists into backtracking on SOA 2.0.

I encourage practitioners who are sick of the hype, and looking for  real information/ammunition to introduce/extend SOA in your business to click through this link, and sign the petition.  (Just don't double submit as I mistakenly did).

Posted by brendamichelson in EDA • SOA • architecture strategies | Permalink | Comments (0) | TrackBacks (0)