gmane.comp.web.services.soa.yahoo-1

Call for Research Papers ISWC 2012

Oshani Seneviratne — 2012-05-21T11:12:02

------------------------------------------------------------------------
Call for Research Papers
http://iswc2012.semanticweb.org/call-research-papers

11th International Semantic Web Conference
http://iswc2012.semanticweb.org/
Boston - USA
November 11-15, 2012
------------------------------------------------------------------------

ISWC is the premier venue for presenting innovative systems and
research results related to the Semantic Web and Linked Data. We
solicit the submission of original research papers for ISWC 2012's
research track, dealing with analytical, theoretical, empirical, and
practical aspects of all areas of the Semantic Web. Submissions to the
research track should describe original, significant research on the
Semantic Web or on Semantic Web technologies, and are expected to
provide some principled means of evaluation.

To maintain the high level of quality and impact of the ISWC series,
all papers will be reviewed by three program committee members and one
vice chair of the program committee. To assess papers, reviewers will
judge their originality and significance for further advances in the
Semantic Web, as well as the technical soundness of the proposed
approaches and the overall readability of the submitted papers. We
will give specific attention to the evaluation of the approaches
described in the papers. We strongly encourage evaluations that are
repeatable: preference will be given to papers that provide links to
the data sets and queries used to evaluate their approach, as well as
systems papers providing links to their source code or to some live
deployment.

Topics Of Interest
----------------------------

Topics of interest include, but are not limited to:

* Management of Semantic Web data and Linked Data
* Languages, tools, and methodologies for representing and managing
Semantic Web data
* Database, IR, NLP and AI technologies for the Semantic Web
* Search, query, integration, and analysis on the Semantic Web
* Robust and scalable knowledge management and reasoning on the Web
* Cleaning, assurance, and provenance of Semantic Web data, services,
and processes
* Semantic Web Services
* Semantic Sensor Web
* Evaluation of semantic web technologies
* Ontology engineering and ontology patterns for the Semantic Web
* Ontology modularity, mapping, merging, and alignment
* Ontology Dynamics
* Social and Emergent Semantics
* Social networks and processes on the Semantic Web
* Representing and reasoning about trust, privacy, and security
* User Interfaces to the Semantic Web
* Interacting with Semantic Web data and Linked Data
* Information visualization of Semantic Web data and Linked Data
* Personalized access to Semantic Web data and applications
* Semantic Web technologies for eGovernment, eEnvironment, eMobility or eHealth
* Semantic Web and Linked Data for Cloud environments

Submission
---------------------

Pre-submission of abstracts is a strict requirement. All papers and
abstracts have to be submitted electronically via the Conference
Submission System
https://www.easychair.org/conferences/?conf=iswc2012.

All research submissions must be in English, and no longer than 16
pages. Papers that exceed this limit will be rejected without review.
Submissions must be in PDF formatted in the style of the Springer
Publications format for Lecture Notes in Computer Science (LNCS). For
details on the LNCS style, see Springer’s Author Instructions.
ISWC-2012 submissions are not anonymous.

Authors of accepted papers will be required to provide semantic
annotations for the abstract of their submission, which will be made
available on the conference web site. Details will be provided at the
time of acceptance.

Accepted papers will be distributed to conference attendees and also
published by Springer in the printed conference proceedings, as part
of the Lecture Notes in Computer Science series. At least one author
of each accepted paper must register for the conference and present
the paper there.

Prior Publication And Multiple Submissions
--------------------------------------------------------------------

ISWC 2012 will not accept research papers that, at the time of
submission, are under review for or have already been published in or
accepted for publication in a journal or another conference. The
conference organizers may share information on submissions with other
venues to ensure that this rule is not violated.

Submission of a Poster or Demo together with your Accepted Research Paper
----------------------------------------------------------------------------------------------------------------------

Authors of accepted papers are invited to submit also a poster or a
demo to the Posters and Demo track. The submission format is the same
as for normal poster and demo submissions but the submission must cite
the corresponding paper from the research track.

Important Dates
----------------------------

Abstracts: June 1, 2012, 11:59pm Hawaii time
Full Paper Submission: June 8, 2012, 11:59pm Hawaii time
Author Rebuttals: July 9-11, 2012
Notifications: July 26, 2012
Camera-Ready Versions: September 4, 2012
Conference: November 11-15, 2012
No extensions of the submission deadline will be granted.

Research Track Chairs
--------------------------------------

Philippe Cudre-Mauroux, University of Fribourg, Switzerland
Jeff Heflin, Lehigh University, USA


Follow ISWC 2012 on Twitter
https://twitter.com/#!/iswcboston


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/service-orientated-architecture/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/service-orientated-architecture/join
    (Yahoo! ID required)

<*> To change settings via email:
    service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> To unsubscribe from this group, send an email to:
    service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Re: Re: The Economics of Reuse: DDD vs SOA

Michael Poulin — 2012-05-20T22:47:50

Two or three perspectives make sense to discuss _only_ if we agree on an ontology and semantic of what we are talking about. OASIS SOA demonstrates complete scheme of ontology and semantic thought through and validated by many people from many organisations. I do not insist that everything should come from OASIS, but I would expect the ontology and semantic foundation for an alternative view not less solid than from OASIS (it does not matter how many people contributed into it if it is solid).

Reading Caminao site, I have not found "two different perspectives of reuse". At the same time, it is known that programming re-use of code couples everything in object hierarchies, which is not acceptable for autonomous services in SOA. From SOA viewpoint, DDD-based reuse is not a perspective. This is why I developed DOSOM back in 2009. In DOSOM, SOA service functionality and interfaces define boundaries of the programmatic code re-use for DDD, and there is no other perspectives - services may not be coupled by their implementation/code_re-use behind their interfaces. Period. Otherwise, it is not SOA. That time I talked with Eric Evans about DOSOM and he told me that I was "probably" right about service boundaries. Sorry, Remy.

- Michael



>

Re: The Economics of Reuse: DDD vs SOA

remyfannader — 2012-05-20T21:25:22

Michael,
As you suggest this forum is not the right place for such a detailed
debate, and therefore I would not even enter it. As for the material
used for the article, it is either published on the Caminao  site or
explicitly referenced. Apart from commonly accepted principles, there
isn't much that could have come from OASIS.
In any case the objective of this discussion is not to allocate points
but to initiate a reflection on two different perspectives of reuse.
Remy.

--- In service-orientated-architecture-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, Michael Poulin
<m3poulin< at >...> wrote:
usability) since
January 2009
DDDâ[
http://www.ebizq.net/blogs/service_oriented/2009/01/a_domain_service-ori\
ented_modelling_or_how_soa_meets_with_ddd.php]).
Caminaoâs
that are different
immutable execution context,
draft of the
âCaminaoâ correct
by my early contributions,
found a
the whole ontology
a set
follow. In this
externalities by
internal
policies in a changing policy
a changed
of Business,
are
when
perspective:
business
SOA RAF, an
Execution
context-parts depend on
context-parts
this applies
context-parts together
outside of
that âreused
contextâ leads to
results in
(artefact/component)
âCaminaoâ really
recommendations
reuse the
possibly misleading.
have not found




------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/service-orientated-architecture/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/service-orientated-architecture/join
    (Yahoo! ID required)

<*> To change settings via email:
    service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> To unsubscribe from this group, send an email to:
    service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Re: The Economics of Reuse: DDD vs SOA

Michael Poulin — 2012-05-20T10:02:47

It is possible I am out of sync with contemporary materials
but I have not seen publications on "DDD vs SOA" from usability
perspectives (and economics is one of the forms of sublimated usability) since
I published my analysis of superposition between SOA and DDD back in January 2009
(“A Domain Service-Oriented Modelling or How SOA Meets DDD”[ http://www.ebizq.net/blogs/service_oriented/2009/01/a_domain_service-oriented_modelling_or_how_soa_meets_with_ddd.php]).
The same relates to the definition of reuse presented in the Caminao’s
publication (“Reusing artifacts means using them in contexts that are different
of their native ones” vs. multiple use of artefacts in the immutable execution context,
which I articulated back in 2007 when we worked on the first public draft of the
OASIS SOA RAF specification). So, I dare to conclude (and let ‘Caminao’ correct
me), that aforementioned publication has been “fueled” by my early contributions,
which is pleasant to me.

I do assure you that the publication is a very serious and
respectful work, and deserves attentive reading. Nevertheless, I have found a
few discrepancies in there maybe because I am not that familiar with the whole ontology
model of Caminao’s Way. In particular,

1) OASIS SOA RAF defines execution context as a set
of policies that consumer of the services and the service itself follow. In this
case, a statement “Reuse policies may also bring positive externalities by
inducing a comprehensive approach to software design” contains internal
contradiction – “Reuse policies” is a use of policies in a changing policy
environment, i.e. it is difficult to comprehend how the same policy is a changed
policy at the same time.

2) Similar confusion relates to enumeration of Business,
Engineering and Architecture perspectives: “ Business
perspective: how to factor out and reuse artifacts associated with the
knowledge of business domains when system functionalities or platforms are
modified. Engineering perspective: how to reuse development artifacts when
business contents or system platforms are modified. Architecture perspective:
how to use system components independently of changes affecting business
contents or development artifacts.” Again, according to OASIS SOA RAF, an
Execution context comprises Business Execution context and Technical Execution
context (see “Ladder to SOE”, 2009). Policies of these context-parts depend on
local laws and regulations simultaneously; a change in any of the context-parts
constitutes a change in the Execution context as a whole. Especially, this applies
to the presented “Architecture perspective”, which ties context-parts together
(vs. “independently
of changes”). It seems that presented enumeration is taken outside of
the ontology and semantic realm, i.e. for the sake of its own.

