Todd Biske: Outside the Box

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.

James McGovern has a few

outstanding questions on becoming an industry analyst. One of his five questions wasn’t directed at becoming an analyst, but interacting with analysts:

I have seen many bloggers comment on how software vendors should interact with industry analysts but have never seen anyone really explain how us folks in corporate America should? Come someone please blog about best practices in this space?

As a corporate America user of research from analysts, here’s my take on this. As with most things in this world, there are companies who are leaders, followers, and laggards. The 80/20 rule applies, with the “follower” category taking up the 80%, and the remaining 20% equally split between the leaders and the laggards. The leaders are taking risks, trying to innovate, and, when they choose wisely, reaping the rewards. The followers sit back and watch, and then try to follow a similar path of the leaders, albeit at less risk. The laggards, well, they’re distracted doing something else and eventually get left behind to wither and die.

The challenge for companies in this follower region is to identify the trends that lead to success, versus the trends that were not successful. SOA is a great example to use here. Virtually every single presentation I’ve seen on SOA begins with a definition. This is because there are so many different ways of applying service-oriented principles, and the right approach is dependent on the company’s strategy. When the CIO simply makes a statement that the company is going to embrace SOA, someone has to go out and figure out what that means. There are two common ways of doing this:

1. Hire someone who has helped other companies embrace SOA, effectively outsourcing the strategy and execution. When the consultants leave, so does the thought leadership. While some of that knowledge will carry over, the ability to analyze and implement primarily stays with the consultants. They go on to the next big thing, while the corporate workers continue to maintain the status quo.
2. Seek out information to build the internal thought leadership. This is done through books, magazines, whitepapers, webinars, and conferences. Of these, the best sources are going to be the ones that involve the widest coverage of case studies. Who has this? Analysts.

If we didn’t have analysts, the source of these items would lack breadth. The only entity with significant coverage would be vendors. Vendors’ bottom line is selling product, period. While they publish whitepapers, host conferences, etc., and these can be at a very high quality, it is all comes down to selling product. Outside of vendors, consulting firms are next in line. They, however, are more interested in sharing resources than they are in sharing information. If they share information, their resources may not be necessary. User groups and conferences that are not vendor sponsored tend to be local, which may constrain the amount of information that can be shared due to local competition for resources. So, there’s a big gap that needs to be filled, and that’s where the analysts can help.

Back to the original question: how should corporate America work with them? Clearly, the communication should be a two-way street. Just as the best service interfaces will probably come about through close communication between consumers and providers, the best analysis will come out through close communication between analysts and customers. The question, then, is how does the funding model reflect this? Do companies that share their information with analysts get discounts? Using the 80/20 rule again, 80% of the companies will likely be consumers of information only. That’s probably enough to sustain a healthy revenue stream. For the 20% that do share information, I would expect that discounting would be involved. If those companies fall into the leadership category, analysts may even need to pay for access to those companies. After all, these are the companies paving the way without support of external analysis, and they are the ones that the followers want to emulate. I’ve never had a research firm offer to pay me for information, so I don’t even know if this occurs.

Fortunately, analysts don’t publish evaluations of their corporate customers, so there isn’t the same conflict of interest that exists in the vendor space. There is potential for conflict of interest when two competing companies work with the same analyst firm, but again, the analyst research typically speaks in generalities, so this risk is mitigated. Additionally, many of the leaders are usually willing to talk about their experience, and are encouraged to do so. James’ should be familiar with this practice at The Hartford. This is further supported by the existence of research companies like the Corporate Executive Board who work to establish networks of companies for direct information sharing.

Ultimately, analyst firms exist to facilitate information sharing. Reading publications, case studies, vendor strategies, etc. is a full time job, and most companies are focused on providing solutions for their customers. Every company will have a different stance on how much “overhead” they want to fund. If the preference is to focus resources on execution rather than analysis, external research analysts will fill the gap. If a company is willing to fund analysis activities, there is a ton of free and low-cost information available. You may have every vendor knocking down your door, but it can be done.

Two days ago, I posted about my own aha moment with regards to SOA. This was in response to the latest ZapFlash from Ron. Today, they released their latest podcast
, which was further discussion about policies, contracts, SOA, and Web Services with Eyal Ma’or, CEO and co-founder of Silver-kite.

