Modern Software


January 31, 2006

Click ARCast: Modern Software to listen to this ARCast.

Ron Jacobs:   OK, so, what did you think of... of David's talk?

Anonymous:   I thought he was pretty good. He was real animated, I thought.

Ron Jacobs:   Oh, yeah, and... and did you learn anything?

Anonymous:   Yeah, he explained a lot of stuff about the WinFX and the BizTalk that really made a lot of sense to me.

I thought he was very informative and is a very good speaker.

Ron Jacobs:   OK, and what did he talk about that impressed you?

Anonymous:   I liked the way he boiled down the… the new components of the WinFX and something that most of us can take away and apply back at home. That's about the best speaker we've had so far.

I like it a lot, and he is really cool; he is a very good speaker.

Ron Jacobs:   Did you learn something now?

Anonymous:   Oh, most definitely. I went into it not knowing very much about Windows, the workflow portion of it and the really… BizTalk was and came away knowing lot more about that kind of stuff.

Ron Jacobs:   And that's why we do what we do here at ARCast. Yeah, I am your host, Ron Jacobs, coming to you from VS Live San Francisco, where I have been just chatting it up with many, many of the speakers here, learning a great deal about all kinds of interesting things, and today we have the privilege of being joined by the David that they were talking about, David Chappell. David was delivering his keynote address this morning, and I snagged him inside and said, "Hey David, let's do an ARCast episode." And he graciously agreed to do so, and I think you are going to enjoy this. David is a really smart guy and easy to listen to. So, let's give it up for David Chappell. [Applause] David, welcome to ARCast.

David Chappell:   Thanks, Ron. Thank you very much.

Ron Jacobs:   I have to tell you [a] little joke, because I have never got to do a keynote. I have been waiting and waiting, and hopefully one day I will ascend to the stage of keynote, but I have never gotten there yet. How to get there?

David Chappell:   I am sure… I am sure you're gonna get that, Ron. I don't know the answer to that question, really. I just give talks and eventually I wanted doing talks like this. I think that the big difference is that a lot of people who give talks have a real job. I don't really have a real job. This is the heart of what I do, speaking and writing, so I think I am just more focused on it some ways than most people are who do this kind of thing.

Ron Jacobs:   OK, well, I guess, you know, we have seen each other at many events around the world over the years. I think I first met you at a... at an event at Europe, but if I remember right, it was it was quite some time ago, because I got you confused with a... Oh, I am not going to remember his name. Well, I was on the COM+ team... And there, I can't... It's on the tip of my tongue...This guy that has the Rolling Thunder who wrote the book on COM.

David Chappell:   David Platt.

Ron Jacobs:   David Platt, yes, that's right. So, I got you confused with David Platt, because I was talking about how much I liked his book about COM+ and you said, "That's a nice book, but I didn't write it."

David Chappell:   Oh, that's why I am honored, because David Platt is a good guy. And now, of course, people routinely confuse me with David Chappell, who works for Sonex Software. I began my keynote this morning by introducing him. He was in the front row of the audience, just to make sure the audience [knows] that we are in fact two separate people.

Ron Jacobs:   And that is very confusing on many occasions, I am quite sure. Yeah, so you know, it is an interesting experience sometimes to go Google on the Web, or as you say actually as a Microsoft employee, I will never do that, I would use MSN search. [Laughing]

David Chappell:   The verb "Google" is not in your vocabulary. [Laughing]

Ron Jacobs:   But I search for my name on Web, you know, to see who else is out there. Over the years, I have been contacted by many other folks named Ron Jacobs, because I own and it's quite interesting to see what comes up.

David Chappell:   I own and I get e-mail for David Chappelle, the TV comedian. And I gotta tell you, I routinely get suggestions for shows and skits on the show. I do not think David Chappelle has [the] world's most intelligent audience, based on the e-mail I get, but I could be wrong. [Laughing] Exciting.

Ron Jacobs:   Well, OK, so in today's keynote, you were talking about building a modern software application and I was intrigued by that title. What do you think makes up a modern software application?

