These are my notes from the SDForum workshop on interoperability held on January 31. I managed to attend all but one of the sessions. A warning that these are mostly raw notes (even the stuff in quotes is likely not verbatim), with a few dollops of opinion interspersed throughout. If I have time, I might noodle more on this in a separate post.
By the way, I heard that IT Conversations will be posting audio from the event sometime in the next couple of weeks. Oh, and Paul Krill has written an article on the event, picking up on the web services complexity theme.
Keynote: Interoperability: Why It’s Key to Your Business Success
Anne Thomas Manes, Burton Group
[It was great to see her again! She was at Sun some years ago, and we met in Menlo Park — though we were both living in the Boston area — while working on Sun’s assessment of the W3C SOAP submission. We went years without running into each other, but the pace seems to have picked up.]
Burton’s target audience is architects of various sorts.
Homogeneity vs. diversity: Diversity is often a good thing when it comes to cultures, investment portfolios, workplaces, etc. But it’s a pain in IT systems — though a reality (languages, platforms, middleware, IdM, system management). Costs when systems don’t work together: inflexibility, delays, higher costs…
What enables interoperability? Standards (protocols, interfaces, metadata formats, data formats/models) and semantic agreement. But we have “WS-Vertigo” — too many standards. Also, some standards (and “standards”) have errors and are underspecified. The soapbuilders forum and WS-I BP have helped SOAP and WSDL 1.1.
Profiling can help the semantic situation at the protocol level. But, e.g., some schema interpretation issues and missing functionality (such as attachments) can’t be solved by profiles.
“WSF 2.0”: SOAP 1.2, MTOM, WS-Addressing, WSDL 2.0, XML Schema Patterns for Data Binding. Going from “WSF 1.0” to “WSF 2.0” will be disruptive. But Indigo/WCF will spur SOAP 1.2 adoption. [Ugh, I really don’t like Burton calling this “WSF”. Most people call it WS-*, and a few still think of it as GXA. But WSF is multiply defined — there’s also Liberty’s ID-WSF, the only formal use of this initialism by the actual publisher of the specs in question. In fact, I just googled “WSF” by itself and got nothing web services-related on the first page.]
What about all the SOAP extension specs? There are so many that it produces WS-Vertigo. [Agree, though quite a few of the standards and specs out there are nicely complementary. As one tiny example, no one would argue that any one of the following could replace one of the others: XML Signature, XML Encryption, XKMS, XACML… That’s not to say everyone wants all of them, though.]
There have been recent standardization milestones. WSDM is ratified, WS-Security 1.1 will be shortly, and WS-SX, RX, TX, and Management specs have been submitted.The MSFT/Sun settlement was a wonderful thing. It makes the future look so much brighter. No more rabid fighting! Now all the fights seem to be between IBM and MSFT!
There are still competing standards:
WSDM vs. WS-Management: WSDM too heavy for small devices; WS-Mgmt has the backing of a lot of critical manufacturers, including IBM, and is now in DMTF, a great place.
WS-Notification vs. WS-Eventing: Notif is at OASIS but going slowly; Eventing still not in a standards body.
BPEL vs. WS-CDL: BPEL is moving slowly at OASIS and facing philosophical difficulties; people think BPEL is wonderful, except those working on it! WS-CDL is at W3C.
SAML protocol vs. WS-Trust: SAML has its own protocol that only works with SAML tokens; WS-Trust can be used with any type and will likely win. It seems to have taken over. [I’m not sure what this assessment is based on. I know of many SAML production deployments and no WS-Trust production deployments, but then SAML is pretty mature by now and has been in products for a long time. And maybe I’m not hanging with the right crowd. :-)]
Liberty ID-FF vs. WS-Federation: thinks Liberty will win here. But no one focuses on the federation of web services space. [Not sure what this means. If it means portable identity across web services, that’s Liberty ID-WSF’s and ID-SIS’s realm.]
Most aggravated that WS-Policy isn’t submitted yet.
Conclusion: Interop is the goal. Standards are the solution. It takes time. Vendors typically do it, and they always pursue their own agenda.
Q: Harold Carr: Regarding WS-Addressing’s asynchronous support: Do you think having a response sent to a different endpoint is a good architectural feature? Asked people on the committee, and they couldn’t come up with use cases. Anne: Use cases exist that demand it. Kelvin Lawrence: “faults go here” is one use case, and re-routing gold members is another. Anne: the latter is routing, and shouldn’t really apply here. Harold: Concern is that this feature will give them asynchrony. If you want a reply to go somewhere else, and it comes back a week later, who correlates? Anne: Agreed that the application level has to pick up a lot of this. Harold: Prefers building this into their own envelope; the application would have to get into the middleware with a handler otherwise. Anne: Would prefer to try and put as much of this tracking done in the middleware as possible.
Q: M.R. Pamidi: Are BPEL and WS-CDL complementary rather than competing, with CDL doing orchestration? Anne: BPEL will get out of hand when you start adding more than one business entity. CDL specializes in that upper level. Not a big fan of BPEL because it has the wrong model.
Q: How to get users involved in standards? Anne: Most customers don’t want to spend resources sending people to these groups. WS-I ha some user companies involved. [Also Liberty, particularly from financial, government, and telecom.] Not sure how to fix this problem. Q: Exec director of FSTC: They invest in W3C but it’s difficult. It would be good to leverage trade organizations that specialize in this and are willing to invest, but need greater incentives/support. Anne: Domain-specific organizations are in a position to standardize critical business semantics. Commenter: E.g., Citigroup participates in some W3C activities to convey requirements; it’s a challenge to populate those conversations with this input. Anne: OMG gets customer input.
Panel: Web Services Interoperability
Andy Daecher, Deloitte: moderator
Nick Kassem, Sun: his focus is web technologies and standards. Have a fairly large team working on implementing the specs Anne mentioned.
Wes Swenson, Forum Systems: company focus is web services security.
Ed Cobb, BEA: team is responsible for representing BEA at standards activities.
Andy: Web services have gotten off to a slower start than expected. Agree? What are inhibitors?
Nick: Sun delivered JWSDP 3.5 years ago. Stunned by level of adoption. First-generation web services had modest goals. Messaging is necessary but insufficient for enterprise-class apps. Some next-gen work in the pipeline (security, quality of service) will bring up the sufficiency a lot.
Ed: Most of the specs are wire-level protocols. These need to be used by apps. The complex protocols have complex low-level APIs for using them, which is an inhibitor. You want to be able to exploit the low-level features, but it’s difficult. Indigo will likely help, and BEA has some things coming that will help too.
Andy: What are some of the security issues?
Wes: It’s a problem of practicality. The architects have to funnel security down to the people who manage the policy and so on. The complexity is a problem. Customers have gravitated towards the simpler specs (WSDM, WS-Security, WS-I Basic Profile), then managing policy off of that. We get requested to store the transaction ID rather than the message, then match it up with requests and replies going between JMS, MSMQ, etc. Customers were gravitating towards XML Signature and XML Encryption, but not so much today because PKI management is so difficult — the standards were way ahead of implementation.
Q: Regarding complexity: Developers using a tool to better understand what they’re doing causes more problems than it solves. How is the .NET-Java interop problem going to be solved? Nick: For the first-gen standards, things like JAX-WS (was JAX-RPC), the challenge was to incorporate the next-gen features without overwhelming the Java developer community. You won’t see us introducing yet another JSR for every one of these WS-* specs. Those who are tracking JAX-WS and the Sun developer network (SDN) should hopefully find the improvements to support these features unobtrusive. A new project (internal name Project Tango) focuses exclusively on this.
Ed: We don’t think every piece of functionality should show through to the developer. The MSFT developer community probably has it a little easier than the Java developer community in this respect. The only way to simplify is to continue raising the level of abstraction.
Q: Some tooling is needed that makes it easier to develop reusable patterns. Developers shouldn’t have to guess how to implement a business use case. Ed: The Eclipse community is building web services tooling. Iona has started a new tooling process for SOA. But don’t mask complexity with tooling. The abstractions have to be simple too, and then they’ll lend themselves to good tooling. Commenter: We need more patterns to reuse.
Nick: We need to distinguish between abstraction levels. JAX-WS targets a particular class of developer. Don’t oversimplify the conception of “a developer”. A BPEL developer would worry about different issues than one who cares about PKI issues. It’s incumbent on all of us vendors to provide the appropriate tooling for the appropriate developer. E.g., look at the NetBeans work.
Q: Do you feel we’ve reached a steady state to start investing in web services? How do we ensure our investments stay relevant?
Wes: We have 250 customers, and half are in production. So they’re not waiting — they’re rolling out now. They do this by using gateways. The bootstrapping is to insert ourselves without disrupting. We have integration with the IdM players, the message queues, and the network layer. Our customers don’t build in the web services protocols at the application logic layer, though eventually they’ll want to. Dealing too much at that layer right now results in “science projects” that will never go into production!
Ed: To get into production today, you still need to build glue code. SIs and consultants are finding this a boon. As an industry, we need to make all this easier to do. Customers still have to invest a large amount of effort, which is not how we envisioned web services.
Q: Mark Hapner: If I were a customer of your middleware product, how would you describe the separation of security concerns in app logic vs. your gateway? Wes: We use an existing WSDL file, and ask some questions: how the customer wants to handle IDs at the messaging layer, how they want to enforce checking of XML packets vs. their existing firewalls that do no XML checking. Forum secures the IRS’s 1040 forms coming in, such as GM’s. It comes in as an attachment, and it needs to be checked! Malicious scripts could be inside such attachments.
Andy: Can you talk about your work on quality of service, such as scalability and performance? Nick: The JCP has the JMS API, which did a pretty good job of queuing infrastructure. It assumes it owns both ends of the pipe (same as MQ Series, MSMQ, etc.). Quality of service when you own both ends is more tractable. With web services, when you don’t own both ends and can’t make assumptions about it, how can you offer high QOS? We looked at the WS-ReliableMessaging spec about a year ago. It has some shortcomings, but we feel it is useful. Note this is entirely separate from the data binding issue; you can flow the infoset over various different bindings, and we think those should remain as options. An HTTP binding will always have a lot less quality. The WS-RM approach, depending on the binding, may require compensation-style programming. We’re working on WS-RM aggressively.
Ed: We made a major announcement with other companies in October for new technologies to create web services and apply QOS declaratively. We need to better separate the concerns for app developers, IT, security admins, etc. RPC isn’t a good paradigm to use across the Internet. Messaging hasn’t been the principal paradigm but we need to go there.
Andy: Can you respond to the skepticism around BPEL?
Nick: We think BPEL is useful, though it has growing pains. When it grows up, it’ll be something useful. It targets a class of developers that Sun and the Java community as a whole care about.
Ed: We were in the forefront of pushing BPEL. It’s a problem worth solving. We perhaps went to standardization too early; the problem space was still immature. We do have products today.
Q: The idea of messaging as an alternate “wide-area” model vs. RPC is interesting. Where to go to pursue wide-area networking in messaging? Ed: The whole area is ripe for some new standardization.
Wes: Regarding BPEL, our customers have low expectations of the standards bodies and vendors. They’re not looking for perfection. Most of them request BPEL today, and they perceive it to be adequate. They’re not waiting for improvement. Their use cases will influence the future work on the standard.
Fireside Chat
Anne Thomas Manes, Burton Group: moderator
Andrew Layman, MSFT director of distributed computing
Graham Hamilton, Sun fellow
Kelvin Lawrence, CTO of software standards at IBM
Anne: Things like null or missing values tend not to work. How can we make them work?
Graham: We want XML to work well with all the major language. Certainly for Java we are striving for this. It might be interesting to have W3C giving guidance on a half-dozen important cases, but it will be more a matter of pragmatism.
Andrew: Agree. Programmers expect things to just work. If they’re used to a programming language, they work by definition. When you need interop across languages and object models, we’ve grappled with whether to have a standard representation of some of the more complex objects. Should you just put the minimal facts on the wire, or more? Do hash maps belong on the wire, or purchase order line items?
Anne: On the Apache Axis list, someone asked how I get SOAP to expose hidden fields? Graham: That’s one of the strengths and weaknesses of Java object serialization; suddently private fields are exposed. That’s a lesson learned in the Java community. Anne: You should never get to the point where you’re unaware that you’re doing distributed computing. Don’t think you’re working in Java; think you’re working in XML. Kelvin: We blame XML Schema for these problems, but choices and ANY came from DTDs first, so we’d have these things anyway. Even JavaScript for XML is making life easier.
Anne: What can programmers do at this point to allow programs to communicate? Why don’t the tools flash something that says “Really bad idea”? Andrew: Tools can restrict the options according to an organization’s wishes. IT managers should be able to selectively scope down what can be done. Anne: But tooling doesn’t have this. Andrew: The version of Visual Studio you can get soon will have this. Graham: The tension between what developers want to do (flexibility) and interoperability means you can’t let people manipulate raw XML fragments and protocols. Java annotations let you abstract away from XML and the “web services standard of the week”. Andrew: Disagree a bit. EDI is old technology, but it’s a testament to how good it is. It defined the wire format. [Hmm, EDI isn’t famous for producing interop! In fact, it’s a poster child for a “framework” that has to have profiles, and which is used incompatibly in each pairwise case.]
Graham: You need to keep a strong grip on the types that are flowing, but if you depend on the other’s handling of it, you’re in trouble. People’s web services stacks will do a metadata exchange to figure out the particular protocols you speak and optimize on that basis. [Sounds like the Web SSO MEX draft spec!]
Anne: Disappointed that WS-MEX hasn’t been submitted to a standards body! Graham: So am I! Kelvin: That’s work that is ongoing. I think you’ll see progress soon. No one disagrees with you.
Anne: Also WS-Policy, by the way. What’s the delay? It’s delaying some implementations. Andrew: Three months ago wasn’t quite the right time. We’re learned a lot by having running code and test cases so that the standard follows what’s known rather than getting way ahead. We now have concrete policies for transactions, reliable messaging, and security, and we learned things that caused us to slightly modify the WS-Policy spec. We’re done with that, and it’s time to go in. Kelvin: Last year was a good year for WS-* specs. We’ve reached the top of hill and we’re about to go down. :-)
Graham: People didn’t used to need to know about the plumbing underneath, and with web services we’ve gone backwards in exposing it. Anne: With Java annotations, people can get away from that. Kelvin: And you don’t want non-security developers writing security code, so that’s good. That will be good for the industry. Andrew: And then we can move to being very conscious of our datatypes, as Graham said.
Anne: Where does app functionality end and infrastructure start? Where do you draw that line? Andrew: You build infrastructure at all because there are common things in many applications. It’s to extract certain common patterns. Graham: As middleware vendors, we’re too in love with middleware. Developers want simpler scenarios and for the common cases to work really well. Their first encounter has too much complexity. Anne: Isn’t this a problem of the tooling? Graham: We had this conceit in the older days of Java, but it wasn’t working for people; tools have to be good but can’t successfully hid complexity.
Kelvin: Regarding profiling, not just in WS-I but in other cases as well, IBM is doing customer-specific profiles. RAMP is an example. This is all being driven by customers, and it will help for middleware and tools to claim support of these profiles.
Q: “Make things simpler” is a religious point that’s paramount. However, comparing things to EDI struck me as perfectly contradictory — it doesn’t scale because of the large amount of negotiation, and the MEX over the wire guarantees highly inefficient exchanges. Andrew: The people working on web services — about 70 companies who have participated in workshops and done interop testing — have learned how to get the data model on the wire agreed on. MEX to retrieve a policy will let you interchange without lawyers in the room. [This doesn’t seem to square with what we’ve heard from customers, which is that the technical work is maybe 30% and the business agreements are still 70% of the work.] Efficiency isn’t the primary driver — after all, HTML is popular.
Graham: I want to simplify the life of the developer. Vendors doing more complicated things in the protocol stack to buffer users of it is okay. Development costs are huge for IT organizations. We want to reduce them. Anne: Every company I work with has at least 25 structures to represent the concept of a “customer”.
Q: Harold: Unix was popular where Multix wasn’t. Graham: C became popular too, but now we find ourselves with a different tradeoff point. Andrew: We’re looking at the economics of running IT over a long period. We’re very motivated to reduce it.
Q: Stateful computing has been tried so many times, and it’s just not happening. Do you think web services may collapse? Anne: You mean, and just use REST? Kelvin: Web services is happening and continuing to grow. I have lots of customers who are using it. The panel in May talking about REST and AJaX etc. was useful. But people are concerned about audit trails, reliability, security, and so on, and so if you need these things, those specs are there for that. Graham: REST will be part of the ecology. In Java, the higher-level models like JAX-WS will let you do it, e.g. DCOM and CORBA had enormous levels of adoption, but they’ve been dying because of lack of interoperability with the MSFT space. Now we have a new paradigm that we’re all interested in. Anne: Its being a message-based system rather than a distributed object system gives it a better chance of success. [But many people are using it for the latter, hence some of the efforts to fix schema impedance mismatches, it seems to me.]
Q: Harold: Web services is where we would have been 10 years ago if MSFT had joined OMG. Andrew: You’re giving us too much credit. At some point, it’s better to change the model. Latency issues, e.g., needed to be tackled head-on. Web services have been an opportunity for vendors and customers to cherry-pick the last few decades of experience. Explicitly addressing a wide-area network, etc.
Panel: Identity Management
Rena Mears, Deloitte: moderator
Karen Wendel, Identrus
Kim Cameron, MSFT
Prateek Mishra, Oracle
Prateek: The identity problem is that it’s stuck in a few places: your employer, your bank, other places you do business. It wants to be free. How does it get from the IdP, where people know you well, to all the other business processes? If you want to convey it across the Internet, you need to solve three pieces:
The protocol that represents it and lets you get it (SAML addresses this, as does Shibboleth, Liberty), now solved.
The governance model — under what conditions do you allow it to travel. This is a harder problem. Kim will likely address this, and Liberty has addressed this though specs and papers. Shibboleth also have a governance framework.
How do you have normal folks [What are you suggesting? :-)] sitting at their computers and other devices manage their identities?
Kim: I’m a great fan of SAML and Liberty. The Internet was built without an identity layer. As we have more interconnected systems, we need that layer. When there’s an architectural hole of that size, you have a lot of kludges (ad hoc answers for particular use cases). Users have no way of predicting their behavior, increasing the danger. We also have different identities in different parts of our lives. It doesn’t make sense to have a single identity for everything I do. Knowledge about the newspaper articles I read shouldn’t be connected to my MSFT employee status. The different contexts have use cases that suggest different technologies. You may want an anonymous identity when reading your newspaper, but not when filing your tax return (you may want it, but can’t have it!) So you need a metasystem, where you have the quality of the underlying systems, but you have a consistent interface. Just like TCP/IP allowed encapsulation of the underlying systems (Ethernet and token ring). The metasystem doesn’t imply that PKI, SAML, SXIP, etc. go away; they’re just now accessible through a common user environment.
Karen: I come from a business perspective, not technology. Identrus was founded to be a metasystem. Everyone has a Visa card because, in 1974, Bank of America realized that having all the store credit cards wasn’t viable long-term. The credit industry would be stuck if those silos continued to exist. The bank instead would issue the credit, removing the risk from merchants and allowing it to be used around the world. It allowed a single connection instead of forcing multiple bilateral relationships. It solved the policy and legal issues and gave a consistent, clean user interface. Identrus was formed by the banks in 1999 to do the same thing for identity. (Now it’s privately held.) It’s technology agnostic, though it tends to use PKI for the banking transactions. It’s got 1.5 million certs. Identrus sets policy and worries about compliance with regulatory infrastructures. It also tracks legal liability, e.g. for identity theft. It also tracks operational aspects and ultimately technology aspects too. PLOT: policy, legal, operational, technology.
Rena: One big problem is using a common language. “Access”. “Assertions” vs. “claims”. How do the definitions make a difference?
Kim: Claims vs. assertions isn’t a very important difference. Essentially they’re the same thing, beyond sets of things vs. individual ones. I prefer “claims” because it’s an assertion which is in doubt, according to the dictionary. But it’s not intended to go against the SAML community. SAML is good in contemporary browser environments. People running SAML installations benefit by having a secure user environment. If we can secure it better, that’s better for SAML. The Shibboleth people worry about home site discovery; the InfoCard paradigm where the user holds representations of their identity could help this. SAML is used between a portal and providers of services to the portal, though there are other use cases. A metasystem would let you authenticate directly to the portal. [Huh? I don’t understand what is “meta” about this. I keep feeling like a number of different things — “meta”ness, user interface consistency, convenience, privacy — are getting conflated.] The other infrastructure wouldn’t go away.
Karen: Identity should be seen separate from the technology to manage it. Identity and security aren’t necessarily identical. We have dealings with Shib, Liberty, the U.S. federal government PKI bridge — people can become fanatics.
Kim: People can get infected by the protocol they work with.
All: Prateek is Mr. SAML; we’ll let him stay up here. :-)
Prateek: Eve in the audience is an original SAMLer, let’s not forget her. :-)
Prateek: We’d be excited to bind to InfoCard if we could figure out what it was in protocol terms! IdP discovery is out of band.
Kim: But authentication is also out of band of SAML, so we’re not competitors.
Prateek/Kim: So let’s work on this together. (They shake hands.)
Q: Eve: So you’ll join the SAML TC, right?
Kim: I don’t have any control of that, but I’m already working with Scott Cantor with Bob Morgan of Shibboleth.
Rena: Have we all given up on a single authoritative source for identity?
Kim: Karen said earlier that Identrus has some problems hooking into the federal government bridge?
Karen: Prateek leaves the binding out of band. Everyone in the Identrus community is bound. The bank that issues the identity, the bank binds themselves to it and assume liability. The bridging environment destroys this usual level of trust. A lot of federated models lose the binding between the parties, and you’re left open to the business jurisdiction without benefit of a contract.
Kim: So the government might consider itself the binding authority, and the bank might consider itself the binding authority, and this might mean there’s reason for you to be in control of that. [So you have to personally host your own identity? This seems to be begging the question. If identity is stuck and it wants to be free, we’re going to have to solve for the general case of sharing identity — though granted that the legal and contractual aspects may be less obviously solvable right now than the technical aspects.] When I was in Belgium, I visited groups doing interesting things with identities. The assocation of mayors was upset at signing legal documents with individual citizens. Think of roles as identities, and they can be tightly or loosely coupled.
Q: Mark Hapner: I’m trying to implement a portal for a business, where employees authenticate directly to the portal, which is an agent to six other outsourced companies. I have legal agreements with them. They all use IT products from many vendors. Today, what aspect of identity can I put on the wire that will allow me to establish this specific exchange such that I can do this outsourcing? What protocol is broadly enough supported to solve this problem?
Kim: SAML is out there and we have a product based on WS-Federation. But people make it work right now.
Prateek: You can use an open-source implementation of SAML, or a product that serves as a gateway. Oracle offers one, e.g.
Karen: What is the business application?
Mark: 401(k) outsourcing.
Kim: Internally, when the employees saw what was being done with 401(k) outsourcing, they were horrified that others could go in and look at their 401(k) plans.
Q: Identity and privacy are in the same domain, particularly in healthcare.
Karen: Identrus wants internal companies to be in control of identity information. This is particularly germaine in the HIPAA space.
Kim: The central security question of identity is privacy.
Prateek: A lot of identity problems have been solved, though. There are broader questions that haven’t been solved, but there are many use cases that are being done today.
Kim: We should applaud every identity effort that takes the issue forward.
[Missed the enterprise systems management panel.]
CIOs: How Interop Matters to Their Business
Dean Lane, CEO Varitools and former Sr. Dir. of IT at Symantec
Vivek Asija, CIO of McGuire Real Estate
Jim Swartz, CIO of Sybase
Vivek: The Internet hit the real estate industry like everyone else. Brokers were caught off-guard regarding IT infrastructure. MLS on the Internet made them fear disintermediation. McGuire had disconnected systems, and lack of interop caused an integration problem. He chose a single-vendor solution to solve the problem.
Jim: Was previously at SRI. Sybase is more than a database company — also middleware and mobility. They optimize database backends. link them, then push data out to the edge (PCs, PDAs, etc.). It has lots of legacy systems; is 22 years old. For various reasons, they don’t partner with SAP or Oracle or Peoplesoft/Oracle. They’ve acquired some middleware companies. Information to be integrated is sometimes real-time, and sometimes reporting information. They manage the data of thousands of customers. Quality of information is an issue in heterogeneous environments. Mergers and acquisitions contribute to the problem. They have a “cleansing factory” to clean up data before warehousing it.
Dean: [He’s like a standup comic! — a standup CIO?] Has been a CIO four times. Wrote a book called CIO Wisdom. The interop issue has been around for a long time, and it won’t just go away. It’s not amenable to just getting smart people in a room and solving it once and for all. There’s technology that’s out there, and there’s technology that’s “out there” — it’s coming at some point, and you’ll have to deal with it. When will you have to re-solve each of your problems again? Putting “re-” on something (rework, review…) is inherently not value-add.
Q: Dean: What are the problems with M&A’s?
Jim: One approach is shut down all the systems and force a change. The other is let them operate semi-autonomously. Where the product lines are very different, the latter approach tends to be more appropriate. We buy about 3 companies a year, from roughly $20-100M in size. Even with the latter approach, you still have to be able to integrate the data. Customer data, HR data, facilities data… If the acquired company is privately held and doesn’t deal with Sarbanes-Oxley, or happens not to have kept good security hygiene around their data, the data may not be clean enough.
Q: In the banking industry, we’ve had lots of mergers. IT management often isn’t asked for an opinion. Do you get drawn in?
Jim: It’s been both ways. Was at SAIC when it bought Bellcore ($1B). It was left semi-autonomous. He can beg to be brought in to the discussion, but sometimes they’re not allowed to disclose too much info into later in the process because of regulations.
[Missed some of the discussion here.]
Vivek: Real estate people don’t work for you; they’re independent contractors of a sort. So they bring a transaction system with them, provided by the CA association of realtors. MLS is the market maker, and we have to comply to it. All the MLS databases for each region need to be integrated, and it’s not trivial. The Real Estate transaction Standard has several different flavors, so it doesn’t help enough in terms of avoiding customization. But now there’s an effort to have a single northern CA MLS, although this may 3 years away.
Q: Where do you stand in terms of web services adoption? We heard they’re a reality, but also that they’re not mature.
Dean: Varitools doesn’t integrate to anybody. They’re a compliance company and they put everything on a compliance server. That box talks to their client systems through standard APIs. They’re moving data, but they’re not interoperating with the other system because everything substantive is done on the box.
Jim: We sell SOA-compliant web services tools. We call them “unwired orchestrators” or “unwired accelerators”. E.g., purchase orders are typically done on a PC, but when someone was on travel, approval couldn’t be done. So now these are pushed out to various devices. The apps are device-independent.
Vivek: RE is pretty far from web services, maybe 5 years behind everyone else. They have to follow the MLSs, which is ironic since the MLS data comes from the RE agents.
Dean: In aerospace, we were given constraints like “We have a space exactly this big, and we need you to build something that does XYZ job that fits into it”. This is the same interop problem.
1 Response
[…] This is quite interesting. […]