Joe McKendrick, ebizQ's SOA in Action Blogger, is a nationally published author and consultant
with deep knowledge and insights regarding trends and developments in
the technology industry. He is a contributing editor to a number of
national and international publications and Websites including
Database Trends & Applications, ZDNet, and Webservices.Org. He also
serves as analyst for Evans Data Corp., and is lead analyst for Evans'
Web services and enterprise development management issues surveys.
SOA in Action Blog
|
« BPM is from Mars, SOA is from Venus | Main | 'Visionary Architects' Will Lead SOA Charge » January 18, 2007Crossing the Chasm From JBOWS to SOA Dave Linthicum picked up on my JBOWS (Just a Bunch of Web Services) discussions and, in a recent podcast, connected the dots between JBOWS and SOA. Dave observed that many organizations he's visited thought they had an SOA, but were, in reality, still in the JBOWS stage, in which they are simply Web service-enabling back-end systems. There's nothing wrong with JBOWS, as it's a first step toward SOA, Dave says. "Whether you want to call that an SOA or not, that's up to you," he said. But, "in my mind, you're not really getting to the value of SOA." Unlike Web service-enabling systems, SOA "is a systemic change in the way your do enterprise architecture -- not something you can do in a couple of months project," Dave says. "It's going to take a long-term commitment to changing the way you're doing enterprise architecture, so that it aligns with something that's more agile." In all likelihood, a JBOWS architecture is not orchestrated, does not have a registry, has no process-based testing, does not reuse the services, and has no management tools. Web services often are deployed and managed on a piecemeal basis by enlightened individuals or departments that are attempting to do end-runs around calcified management structures. But this is where many organizations stand. Dave poses some questions to determine whether you are building a JBOWS, or a true SOA: - Are the services a true representation of the core behaviors found in your key enterprise systems, as well as new services required to provide other critical behaviors? - Have those services been abstracted for most foreseeable uses? - Are the services combinable into composites, and are those composites well defined? - Is there a plan for governance and security, managing the use the services? - Are both the information and services abstract-able to an orchestration/process layer for configuration-oriented agility of most of the IT assets? - Is your information/data managed in such a way that you're loosely coupled from the underlying physical schemas? Dave raises some good points about the role of of SOA in data management, enabling sites to "take big messy databases and make them look less messy." In most data centers, "the physical back-end databases are messy, and, ultimately, not combined around logical entities such as sales, orders, transactions, and employees. We do this as a mechanism for loosely coupling the local representation of the data from the underlying physical representation. It actually enhances agility." If you are still stuck in the JBOWS stage, don't despair, Dave adds. "Not to worry, JBOWS can be a good start towards a SOA. Just know, you're not there yet." Posted by joemckendrick in | Digg This | Add to del.icio.us Trackback Pings TrackBack URL for this entry:
|
