Todd Biske: Outside the Box

Archive for the ‘SOA’ Category

Dave Linthicum had a great quote on his eBizQ blog:

Integration should be a configuration exercise, not a programming exercise, especially when considered in the context of a SOA.

While it may be true that some integration still needs to be programmed, we should be striving for configurable integration. As standards are adopted and incorporated into more and more systems, we can get there.

There’s a lot more to Dave’s statement, however. If you read between the lines, the message is that to really achieve the agility touted by the SOA pundits, the things that need to be touched when a business change occurs should be configured, not coded. Coding is a longer exercise than configuring, in most cases. In order to reach this goal, tools will need to continue to improve. At the same time, we can’t lose sight of the importance of testing. The promotion cycles associated with the deployment of a coded solution typically require extensive testing in order to enter an environment. In the case of a configuration change, that may not happen, but in the future, the impact could be catastrophic, as ZapThink analyst Jason Bloomberg called out in his ZapFlash, SOA Governance and the Butterfly Effect.

The point of all of this is that if you are an Enterprise Architect leading an adoption of SOA, you need to make sure that you’re making the appropriate things configurable, geared toward your operations staff, and using your developers for the most important things, developing business services.

Congratulations to my friend, Brenda Michelson, on her new blog on eBizQ, Business Driven Architect. Brenda is the “architect-in-residence” for the Patricia Seybold Group, and was kind enough to appear at a workshop in St. Louis a few months back, presenting some of her research on SOA.

Her most recent posting lists some practitioners in business-driven architect positions. A few of these are on my blogroll, while I hadn’t heard of some of the others. Now I have, and have added them to my subscriptions. Personally, these practitioners are the ones I enjoy reading the most. Perhaps it is because I’m a practitioner myself, so the issues they discuss hit home. So thanks, Brenda, and I look forward to hearing what you have to say!

James McGovern asks why more enterprise architects aren’t speaking at industry conferences? As an enterprise architect who has presented at an industry conference, I offer the following opinions:

• As James suggests, the conference chairs don’t have a good network of practitioners. I established my contacts not through my employer, but through participation in the online community on my own time. Those enterprise architects that don’t do this go unknown. I, like James, would love to see more participation from our peers.
• On the other side of the equation are the enterprise architects themselves. Rightly so, their primary interests are in helping their company. Their thought leadership needs to be directed internally, first. This is the same reason why you’re far more likely to see a vendor, consultant, or analyst quoted in the press than an enterprise architect or other corporate practitioner. Unless you happen to be one of the lucky few who work at a company with a very liberal external communications policy, it can be very difficult to get approval for outside communications.

I consider myself very fortunate to have had the opportunity to speak at industry conferences in the past, and in the future. I am a strong proponent of giving in order to receive. The more willing I am to share my knowledge, the more likely people will open up to me and share their own knowledge. I’m of the opinion that most companies have people just as smart or even smarter than myself, and therefore, that means they’re probably thinking about many of the same things that I am, at least from a technology perspective. It’s not a competitive advantage situation if we’re simply discussing the merits of open source software versus commercial software; Java, C#, and Ruby; etc.

Thank you Phil Wainewright! Phil recently posted a blog on ZDNet titled: “It’s the user experience, stupid”. It’s nice to see the “long-neglected backwater of usability” getting some well deserved attention.

The Business Week article that Phil mentions was particularly interesting because it mentions “the natural advantage” that companies like SalesForce and NetSuite have because of their ability to track all activities going on in their solutions. So what can we learn from this? Is this about usability? In part, it is. While I’m sure these companies are performing usability tests, nothing beats actual field observation when it comes to usability. In the setting of a usability lab, if you’re fortunate enough to have one, you can glean a lot of excellent information. Unfortunately, it’s still a lab setting, and is largely dependent on your ability to get representative users. Unfortunately, we also can’t go out on observe each and every single user.

In the absence of field observation, the next best thing is to collect as much information we can from the solution itself. If you do this with a desktop solution, the spyware police will be all over you, regardless of how good your intentions were. If you host the solution, all bets are off.

