• Blog
  • About
  • Archives

elemental links

brenda michelson's technology advisory practice

Archives for July 2006

Business-Driven Architect: SOA and Agile

July 19, 2006 By brenda michelson

If you read my business-driven architect blog, skip this post.  If you don’t, and you have some thoughts on the relationship (or not) between SOA and Agile, I encourage you to check out my Agile & SOA: Like Apples & Oranges, Google & Search, or Oil & Water post.

I excerpted an article that shared Gregor Hohpe’s views on Agile & SOA being a powerful combination.  That makes sense to me.  But, I’m curious about how folks are using (or thinking about using) the two together.  And how the architecture aspect is reconciled (Agile is design-test-code, SOA is an architectural strategy).

Or, if you think the two are ‘oil and water’, I’d like to know that as well.  Some folks have already jumped into the conversation. 

Filed Under: services architecture, soa

StreamBase’s Da Vinci Coder Contest

July 13, 2006 By brenda michelson

Looking for an interesting way to learn more about event stream processing? Could you use a laugh after a long day of trying to get something done between meetings and email? Then, you should check out StreamBase’s Da Vinci Coder Contest, and the related short film, a parody on the Da Vinci Code.

The first part of the contest is a series of weekly "Jousts". To complete each joust, you need to discover secrets within StreamBase developer edition, the video, or "other" (easy to find) resources. This week is joust #2. Each weekly joust awards a prize ($1,000 range). If you’re so inclined, you can choose a charitable donation.

The second part of the contest, starting August 14, is the "Grand Tournament". This is a StreamBase application coding contest to win the coveted (?) title of "Da Vinci Coder" and a bigger prize ($10,000 range).

StreamBase, if you don’t know, is Mike Stonebraker’s latest company. No surprise, StreamBase takes a database approach to the event/information stream processing problem. StreamBase uses an SQL derivative (StreamSQL) to perform in-stream complex event processing. The StreamBase product is based on Mike Stonebraker’s Aurora project.

I had a chance to meet with the StreamBase team earlier this year, and was definitely impressed. This paper does a good job explaining the requirements for an event stream processing engine.

Filed Under: event driven architecture

OMG SOASIG Meeting: Quick Chat with Rhysome’s Bob Covington – Event Sensors

July 12, 2006 By brenda michelson

During the afternoon caffeine break of the OMG SOASIG meeting, I sat down with Bob Covington, CTO and co-founder of Rhysome, a provider of sense and respond (event-driven) technology.  In our quick conversation, I learned about Rhysome’s founders (former enterprise IT practitioners), how Rhysome’s products evolved, and what (in my view) makes them unique.

Rhysome’s original mission was to create a real-time reporting tool.  However, the team quickly recognized a gap – sensing and delivering relevant real-time information.  This led the team to the broader event-driven space: event detection, collection and processing. 

What’s unique about Rhysome is the focus isn’t solely on event processing.  Rhysome starts at the source – event detection and collection.  See left hand side of illustration copied from Rhysome’s site.

rhysome sense and respond

Rhysome describes the “smart cyber-sensorstm” as follows:

• Detects and collects very small changes in both data and metadata from each information source in an enterprise, in real-time, using a native Event-Driven Architecture.

• Supports a wide range of information sources such as files, database transactions and schemas, logs (device, system application, and transactions), emails (both enterprise and web mail) instant messages (IM), SOAP messages, messages queues, HTTP, and Web content.

• Smart Cyber-Sensors run in the background with negligible or no impact on client or system performance, and no use of invasive database triggers.

• Dynamic filtering techniques remove non-relevant information at the source, significantly reducing implementation requirements and system overhead.

While designed as part of the broader Rhysome solution, the cyber-sensors can (and have) been incorporated in applications that require non-invasive tracking (think security and compliance) without the downstream complex event processing. 

When you start to think of the possibilities, mixing and matching sensors, services, events, business processes, information sources, and user interfaces, things get interesting.  With standards, to ease the interactions, it is even probable. 

For more on Rhysome, see their site.  [Shaded lenses recommended. :)]

[Note: This post was republished (unchanged) on July 13, 2006 at 3:22 due to Typepad system problems]

Filed Under: event driven architecture

OMG SOASIG Meeting: SOA, EDA and when an Event Occurs in the Forest…

July 11, 2006 By brenda michelson