My own experience had to do with a realization on how aspects of things that we used to put into source code can be extracted and enforced through policy-based infrastructure. This is exactly the scenario that Eyal discussed with Ron and Jason. They discussed the lack of domain specific policy languages as a current barrier. To me, that’s one half of the problem, the other half being corporate culture. How many organizations have the maturity to properly express technical policies, let alone business policies? I fully believe that this is the way of the future, however, I don’t think I’d put this on my list of predictions for 2006 or 2007. My questions to my readers out there (and I’ve emailed it to Eyal, Ron, and Jason as well) is what policy domains can we apply this in today? Clearly, the most advanced domain is security. Whether through proprietary languages as part of an identity and access management infrastructure or through WS-SecurityPolicy, it can be done today. Beyond security, how would you prioritize the policy domains (and what are the policy domains)? Mine are:

1. Security
2. Routing/Accessibility (I’m not sure if you routing is the proper term, but this gets into the domain of load balancing algorithms and the drivers beyond them.)
3. Auditing/Compliance
4. Integration (i.e. transformations)

None of these begin to get into the “business” space, and I’m sure this is far from a complete list. What would be on your list? Leave comments or a trackback!

In the latest ZapThink ZapFlash, Ron Schmelzer provides some guidance on services, contracts, and policies. He speaks of the “aha” moment that many of us experienced when learning object-oriented programming languages, and compares this to a migration to service-oriented development.

Ron goes on to discuss the differences between a policy and contract based approach versus an object API-based approach. He discusses the need for a many-to-many relationship between policies and contracts, as well as between contracts and implementations. His analysis is correct, but what he didn’t go into is how the “aha” moment can occur.

In my own case, the key to this was when container-managed code was introduced with the J2EE platform. One of the goals of J2EE was to remove the responsibility for security, transaction management, and more from the developer by declaring the policies surrounding this in a separate configuration file. When J2EE was introduced, Sun also outlined the roles and responsibilities associated with a development project. One of these, the Application Assembler, was intended to create this descriptor file, while the Application Component Provider was responsible for the implementation. In my experience, these two roles were typically played by the same person. There’s even recognition of this in the C# and .NET framework where these policies are implemented by annotating source code. This is also now common practice in the Java camp as well, first through JavaDoc tags, and now through J2SE 5.0 Annotations.

When I began investigating Web Services, the “aha” moment occurred when I realized that the declarative policies that were established in a platform-specific manner can now be utilized independent of the platform. In fact, the entire “container” concept can be externalized from the actual implementation container. Since Web Services are sent as XML messages on the wire, policies can be enforced anywhere between the consumer and provider. Working on the infrastructure side of things helps this understanding, because some policies, typically routing, are already configured on a separate device from the application container.

This truly is a light bulb moment, because of the implications. As soon as policies can be externalized from the source code and execution container, we begin down a path where policy definition can be separated from policy enforcement points. Once policies are separated from the enforcement points, a new breed of tooling can be created for policy definition appropriate to the policy setters, rather than appropriate to the enforcement point.

For example, an organization may have an Information Security department that sets policy, but it may require an IT operations staff member to express that policy in a way that can be enforced by the infrastructure. If that same infrastructure also enforces routing policy, there is a dilemma. The person configuring routing policies should not be able to configure security policies. The key to this, as Ron suggests, lies with standards and tool support. By creating standard policy languages, an interoperability framework for sharing policies between editing, management, and enforcement points can now be created.

The more I think about this, the more there is to say. Some more thoughts:

• To have success as a good service provider, you need to provide a good service.
• Services developed in Corporate IT are inherently more difficult than many Web 2.0 services because of the user-developer disconnect. In the case of Web 2.0, many services are consumer oriented. Guess what? Most developers are also consumers. In the corporate world, services are business oriented. Chances are, you don’t also play the role of the business user. Interestingly, however, we still are always moving in a direction of allowing the actual end user to build their own systems. Arguably, many tech-savvy users come up with new ways to utilize technology beyond what the IT department provides, whether it’s as simple as a good set of bookmarks in their browser, or some sophisticated use of scripting.