So how does this tie into SOA? It ties into SOA for two reasons. First, SOA is about taking a more granular approach to the entry points into our solutions. By decomposing the problem down into independently maintained pieces, additional entry (integration) points have now been created. Every entry points represents a new location to collect metrics. Secondly, if you choose to use XML to represent the messages for your service interchanges, the opportunity exists to glean information from those messages (all the more reason to make sure you’ve encrypted all elements of the messages for which privacy must be maintained). Through analysis of this information, we can learn more about the service consumers and their usage patterns. Voila, there’s your field information. Need another example? Head over to IT Conversations and listen to Nathan Eagle’s presentation from Where 2.0 on what information he was able to glean simply by monitoring the location of cellphones, and the cellphones in proximity that were detected via Bluetooth.

Now there are obvious privacy concerns with the collection of any information. There are also clear benefits to the collection of metrics through management infrastructure. The key point of all of this, however, is that the better you are able to understand the needs of your customers, whether they are humans sitting in front of their web browser, or other systems issuing web services requests, the better solutions you’ll be able to provide. It’s not simply about collecting the information, but about collecting and using the information to make things better.

In between the recent (and completely unnecessary, in my opinion) debate over Web 2.0 and SOA, a more pessimistic tone toward SOA has begun to emerge. Joe McKendrick recently discussed this in his ZDNet blog, “Is SOA ready for the ‘slope of enlightenment?'”

The pace of things that the press, analysts, and vendors like to push is absolutely ridiculous, and increasingly frustrating. Unfortunately, it’s the way things work. Simply writing this blog has given me some exposure to this world. It is no easy task to continue to come up with interesting SOA related things to discuss on this blog. Kudos to bloggers like James McGovern who are posting every single day, and on the whole, keeping it interesting. I’m doing it on my own time, with only a goal of sharing information with experts in the community. Imagine if I was actually trying to make a living based on this information. In order to keep it interesting, you either have to provide a new spin on the same old information, or take the emphasis off of the information and focus it on the presentation. The most successful path is to do both: continue to look for a new angles (and new information), while doing so in a manner that keeps people interested.

On the flip side, there are those of us that are actually trying to adopt SOA within an enterprise. What’s a realistic timeframe to do so? It certainly isn’t 6 months, and I’d be hard pressed to believe that it can be done in a large organization in 18 months. Let’s face it, unless you’ve already taken some of the first steps toward SOA prior to the recent hype cycle, we’re talking about an effort that will take years, not months. It’s hard to market something successfully for that long of a timeframe. A case study that states that a company is 40% of the way there is less interesting than one that makes it appear that a company is 100% of the way there.

As companies are in the middle of their adoptions, comments about the “trough of disillusionment” actually make it more difficult for organizations to be successful due to management by magazine. The marketing hype continues the trend of unrealistic expectations, too much focus on short term gains, and a lack of strategic planning. For once, it would be nice if technology adoption had expectations like the drug discovery process. It takes years, often more than 10, to bring a successful drug to market. When a potential lead compound is found by a company researching cancer cures, there is no huge marketing hype. The lead compound merely goes to the next stage in a long, long process. Only when some form of clinical trial success begins to occur does the marketing machine come into play.

While I’m certainly not advocating a turtle’s pace in SOA adoption efforts, I am advocating a steady, managed approach. There are technology trends that will provide short term benefits, and there are technology trends that are broader and more strategic in nature. A company needs to leverage both to successfully use technology for competitive advantage. Just because it is technology-based, doesn’t mean that it can be implemented faster than any other strategic initiative.

A friend of mine, Fred Domke, blogged about using a B2B scenario as an SOA pilot. In a previous posting, I discussed my opinions on what constitutes a good pilot. The key item that I mentioned was choosing something that will expose the organization to the cultural changes associated with becoming a service provider.

In this case, I don’t agree that a B2B scenario makes for a good pilot. I agree completely that B2B scenarios are great applications for SOA, but I don’t think they’re going to introduce an organization to the cultural changes. The first problem is that a B2B integration may not involve the cross-organizational concerns that arise. Of the case studies/presentations I’ve seen, the B2B integration scenarios only involved one organization (at least on one end of the integration). That organization was already acting as a service provider, so there is no culture change needed. Yes, there may be some inefficiencies in the integration processes, but outside of some incremental improvements, will the use of standards-based integration technologies in this scenario provide the results for an adoption of SOA across the entire enterprise?