David Chappell:   For first of all, constrain the discussion to where we are, VS Live. So, we are talking about Windows development specifically, and so I think that, what it means to be modern is to be using those technologies and those approaches that reflect (a) the latest [that] Windows has to offer and (b) that address the real problems of supporting business process. One of the big themes of my talk this morning was that we as software developers would like to think that we are artists, and sometimes we are, but a lot of [the] time we are there to help somebody make their business processes better in some way, and so we can use new technologies to make that happen. My examples this morning were primarily Windows Communication Foundation and Windows Workflow Foundation. So, to answer your question succinctly, I would say that in the Windows world going forward, building modern applications is going to mean certainly building service-oriented applications, and what it makes sense building applications that are workflow-driven, as well.

Ron Jacobs:   So, this wave of stuff that's coming with WinFX and BizTalk Server 2006, we're certainly enablers for this, but this is a trend that's been coming a long time, right?

David Chappell:   Oh, absolutely. The idea of Service Orientation has been here for who knows how long, but really it's become mainstream now, because finally all the vendors after decades of fighting about it have agreed Web services… have agreed on SOAP. It's like TVM and TCP that happened 10 years ago that gave us the Internet, this agreement is giving us this enormous industry-wide shift towards service orientation.

Ron Jacobs:   Yes, it's too bad we couldn't have agreed on these 10 years ago, and [laughing] we would have been blocked further down the road.

David Chappell:   You know, I have spent almost my whole career working in app-to-app communication, literary 20 years, and I have worked on many preceding technologies like DCE/RPC, CORBA, and DCOM. I have been waiting my whole life, really for this to happen, and I can die happy. [Laughing]

Ron Jacobs:   And I can see it. Your face is just glowing as you talk about this wonderful moment in history.

David Chappell:   Yeah, we are lucky to be alive right now. [Laughing]

Ron Jacobs:   We'll tell our grandchildren, "I was there." [Laughing] Well, so, what's the... As you being exploring Windows Communication Foundation, what do you think makes it so much better than anything we had before?

David Chappell:   We… It's just consistent, rather than having diverse choices enforcing developers to choose the one that best fits with [whatever they're] trying to do, whether its ASMX or .NET Remoting or Enterprise Services or MSMQ. Now you can do all those things from one coherent foundation, and that make perfect sense. You could argue that Microsoft should have done this, years ago. At the same time, it's fair to say the Java world also saw the distributed computing space as comprising these distinct problems, because they also have discrete technologies in all the same areas. They have one that's like remoting, they have one that's like enterprise services, they have one like MSMQ, one like ASMX. So, that view of the world [as] being discrete and being different enough to warrant different technologies was pervasive, for both .NET and Java. Microsoft with WCF has now gotten away from that and said, "No, services are where we are going, because it's the platform, it's the way to do it; hence, WCF."

Ron Jacobs:   And it was the thing that strikes about me is, I am... Having watched this thing evolve with over the, you know, from the inside of the Microsoft is how amazing they did a... building a very simple programming model. I mean, it's not complicated rocket-science stuff, it's pretty easy to put this together.

David Chappell:   First statement, it's easy and it's simple if you are doing fairly straightforward stuff. When you start doing more complex stuff, asynchronous multithreading communication; well, OK. Think about complexity. I think Martin Fowler said this: "You could run, but you can't hide." [Laughing] So, some of those things just become inherently complex, but to do basic stuff is straightforward, and that's a good thing.

Ron Jacobs:   Yeah, absolutely. Well, in the companies that you deal with... Here's the thing, I get lot of people saying, "Well, this sounds interesting, but how real is this?" Is this moved to service-oriented architecture, or are people really being successful doing it and... Or it is just another hype phase?