One last thought- I recently read An Introduction to Enterprise Architecture by Scott Bernard. One of the points he makes early in the book is that one element of enterprise architecture is social theory. Given this debate and my own experiences, I couldn’t agree more.

There’s some interesting banter going back and forth between Dion Hinchcliffe and Steve Vinoski, stemming from Steve’s IEEE Internet Computing column, entited The Social Side of Services.

In this blog entry, Dion states that socializing SOA is “not the first order of business or the most important aspect of adoption.” Steve counters in his own blog.

Whether you agree with Dion or Steve, this is a very interesting conversation. I, for one, fall more on Steve’s side. In 1998, a presenter at SD East spoke on implementing reuse in a corporate IT shop, and his experience at several large firms was that marketing and communications was the number one factor in achieving success. I tend to agree. The degree of communication across IT groups is simply not what it needs to be to foster reuse. Dion dismisses this, and more blames it on “software that is actually extremely hard to mesh together.” Here, I disagree. I don’t think that integrating a typical corporate Web Service using SOAP/WSDL is all that more difficult that integrating a REST-based service, especially for system-to-system interaction. I’ll give REST or simple XML over HTTP the nod for AJAX-to-service interaction.

Dion does make some good points that corporate developers do need to embrace, however. He states that “Web 2.0 approaches to service design dictate an almost extreme preference for encouraging unintended uses.” Here, he hits the nail right on the head. Roy Schulte commented in a webinar that we need to switch from “build to last” to “build to change.” If an internal IT team builds a great service, they need to understand what it means to be a service provider, and encourage any usage they can get. If they take a rigid stance with regards to their customers, they won’t be successful.

Where I see the gap in this debate is really the cultural differences between Web 2.0 development and corporate development. Corporate developers are working to the demands of the business according to a project schedule. I’m willing to bet that the typical Web 2.0 Google Maps mashup is not, or at least not in the early days. On top of that, the mashups are creating new applications out of existing parts that would be too expensive to go and build from scratch. I don’t think any Web 2.0 programmer (unless they work for MapQuest, Yahoo, or the mapping provider…) could go out and write Google Maps on their own. For the services being reused in corporations, this isn’t the case. Often times, the developer has everything they need to write it themselves. In this situation, it absolutely is about marketing and communication. If the developer doesn’t know someone has already done it, they’ll go off and do it themselves. If they do know it exists, now it’s more of a trust and control issue.

In the Web 2.0 world, we’re encouraged to communicate, socialize, and share. (hmmm, isn’t this what Steve was saying is a critical factor?) If the service needs to be tweaked, we’d contact the service provider and get it tweaked. Even in the Web 2.0 world, if the group was unresponsive, that service will quickly fade away.

In the corporate world, the team providing the service does not have resources assigned to that project, and this makes project managers very, very nervous. They’re now dependent on something outside of their control, and unless the corporate culture changes to allow that, they may be apt to do it themselves, strictly to control their own destiny. If your organization can’t built the internal trust to get over this, they won’t be successful with SOA.

Just a quick note to thank Brenda Michelson for coming to St. Louis last week, and for the good people at CAIT (Center for the Application of Information Technology from Washington University) for setting it up, including my good friend Fred Domke. It’s a shame that her luggage couldn’t make it, but she still made the best of it. As Brenda reflected in her blog, events like these (the CAIT event, not loosing your luggage) can only help all of our work get better. I look forward to CAIT’s continuing workshop on SOA and being a part of it. As if that wasn’t enough, Thomas Erl also paid us a visit courtesy of Microsoft, including copies of his latest book.

Both presentations were very good. I always enjoy these exchanges on best practices and approaches to SOA. Everyone comes at SOA in a slightly different manner, and it’s interesting to see what points others emphasize or include. Thomas clearly came from the technical side of things, which was appropriate for the audience. Brenda, as I had hoped, brought the user element back into the mix. I was glad to see this as well as recent articles that also touched on this from Ron Schmelzer of ZapThink and JP Morgenthal (blog) of Avorcor.

Anyway, it was a good week for SOA in St. Louis. Hopefully, it’s the beginning of a good trend, although I certainly don’t mind having to travel to Orlando, San Francisco, etc. to discuss SOA.