I think there are far more problems on the inside of the firewall that require the cultural changes associated with SOA for resolution. Companies that are doing business together already know that they must work together. Ironically, sometimes it’s easier to get two companies to work together than it is to get two departments within a company to work together. By all means, apply SOA to your B2B integration scenarios. You’d be nuts not to. But to really see the benefits, it needs to be applied inside the firewall.

Many pundits have compared the adoption of SOA to the adoption of object-oriented programming or other development technologies. One of the things that I don’t like about this is that these comparison are rooted in the technology side of things. While I enjoy new technology as much as the next engineer, I tend not to get excited over technology for technology’s sake.

My friends and colleagues know that I have a background in human-computer interaction, usability, and user interface design. The application of technology to the problems facing the end users has always interested me. It is precisely this interest that makes SOA so appealing to me. If I had to compare adoption of SOA to something, I’d compare it to an adoption of user-centered design and usability techniques based upon the work of Jakob Nielsen, Larry Constantine, and others. I was originally introduced to these concepts in 1994, and it’s somewhat disappointing that it never achieved the hype that SOA currently has.

As I see it, in the application focused world that we’re migrating from, a key differentiator is the ability of the user interface of those applications to meet the needs of the end user in a manner that was intuitive. This means that the context of the application needed to match the context of the business process being executed. Hmm… that sounds vaguely familiar. With SOA, we’re now extending that concept to the business tier. The truly successful service providers will differentiate themselves by providing business services that meet the needs of the service consumers. While usability techniques aren’t needed to do this, the concepts embodied in user-centered design will. The key to successful user interface design is the involvement of the user. Likewise, the key to successful service interface design will be the involvement of the service consumer.

Just as I felt that usability and user-centered design created an opportunity for companies to leap frog their competitors, I think SOA creates that same opportunity. They both have the common thread of trying to make our technology better match the needs of the end users- the business. The better understanding of the business, and the better we’re able to incorporate that knowledge into the design process, the more successful the SOA adoption will be.

So, you want to adopt SOA? What exactly will it mean to your IT organization? Previously, you were an application provider to your business customers. Now, you still need to provide those solutions, but in addition, you now need to provide services to the rest of IT. You have become a service provider.

This is part of the culture change that must occur to be successful in an enterprise wide adoption of SOA. In an era where IT projects can so easily spin out of control, we’re suggesting increasing the number of groups that need to come together to produce a solution. Nothing scares a project manager more than having to depend on something outside of the control, and that’s exactly what must happen.

Becoming a service provider is a big challenge. Your Enterprise Architecture group may have figured out what services you need, but who is going to provide them? This is not an easy question to figure out, because there are many different ways that things can be sliced and diced. Odds are, your current organizational structure may not map easily to the services that have been identified.

The best way that I’ve found to understand what it means to be a service provider is to ask yourself what you would expect if a third party was providing the service.

• Would you want a contract? Your legal department certainly does, and the contract would certainly have language regarding availability of the service, support structure, ongoing releases, etc.
• Would you want usage documentation? Absolutely. Would you need customization for your new requirements? Very likely.
• What about the relationship going forward? After that vendor provided the first production version, would you want them to disappear and pay no attention to you whatsoever?
• Do you think they’d be able to respond when you tell them you need modifications for your project with a production timeline 2 months from now?
• Would you want them to let you know that in one month, a new version goes live that another customer requested, and you need to upgrade or else your consumers will break?

All of these things apply to internal service providers as well. A typical application team that only had to deal with end users can get away with far more. Humans are much more tolerant to change than systems are. As you make the transition from internal application provider to internal service provider, you’ll need to change and mature your processes, changing the culture of your development staff right along with it.

Miko Matsumura recently posted about the myth of starting small which was followed up by a response from Joe McKendrick of ZDNet.