3) In line of logic of OASIS SOA RAF, a fact that “reused
artifacts are meant to be used independently of their native context” leads to
that the same service (artefact/component) may produce different results in
different Execution contexts. That is, befaviour of the service (artefact/component)
directly depends on the context policies. I am not sure that ‘Caminao’ really
grasps this service specific quality. In this regard, the recommendations
following “From the enterprise perspective, the problem is to reuse the
knowledge of business domains and processes” worries me as possibly misleading.

I could continue this observation but I am not sure that
this forum is the right place for such detailed debate. Moreover, I have not found
one reference to DDD in this Caminao’s
publication and got confused even more.

- - Michael Poulin

The Economics of Reuse: DDD vs SOA

remyfannader — 2012-05-20T04:44:51

While many remain unconvinced by the benefits of reusing software artifacts it's worth to start with requirements and reexamine the economics of the different options.
http://caminao.wordpress.com/engineering/system-engineering-processes/reuse/



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/service-orientated-architecture/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/service-orientated-architecture/join
    (Yahoo! ID required)

<*> To change settings via email:
    service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> To unsubscribe from this group, send an email to:
    service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Jacobson on REST

Gervas Douglas — 2012-05-16T12:36:16

<<Why REST Keeps Me Up At Night
<http://blog.programmableweb.com/2012/05/15/why-rest-keeps-me-up-at-night/>

*Guest Author
<http://www.programmableweb.com/profile/guest_blogger>*, May
15th, 2012
Comments
<http://blog.programmableweb.com/2012/05/15/why-rest-keeps-me-up-at-night/#comments>(0)

