[service-orientated-architecture] Paranoia Oriented Architecture

[Todd Biske]

I thought my latest blog entry might stimulate some discussion on business drivers for SOA.  Admittedly, my items are of the most basic nature, but I also think that the typical developer doesn't think about things like what an acquisition or merger might mean.  I'm hopeful that all of you will have more insight to share.    If not, we can have fun with the first paragraph.  I've copied it for your convenience.  -tb ----- I received my copy of Service Orient or Be Doomed by Jason Bloomberg and Ron Schmelzer of ZapThink earlier this week. I'm through the first 50 pages, and it certainly has my interest, since it is touted as a business book about business concepts, yet, in their own words, it's written by a couple of technologists. Before I get to the subject of this blog, one warning on the book. Jason and Ron seem to have gone to extremes to follow up with the title. In addition to already being everywhere by virtue of the number of times they're quoted, the next time I went to Amazon after purchasing the book, there was a photo of Ron, courtesy of Amazon's new "plog" feature, asking me for feedback on the book. I'm wondering now that if I don't service orient everything, either Jason or Ron will keep appearing at bizarre places. I'll go to buy milk on my way home from work, and they'll be in the dairy case. I'll go out in the morning to get the paper at they'll be at the end of my driveway. This could get scary. Anyway, on to the theme of the blog. The book already has me thinking about the business side of SOA, and I haven't even reached the sections that really deal with it. We all know that applying service-oriented principles to tactical projects runs a risk of creating JBOS- Just a Bunch Of Services. If we don't take look at the broader business picture, we won't reach our goals. Unfortunately, we like to stay in our comfort zone of IT. With all the best intentions, the IT workers on the project begin to ask "What if?" as part of the service interface design. It is likely that this will broaden the scope of the interface, but there's no guarantee that this will yield an interface any more appropriate than if the IT team had just looked at the project requirements at hand. This pattern of asking "What If?" may result in a number of modifications to the interface that are simply the result of a paranoid influence- Paranoia Oriented Architecture! The decisions are all rooted in possible events that may occur, without an understanding of the core business drivers that could create those events. To that end, what are the common business drivers/strategies that may point clearly to areas for service interfaces? Here's some obvious ones I've thought of, leave some comments or trackback with others that come to mind. Growth by merger/acquisition. Clearly, this has implications when the core processing systems of the two companies need to be combined to eliminate redundancies. The exact areas of interface will vary by company. Improved customer experience. How do you improve customer experience? One way is through personalization. Personalization requires gathering information about the customer, and then integrating services based upon their profile. Once again, if things aren't broken down into composable elements, you'll only get so far. This also begins to branch into cross product sales, such as is common in the insurance industry Reduce costs through by eliminating redundancies. While redundancies can be created through mergers and acquisitions, there are plenty of redundancies that may have already existed prior to the merger. Certainly this was the case in the dot-com bubble, as companies tried to establish an internet presence. Improved efficiencies through self service. This is very similar to improving the customer experience, however, this may be directed completely internally. My company is a service provider. Okay, this is a no-brainer, but may not be as easy as it looks. What if the service you're providing is more of a human-based service? I would still argue that sooner or later, someone will want to integrate their system with yours rather than go through the human channel. Regulatory drivers. Regulations create new auditing requirements. The easiest place to capture things are at the interfaces between the systems, i.e. the services. If we don't have services in the right place, the cost associated with regulatory compliance will be high. If you're interested in this, another book besides Service-Orient or Be Doomed is Services Blueprint: A Roadmap For Execution by Ravi Kalakota and Marcia Robinson. They list ten focal points that include the few I've listed here and then some. SPONSORED LINKS Computer software Computer aided design software Computer job Soa Service-oriented architecture YAHOO! GROUPS LINKS  Visit your group "service-orientated-architecture" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.