Miko stated that the only ones getting it right were ZapThink, who state that “the things you do in a pilot are the exact opposite of what you need to do to get to enterprise scale.” For the record, I agree. This all comes down to defining the pilot properly. In their book, “Service Orient or Be Doomed!” Jason and Ron call out three SOA Pilot essentials: an architectural plan (the pilot will cover some portion of it), a specific scope, and clear acceptance criteria.

There shouldn’t be much controversy over these, but yet, the case studies and whitepapers that I see presented don’t have these elements, and it’s usually because the study is equating web services usage with SOA. Taking a user-facing customer portal and extending it by allowing customers to integrate their systems directly can be a good thing, but is it really an SOA pilot?

One of the key things, in my opinion, in a proper SOA pilot is to pick a problem that will require the organization to see the cultural changes that are necessary to become a service provider. In the portal case, the group maintaining the portal is already a service provider, so there’s no big stretch there. Instead, we need to find a service that has potential for reuse, and has no clear owner in the current organization structure. This scenario will give a good dose of what SOA is all about from an IT perspective. If you’re using the pilot to sell SOA to the business, you’ve got to be even more careful in your selection, especially in picking the right service consumers. Agility is a particularly difficult thing to pilot, because it only becomes evident when something needs to change. If a pilot is putting it in place for the first time, there’s no change involved. What can help pick the right pilot? The architectural plan. If the architectural plan isn’t already service-oriented, however, what do you do?

My advice is to first focus on why you’re doing the pilot, and what you hope to achieve/prove. If IT begins to understand what being a service-provider means (you need to have a pilot that have distinct service consumers and providers to do this), it is progress, even if the service isn’t as coarse-grained as it should be or can be used as a good case for business justification. It may not be SOA yet, but it is a step in right direction. Once you understand how the IT organization needs to change, now you can pick a service with a bit more impact that really can show the business that IT has its act together and can make a difference.

I had the opportunity to meet Eric Newcomer, CTO of IONA, at the InfoWorld SOA Executive Forum last week. He recently blogged about some of their interchanges we’ve had on a Yahoo SOA group as well as the things he heard from end users at the forum.

What Eric points out is that “Vendor suspicion runs very high.” He goes on to say, “I think it was someone on the SOA discussion list who said that IT vendors today are like going to an automobile dealer and having the dealer tell you what kind of car you want to buy.”

First, I commend Eric for posting this, since he is, after all, a vendor. Just as Eric has called on all vendors to rethink how they’re working with their customers, I encourage all end users to rethink how they’re working with their vendors. It’s a two way street. Vendors can only work from the information that their end users give them. If you want better products, let your vendors know. The ones I’ve spoken with would love it if they had more interaction from their customers. Try asking them for a corporate visit, or a phone call with the product manager for your solutions. I bet they’d be more than happy to accommodate your request.

Another person I had the opportunity to get some face time with is Miko Matsumura, VP of Marketing and Technology Standards for Infravio, as well as the Chair for the OASIS SOA Adoption Blueprints Technical Committee. We had a good chat about SOA governance, as well as discussed some upcoming things for the committee. What’s great about what Miko’s trying to do through OASIS is the fact that it is adoption blueprints. This isn’t some vendor’s reference model intended to sell product, this is a set of blueprints rooted in the experiences of the end user community. I would love to see end user participation increase on this TC, as it will only increase the quality of the deliverables and help us all with our SOA adoption efforts.

Thanks again to InfoWorld for putting on a great event. In addition to Eric and Miko, I also chatted with/met Jeff Schneider and Hjalmer Danielson of MomentumSI (thanks for the t-shirt), David Chappell of Sonic Software, David Linthicum of BridgeWerx (and the voice behind the SOA Expert Podcast), Andrew Nash of Reactivity, Phil Wainewright of ZDNet and LooselyCoupled.com, and Sean Fitts of AmberPoint. It was a great event.

I’ve been at the InfoWorld SOA Executive Forum today, including my stint on Phil Windley’s panel on SOA Governance. I was joined by Ed Vazquez from Sprint-Nextel, along with two last minute substitutions, Jeff Schneider of MomentumSI and Sean Fitts of AmberPoint.