David Chappell:   Man, this is a great question, and it's something I think about literally every day. I think it's useful to differentiate two separate things here. One of them is the very technical idea that I talked about in my keynote this morning and we have implicitly [been] discussing so far in our conversation, which is that you build new application[s] and they communicate for Windows using WCF, not using remoting or something else. Now, that is a slam dunk. That is where we are going. I feel utterly confident in saying that, because Microsoft pushes us in that direction. It's an improvement. They tell us to do it. Why wouldn't we do it? That aspect of service orientation is absolutely the future for Windows developers. But we talk about SOA (Service of Architecture), there is a range of things people mean by that. If all they mean is building apps on WCF, then I think as I said it's a slam, that's not going to happen. Most often, though, in my experience, by the term SOA, people typically have a more enterprise-oriented view. And so they mean things like especially extensive reuse of services, or at least being able to repurpose existing services for better… agility, I guess is the buzzword. That aspect of SOA I personally [am] becoming a little bit more skeptical about, because I have talked to so many people in so many organizations in the last two years, and we are trying to do this, and some of them get value, but an awful lot of them find that the organizational challenges to that kind of enterprise-wide reuse are overwhelming. The technologies with services have got much better, much easier, but the fundamental problems to deriving that substantial business value are not technical. They are human, [they're] organizational, they are daunting.

Ron Jacobs:   You know, that's a very interesting observation, because I think it may explain why none of the revolutions that we previously had, you know... Object orientation was going to save the world, we are all going to reuse, reuse, and impact is we worked and we found that there wasn't a lot of reuse going on. There was maybe a little bit here and there, certainly it was an improvement, it enabled a, you know... Even the idea of something like the .NET framework has a very substantial advance over the old C run-time libraries, some things that we had years ago. But organizations, they had very hard time achieving reuse for not technical reasons, but people reasons. Like, well, I don't trust those guys and I don't know what they did on the inside of that framework, and I want to rather build my own, and we are going to face the same obstacles here.

David Chappell:   Absolutely, we do face the same obstacles. In some ways they are worse, and in some way is that better, but in some way they are worse. They are better in that… When I was using objects, I would use your code, and so I could rewrite it if I [wanted] to with reusing services exposed by an application [only]. For well-defined services, well-designed and modified services, the service exposes data as well, and in a well-run organization that service provides the only way to get to that critical corporate data. In those scenarios, you couldn't mandate reuse. You couldn't say to people that you want that data, you must call this service. I like that norm. So, from that point of view, it's easier. It is also harder in some ways, though, because with object reuse I can take your code and simply use your code independent of you. With service reuse, you got an app. I am using your app. First of all, why should you let me use your app? You are some part of an organization where some manager who owns in phase four that app, the CPU cycles, the storage. Why [in] the world should this manager let me, elsewhere in the company, build an app that uses his app? What's in it for him? That's a compelling problem that I run across in many organizations, so the level [of] reuse implied by services can be better in some ways. You can force it by tying it [to] unique access to corporate data. It can be worse in other ways, in that requires a degree of integration and sharing across business units that even greater than what objects purported to give us.

Ron Jacobs:   That's very insightful, because, you know... Recently, I recorded an episode of ARCast with Rick Merrifield from Microsoft. He is running a program we have called MOTION, and if you have heard about motion?

David Chappell:   You bet. Yeah

Ron Jacobs:   And so it's a very interesting program, because it's a sort of breaking new ground for Microsoft in that we, you know... typically not done what might... all people might call business consulting, [it] certainly is IT/business consulting, anyway, in that looking at organizations and trying to understand their business process from the business point of view. And he was telling me a story about an organization that had many different divisions, and they had the feeling that these divisions were duplicating a lot of work and that they weren't achieving the economies of scale that they wanted it to achieve, because these business units weren't... didn't understand enough about their own process to be able to identify the duplicate work that was being done. And if you could get through and identify the opportunities for the business to drive economies of scale, lower cost, and improved efficiencies from the business perspective and have the support of the executives driving this down, then the technology enabling is relatively easy, if you could understand from that perspective.

David Chappell:   Hmm. True. In my experience, however, two things: One is that it's very difficult for IT guys to go to the business and say, I am going to help you make your business processes better. [Laughter] The IT guys come in with many organizations approximately zero credibility, and so it just doesn't work. Second, you mentioned an executive support. In my experience, if you have top business-management support for [the] move to SOA in this more enterprise-oriented sense—not just [the] sense of using WCF, building the apps that style, but the enterprise sharing that SOA often imply—if you have business top-down support, your job is much easier and… Yeah, in my experience, getting that support is essentially impossible in at least 90 percent of organizations. And the reason again is that IT just lacks credibility. IT can't go to the business and say, Give us 5 million dollars, [we'll] SOA the world and come back with substantial ROI in three years. It doesn't work. [Laughing]