At the end of June, I shared my views on the relationship between SOA and EDA (peers and complements) with the OMG’s SOA SIG during the OMG Technical Meeting in Boston.  As I mentioned previously, the purpose of my talk was to discuss why EDA is important, and speak to the SOA-EDA relationship from an architectural point of view.

Yes, the SOA 2.0 thing came up, but was quickly discounted (not just by me) as marketing.  An interesting aside on the SOA 2.0 thing is the ‘ripple effect’.  Now that a giant (Oracle) has stepped into the event processing waters, many of the smaller event processing specialists – StreamBase, Coral8, Rhysome, Apama (Progress) – are (rightfully) finding their way into the press and onto practitioner radars.  So, that’s good.

I based my presentation on my event-driven architecture overview paper.  Because I prefer pictures over bullet plastered slides, I created three new illustrations that I want to share here.  Given I was at the OMG, I was very careful to characterize all of my ‘diagrams’ as pictures, since they include no standard notations (oops).

SOA and EDA’s Complementary Relationship

The first two are simple (conceptual) pictures, showing the interactions between services and events. 

The first, is “event-driven SOA”, when the occurrence of an event (a thing that happens inside or outside your business) triggers the invocation of one or many services.

[click on picture to enlarge]

Event_driven_soa_interaction

The second, is “service as event source”, when a service generates an event.  That event may signify a problem or impending problem, an opportunity, a threshold, or a deviation. 

[click on picture to enlarge]

Service_as_event_source_3

In the third picture, I show the broader event architecture, again at a conceptual level.  On the far left, I show 8 different event source examples.  In the middle, I show 6 examples of event-driven actions, and a variety of subscribers.  So, while services can play the role of event source or target, they are just one of many event sources/targets.  Event-driven architecture is much broader than its relationship with SOA, including real-time information flow and analysis and complex event processing.  This is why I say ‘complements and peers’.

Broader EDA – EDA as Peer

[click on picture to enlarge]

Eda_overview_picture

The Discussion

I must admit, I wasn’t sure how my talk would go.  The first presenter, David Frankel from SAP, gave an interesting presentation on Model Driven Business Process Platforms, and the group was receptive, but quiet until David finished.  Then, they asked questions.

Me, I prefer discussion along the way.  Because the discussion – unless completely off topic or down a rat hole – is the most interesting part.  So with some trepidation that the next 45 minutes would be me talking at the group, I started my spiel.  A few slides in, as soon as I said “events have specifications (definitions) and occurrences (instances)” the discussion broke out.  [it’s always good to follow a coffee break!]

The part of the discussion I want to highlight here focused on the ‘event splat’ on the left side of the conceptual EDA diagram above.  For folks that have designed and/or worked with an event-driven architecture/system this will be familiar territory.  For those thinking about event-driven architecture, the concepts raised are important to be aware of.

As mentioned, the discussion started with my providing some definition around the term event.  I presented the following:

•        An event is a [notable] thing that happens inside or outside your business.

•        An event (business or system) may signify a problem or impending problem, an opportunity, a threshold, or a deviation.

•        Events have specifications (definitions) and individual occurrences (instances).

Conceptually, this was fine.  However, the group wanted clarity around “event occurrence”.  Aren’t there really two concepts embedded in “event occurrence”? One: The thing that happened.  Two: Notification that the thing happened. 

As it was asked in the session, “If an event occurs in the forest, how do you know it happened?”  Isn’t that through a notification? 

Good question.  Logically, there are two event concepts (occurrence and notification), plus the originating thing that happened.  Consider a simple example, where orders are treated as events:

  • A new order (123) comes in.  Physically, order 123 is captured and processed as an order.  The order is the originating Thing that Happened. 

  • Logically, the order is also an event.  More specifically, order 123 is an occurrence of the order event.

  • For the event to be processed (heard), it must be detectable and understandable by the event processor.  This is accomplished via a notification that order 123 happened.

  • The event notification carries information about the event occurrence (order 123), in a format described by the order event specification.

These concepts and relationships are depicted in a new (almost standard modeling format) illustration below.  You’ll see that I’ve grouped the individual concepts “Thing That Happened” and “Event Notification” as “Event Occurrence”.

[click on picture to enlarge]

Event_occurrence

In my own event work, we chose to instantiate and process the composite “event occurrence”. In this view, the arrival of the event occurrence served as notification.