As Ed pointed out, we covered the entire SOA Governance map, whether run-time, design-time, and everywhere in between. Thankfully, we didn’t have to employ any Jerry Springer-esque techniques to keep the audience interested. The interesting part for me was that we were all coming from different points of view, but yet we seemed to agree on all of the major points. My points were consistent with my previous posts, which is to match your SOA governance to your corporate culture. Just as we shouldn’t boil the SOA ocean if the organization still develops in silos, we can’t govern everything if we’ve never governed before.

Both Jeff and Ed made great points on the importance of grass roots governance, that is, relying on the people in the trenches. An ivory tower approach to governance will not be successful, especially when it’s the people in the trenches who have to adhere to the policies.

All in all, it was a lot of fun. Thanks to Phil for the opportunity, and I hope we can do it again.

The latest ZapForum Podcast was a conversation between Ron, Jason, and Charles Stack from Flashline. As always, this was an excellent conversation. One of the things that was very interesting for me was the three patterns for SOA governance that Charles introduced. They were:

1. The gating pattern. You need to have appropriate gates in the development lifecycle at which reviews can occur. This is absolutely critical to avoiding JBOS. The development team is most likely to develop to the constraints of the project at hand. If you don’t provide an external review that brings in a perspective from outside of those constraints, your chances of getting a service that is useful outside of that project are very slim.
2. The library pattern. This is self-explanatory. If you want people to reuse services, they need someplace to find them.
3. The dashboard pattern. Measure and monitor! This has been a key part of Flashline’s products from their early days exclusively focused on reuse. Even beyond reuse, it’s amazing what insight you can get into your systems by add a little bit of metrics. It’s very easy to add a SOAP mediation layer in to collect this information.

To this list, I add a fourth pattern: the legislation pattern. We can’t do a review unless we have something to review against. What’s really interesting about this one, however, is the different approaches to legislation. It’s very important to pick a legislative, or governance, style that matches your corporate culture. There are direct parallels to traditional government. Google “types of government” and you’ll find a number of them (this site has quite the exhaustive list). There is no one style that is best, and you need to match your company culture. A country rooted in deep religious beliefs is going to tolerate a theocracy much better than a statocracy. If you presently have no formal reviews in your enterprise, you need to give careful thought to whether legislation should be done in a dictatorial fashion (sometimes a strong arm is needed to lay down the law) or whether legislation should be more democratic in nature, to build the backing of the developers that must adhere to the law. Anarchy will definitely not get you an SOA. Too many legislators may stymie the agility and flexibility you hope to achieve through SOA. What approach to governance is your enterprise taking?

A subject that I’d love to see discussed more is the role that SOA can play in education, specifically elementary education. Our schools have to make increasing use of technology, yet they certainly can’t afford to spend a lot of money on it. How can SOA play a role in allowing elementary schools to get the most from their technology dollars?

One good thing is that the standardization that has brought about the emphasis on SOA in the corporate world will likely lower the cost of technology for schools. Continued advances in SaaS capabilities should certainly allow many of the administrative functions to be handled through a web-based provider. If SMBs can utilize salesforce.com for CRMs, there’s no reason why there can’t be a schoolforce.com for elementary school administration (except that schoolforce.com is already claimed by SportPal Team Management- we’ll come up with a better name).

My father-in-law is the principal of a K-8 private elementary school. Unlike private colleges, private elementary schools face significant challenges, and he has to utilize every grant and donation, no matter how small. The administrative challenges of this are daunting. It’s not simply about having an online grade book available. They need to keep detailed records regarding student attendance, paid lunch counts (versus kids who bring their lunch), etc. and report it on a regular basis to the authorities that administer the grants. I’m sure this is just the tip of the iceberg. I’m sure technologies used for inventory management could be applied to collect student data in real time, and then send that information to a web service exposed by the grant authorities, eliminating a lot of the paperwork associated with the effort.

Beyond SOA, I think schools can also leverage the social networking technologies associated with Web 2.0. After all, what elementary school doesn’t have a parents’ organization? I’m still disappointed that some open source group hasn’t created a complete school intranet with LAMP and made it freely available.