Ron Jacobs:   I hate to be on that conversation. Yeah, well, you know.

David Chappell:   It's a very short conversation.

Ron Jacobs:   Yeah, maybe that's why it makes sense to bring in, you know, somebody like Microsoft or some other partner, some consultant from the outside to help with that process, because... You know, for the IT staff to try to do that on their own is very difficult.

David Chappell:   It's a first statement. I think it is still difficult, I think that unless the business people themselves bring in the consultants… If IT bring in consultants and says, "Look, business guys, we brought you this consultant," it's still IT coming to them.

Ron Jacobs: Yeah.

David Chappell:   And in so many companies, IT doesn't have credibility of the business. It's a shame.

Ron Jacobs:   Well, it's easy to understand after years of failed projects and failing to deliver on promises, and they have [been] burnt so many times, they just don't want to do it anymore.

David Chappell:   And it's not just that there is this personality division between us and them. Right, we are geeks; they are [frat] boys. We laugh at Star Trek jokes; they laugh at golf jokes.

Ron Jacobs:   Yeah, there is a big communication gap certainly in that, and honestly, well, [a] lot of us have come up from the trenches of being developer and looking at the world through the microscope of development and, you know, we never contemplated the larger question about who is funding this project and who is paying the bills on this and, you know, how is this project [going to] help the company realize any kind of competitive advantage. We never thought about that.

David Chappell:   My talk this morning began with a story I told about that. I began my working life as a musician, and when I was first being a musician I played [in] a band as one of my activities and thought I was an Artist. I perceived what I was doing [as] art, and I was disabused of that very quickly. It was clear that really playing in a band, playing in bars, I was in fact a liquor salesman. And the analogy of developers, I think, is quite real, that we are taught in college and graduate schools to be artists. We were taught that what we do is creative, and it is creative, but you get out to real world and fundamentally, most of the time, we are liquor salesmen. We [exist to] help people make business processes better, faster, and cheaper. There is no shame in that, but I think that embracing that reality is fundamental to being really effective, whether you are talking about a SOA world or any other software project. Now, not to be too negative here, I think we are also artists, just as I and my bar band got some artistry going from time to time, and so we certainly do… We have aspects of art, and I think I embrace and celebrate those. Those are great things. But to a large degree, we exist to make someone else's life better.

Ron Jacobs:   You know, it's funny that you mentioned music, because I am also a musician. In fact, my bachelor's degree is in music, so...

David Chappell:   I didn't know that.

Ron Jacobs:   Guess how many people, you know, who are musicians get in the computer business.

David Chappell:   You might know there was this odd little band [Ron: Yeah] that I was in for a while, it was… We are on hiatus now, it seems, but Don Box at bass, Ted Pattison playing guitar and singing. It's called Band on the Runtime.

Ron Jacobs:   I remember that.

David Chappell:   We sung dumb songs about .NET.

Ron Jacobs:   Yeah, and I request... My favorite was Pat Hellen doing "The Day that IT Died." Did you hear that one?

David Chappell:   That's right, I am the piano player on that.

Ron Jacobs:   Are you? OK, yeah.

David Chappell:   Don is playing bass and I am playing piano. That was a take at Amsterdam.

