In the world of SOA, the economics of funding determines what services actually get funded to be developed. This is why we need a set of criteria by which we can assess which candidate services are a priority for inclusion in your next budget cycle. We call these criteria or gating factors, the Service Litmus Tests (SLTs). SLTs are included in SOMA , the de facto end to end SOA Development Method .
Not all candidate services should be implemented as services; we may not have enough budget for that. But here this: we STILL need the functionality of the services that fail to pass the SLTs. Therefore those services still need to be implemented as part of some service component or realized by an application.
Economics is hand in glove with governance and of course SOA Gov includes the issues of economics, funding and budgets and ownership.
BPM, APIs & Service-oriented Architecture: Insights and Best Practices
From archive: October 2007 X
Ali_Arsanjani 120000D8QB 3,715 Views
Lots of SOA projects later, I have finally gotten back to this blog.
I am seeing a large surge in SOA projects, each with greater maturity and more complex needs; but some of the basic remain the same. Often, projectsface unpredictable and complex human situations which may defy rigorous algorithms and require the soft art of consulting. Some are attempting to bridle this erratic and unpredictable aspect of human and group behavior. More of the SOA Projects later.
A recent post by the Univ of Arizona talks about the development of a software that sifts through tons of data and "will use sophisticated computational methods based on game theory, co-evolution and genetic development models to find solutions that make sense in illogical times. Genetic algorithms analyze situations in an evolutionary context, where actions with the highest “fitness factor” (chance of achieving the greatest success) gravitate toward one another, produce offspring and eventually rise to the top."
This form of evolutionary, convergent behavioral computing promises to be used in more and more simulation situations.Typically, rule engines are cluncky (technical term) and finding relations between multiple rules is a tricky proposition.Patterns can help. For example, the Business Rule Pattern Language I have documented starts with a lighteweight way of handling rules and moves into increasingly complex ways of handling rules within object oriented applications.
Follwing its use on three past projects, I have recently revised this pattern language to support SOA. I have gotten quite a bit of email requesting this and I am responding by saying that I will be publishing a draft soon.