EDA and SOA Myth #4: Think SOA or EDA Architecture First

Todd Biske made some interesting observations about Myth #3:  BAM and BPM are Converging.  Here's what he wrote:

I think that the most important takeaway on this is that you have to be thinking from an architectural standpoint as you build these things out. This isn’t about running out and buying a BAM tool, a BPM tool, a CEP tool, or anything else. What metrics are important? How will the metrics be collected? How do you want to perform analytics (is static analysis against a centralized store enough, or do you need dynamic analysis in realtime driven by changing business rules)? What do you want to do with the results of that analysis? Establishing a management architecture will help you make the right decisions on what products you need to support it.

I agree with 105 of the 114 words he writes.  I violently agree that the most essential element to consider on any project is the business requirements ("what metrics are important," "how to perform analytics," "Do you need dynamic rules management," etc.).  But the 9 words I don't like, and another great myth of the SOA versus EDA debate is:  you have to be thinking from an architectural standpoint.  Perhaps he didn't mean it this way, but it sounds like he may be advocating beginning by choosing the right architecture like BAM, BPM, and CEP, then consider the requirements the technology is supposed to fill.

Todd may not have meant it that way, but many people do it this way, every day.  They buy technologies without careful consideration of what they are trying to achieve.   Now I can hear you grown:  "Great insight - gather good requirements first - duh."  Simple idea, hard to follow.  As a software vendor, we encounter a steady stream of technology investigations that have lost sight of this simple truism.  Technology RFIs, proof of concepts, benchmarks, programming language evaluations, philisophical debates over what language syntax is better - SQL or rules languages or Java or visual for CEP logic.  Blaa, blaa, blaa, blaa.  The architecture and technology debates go on forever. 

Software vendors are guilty of fanning the techno-babble flame.  Wild claims about broad support for one vendor's proprietary language approach, or declarations of performance barriers broken by "new, revolutionary" approaches.  Here's a quick sampling of best hyperbole from the past few months:

• Skyler manages rates as high as 200,000 messages/second
• Key feature:  Coral8 handles thousands to millions of events per second
• StreamBase extends performance leadership by processing over one million events per second with near zero latency
• Aleri Labs breaks sub-millisecond latency barrier

Can't the marketing vice presidents of the world come up with something new rather than droaning on about feeds and speeds? 

Fortunately, there are cagey technology professionals out there.  The cagey ones never stop asking the question:  "What are we trying to achieve?"  The cagey ones constantly ask, answer, and re-ask these questions.  The cagey ones care about thoughtful product functionality that solves specific problems and provides specific value.  The cagey ones think about the problem first, and architecture, features, quality, reputation, languages, feeds and speeds next.

So this myth, myth #4 on our list, is to NOT consider architecture first;  instead, spend more time measuring twice, three, and four times before choosing the right architectural cut to make in your enterprise architecture fabric.

Comments

[Todd Biske]

You're right, that not what my post was saying at all. If anything, I'm saying the exact same thing that you are. I subscribe to the city planning analogy for enterprise architecture. To that end, you first need some set of goals that you're trying to achieve. These can be thought of as your requirements. Next comes an architecture that allows those goals to be met, and only after both of those exist do we start looking at products. Yes, this is a very top-down approach, but arguably, city planning is very top-down. Companies that adopt SOA or EDA because some magazine or vendor said to do so are at risk for failure because they haven't answered the "Why SOA?" or "Why EDA?" question. It must begin with a set of goals and/or requirements that justify the architecture.

-tb

[Mark Palmer]

Great city planning analogy - a simultaneous top-down and bottom-up approach to a software solution is critical. Thinking in terms of requirements and software architecture is the best way to make a sensible decision. Well said!

The point of this myth was to point out that an architecture-only approach, which we still a lot, is entirely ineffective.