Ron Jacobs:   That was hilarious. It was very, very good. Yes. Well, so the other really interesting shift (and it's kind of funny to me) is that Indigo took so much of the oxygen, you know. I mean, there was so much hype about Indigo, Indigo, Indigo, which is the code name for Windows Communication Foundation, but later we began to hear about its little brother, which I think [has] very profound implications as the Workflow Foundation. I think that has a lot of potential to change the way we think about architecting systems.

David Chappell:   I absolutely agree. My keynote this morning was about half on WCF and half on Windows Workflow. Windows Workflow is really important. It is, however, I think a little challenging for people to understand [at] first blush, primarily because we all have an association with the word "workflow," and those associations usually are not correct for understanding what Windows Workflow Foundation is all about. So, for example, when you heard about workflow, people tend to think either in a business-process sense where we do this and do that, and then Mary in accounting gets this, it goes to Joe in HR. Or we think in the sense of a graphical tool for information workers, where they can define document flows in workflows. And those are both valid meanings of the term, but that is not what workflow means in the context of Windows Workflow Foundation. Instead, this technology defines workflow in a very technical way. You create these things called "activities," which is just classes that are executed one at a time by workflow engine, and the sequence in which they are executed is defined by the activities themselves. So, this notion very clearly delineating the flow of your application as a service of activities run by this engine is at the technical heart of understanding what it means to use Windows Workflow Foundation.

Ron Jacobs:   Well, you know, the thing that hit me, when I first started looking at, was that lot of the code that you write essentially is doing what thus workflow engine will do, right? You are kind of laying out the processes, a series of steps you [are] going to take, you have conditional branching and you are doing lot of this sort of stuff. So, we have been writing that code for [a] long time and I asked the question, "Well, why would I want to not write that code and describe it in a format that this engine can consume?" And the first time, I was a little skeptical about it, but when I sat down and did some hands-on lab with it and worked with it for a while, I came to realize there are some very substantial advantages, I think, to allowing this engine to run that code for me.

David Chappell:   There are. There are. Just a notion of breaking your process into discrete activities which you—again are really just classes—is interesting. The engine, for example, can insert tracking automatically. So, you can have a run-time record of what's happening inside your process between activities. The engine can also rely on some run-time services that do things like persisting your workflow state automatically when there is a delay, sit waiting for him being responded to something. There are also graphical tools which can let you create workflows graphically if you want to, although the technology does not require using them. You can just write code if you wish. So, I think there are a lot of possible benefits of this. At the same time, I don't think every application will be written as a workflow app. You could argue that it should be (because, at some level, every app is a workflow in the highest, most abstract sense), but there is some level of overhead in understanding required to use Windows Workflow Foundation. So, I guess is that not every app is going to use it, but developers… I think again, back to our theme of modern application, to build modern Windows apps, developers ought to understand what the Windows Workflow Foundation does, what is it good for, and when they are using.

Ron Jacobs:   Well, and of course, most people think of these sort of sequential workflow like a flowchart, you might imagine, right, but I thought as, the more I learned about it, the part that really excited me was sort of the state-driven workflows which I think are really interesting, especially as you consider building application that have to deal with long-running processes and message exchanges that are hard to predict, what order they are going to occur, and building a state-driven workflow seems like a very elegant solution that...

David Chappell:   I agree, that's one of the built-in options in that technology; or, for example, if you have a workflow where the user [by him being, for instance] can cancel any step. If cancellation can occur anywhere in a flowchart, then every single node needs to be a branch. If "Cancel", go this way; if not, go that way. But in the state machine, cancellation is an event. It appears as one event in your state machine. Much cleaner, much nicer.

Ron Jacobs:   Oh, yeah, it's in... So, here is the thing I am thinking about is, on the back end of a service-oriented architecture, so if a bunch of services are collaborating together to get some business process done, you know, using that state machine behind the services sounds very interesting to me, like I could receive a message and in the message maybe I have stuffed a cookie and that tells me the identifier about the workflow, the message relates to. So, correlates the message to the workflow the message the fact that the message received may cause a state transition in the workflow itself and allow me to respond by, say, doing something on the back-end system or sending out another message. I think there is a lot of potential there, but the question I have is when, when do I cross the line between sort of that kind of scenario into a scenario where I probably ought to be using BizTalk instead?

David Chappell:   Yeah, that's a very good question. The model you described of having some business logic built on a workflow that invokes some number of services using, say WCF, is paradigmatic of what people call composite application—a kind of a blowy term—but that is one of the end goals of doing in order to create these kinds of composite apps more easily. So, we will see people are doing that; it might become mainline, it might not. I am not certain about this myself, but it certainly has one application of workflow, certainly. And you are right. When you start thinking about a workflow-based app that talks to other software—which, by the way, is in no way required; a workflow-based app most often, I think, runs into its own process like any other app—but if your workflow-based app talks to other software, then at what point does the problem become an integration problem rather than just a workflow application? And I think the answer is when you start to need the services that you get in a product like BizTalk server; when you need the diverse adaptors—for example [that] BizTalk provides to speak to IBM MQ-Series or to speak to file system or something else—when you need the transformation of schema in messages that you get with BizTalk; when you need, for example, the business-to-business accelerators for standards like swift or HL7; or when you need things like business-activity monitoring. All of which are in BizTalk, none of which are in Windows Workflow Foundation. As you might know, in the release of BizTalk after the 2006 version, the plan is to replace the orchestration functionality in BizTalk with Windows Workflow—so, just that one part of BizTalk. But it is important to understand as well [that] BizTalk is whole lot more than just orchestration. And so, when you need those other things, that's when your problem stops being [a] Windows Workflow problem and becomes a BizTalk problem.

Ron Jacobs:   But you know, it's interesting, as I find that [a ] lot of people are willing to go to great lengths, create lots and lots of service-identified structure, because they hesitate to pick up and learn a new server product like BizTalk server.

David Chappell:   It's more […] stuff, and it can be a horror to convince your manager to write a check for a new software product than to spend to time to do it yourself. Yeah, I think those are real issues.

Ron Jacobs:   Yeah, it's a shame, because I think it's the people who have picked up BizTalk server and used it, I have talked with them, and I find that they are really happy with the result they got, but it was, you know, it was a leap. You have to take a leap to get there, and once you did, you are happy you did it.

David Chappell:   Yeah. In general, it's my experience, as well, and the product can be really cheap in some configurations, too. People are scared of, in some ways, by the high price and the complexity of other integration products. BizTalk is just different in some ways.

Ron Jacobs:   Yeah, and you are right. I mean, other integration products, I have seen the price tags of some of those and they are astonishing. How much money they get out of those makes me wonder why we sell BizTalk as cheaply as we are doing, in comparison.

David Chappell:   You might have sold more copies if it were more expensive.

Ron Jacobs:   Yeah, that's true. Yeah

David Chappell:   Because people will feel more comfortable buying it. It's the reflection of, I think, of the value, the real business value the integration has, because firms like webMethods make lots of money with relatively high-priced products. They are very successful. They are doing something right. They are providing real value to [the] company, so are there truly is a value in these kinds of products.

Ron Jacobs:   I think these sorts of integration problems are the kind of problems that they have to be solved, you know. It is a just like a business concept where we say, We have to solve this, we must spend the money and we are going to do it. And so hopefully, you know, more and more people will pick this up, and of course, as you said, you can get a BizTalk developer edition very, very cheaply. So you can you can work with it and learn it, and without having to make an enormous price commitment, and evaluate it for projects and see if it works for you. [David Chappell: Right.] Well, we are about [out of] time, but thanks so much for stopping by here on your busy day.

David Chappell:   It's my pleasure. Thanks, Ron.

Ron Jacobs:   Yeah, and [I] look forward to seeing you at some... I am sure I'll bump into you somewhere else in the world.

David Chappell:   I am sure we will. [Ron Jacobs: Alright.] I look forward to that, too. [Ron Jacobs: OK, see you.] Thanks.

Ron Jacobs:   David Chappell, everyone, David Chappell. Very, very bright, intelligent, just an all-around smart guy, and I love talking [to] guys like that, because I always come away smarter for the experience, as I hope that you do, as well, when you listen to ARCast. So, tell me what you think, send me a note to I would like to know who you would like to hear from, what kind of interesting person would you like to hear interviewed on the show, and maybe I will get them on. Who knows? See you next time on ARCast.