/This guest post comes from Daniel Jacobson (< at >daniel_jacobson
<http://www.twitter.com/daniel_jacobson>), director of engineering for
the Netflix <http://www.netflix.com/> API
<http://developer.netflix.com/>. Prior to Netflix, Daniel ran
application development for NPR <http://www.npr.org> where he created
the NPR API <http://www.npr.org/api>, among other things. He is also the
co-author of APIs: A Strategy Guide
<http://shop.oreilly.com/product/0636920021223.do> and a frequent
contributor to ProgrammableWeb <http://www.programmableweb.com> and the
Netflix Tech Blog <http://techblog.netflix.com>./

Netflix <http://www.programmableweb.com/api/netflix>With respect to Web
APIs, the industry has clearly and emphatically landed on REST as the
standard way to implement these services. And for good reason... REST,
which is generally implemented as a one-size-fits-all solution, is an
excellent choice for a most companies who wish to expose their content
to third parties, mobile app developers, partners, internal teams, etc.
There are many tomes about what REST is and how best to implement it, so
I won't go into detail here. But if I were to sum up the value
proposition to these companies of the traditional REST solution, I would
describe it as:

REST APIs are excellent at handling requests in a generic way,
establishing a set of rules that allow a large number of known and
unknown developers to easily consume the services that the API offers.

In this model, everyone knows how to behave and it can be incredibly
powerful. The API providers establish a set of rules and the API
consumers must adhere to those rules to get what they want from the API.
It is perfect, right? In many cases, the answer is obviously yes. But in
other cases, as our world scales and the number of ways for people to
consume digital content and services continues to expand, this
one-size-fits-all model is likely to fall short.

The potential shortcomings surface because this model assumes that a key
goal of these APIs is to serve a large number of known and unknown
developers. The more I talk to people about APIs, however, the clearer
it is that public APIs are waning in popularity and business opportunity
and that the internal use case is the wave of the future. There are
books <http://shop.oreilly.com/product/0636920021223.do>, articles
<http://econsultancy.com/us/blog/9456-api-strategies-for-disruptive-digital-sellers>
and case studies
<http://blog.programmableweb.com/2011/04/18/what-we-did-wrong-npr-improves-its-api-architecture/>
cropping up almost daily supporting this view. And while my company,
Netflix, may be an outlier because of the scale in which we operate, I
believe that we are an interesting model of how things are evolving.

Netflix is currently available on over 800 different device types,
including game consoles, mobile phones, TVs, Blu-ray players, tablets,
computers, and almost any other device that can stream video. Our API
alone handles more than two billion incoming requests on peak days,
which translates into almost ten billion real-time outgoing requests
from the API to internal dependency services. These numbers are up by
about 70x from just two years ago. Most companies do not have that kind
of scale, but it is clear that with the continued growth of the device
market more companies are resetting their strategies to be less about
the public API and more about internal consumption of their own APIs to
support device proliferation. When this transition occurs, the API is no
longer targeting "a large number of known and unknown developers."
Rather, the key audience is a small number of known developers.

The potential conflict between the internal and public use cases is in
the design of the API itself. Keep in mind that the design implications
will not be problematic in many scenarios. It becomes a potential
problem if the breadth of devices becomes so wide that the variability
of features across them becomes substantially harder to manage. It is
the breadth of devices that creates a problem for the one-size-fits-all
API solutions.

If your target is a small group of teams with whom you have close
relationships, the dynamics around the API change. For Netflix, we
persisted on the one-size-fits-all REST model for quite a while as more
and more devices got added on top of the API. But given our scale, one
thing has become increasingly obvious. *Our REST API, while very capable
of handling the requests from our devices in a generic way, is optimized
for none of them.* This is the case because our REST API focuses on
resources that are meant to be granular representations of the data,
from the perspective of the data. The granularity is exactly what allows
the API to support a large number of known and unknown developers.
Because it sets the rules for how to interface with the data, it also
forces all of the developers to adhere to those rules. That means that
each device potentially has to work a little harder (or sometimes a lot
harder) to get the data needed to create great user experiences because
devices are different from each other.

The differences across these devices can be varied and sometimes
significant. Here are some examples of variances across devices that may
be challenging for one-size-fits-all models:

* Different devices may have different memory capacity
* Some devices may require a unique or proprietary format or
delivery method
* Some devices may perform better with a flatter or more
hierarchical document model
* Different devices have different screen real estate sizes which
may impact which data elements are needed
* Some devices may perform better having bits streamed across HTTP
rather than delivered as a complete document
* Different devices allow for different user interaction models,
which could influence the metadata fields, delivery method,
interaction model, etc.

Just think about the differences between an iPhone and your TV and how
they beg for different user experiences. Moreover, the XBox and the Wii,
both of which project to the TV, are different in the way users interact
with them as well as in the hardware constraints, both of which may
require different APIs to support them. When considering more than 800
different device types, the variance across them becomes overwhelming.
And as more manufacturers continue to innovate on these devices, the
variance may only broaden.

How do you know if your company is ready to consider alternatives to the
one-size-fits-all API model? Here are the ingredients needed to help you
make that decision:

* Small number of targeted API consumers is the top priority
* Very close relationships between these API consumers and the API team
* An increasing divergence of needs across the top priority API
consumers
* Strong desire by the API consumers for more optimized interactions
with the API
* High value proposition for the company providing the API to make
these API consumers as effective as possible

If these ingredients are met, then you have the recipe for needing a new
kind of API.

Because of the differences in these devices, Netflix UI teams would
often have to do a range of things to get around our REST API to better
serve the users of the device. Sometimes, the API team would be required
to extend the base service to handle special cases, often resulting in
spaghetti code or undocumented features. And because different teams
have different needs, in the REST API world, we would often need to
delay feature development for some due to the challenges around
prioritization. In addition to these kinds of issues, significant
performance and/or architectural problems are bound to emerge. For
example, these more granular APIs often result in chattier interactions
between device and server or chunkier payloads, as I discussed in a
previous post on the Netflix Tech Blog
<http://techblog.netflix.com/2011/02/redesigning-netflix-api.html>.

To solve this issue, it is becoming increasingly common for companies
(including Netflix) to think about the interaction model in a different
way. Rather than having the API create a set of rather rigid rules and
forcing the various devices to follow them, companies are now thinking
about ways to let the UI have more control in dictating what is needed
from a service in support of their needs. Some are creating custom
REST-based APIs to support a specific device or category of devices.
Others are thinking about greater granularity in REST resources with
more batching of calls
<http://developers.facebook.com/docs/reference/api/batch/>. Some are
creating orchestration layers, such as ql.io, in their API system to
customize the interaction. These are all smart and practical ways around
the problem. But with the growing number of devices, the increasing urge
for companies to be on as many of them as possible, and the desire for
continued innovation across these devices, these various solutions are
still somewhat restricted. They are still forcing the developers to
adhere to server-side rules and non-optimized payloads in an effort to
have a one-size-fits-all solution. These approaches are closer to the
flexibility needed in that they are not as rigid as the typical
REST-based solution, but when supporting as many devices as Netflix
does, we believe they fall short for us.

For Netflix, *our goal is to take advantage of the differences of these
devices rather than treating them generically*. As a result, we are
handing over the creation of the rules to the developers who consume the
API rather than forcing them to adhere to a generic set of rules applied
by the API team. In other words, we have created a *platform for API
development*. In my next post, I will discuss in more detail our
implementation of this approach. In the meantime, if you are interested
in helping us solve these and other problems, we are hiring
<http://jobs.netflix.com/jobsListing.html?function=Engineering>!>>

*You can find this at:
http://blog.programmableweb.com/2012/05/15/why-rest-keeps-me-up-at-night/
*

*Thanks to Anne for pointing this out.
*

*Gervas*

[ZapFlash] You Say You Want a Revolution...

Gervas Douglas — 2012-05-14T22:58:57

    You Say You Want a Revolution...


        Document ID: | Document Type: ZapFlash
        By: /Jason Bloomberg/ | Posted: /May 14, 2012/


Remember the heady dot.com days circa 1999? We thought we were 
reinventing business, forming a New Economy, revolutionizing the 
essential nature of commerce. In our dreams! By late 2001 the bubble had 
burst, and what we thought was a new /paradigm/ for business---the World 
Wide Web---turned out to be little more than a new /marketing channel/.

Don't get me wrong---I'm not trying to disparage the power and 
importance of the Web. After all, the Web, and the Internet in general, 
have deeply affected so many aspects of business today. It's hard to 
remember the time when you had to talk to a teller to use a bank or a 
stockbroker to trade stocks! But we were wrong that the Web was a 
revolution. It wasn't a paradigm shift. Fundamentally, the rise of the 
Internet was more /evolutionary/ than /revolutionary/.

Not wanting to succumb to this delusion again, ZapThink has long held 
that the rise of SOA was also more evolutionary than revolutionary. We 
point to many SOA best practices, including abstracted interfaces, 
encapsulation, loose coupling, and iterative approaches to dealing with 
changing requirements, among others---all practices that were already 
well-known and favored before SOA came along. SOA moved the ball 
forward, to be sure, but didn't fundamentally change the way we tackled 
distributed computing. It wasn't a true paradigm shift, because we 
didn't have to throw out old ways of thinking and replace them with new 
ways. Instead, we leveraged the existing approaches while tweaking and 
improving them.

Today, however, ZapThink is willing to go out on a limb and proclaim 
that we now have a true revolution on our hands. A true paradigm shift 
in the world of IT is afoot, one that is already forcing us to discard 
old ways of doing things, in favor of new approaches, new technologies, 
and new ways of thinking. Yes, we're talking about ZapThink's vision for 
Enterprise IT in 2020 
<http://t.ymlp278.net/uyhewanamywsanaesatambmuu/click.php> with its five 
Supertrends <http://t.ymlp278.net/uyheqaramywsaraesapambmuu/click.php> 
and multiple Crisis Points 
<http://t.ymlp278.net/uyheyazamywsapaesalambmuu/click.php>. We've 
already laid out the context for the turbulence that is already underway 
and yet to come. But we haven't explained why we're calling this period 
in time a revolution. Why does this decade herald a true revolutionary 
change, when even the dot.com period (aka "Web 1.0") of 1994-2001 didn't 
qualify?

*The Context for Revolutionary Change*

The most familiar revolutions, of course, are political---the American 
Revolution, the French Revolution, etc. The author most responsible for 
extending this definition beyond the political sphere was Thomas Kuhn, 
whose 1962 book /The Structure of Scientific Revolutions/ 
<http://t.ymlp278.net/uyhmsacamywsagaesakambmuu/click.php> discussed the 
nature of revolutions such as the Copernican Revolution or the one 
leading to the Atomic Theory of Matter. Such revolutions in the process 
and theory of science represented periods of dramatic change, requiring 
intellectuals of the day to discard old ways of thinking and replace 
them with new ones---often over the course of a generation, as the old 
guard eventually died off. Kuhn also coined the term /paradigm shift/ to 
refer to such upheaval in ways of thinking. (Yes, if you ever wondered 
where the notion of paradigm shifts came from, it was Thomas Kuhn who 
came up with the whole idea).

Kuhn's book was so influential that his notions of revolutions and 
paradigm shifts expanded well past the realm of the history of science 
into virtually any area of human endeavor. His insights, after all, 
applied to fundamental aspects of human thought and behavior: human 
endeavors don't progress evenly and gradually, but rather in fits and 
starts, and occasionally there's a large upheaval that resets the 
playing field. But not every change represents a paradigm shift, and not 
every trend is revolutionary.

*Revolution vs. Evolution*

How then do we know we're truly in a revolution, and not simply another 
period of evolution like the dot.com or SOA eras? Kuhn points out that, 
well, it's harder than it sounds. People often don't recognize that a 
revolution has taken place until well after the fact. It's not like one 
day somebody wakes up and realizes that the way they were doing things 
is suddenly obsolete. In fact, the pre-revolutionary patterns often 
persist well into the revolutionary period, even though in retrospect it 
becomes clear their days were numbered.

Another reason why revolutions are hard to identify while in the midst 
of them is that the changes are numerous, often sporadic, and typically 
subtle. When Galileo turned his telescope toward the moons of Jupiter, 
it's not clear that he realized he was helping to change an entire 
civilization's world view. When the Catholic Church forced him to recant 
his discoveries, I'm sure the church authorities had no idea they were 
fighting a losing battle. Only in retrospect can we place these events 
into the proper context of the Copernican Revolution.

A third impediment to identifying a revolution in progress is the 
clichéd nature of the terms /revolutionary/ and /paradigm shift/. It 
seems that every technology startup these days touts their new widgets 
as being revolutionary paradigm shifts. Hell, it seems that every minor 
improvement in laundry detergent or automobile oil is revolutionary. 
It's no wonder we've become jaded about the entire subject. If the 
marketeers tout every minor improvement as revolutionary then nothing is 
revolutionary.

That is, until a /real/ revolution comes along.

*Why ZapThink 2020 Signals a Revolution*

If we only spotted one trend (like SOA) or one disruptive change (e.g., 
the Web replacing tellers and stockbrokers), then we might have a hint 
of a revolution, but more likely than not, we'd be wrong to apply the 
term. However, there are simply too many different forces of change 
impacting IT today, and in turn, impacting business in general to 
consider such changes to be an evolutionary trend. We have Cloud 
Computing, mobile computing, the threat of Cyberwarfare, the rise of 
social media, the app store model for purchasing software, outsourcing, 
insourcing, complex systems engineering...the list goes on and on. Any 
of these trends taken separately may be considered evolutionary, but put 
them together and there are strong hints of a paradigm shift in progress.

The second aspect of ZapThink 2020 that indicates a revolution in 
progress is the potentially disruptive nature of the Crisis Points. 
While the Stuxnet 
<http://t.ymlp278.net/uyhmuaaamywsaxaesaoambmuu/click.php> worm may have 
only disrupted Iranian power plants, the next professionally designed 
cyberattack <http://t.ymlp278.net/uyhmeafamywsaxaesagambmuu/click.php> 
promises much greater disruption. And while buying enterprise-class apps 
via your phone is novel, it has yet to put one of the big enterprise app 
vendors out of business. So, we won't really know just how disruptive 
this paradigm shift will be until after the fact.

Perhaps the greatest indicator of an ongoing revolution is the evolving 
perspective on /change, /and the role technology has in supporting it. 
People are simply getting fed up with inflexible technology. We're sick 
and tired of legacy that slows down our organizations and sucks up our 
budgets. The need for greater agility drove the move to SOA, but SOA 
alone doesn't solve our inflexibility problems, in large part because 
SOA is part of the old paradigm. What we need is a new paradigm for 
architecture-driven agility 
<http://t.ymlp278.net/uyhmmapamywsaxaesaoambmuu/click.php> that is 
inherently different than today's architectural approaches. It's the 
fact that we're already seeing the shift to this new paradigm that is 
the primary reason we're calling this point in time a revolution.

*The ZapThink Take*

The most challenging aspect of identifying a revolution is that it's 
extraordinarily difficult to do so while it's still in progress. We 
understand this challenge, and realize that we may be wrong about the 
whole affair. After all, there are still so many unanswered questions. 
For example, in 20 years when we look back on this time, what will we 
call the revolution? We can guess, but there's no way to know what the 
next big thing 
<http://t.ymlp278.net/uyhmjaxamywsakaesavambmuu/click.php> will be until 
it's finally here.

Perhaps we can look back at the last revolution for inspiration---the 
postwar Information Revolution that heralded the Information Age. 
Starting with Colossus 
<http://t.ymlp278.net/uyhmbacamywsaiaesadambmuu/click.php> cracking the 
Nazi's Enigma codes at Bletchley Park, through the rise of digital, 
programmable computers to the networked world we have today, no one can 
disagree that the rise of computing disrupted the pre-computer ways of 
thinking and conducting business, leading to an entirely new context for 
human endeavor writ large. But no single innovation, no single 
disruption signaled the revolution. Only in retrospect can we take all 
the disruptions together and recognize a true paradigm shift.

We're the first to admit, therefore, that we may be completely wrong 
about what we call the Agile Architecture Revolution 
<http://t.ymlp278.net/uyhmhaaamywsapaesadambmuu/click.php>. And we may 
not know how right we were for another twenty years. But we can say that 
rethinking how we approach agility will be a critical enabler for 
organizations over the next ten years and beyond. Whether agile 
architecture heralds a revolution may be too hard to say with any 
certainty, but agile architecture is undoubtedly here to stay.

Bradshaw on EAI Adapters

Gervas Douglas — 2012-05-13T22:39:33

<<Why Traditional EAI Adapters Fail

By Jeff Bradshaw
<http://www.businesscomputingworld.co.uk/author/jeff-bradshaw/> March
26, 2012Share3

EAI

*Many years spent building integration solutions have taught me a great
deal about what makes certain approaches successful. During this time,
I've observed many projects where traditional EAI
<http://en.wikipedia.org/wiki/Enterprise_application_integration>
(Enterprise Application Integration) adapters were used to connect IT
assets to the integration infrastructure.*

The recurring feature in all of these projects is the staggering amount
of legacy code that needs to be written to make, what should be a
completely configurable adapter, actually work. This isn't necessarily a
criticism of those specific vendors' adapters; instead it's a comment on
the futility of attempting to build configurable pre-packaged adapters
for every possible use case. It just isn't practical.

The configuration threshold

Common sense suggests that vendors should only produce a pre-built
plugin when it could be reasonably deployed through configuration alone.
If plugins require bespoke code on top of the configuration to achieve a
certain design goal, then it implies that the configuration threshold
has been crossed and that the better course of action would be to
produce a more specific plugin to do the job.

Adopting this approach has impacted our strategy in two main ways; the
rationalisation of plugins and the encouragement of end users to create
their own mediation plugins.

Rationalise not compromise

Only producing a pre-built plugin when it can simply be deployed through
basic configuration, undoubtedly leads to a rationalisation of plugins
produced. However, looking at the range of adapters that other vendors
offer, tells me that their customers must be cutting a lot of code or
making a lot of compromises.

Contained code

Secondly, and more importantly, this approach leads to organisations
opening up their architecture and exposing design frameworks to allow
end users to produce their own mediation plugins. For example, hooks and
mechanisms are available to deploy custom code within the mediation
plugins container.

This "contained" code limits the need to write legacy code outside of
the plugin. In my experience, such "uncontained" code is typically 8 to
12 times more costly to develop and maintain because it is usually
developed within a non-productive, code-intensive, skill-shortage legacy
environment.

By following this rule, organisations can realise significant
productivity improvements. Whilst some coding is required within the
plugin, the result will be a perfect fit, built upon and reusing
existing services, and in keeping with the design approach of the
embedded mediation framework.

A pragmatist stance

I'd certainly not advocate writing bespoke code for every mediation
plugin deployment -- far from it. In fact, the majority of our 1250+
customer deployments have been made using our configuration tools alone.
The key here has to be pragmatism. Where there is a functionality delta
between the mediation plugins and the IT asset being integrated, allow
the code that will reduce the delta to be accommodated within the
mediation plugin.

Such pragmatism makes it possible to package new "adapters" within days
rather than months or years, offering customers a greater level of
flexibility in how they bring packaged applications into a Service
Oriented Architecture.

What about hosting the integration logic?

One thing that often gets overlooked is the runtime aspect of the
adapters. Generally adapters are hosted locally, close to the target
application. Hosting locally is one option, however an increasing number
of customers want to host integration logic elsewhere, or use adapters
to integrate on premise applications with cloud applications. Such
flexibility is undoubtedly key and ties in to my belief in integration
anywhere -- and something that more and more customers are looking to
harness.>>

*You can find this at:
http://www.businesscomputingworld.co.uk/why-traditional-eai-adapters-fail/?goback=.gde_87715_member_103753297
*

*Gervas*

Final CfP+deadline extension: WoMO 2012 - 6th Int'l Workshop on Modular Ontologies

WoMO 2012 — 2012-05-10T21:47:03

========================================================
     6th Int'l Workshop on Modular Ontologies (WoMO)
              Graz, Austria, July 24, 2012
           held in conjunction with FOIS 2012

             --- Final Call for Papers ---
========================================================
   +++ EXTENDED SUBMISSION DEADLINE: May 18, 2012 +++
========================================================

+++ Following requests, we have extended the submission deadline to
MAY 18, 2012. +++

INVITED SPEAKERS:

* Thomas Eiter, Vienna University of Technology, Austria
  Title TBA

* Luciano Serafini, Fondazione Bruno Kessler, Trento, Italy
  Multi context logics: a formal support for structuring knowledge and
beliefs (Tentative title)


http://www.informatik.uni-bremen.de/~ts/womo2012

MODULARITY, studied for years in software engineering, allows
mechanisms for easy and flexible reuse, generalization, structuring,
maintenance, design patterns, and comprehension. In formal and applied
ontology, modularity is central to reducing the complexity of
designing and understanding ontologies, and to facilitating ontology
verification, reasoning, development, maintenance and integration.

Recent research on ontology modularity shows substantial progress in
foundations of modularity, techniques of modularization and modular
development, distributed reasoning and empirical evaluation. These
results provide a solid foundation and exciting prospects for further
research and development.

The workshop continues a series of successful events that have been an
excellent venue for practitioners and researchers to discuss latest
and current work; the most recent WoMOs were held at FOIS 2010 and
ESSLLI 2011.

TOPICS include, but are not limited to:

- What is modularity?: kinds of modules and their properties; modules
vs. contexts; design patterns; granularity of representation;

- Logical/foundational studies: conservativity; modular ontology
languages; reconciling inconsistencies across modules; formal
structuring of modules; heterogeneity;

- Algorithmic approaches: distributed and incremental reasoning;
modularization and module extraction; sharing, linking, reuse;
privacy; evaluation of modularization approaches; complexity of
reasoning; implemented systems;

- Applications: semantic web; life sciences; bio-ontologies; natural
language processing; space and time; ambient intelligence; social
intelligence; collaborative ontology development and ontology
versioning.

IMPORTANT DATES

Paper Submission: May 18, 2012
Notification: June 19, 2012
Camera ready: July 6, 2012
Workshop: July 24, 2012

SUBMISSION GUIDELINES:

We welcome submissions on modularity in a broad sense. The workshop is
open to papers of theoretical or practical nature. Submissions should
be of up to 11 pages in length, formatted according to Springer LNCS
style (see http://www.springer.com/comp/lncs/Authors.html), prepared
in PDF format and submitted no later than May 18, 2012, through the
EasyChair Submission System (see
http://www.easychair.org/conferences/?conf=womo2012).

Submitted papers will be peer-reviewed by members of the program
committee. Accepted papers will be made available in the proceedings
to be published electronically in the CEUR Workshop Proceedings series
(see http://www.ceur-ws.org).

(Find the WoMO 2010 and 2011 proceedings here
http://www.booksonline.iospress.nl/Content/View.aspx?piid=16268 and
http://www.booksonline.iospress.nl/Content/View.aspx?piid=20369)

WORKSHOP CHAIRS:

Thomas Schneider, University of Bremen, Germany
Dirk Walther, Technical University of Madrid (UPM), Spain

PROGRAM COMMITTEE:

Kenneth Baclawski, Northeastern University, Boston, MA, USA
Stefano Borgo, Italian National Research Council, Trento, Italy
Oscar Corcho, Universidad Politecnica de Madrid, Spain
Bernardo Cuenca Grau, University of Oxford, UK
Mike Dean, Raytheon BBN Technologies, Ann Arbor, MI, USA
Silvio Ghilardi, Universita degli Studi di Milano, Italy
Michael Gruninger, University of Toronto, Canada
Janna Hastings, EMBL-EBI, Cambridge, UK
Robert Hoehndorf, University of Cambridge, UK
Boris Konev, University of Liverpool, UK
Roman Kontchakov, Birkbeck College, London, UK
Thomas Meyer, Meraka Institute, CSIR, Pretoria, South Africa
Till Mossakowski, University of Bremen, Germany
Immanuel Normann, Birkbeck College, London, UK
Leo Obrst, MITRE, McLean, VA, USA
Adrian Paschke, Free University of Berlin, Germany
David Perez del Rey, Universidad Politecnica de Madrid, Spain
Uli Sattler, University of Manchester, UK
Luciano Serafini, Fondazione Bruno Kessler, Trento, Italy


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/service-orientated-architecture/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/service-orientated-architecture/join
    (Yahoo! ID required)

<*> To change settings via email:
    service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> To unsubscribe from this group, send an email to:
    service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

3rd CfP: WoMO 2012 - 6th Int'l Workshop on Modular Ontologies

WoMO 2012 — 2012-05-07T14:58:39

========================================================
     6th Int'l Workshop on Modular Ontologies (WoMO)
              Graz, Austria, July 24, 2012
           held in conjunction with FOIS 2012

             --- Third Call for Papers ---
========================================================
           Submission deadline: May 11, 2012
========================================================

INVITED SPEAKERS:

* Thomas Eiter, Vienna University of Technology, Austria
  Title TBA

* Luciano Serafini, Fondazione Bruno Kessler, Trento, Italy
  Multi context logics: a formal support for structuring knowledge and
beliefs (Tentative title)


http://www.informatik.uni-bremen.de/~ts/womo2012

MODULARITY, studied for years in software engineering, allows
mechanisms for easy and flexible reuse, generalization, structuring,
maintenance, design patterns, and comprehension. In formal and applied
ontology, modularity is central to reducing the complexity of
designing and understanding ontologies, and to facilitating ontology
verification, reasoning, development, maintenance and integration.

Recent research on ontology modularity shows substantial progress in
foundations of modularity, techniques of modularization and modular
development, distributed reasoning and empirical evaluation. These
results provide a solid foundation and exciting prospects for further
research and development.

The workshop continues a series of successful events that have been an
excellent venue for practitioners and researchers to discuss latest
and current work; the most recent WoMOs were held at FOIS 2010 and
ESSLLI 2011.

TOPICS include, but are not limited to:

- What is modularity?: kinds of modules and their properties; modules
vs. contexts; design patterns; granularity of representation;

- Logical/foundational studies: conservativity; modular ontology
languages; reconciling inconsistencies across modules; formal
structuring of modules; heterogeneity;

- Algorithmic approaches: distributed and incremental reasoning;
modularization and module extraction; sharing, linking, reuse;
privacy; evaluation of modularization approaches; complexity of
reasoning; implemented systems;

- Applications: semantic web; life sciences; bio-ontologies; natural
language processing; space and time; ambient intelligence; social
intelligence; collaborative ontology development and ontology
versioning.

IMPORTANT DATES

Paper Submission: May 11, 2012
Notification: June 12, 2012
Camera ready: July 1, 2012
Workshop: July 24, 2012

SUBMISSION GUIDELINES:

We welcome submissions on modularity in a broad sense. The workshop is
open to papers of theoretical or practical nature. Submissions should
be of up to 11 pages in length, formatted according to Springer LNCS
style (see http://www.springer.com/comp/lncs/Authors.html), prepared
in PDF format and submitted no later than May 11, 2012, through the
EasyChair Submission System (see
http://www.easychair.org/conferences/?conf=womo2012).

Submitted papers will be peer-reviewed by members of the program
committee. Accepted papers will be made available in the proceedings
to be published electronically in the CEUR Workshop Proceedings series
(see http://www.ceur-ws.org).

(Find the WoMO 2010 and 2011 proceedings here
http://www.booksonline.iospress.nl/Content/View.aspx?piid=16268 and
http://www.booksonline.iospress.nl/Content/View.aspx?piid=20369)

WORKSHOP CHAIRS:

Thomas Schneider, University of Bremen, Germany
Dirk Walther, Technical University of Madrid (UPM), Spain

PROGRAM COMMITTEE:

Kenneth Baclawski, Northeastern University, Boston, MA, USA
Stefano Borgo, Italian National Research Council, Trento, Italy
Oscar Corcho, Universidad Politecnica de Madrid, Spain
Bernardo Cuenca Grau, University of Oxford, UK
Mike Dean, Raytheon BBN Technologies, Ann Arbor, MI, USA
Silvio Ghilardi, Universita degli Studi di Milano, Italy
Michael Gruninger, University of Toronto, Canada
Janna Hastings, EMBL-EBI, Cambridge, UK
Robert Hoehndorf, University of Cambridge, UK
Boris Konev, University of Liverpool, UK
Roman Kontchakov, Birkbeck College, London, UK
Thomas Meyer, Meraka Institute, CSIR, Pretoria, South Africa
Till Mossakowski, University of Bremen, Germany
Immanuel Normann, Birkbeck College, London, UK
Leo Obrst, MITRE, McLean, VA, USA
Adrian Paschke, Free University of Berlin, Germany
David Perez del Rey, Universidad Politecnica de Madrid, Spain
Uli Sattler, University of Manchester, UK
Luciano Serafini, Fondazione Bruno Kessler, Trento, Italy


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/service-orientated-architecture/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/service-orientated-architecture/join
    (Yahoo! ID required)

<*> To change settings via email:
    service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> To unsubscribe from this group, send an email to:
    service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Re: [ZapFlash] Deconstructing Agile

Michael Poulin — 2012-05-04T19:04:00

Fantastique!

After reading "In other words, the users of the software must actually be part of the agile system", I thought that I'd got into a time-machine and had been shifted back to early 90s.

Then I read, "Agile architectural approaches like SOA" and started to scratch my head trying to figure out what was agile to what.

Indeed, "The challenge, of course, is actually building such systems that meet the business agility meta-requirement." In simplified SOA language, it is agility to business needs (at least, this is how OASIS SOA standards define what is service-oriented architecture is about). In other words, a SOA service (to be useful) has to anticipate not changing requirements but particular need of certain category of consumers. When a SOA service is designer, particular requirements of the consumers are unknown. Moreover, the author of the service cannot physically consider all variety of way hoe the service will be used but future consumers. I've believed that this is 101 of Service Orientation theory and it does not require special ZapFlash.

A bit confusing (to me) was "... it’s a property of the system as a whole—what we call an emergent property." What system is meant? Is it an architecture? Unlikely. Is it a service? Then why it is not addressed as such? If it is a SO Ecosystem? Then the statement is incorrect...

Why do we need special ZapThink term "emergent property" if we have "business service", which is an aggregation of manual/human and technical means that help consumers to reach results of executing particular capability? It is the business service that provides agility of technical part to its business part and, as a whole, agility of the service provider (or owner) to the business needs of the market, i.e. business needs of consumers.

Many write this for last 3 years including your humble servant (see the whole book about this: "Ladder to SOE")

- Michael

communicated, poorly understood, or both. Or even if they’re
properly communicated, they change before the project is complete.
Or most aggravating at all, the stakeholder looks at what the
techies have built and says, “yes, that’s exactly what I asked
for, but now that I see it, I realize I want something different
after all.”
each iteration reevaluates and reincorporates the original
requirements with any further input the business wants to
contribute. But even with the most agile of Agile development
teams, the process of building software still falls short. It
doesn’t seem to matter how expert the coders, how precise the
stakeholders, or how perfect the development methodology are, the
gap between what the business really needs and what the software actually does is still far wider than it should be. And while many business stakeholders have become inured to poorly fitting software, far more are becoming fed up with the entire situation. Enough is enough. How do we get what we really want and need from IT?
requirements in a fundamentally different way. Instead of thinking
about what it wants the software to do, the business should
specify how agile it expects the software to be. In other words,
don’t ask for software that does A, B, C or whatever. Instead,
tell your techies to build you something agile.
possible to meet new requirements without having to change the
software. Whether the process inside the box is Agile is beside
the point. Yes, perhaps taking an Agile approach is a good idea,
but it doesn’t guarantee the resulting software is agile.
>

[ZapFlash] Deconstructing Agile

Gervas Douglas — 2012-05-04T17:20:15

    Deconstructing Agile


        Document ID: | Document Type: ZapFlash
        By: /Jason Bloomberg/ | Posted: /May 4, 2012/


Every specialization has its own jargon, and IT is no different---but 
many times it seems that techies love to co-opt regular English words 
and give them new meanings. Not only does this practice lead to 
confusion in conversations with non-techies, but even the techies often 
lose sight of the difference between their geek-context definition and 
the real world definition that "normal" people use.

In our Licensed ZapThink Architect 
<http://t.ymlp349.net/uyjybadamqjhaiaubmarambmuu/click.php> course, for 
example, we spend far too long defining /Service 
<http://t.ymlp349.net/uyjyhafamqjhakaubmatambmuu/click.php>/. This word 
has far too many meanings, even in the world of IT---and most of them 
have little to do with what the rest of the world means by the term. 
Even words like /business/ have gone through the techie redefinition 
process (in techie-speak, /business/ means /everything that's not IT/).

It comes as no surprise, therefore, that techies have hijacked the word 
/Agile/. In common parlance, someone or something is agile if it's 
flexible and nimble, especially in the face of unexpected forces of 
change. But in the world of technology, /Agile/ (Agile-with-a-capital-A) 
refers to a specific category of software development methodology. This 
definition dates to 2001 and the establishment of the Agile Manifesto 
<http://t.ymlp349.net/uyjywacamqjharaubmadambmuu/click.php>, a set of 
general principles for building better software. In the intervening 
decade, however, /Agile/ has taken on a life of its own, as Scrum, 
Extreme Programming, and other Agile methodologies have found their way 
into the fabric of IT.

Such methodologies indubitably have strengths, to be sure---but what we 
have lost in the fray is a sense of what is particularly agile about 
Agile. This point is more than simple semantics. What's missing is the 
fundamental connection to agility that drove the Manifesto in the first 
place. Reestablishing this connection, especially in the light of new 
thinking on business agility, is essential to rethinking how IT meets 
the ever-changing requirements of the business.

*The Paradox of Business Requirements*

How do techies know what to build? Simple: ask the stakeholders (the 
"business") what they want. Make sure to write down all their 
requirements in the proverbial requirements document. Now build 
something that does what that document says. After you're done, get your 
testers to verify that what you've built is what the business wanted.

Or what they used to want.

Or what they said they wanted.

Or perhaps what they /thought/ they said they wanted.

And therein lies the rub. The expectation that the business can 
completely, accurately, and definitively describe what they want in 
sufficient detail so that the techies can build it precisely to spec is 
ludicrously unrealistic, even though such a myth is inexplicably 
persistent in many enterprise IT shops to this day. In fact, the myth of 
complete, well-defined requirements is at the heart of what we call the 
"waterfall" methodology, illustrated in the figure below.

<http://t.ymlp349.net/uyjyqaoamqjhavaubmavambmuu/click.php>



In reality, it is far more common for requirements to be poorly 
communicated, poorly understood, or both. Or even if they're properly 
communicated, they change before the project is complete. Or most 
aggravating at all, the stakeholder looks at what the techies have built 
and says, "yes, that's exactly what I asked for, but now that I see it, 
I realize I want something different after all."

Of course, such challenges are nothing new; they gave rise to the family 
of iterative methodologies a generation ago, including the Spiral 
methodology, IBM's Rational Unified Process, and all of the Agile 
methodologies. By taking an iterative approach that involves the 
business in a more proactive way, the reasoning goes, you lower the risk 
of poorly communicated, poorly understood, or changing business 
requirements. The figure below illustrates such a project.

<http://t.ymlp349.net/uyjyyaiamqjhataubmaoambmuu/click.php>



In the above diagram the looped arrows represent iterations, where each 
iteration reevaluates and reincorporates the original requirements with 
any further input the business wants to contribute. But even with the 
most agile of Agile development teams, the process of building software 
still falls short. It doesn't seem to matter how expert the coders, how 
precise the stakeholders, or how perfect the development methodology 
are, the gap between what the business /really/ needs and what the 
software /actually/ does is still far wider than it should be. And while 
many business stakeholders have become inured to poorly fitting 
software, far more are becoming fed up with the entire situation. Enough 
is enough. How do we get what we /really/ want and need from IT?

*Changing the Way We Deal with Change*

Even the most Agile development teams still struggle with the problem of 
changing requirements. If requirements evolve somewhat during the course 
of a project, then a well-oiled Agile team can generally go with the 
flow and adjust their deliverables accordingly, but one way or the 
other, all successful software projects come to an end. And once the 
techies have deployed the software, they're done.

Have a new requirement? Fund a separate project. We'll start over and 
include your new requirements in the next version of the project we 
already finished, unless it makes more sense to build something 
completely new. Sometimes techies can tweak existing capabilities to 
meet new requirements quickly and simply, but more often than not, 
rolling out new versions of existing software is a laborious, 
time-consuming, and risky process. If the software is commercial off the 
shelf (COTS), the problem is even worse, since the vendor must base new 
updates on requirements from many existing customers, as well as their 
guesses about what new customers will want in the future. The figure 
below illustrates this problem, where the software project represented 
by the box can be as Agile as can be, and yet the business still doesn't 
get the agility it craves. It seems that Agile may not be so agile after 
all.

<http://t.ymlp349.net/uybssaramqjhalaubmazambmuu/click.php>



The solution to this problem is for the business to specify its 
requirements in a fundamentally different way. Instead of thinking about 
what it wants the software to do, the business should specify how agile 
it expects the software to be. In other words, don't ask for software 
that does A, B, C or whatever. Instead, tell your techies to /build you 
something agile/.

We call this requirement the metarequirement of agility 
<http://t.ymlp349.net/uybsuaramqjhataubmaiambmuu/click.php>---a 
/metarequirement/ because agility applies to other requirements: "build 
me something that responds to changing requirements" instead of "build 
me something that does A, B, and C." If we can build software that 
satisfies this metarequirement, then our diagram looks quite different:

<http://t.ymlp349.net/uybseaaamqjhaxaubmadambmuu/click.php>



Because the software in the above diagram is truly agile, it is possible 
to meet new requirements without having to change the software. Whether 
the process inside the box is Agile is beside the point. Yes, perhaps 
taking an Agile approach is a good idea, but it doesn't guarantee the 
resulting software is agile.

*The ZapThink Take*

Sounds promising, to be sure, but the devil is in the details. After 
all, if it were easy to build software that responded to changing 
requirements, then everybody would be doing it. But there's a catch. 
Even if we built software that could /potentially/ meet changing 
requirements, that doesn't mean that it actually /would/---because 
meeting changing requirements is part of how you would /use/ the 
software, rather than part of how you /build/ it. In other words, the 
/users/ of the software must actually be part of the agile system. The 
box in the diagram above doesn't just represent software anymore. It 
represents a system consisting of software and people.

Such software/people systems of systems are a long-standing fixture in 
ZapThink thinking. In fact, ZapThink frequently talks about agility in 
the context of SOA. With SOA, IT publishes business Services that 
represent IT capabilities and information, and the business drives the 
consumption and composition of those Services. In mature SOA 
deployments, policies drive the behavior of Services and their 
compositions. If you want to change the behavior, change the policy. In 
other words, SOA is governance-driven, and governance applies to the 
behavior of both people and technology.

Agile architectural approaches like SOA, therefore, focus on 
implementing governance-driven technology/people systems that support 
changing requirements over time. The challenge, of course, is actually 
/building/ such systems that meet the business agility metarequirement. 
Where in this system do we put the agility? It's not in any part of the 
system. Instead, it's a property of the system as a whole---what we call 
an /emergent property/. If you've been following ZapThink, you've heard 
this story before: business agility is an emergent property 
<http://t.ymlp349.net/uybsmaramqjhaxaubmanambmuu/click.php> of the 
combination technology/human system we call the enterprise.

In other words, we started by deconstructing the notion of Agile and 
ended up with Enterprise Architecture, because what is Enterprise 
Architecture but best practices for designing and building the 
enterprise to better meet changing requirements over time? This is not 
the static, framework-centric EA 
<http://t.ymlp349.net/uybsjadamqjhagaubmazambmuu/click.php> from years 
past that presuppose a final, ideal state for the enterprise 
<http://t.ymlp349.net/uybsbavamqjhafaubmalambmuu/click.php>. We're 
talking about a new way of thinking about what it means to architect 
technology-rich organizations to be inherently agile.

The cases for reuse

remyfannader — 2012-04-30T11:31:17

How to manage reusable assets according architecture layers.
http://caminao.wordpress.com/2012/04/09/cases4reuse/



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/service-orientated-architecture/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/service-orientated-architecture/join
    (Yahoo! ID required)

<*> To change settings via email:
    service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> To unsubscribe from this group, send an email to:
    service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

ISWC 2012 Call for Tutorial Proposals -- Submission Deadline May 6

Oshani Seneviratne — 2012-04-30T10:46:04

------------------------------------------------------------------------
Call for Tutorial Proposals
http://iswc2012.semanticweb.org/call-tutorial-proposals
In conjunction with the
              11th International Semantic Web Conference
               http://iswc2012.semanticweb.org/
              Boston - USA
              November 11-15, 2012
------------------------------------------------------------------------

The International Semantic Web Conference (ISWC) is the primary
conference on the use of semantic technologies on the web and linked
data, constantly attracting a high number of high quality submissions
participants from academia and industry. It brings together
researchers from different areas of computer science, like artificial
intelligence, databases, natural language process, information
retrieval and others that aim at the development and use of novel
technologies for accessing, interpreting and using information on the
web in a more effective way. Besides the main technical program, ISWC
will host a number of tutorials on all major topics related to the
Semantic Web / Linked Data research, enabling attendees to fully
appreciate current issues, main schools of thought, and possible
application areas.


In order to meet these goals, tutorials should address topics that
satisfy the following criteria:

- the topic falls in the general scope of ISWC 2012,
- there is a clear focus on a specific technology, problem or
- application, and
- there is a sufficiently large community interested in the topic.


In particular, we encourage the submission of tutorial proposals on:

- fundamental problems of the Semantic Web/Linked Data such as
ontology mining, heterogeneity, scalability and distribution,
- applications of Semantic Web technologies in specific domains and
trends,
- important enabling technologies and their adaptation to the needs of
the Semantic Web,
- aspects of semantic web research that have been neglected so far,
and
- techniques from other research fields that are of relevance for
Semantic Web research (e.g., machine learning, NLP).


Additionally, we expect tutorials to:

- have practical parts in terms of examples or preferably exercises to
be carried out by the participants

Proposers of accepted tutorials have to prepare a tutorial webpage
containing detailed information about the tutorial.


Submission Guidelines
-----------------------------------
Tutorial proposals should be submitted via EasyChair
https://www.easychair.org/conferences/?conf=iswc2012tutorials as a
single PDF file of no more than 5 pages and should contain the
following information:
- Title
- Abstract (200 words)
- Motivation on why the topic is of particular interest at this time
- Overview of content, description of the aims, presentation style,
potential/preferred prerequisite knowledge
- Indication on whether the tutorial should be considered for a
half-day or full-day
- Intended audience and expected number of participants
- Audio-visual or technical requirements and any special room
requirements (for hands-on sessions, any software needed and download
sites must be provided by the tutorial presenters)
- Data of the presenters (name, affiliation, email address, homepage)
and short description of their expertise, experiences in teaching and
in tutorial presentation


Important Dates
--------------------------
- Event:                              November 11 & 12, 2012
- Tutorial proposal due:        May 6, 2012
- Tutorial Notifications:        May 20, 2012


Chairs
--------------
 Claudia d’Amato, Unversity of Bari
 Thomas Scharrenbach, University of Zurich

Follow ISWC 2012 on Twitter
https://twitter.com/#!/iswcboston


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/service-orientated-architecture/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/service-orientated-architecture/join
    (Yahoo! ID required)

<*> To change settings via email:
    service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> To unsubscribe from this group, send an email to:
    service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Standards for Smart Applications (2nd Call for Papers)

Christian De Sainte Marie — 2012-04-23T17:41:09

(Apologies for cross-posting, if you receive multiple copies of this 
message) 

Standards for Smart Applications (S4SA) is an ECAI 2012 workshop on 
knowledge representation standards and integrating knowledge sources, with 
a focus on bridging across heterogeneous standards, as a way to avoid the 
creation of "knowledge representation silos". 

Web site: http://sites.google.com/site/s4sa2012/ 

============= 
Call for Papers 
============= 
Submission deadline: 28 May 2012 
---------------------------------------------------- 

The objective of this workshop is to promote research and education on the 
combination and integration of knowledge representation standards. 

Here, knowledge representation standards are meant in a broad sense, not 
limited to what is traditionally seen as knowledge representation in the 
Artificial Intelligence and semantic technology communities: this workshop 
will consider integration and bridges between OWL, RIF, RuleML and other 
?traditional? knowledge representation standards, but also with and 
between BPMN, SBVR, XBRL, fact-based modelling standards such as ORM, 
XML-based and non-XML industry standards such as MISMO, HL7, X9, ACORD and 
many more. 

The workshop will gather researchers and practitioners interested in 
knowledge representation standards and in the standard-based integration 
of multiple knowledge representations for the development of smarter 
applications and for the broader adoption of knowledge-based technology. 

Papers and contributions are invited on all the theoretical, technical and 
practical aspects of combining multiple knowledge representation 
standards, such as, but not limited to: 
- Semantics for combinations of knowledge representation standards 
- Technology that combines multiple standard knowledge representations 
- Mapping and translation between standards 
- Extending VS combining standards 
- Requirements on new standards and extensions of existing standards to 
improve inter-operability of diverse knowledge representation paradigms 
- Experience with standard-based integration of multiple knowledge 
representations 
- New, emerging and proposed knowledge representation standards (and how 
they fit in the bigger picture) 
- Use cases and requirements with standard-based integration of multiple 
knowledge representations 
- Performance and scalability issues related to standard-based integration 
of multiple knowledge representations 

For complete information about the workshop and the call for papers, check 
the workshop Web site: 
http://sites.google.com/site/s4sa2012/ 

For the program committee, 
Christian de Sainte Marie

IBM
9 rue de Verdun
94253 - Gentilly cedex - FRANCE
Tel./Fax: +33 1 49 08 29 81


Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie IBM France
Siège Social : 17 avenue de l'Europe, 92275 Bois-Colombes Cedex
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 639.291.962.10 ?
SIREN/SIRET : 552 118 465 03644 - Code NAF 6202A

Re: Earls on Defining SOA Infrastructure

Michael Poulin — 2012-04-21T22:31:32

My point is that ESB-creature is not the SOA ESB pattern, it includes a combination of patterns implemented by messaging, semantic/mapping transformers, integration mediators/brokers and registries/repositories. 


In the organisations where SOA Patterns are implemented by different systems (listed above) , an ESB-system is a wast of resources and not needed.

I do not see real difference between an enterprise application integrationand department application integration besides differences in integration policies.

Also, "using an ESB for service orientation"is one of the worst things that can happen to technology and IT if it "uses" it. 

As we know, no one system can convince Business to share their resources. This is not because of IT but because of Value Chain/flow mentality and managerial ownership taught in the MBA programmes. Realisation of service-orinentation  must and slowly moves into Business and it is the only factor that can override process-oriented mindset and facilitate business units to share services (but these units per se will be quite different from the ones that we see today). "...the need for communication of the strategic objective " will remain a need only if middle-level management continues operate in processes.

- Michael





        application, vertical and horizontal integration needs using an
        enterprise service
        bus (ESB). 
>

Re: Earls on Defining SOA Infrastructure

Ashraf Galal — 2012-04-21T12:51:59

ESB is a major components of SOA infrastructure.
In order to address the business unit and their corresponding 
application, vertical and horizontal integration needs using an 
enterprise service bus (ESB).

We have to have message flows, mediation, routing, and transformation 
using the ESB and a registry and shared services.

*_For example, To achieve the strategic goal:_“to /improve integration 
both in efficiency/ (e.g., reduced cost of integration and improve 
productivity) and /effectiveness /(e.g., improve flexibility and respond 
faster to business demands*).”

We have to adopt an enterprise service bus (ESB), registry and shared 
services.

Many in the IT department may not understand the difference between 
*enterprise application integration* versus *using an ESB for service 
orientation*.

In the business units and their liaisons, resistance may exist to 
sharing services because they see a potential negative impact on the 
reliance of other teams outside control of their vertical business unit 
for project delivery.

Others in the organization might not understand SOA, or they might have 
both negative and positive opinions about it.

Still others might have seen the failure of past projects that promoted 
sharing of software assets.

In each case, this points to *the need for communication of the 
strategic objective* before, during, and after the implementation of the 
ESB and its corresponding processes and organizational changes.


All the best

Ashraf Galal




On 20/04/2012 9:21 AM, Michael Poulin wrote:

Re: Earls on Defining SOA Infrastructure

Michael Poulin — 2012-04-20T13:21:51

The  2011 Readership Survey results are not surprising - people say what they do, not think. It is known for years that ESB is not needed if an enterprise already has messaging, data transformation and security-and-application servers...

I personally believe that the minimal SOA execution infrastructure should include only registries and repositories that are specially crafted for services.

Also, toMike Rosen's comment, if we would go after what people referred to regarding SOA, we were never created service-oriented architecture.


- Michael





From: Gervas Douglas <gervas.douglas-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>

To: service-orientated-architecture-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
>

Earls on Defining SOA Infrastructure

Gervas Douglas — 2012-04-20T10:55:51

  <<Is it possible to define SOA infrastructure?

Alan Earls <http://searchsecurity.techtarget.com/contributor/Alan-Earls>

  * E-mail
    <http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&asrc=EM_USC_17087237&Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&#>
  * Print
    <http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?vgnextfmt=print>
  * A
    <http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&asrc=EM_USC_17087237&Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&#>
  * AA
    <http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&asrc=EM_USC_17087237&Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&#>
  * AAA
    <http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&asrc=EM_USC_17087237&Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&#>
  * LinkedIn
    <http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&asrc=EM_USC_17087237&Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&#>
  * Facebook
    <http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&asrc=EM_USC_17087237&Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&#>
  * Twitter
    <http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&asrc=EM_USC_17087237&Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&#>
  * Share This
    <http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&asrc=EM_USC_17087237&Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&#>
  * RSS <http://searchsoa.techtarget.com/rss/ContentSyndication.xml>
  * Reprints <http://reprints.ygsgroup.com/m/techtarget>

What do people mean when they say SOA infrastructure? Service-oriented 
architecture may be a way of thinking, but it is also represented in a 
range of architectural practices such as message queuing middleware and 
enterprise service bus (ESB). Certain types of software may be used like 
Legos in a typical SOA project, but there is little consensus on what 
counts as SOA infrastructure.

Indeed, SearchSOA.com recently conducted a 2011 Readership Survey that 
solicited views on which of the contenders mattered most. The range of 
responses was striking as was the lack of any clear "winner." For 
instance, none of the seven different technologies described earned more 
than a 50% score and the lowest scores were in the mid-20% range. 
(Survey choices were message queuing middleware; enterprise service bus 
(ESB); publish & subscribe middleware; SOA and Web services governance; 
test or management software; services registry/repository; service 
orchestration tools; and SOA appliances/XML gateways.)

In other words, there are a lot of choices and little agreement about 
what's best. However, of the choices out there, message queuing 
middleware seems to be leading the pack, followed closely by ESB 
(see*Figure 1*).

<http://cdn.ttgtmedia.com/rms/onlineImages/SSOA-AlanEarlsSurvey-MobileFigure3-SM2.png> 

*Figure 1*: Message queuing leads technologies for SOA infrastructure; 
others are close behind.

Mark Eisenberg, a former member of Microsoft's Azure team and now 
director of Fino Consulting says it is no wonder there is confusion -- 
SOA is simply too big of a concept. "I think that's why it has had 
limited success in the enterprise," he says. In his view, ESBs and 
similar kinds of technology are implementation details. "ESB is a way 
for services to communicate without having to know the specifics of how 
to contact the services," he says. In that sense, he says, ESBs are 
simply an infrastructure element.

The long list of possible SOA infrastructure elements can make 
implementation difficult. Eisenberg says that the original "dream" for 
SOA was that you would build a service, you would register it, and then 
some other service that needed that functionality would simply "go there 
and say, I need that and simply connect to that service." However, in 
fact, that represents a complex undertaking. In Eisenberg's view, there 
is no simple "right" answer to the question of which technology is most 
relevant to the concept of SOA infrastructure. "Message queues are a 
very fundamental computer concept and services buses are also very 
fundamental to SOA," he says.

    The long list of possible SOA infrastructure elements can make
    implementation difficult.

A similar take on the question comes from Mike Rosen, an industry expert 
in business architecture, SOA and enterprise architecture and a practice 
director for Business and Enterprise Architecture at the Cutter 
Consortium (an IT Research Firm). He says, in general, when people refer 
to SOA infrastructure, they mean the product platform that the SOA runs 
on, such as an ESB. "Occasionally, if taken from a high level business 
perspective, they mean the entire SOA stack, including the business 
services, but that would be an unusual interpretation of the term," says 
Rosen. Still, "interpretation" is what's at issue.

"While ESB is probably the most relevant, it of course depends on the 
context of the usage and requirements," he adds. Further, Rosen points 
out that ESB and queuing are not architectural 'practices', but rather 
an implementation of the infrastructure. "Also, virtually all ESB 
products include queuing as an underlying capability," he adds.

So, is there a way to parse the SOA and infrastructure concept a little 
further? Possibly. According to Nate Minshew, enterprise 
architect/principal consultant at Asynchrony Solutions, Inc., who relied 
on Department of Defense definitions related to SOA to provide a degree 
of clarity on a recent project. "In our project we built a service 
taxonomy so we could classify the different services to provide a 
mechanism to quickly identity a service based on what functional purpose 
it had. The taxonomy was primarily a high level category of process 
services.

Minshew says decisions about infrastructure were based on the same 
standards taxonomy. "We wanted to identify specific taxonomy and DOD had 
certain standards mandated from the DOD Standards Repository. A lot of 
those were fairly incomplete, he says.  but there was room to make 
recommendations based on them such as SOAP 1.2, PKI standards and so 
on," he explains.

In turn, says Minshew, he hoped to get clearer definitions of 
infrastructure components, like "what is an ESB?" "We found that a lot 
of vendors market products as ESBs but what they call an ESB also has 
services and governance and management tools -- we wanted to look for 
more granular pockets of technology. Our definition of an ESB was the 
messaging infrastructure and the ability to do composition for web 
services and the routing and processing that goes on," he says.

In short, Minshew notes, infrastructure can take many forms and no one 
term suffices to describe it.>>

*You can find this at: 
http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&asrc=EM_USC_17087237&Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible& 
<http://searchsoa.techtarget.com/feature/Is-it-possible-to-define-SOA-infrastructure?utm_content=UNSC_WW_sSOA_is-it-possible&asrc=EM_USC_17087237&Offer=mn_eh042012SSOAUNSC_UNSC_WW_sSOA_is-it-possible&>
*

*Gervas*

Shah on MDM

Gervas Douglas — 2012-04-19T15:50:22

    <<Why Master Data Should Start with the Business Process, Not the Data

/byLoraine Lawson 
<http://www.itbusinessedge.com/cm/people/LoraineLawson>, IT Business Edge
10-abr-2012 17:33:37/

*Jignesh Shah <http://www.linkedin.com/in/jshah0209>*(< at >*jshah0209 
<https://twitter.com/#%21/jshah0209>*),*Software AG 
<http://www.softwareag.com/>*'s vice president of business 
infrastructure products and solutions, discusses with IT Business Edge's 
Loraine Lawson the benefits of taking a process-driven approach to 
master data management, as opposed to a data-driven approach. (In the 
interest of disclosure, this month Loraine Lawson began writing 
for*B2B.com <http://www.b2b.com/>*, a business-to-business site owned by 
Software AG and overseen by Shah's division. However, this interview was 
scheduled in response to an ITBE blog post Lawson wrote on*marrying BPM 
with MDM 
<http://www.itbusinessedge.com/cm/blogs/lawson/integrating-management-adding-master-data-to-business-process-is-slow-going/?cs=50011>*.)



Jignesh Shah
    VP of Business Infrastructure
    Software AG

*Lawson:*I know that in 2010, towards the end of the year, Software AG 
--- which is known for its BPM tool --- bought Data Foundations, an MDM 
company. How do you see BPM and MDM coming together?

*Shah:*What's interesting is that the process-driven MDM story at 
Software AG precedes Data Foundations, and not a lot of people know this 
because it actually stems from the IDS Scheer side of the house. 
Definitely we put process-driven MDM messages on the forefront for the 
Data Foundation acquisition, but IDS Scheer, which became a part of 
Software AG in 2009 and has been around for about 20 years, has been 
doing process-driven MDM for about 15 years.

IDS Scheer started out as a process improvement company and a lot of 
their practice around process improvement was around SAP 
implementations. So they took a very process-driven approach to 
implementing SAP.  They would document customers' processes, how they 
could be changed, modified, automated, and then use all that information 
to then guide the implementation of SAP systems and modules.

Even with SAP, the databases and the data models are not homogenous, so 
frequently they would implement master data management within SAP 
modules or between SAP modules and other systems that clients may have. 
And guess what? Being a process company, they adopted a process model to 
do MDM as well. Initially, it started out as an extension of just 
process thinking, but very soon they actually had developed a whole 
methodology and discipline around how MDM can be implemented and tied to 
process improvement initiatives. It's a six-point methodology starting 
from strategy, organization, process, data, applications and governance.

The article that you wrote and some of the things that Andrew White of 
Gartner writes, they often kind of equate process with BPM, which maybe 
it's true these days, but you know processes have been around as long as 
we've had the human race, right?

So, BPM and processes are not one and the same, is the point I'm trying 
to make. And IDS Scheer was doing process improvement before BPM became 
fashionable and they've been doing process-driven MDM before people 
started talking about marrying BPM and MDM, shotgun or otherwise. So 
that's the backgrounds. So we've been doing this part of the initiative 
for about 15 years, and then when we acquired in 2010 OneData, it just 
made natural sense to say, "Hey, we're going to go to market with this 
tool and with the methodology that we have developed over the last 15 
years as a combined, unified offering," and that's how we came about the 
process-driven MDM message, the process-driven MDM dummies book and 
that's how we go to market these days.>>


*You can read this at: 
http://www.itbusinessedge.com/cm/community/features/interviews/blog/why-master-data-should-start-with-the-business-process-not-the-data/?cs=50188&utm_source=itbe&utm_medium=email&utm_campaign=EEB&nr=EEB 
<http://www.itbusinessedge.com/cm/community/features/interviews/blog/why-master-data-should-start-with-the-business-process-not-the-data/?cs=50188&utm_source=itbe&utm_medium=email&utm_campaign=EEB&nr=EEB>
*

*
Gervas*


Ger

2nd CfP: WoMO 2012 - 6th Int'l Workshop on Modular Ontologies

WoMO 2012 — 2012-04-19T12:41:16

========================================================
     6th Int'l Workshop on Modular Ontologies (WoMO)
              Graz, Austria, July 24, 2012
           held in conjunction with FOIS 2012

             --- Second Call for Papers ---
========================================================
           Submission deadline: May 11, 2012
========================================================

INVITED SPEAKERS:

* Thomas Eiter, Vienna University of Technology, Austria
  Title TBA

* Luciano Serafini, Fondazione Bruno Kessler, Trento, Italy
  Multi context logics: a formal support for structuring knowledge and
beliefs (Tentative title)


http://www.informatik.uni-bremen.de/~ts/womo2012

MODULARITY, studied for years in software engineering, allows
mechanisms for easy and flexible reuse, generalization, structuring,
maintenance, design patterns, and comprehension. In formal and applied
ontology, modularity is central to reducing the complexity of
designing and understanding ontologies, and to facilitating ontology
verification, reasoning, development, maintenance and integration.

Recent research on ontology modularity shows substantial progress in
foundations of modularity, techniques of modularization and modular
development, distributed reasoning and empirical evaluation. These
results provide a solid foundation and exciting prospects for further
research and development.

The workshop continues a series of successful events that have been an
excellent venue for practitioners and researchers to discuss latest
and current work; the most recent WoMOs were held at FOIS 2010 and
ESSLLI 2011.

TOPICS include, but are not limited to:

- What is modularity?: kinds of modules and their properties; modules
vs. contexts; design patterns; granularity of representation;

- Logical/foundational studies: conservativity; modular ontology
languages; reconciling inconsistencies across modules; formal
structuring of modules; heterogeneity;

- Algorithmic approaches: distributed and incremental reasoning;
modularization and module extraction; sharing, linking, reuse;
privacy; evaluation of modularization approaches; complexity of
reasoning; implemented systems;

- Applications: semantic web; life sciences; bio-ontologies; natural
language processing; space and time; ambient intelligence; social
intelligence; collaborative ontology development and ontology
versioning.

IMPORTANT DATES

Paper Submission: May 11, 2012
Notification: June 12, 2012
Camera ready: July 1, 2012
Workshop: July 24, 2012

SUBMISSION GUIDELINES:

We welcome submissions on modularity in a broad sense. The workshop is
open to papers of theoretical or practical nature. Submissions should
be of up to 11 pages in length, formatted according to Springer LNCS
style (see http://www.springer.com/comp/lncs/Authors.html ), prepared
in PDF format and submitted no later than May 11, 2012, through the
EasyChair Submission System (see
http://www.easychair.org/conferences/?conf=womo2012 ).

Submitted papers will be peer-reviewed by members of the program
committee. Accepted papers will be made available in the proceedings
to be published electronically in the CEUR Workshop Proceedings series
(see http://www.ceur-ws.org ).

(Find the WoMO 2010 and 2011 proceedings here
http://www.booksonline.iospress.nl/Content/View.aspx?piid=16268 and
http://www.booksonline.iospress.nl/Content/View.aspx?piid=20369 )

WORKSHOP CHAIRS:

Thomas Schneider, University of Bremen, Germany
Dirk Walther, Technical University of Madrid (UPM), Spain

PROGRAM COMMITTEE:

Kenneth Baclawski, Northeastern University, Boston, MA, USA
Stefano Borgo, Italian National Research Council, Trento, Italy
Oscar Corcho, Universidad Politecnica de Madrid, Spain
Bernardo Cuenca Grau, University of Oxford, UK
Mike Dean, Raytheon BBN Technologies, Ann Arbor, MI, USA
Silvio Ghilardi, Universita degli Studi di Milano, Italy
Michael Gruninger, University of Toronto, Canada
Janna Hastings, EMBL-EBI, Cambridge, UK
Robert Hoehndorf, University of Cambridge, UK
Boris Konev, University of Liverpool, UK
Roman Kontchakov, Birkbeck College, London, UK
Thomas Meyer, Meraka Institute, CSIR, Pretoria, South Africa
Till Mossakowski, University of Bremen, Germany
Immanuel Normann, Birkbeck College, London, UK
Leo Obrst, MITRE, McLean, VA, USA
Adrian Paschke, Free University of Berlin, Germany
David Perez del Rey, Universidad Politecnica de Madrid, Spain
Luciano Serafini, Fondazione Bruno Kessler, Trento, Italy


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/service-orientated-architecture/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/service-orientated-architecture/join
    (Yahoo! ID required)

<*> To change settings via email:
    service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org 
    service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> To unsubscribe from this group, send an email to:
    service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/