That’s just one way.  Others have done the opposite – instantiating an event notification that embeds ‘the thing that happened’.  And others still, instantiate both. 

Implementation styles and reasoning will always vary.  What’s most important is grasping the fundamental concepts.  As for me, I’ll try to note when I say “event occurrence” I really mean “the thing that happened” + “notification”.  So, when the event occurs in the forest, someone hears it.

Event Related Standards

Following my talk, the group discussed requirements for EDA related standards.  What became quickly apparent is there are numerous existing standards associated to events and event processing.  Most have systems origins.  The next step for the SOASIG is to cull through these standards, and see what’s applicable to business events, and event-driven architecture. 

Some of the standards mentioned were:

WSDM

WS-Eventing

WS-Notification

EPC Global – Application Level Event Spec

eDoc UML Profile

Corba Event Service and Notification Service

If you can think of others, let me know.  As for scope, the OMG SOASIG is currently focused on the interrelationships (interactions) between SOA, EDA and BPM, not the broad event-driven architecture space.

Filed Under: event driven architecture, services architecture, soa Tagged With: archive_0

From the Archives: IT Fundamental Truths

July 11, 2006 By brenda michelson

This morning, while I was searching through a box of old papers, I ran across a list of “IT Fundamental Truths” I wrote for a direct report five or six years ago. At the time, this (immensely talented) person, who was new to IT, was frustrated by all the grey areas she kept running into.

While not every item on the following list is a winner, the essence holds up over time. I’m curious what others think. What would you add to the list? Remove?

Although I’m tempted to edit for (lack of) writing style, here is the list, exactly as first  “published”:

IT Fundamental Truths

1.  IT work is all about Compromise, some of the factors:

  • Add Value to the Business
  • Respond to ever changing business, economic and technology environments
  • We are often bounded by our legacy (assets, skills, fixed costs)

     There is enormous value in the skill of compromise, balancing challenges to create opportunity

2.  IT success relies on collaboration, alliance building, and salesmanship.  IT professionals must develop professional as well as technical skills.

3.  Negotiation is critical – for financial contracts and internal customer relationship/service level agreements, meeting truth #1.

4.  Never prematurely discount the work of those that came before you. (See #1, 2, 15)

5.  “Big Bang” is most successful when you are starting from nothing.

6.  Anything that works in production is legacy.

7.  Continuous learners are most successful.

8.  Systems thinking ability is critical, as are the abilities to think conceptually and deal with ambiguity.

9.  Current State is a representation of assets at a point in time.

10. Desired State is a representation of ideas at a point in time. Desired state should plan for adaptability. (See #16)

11. You don’t have to know everything in advance. You do have to know where to find the information you need. Just in time learning.

12. Always ask questions, brace yourself for any answer or non-answer.

13. Best doesn’t always win at the end of the day.

14. Think big, think broad, act pragmatically, deliver incrementally. (See #1, 5, 6, 9, 10, 16)

15. In requirements gathering “never” means “not yet”, “always” means “most often”.

16. There will ALWAYS be something more important/pressing tomorrow than the most important/pressing item you are working on today.

17. Everyday the domain you are trying to solve and the tools and techniques you are trying to solve the domain with, changes.

 

[Note: This post originally appeared on my Business Driven Architect blog on July 11, 2006, brought over to elemental links on June 7, 2008]

Filed Under: business-technology Tagged With: archive_0

Brenda M. Michelson

Brenda Michelson

Technology Architect.

Trusted Advisor.

(BIO)

  • Email
  • LinkedIn
  • RSS
  • Twitter

Recent Posts

  • Experts Sketch
  • PEW Research: Tech Saturation, Well-Being and (my) Remedies
  • technology knowledge premise
  • The Curse of Knowledge
  • better problems and technology knowledge transfer

Recent Tweets

  • “…where the process of drawing itself can take us. We can follow a suggestion, a squiggle, shadow, or smudge, and s… https://t.co/oRg0x2LoXG November 30, 2022 5:05 pm
  • On the waiting list for Post, join me (on the waitlist) via https://t.co/U8wYK707f6 November 24, 2022 4:17 pm
  • Meet the longtime librarian being honored at the National Book Awards : NPR https://t.co/S44VQeJg83 November 13, 2022 2:51 pm
© 2004-2022 Elemental Links, Inc.