Are there other more philanthropic uses of SOA? Leave a comment or trackback with your thoughts.

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 and 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.

On an SOA mailing list I follow, someone recently posted a very simple question. What is a well-defined interface? The notion of a well-defined interface is frequently cited as a requirement for a good service, but the discussion usually heads in the technology direction of WSDL, IDL, WS-Policy, etc. In terms of importance to an enterprise SOA, I think that the use of standard description techniques is far less important than the qualitative aspects of being well-defined. As I see it, a well-defined interface is one where the actions that will be performed by the service provider are clear and unambiguous. Does using WSDL and WS-Policy ensure this? Absolutely not. Just as the use of standard look and feel guidelines and common user interface toolkits do not guarantee a highly-usable user interface, the use of WSDL and WS-Policy do not guarantee a highly-usable service interface. After all, the reason for defining something well is so that others will use it.

Defining an interface so that the behavior is clear and unambiguous is a very difficult thing to do. Rooted in binary technology, typical IT systems are not designed to deal with ambiguity. Where ambiguity exists, we design systems take a decision tree based approach, always dealing with yes/no decisions. Systems break down when they enter an unexpected state, a situation not modeled in the decision tree. When this decision logic is represented in source code, the cost to go in and add new logic to handle the unexpected state is high.

A very simple example that is timely for those of us in the USA is tax filing. Those of us who do our own taxes often use a system like TurboTax or TaxCut. The final step in the process is the electronic filing of a return. Let’s suppose I am providing an tax return filing service. There are state and federal fees to be collected. How should these fees be represented in the service interface? Hypothetically, the fee could be paid by extracting the fee from any refund the filer is due, they could supply a credit card, it could be electronically deducted from a bank account, a payment service like PayPal could be utilized, or a filer from previous years may have a payment preference on file. What happens if the credit card is rejected? What happens if the tax return is rejected?

When working with human-to-system interactions, systems can deal with this ambiguity by having a very generic return type, such as an HTML page. The interpretation of the response is left up to the human, and we’re good at processing ambiguities. This doesn’t work for system-to-system interaction. The analogous approach would be a web service that returns a message that can be any well-formed XML document.

Choreography is a big part of this. While we may try to decompose things to simple request-response patterns, the real world doesn’t work that way. What may have looked like a simple placeOrder operation may need to be modeled as a conversation, with only one path being a simple request-response. When conversations are involved, we now have to deal with system behavior when one party stops communicating. If I’m a cashier, and I tell a customer that they need to give me more money, I can infer that when they walk away from the counter without giving me the additional money, they’re not going to buy the product any more. I don’t sit there waiting for a response from them, and require the store manager to find another cashier to wait on customers. So what’s my advice? There are two things.

First, we still need to strive to take as much ambiguity out of the system-to-system interaction as possible. Systems must have some level of agreement on the semantics of the interchange and the policies associated with the interchange, including the semantics of the policies (we need domain specific policy languages). That being said, the ambiguity will never go away. If we only focus on removing ambiguity, we’re doing ourselves an injustice. I would argue that removing ambiguity results in more rigid systems, which is exactly the opposite of where we want to be. We’re adopting SOA to allow for increased flexibility and agility, not increased rigidity.

While embracing standards, we must also know that change will continue to occur and ambiguous situations will continue to arise. As a result, the second thing must be a focus on efficient management and incorporation of that change. While SOA and Web Services allow us to remove ambiguity, the worlds of BPM and EDA allow us to efficiently address ambiguous situations and changes to the interaction model. BPM and BAM technologies are allowing the interaction to be modeled and executed by run-time engines, including the ability to run simulations based upon new process variations and new interactions. Event processing allows analysis of a flowing stream of events to infer state (the key to recognizing an ambiguous situation), that can now drive new decisions in the process or new service invocations. Brenda Michelson has a great blog entry that goes into this in more detail, with some feedback from Joe McKendrick at ZDNet. For more on the well defined interface, check out Miko Matsumura’s comments on the same thread and pizza shop blueprint as well.