Envisioning and shaping the future of work and business.

Tuesday, June 17, 2008

Interesting SOA (and EIM) readings

9:48:00 AM Posted by Oscar Berg , No comments
Here are two interesting SOA readings from The SOA Magazine.

"SOA in the DoD" by Howard Cohen and Josh Taylor:

The United States Department of Defense (DoD) understands the value of information. While this understanding is very clear, it does not yet have a fully functional or satisfactory prescription for the strategic and technical ailments that pains its communities. Service-oriented architectures are not magic but the concepts, if applied with logic, leadership and continuity, make sense.

Information superiority is key to its success, not only in relation to the military but also for its position as a global leader...//...The primary obstacle to successfully leveraging this data is that it has simply become detached from consumers that have the right and authority to access and use it.

The DoD recognizes that information must be visible, accessible and understandable to the right people at the right time, which is a very serious ailment.

When it comes to leveraging the what SOA has to offer, the real question is not tied up in the technical methodology used to create a mature service-oriented constructs because these methodologies are well-vetted. It is in our leadership's ability to take these methods and apply them in a meaningful way.

"The Benefits of a Data Abstraction Layer for SOA" by Kirstan Vandersluis:

Companies seeking increased agility and reuse through service-oriented architecture quickly find that making sense of widely distributed and disparate data is a major roadblock to achieving the benefits of SOA. To build a successful SOA, architects need to pour the foundation first – they need to begin with a data abstraction layer that makes sense of an otherwise chaotic data landscape.

Data abstraction leads to the ability to leverage physical data, no matter how it's structured, as new, logical schemas that exist only in middleware – creating a common data layer that architects can restructure as needed, rather than making costly changes to the physical database or core services.


Post a Comment