This is a transcript of a live online chat, moderated by Grady Booch on December 7, 2006, in which he discussed and answered questions related to the release of desktop tools from IBM Rational software (IBM Rational Software Delivery Platform Desktop products V7) two days earlier, as well as the value of SOA and the role of Eclipse.
Grady Booch: Hello everyone. Thank you for joining me this afternoon -- well, whatever time zone you happen to be in -- for this chat regarding IBM Rational's latest release. As you likely know, earlier this year, we released a set of our team products. This week, the so-called Caspian release (that's our internal name) represents the release of our desktop products. Also with me today are Brian Bryson, who can answer any details questions regarding the ASQ [automated software quality] side of things, and Steve Weaver, who can do the same for our ADC [analysis, design, construction] products.
There is no truth the the rumor [that] I'm using IBM ViaVoice to turn my speech into text, although I DO have ViaVoice running on my Mac...it's very sweet.
I'd like to start with just a few words about the theme of our release, then open it up for questions, as I'd like to make this chat serve your needs. Let's start with SOA....
I must admit, that I'm somewhat amused by all the press that SOA has been receiving over the past few months. Amused, because on the one hand, there is no doubt that service-oriented architectures do add value -- particularly for organizations who are faced with addressing the problem of federating a common user experience, despite the fact that, behind the scenes, there are heterogeneous systems. The problem is compounded when an organization has grown by acquisitions and the complexity of said systems is even worse. How, then, does one bring these systems together?
I should also mention that an organization will commonly have some of their assets webified and some -- mainly the legacy work -- not. Thus, SOA, a service-oriented architecture, gives us the means of unifying such systems. HOWEVER, simply using SOA will not make your kids like you, make your teeth brighter, or your love life better although, if you read some of the journals, that's exactly what it seems to be.
Bill Higgins: It seems like SOA is just a bunch of old best practices with regard to information hiding and encapsulation applied to a distributed computing environment. Do you think it's more than that?
Grady Booch: Bill suggests an interesting theme and by the way, I didn't pay him to ask that! Take a look at what I wrote on my blog in October (I won't repeat it here) [http://www.booch.com/architecture/blog.jsp?archive=2006-10.html] on snake-oil oriented architectures. This blog is mirrored on developerWorks at http://www.ibm.com/developerworks/blogs/page/gradybooch. In essence, as Bill suggests, there is something fundamentally not new about SOA, at least not new in the sense that SOA is, in effect, a message-passing pattern.
However, there are differences. I distinguish between SOA with a big S and SOA with a little s -- the big S being classic Web services, and the little s being true services offered up by a system, as manifested in a set of APIs that let you pass messages/objects and initiate/derive some behavior from that system. There is something different in the way one approaches services, however. Again, it still requires a focus on the fundamentals -- namely, a focus on good architectures. I could spend a few hours talking about architecture.
Jeff Butler: Seems to me that it's just another "pseudo product" for pointy haired salespeople to sell. Promise the moon, then disappear before anything real has to be delivered.
Grady Booch: Oh, I don't think it's quite that bad, Jeff, but one does have to beware of the hype factor, which is why I tend to emphasize the A in SOA... drum roll please ...
Let me briefly describe it as the problem of setting the most significant design decisions in a system -- i.e., all architecture is design, but not all design is architecture. If you accept that architecture is important and that it is fundamental to SOA in particular, SOA being in effect one architectural design pattern, then it follows that providing tooling -- both ADC and ASQ tooling -- for the same there is value. (OK, let me catch my breath and rest my fingers a moment). I have a few more things to say, but, any questions thus far?
If you don't I have some for you ... a trick I learned from Bill Higgins' chat yesterday. And if you weren't there, do read Bill's transcript [http://www..ibm.com/developerworks/java/chat/higgins.html]. It will change your life!
Bill Higgins: Grady, what has caused the big interest in SOA in the past couple of years? Is it technology-driven or marketing-driven?
Grady Booch: I think it's a confluence of events. First, we had a period of time where organizations were webifying their systems (if "google" is a verb, than surely I can make "webify" a verb too). During this time, groups struggled with the right architecture for putting facilities online that were historically invisible to their customers. Thus, there was a technology "push" as Web standards and best practices evolved, and a business "pull" that meant customers demanded such access. Most organizations have finished webifying the low-hanging fruit, and now the compelling move is toward making the harder things accessible -- things that traditionally were in non-web-centric legacy systems. So, the architectural question is ... how?
Well, connections among such disparate systems is nothing new. Remote procedure calls, sharing of files, FTP, are all well-known mechanisms, as are message-passing mechanisms like CICS, or what's manifested these days in things like CORBA and its successors. If you have a web-centric system and you want to pass messages through firewalls, well, this is what SOAP was born of. The web services we see today are solving the problem of, in effect, message passing across firewalls using standard Web protocols -- the SOA with the big S. This, then, is why I think people are struggling with SOA today, and why tooling to support them now is so timely.
In my lectures, I use this visual aid -- OK, it's my hand -- and I point out that the reason that Ajax is so hot these days is that it deals with building bits on the fringe of systems.
(Ajax, by the way, was Bill's topic yesterday.) If you think of my fingers in that visual aid as the silos that need to be federated, then SOA offers the glue to bind them together.
But one must design messages carefully. I've seen too many organizations fail in their approach to SOA by just slapping services about and ignoring the semantics of the messages that are passed. This is a significant design decision, ergo, an architectural decision, (and, among other things, is one of the things that the latest release of our modeling tools focuses on, namely, the modeling of services). Let me not ignore the testing of said services either. OK, enough about me.
Michael O'Connell: Grady, I know I've heard others ask: How does Eclipse fit into the equation?
Ferran Rodenas: Grady, I'm Ferran Rodenas. Two general questions, which are the biggest concerns about SOA and how the Rational toolset could help to mitigate them? It's just a technological change or an organizational change also?
Grady Booch: And I would like to know how many of you/your organizations are currently involved in trying to implement some degree of services...
Hello Ferran. OK, I think there are four questions there. As for Ferran's question on the biggest concerns about SOA: My experience is that organizations fail to understand that a sound architecture -- and the processes that lead to that architecture -- are a precursor to having SOA used properly. As for the tooling, let me have Steve and Brian step in for just a moment, and offer a few words on the specifics of the V7 release that support SOA, then I'll come back to the organizational part of your question.
Brian Bryson: Be glad to cover a bit on the testing side, and I'll leave the construction to my noble partner, Mr. Steve Weaver.
Grady Booch: Fire away then.
Steve Weaver: You first, Brian.
Brian Bryson: On the testing side, we've always categorized testing into two broad categories...black box and white box. The "box" refers to the system...where in black box testing you have no visibility to the inner workings of the system. Logically leading us to "white box" where you do have visibility. On the black box side, the architecture is ... (and Grady, don't fire me for saying this) irrelevant. We test the system as the user sees it. And the user has no visibility into how the thing works. Essentially we provide inputs, and validate that the system outputs are what we expected. We've been doing this for years -- regardless of how the system was built -- webified or not.
Grady Booch: I have no firing authority! And you are correct...indeed, I'll go so far to say that the best architectures are totally invisible to the user...as they should be...whenever the bones of the architecture stick through, the development team has done something seriously wrong.
Brian Bryson: Boy, I'm glad to hear you say that. So, on the black box side -- which is what 90% of what the QA teams focus on, SOA is a non-starter. It's business as usual. Now, things get interesting on the white box side, where you do see how things operate. In white box testing, you see the service calls, you see what comes back, you can touch the WSDL if you'd like. Here, SOA testing requires new technology. As part of this release, we've put out a beta/tech preview of a new SOA testing product which does exactly this. We actually snuck this out a little before the release, and we've had great feedback.
Good testing requires both black and white box...and we're doing some great stuff on both sides. If anyone's interested in finding out more about the beta of our new technology, ping me at bbryson@ca.ibm.com.
Grady Booch: Thanks, Brian. Steve, do you want to mention some of the modeling facilities we are offering in this release?
Steve Weaver: Sure. On the modeling side of things, we've added the UML profile for software services into RSA, and also a services modeling template. We've also added process guidance for SOA into the process advisor via RUP. In addition, from a development standpoint, we've improved our web services development tools by creating a brand new web services wizard to allow you to build top down and bottom up web services very easily. One of the key messages really is about the ease of use of a lot of the new features -- consumability is a major aspect of this release. Back to you, Grady.
Grady Booch: Thanks Steve. Ferran, you also asked about the organizational implications....
In Jim Coplien's book, Organizational Patterns of Agile Software Development, he and his co-author describe a number of common structures and practices of hyperproductive teams. One of the groups of patterns that I resonate with are those around the architect and architecture patterns, such as "organization follows location," "organization follows market," "developer controls process," "architect controls product," and my all-time favorite, "architect also implements." These patterns -- I've been using the name of these patterns from Jim's PLOP 1 article, though they may have changed slightly in his organizational patterns book -- reflect the notion of hyperproductive teams having this binary star organization, with the architect and product manager in tight conjunction, orbited then by all the other stakeholders.
My point is that, if you've already got the fundamentals down with your organization, then moving to SOA is not revolutionary. But if you don't have your organization down, you'll want to reconsider how you architect to get SOA right. Just throwing services on a legacy platform and seeing where they stick is a Really Bad Way to approach SOA.
Bill Higgins: You were pretty influential in popularizing object-oriented software development with your books and articles on the topic. how do you see the relationship between OO and SOA?
Grady Booch: The answer for me is that it all comes down to some fundamentals. There are just a handful of principles that I find common among hyperproductive teams, and absent from less productive ones -- a focus on building crisp abstractions, having a good separation of concerns, having a balanced distribution of responsibilities, and a fierce drive toward simplicity. Those things are at the heart of both OO and building good architectures, with or without the use of services.
Frodenas: OK, I have another question related to your last comment, but after Michael's one: How does Eclipse fit into the equation?
Grady Booch: The short answer is that Rational has made the architectural decision to base all of our desktop-facing tools on the Eclipse platform. Being open source, that platform offers a well-engineering foundation for the developer experience. The past several years, we've been moving our tools to that platform, and this V7 release in effect represents a continuing maturation of that effort. (The best architectures are grown over time.) Is that a fair, albeit short, assessment, Brian/Steve?
Steve Weaver: Yes, that's good.
Brian Bryson: Your answer works on the testing side as well.
Chris Fagyal: Grady, Hi, Chris Fagyal from BAE Systems in Minneapolis. I'd like to expand the Eclipse question and talk a bit about different concerns re: Java vs. C++. I'm interested in how the Caspian release mitigates and addresses some of the C++ issues that have been present in Eclipse (and thus in RSA 6), which was developed as a Java environment. It seems all of the brightest and best technologies are only Java, or are poorly done for C++. How is IBM addressing this disparity with Caspian and in the future?
Grady Booch: BAE...hmm, I've heard of you guys ...
Chris Fagyal: You visited years ago when it was United Defense ... I've read your paper you wrote for us.
Grady Booch: Ah yes, I remember.
Chris Fagyal: You were spot on.
Grady Booch: But now that you told everyone here that I visited United Defense, afraid I'll have to kill all of you for knowing that ... homeland security, you know.
Bill Higgins: <signing off
Chris Fagyal: *chuckle*
Michael O'Connell: <ducks>
Grady Booch: We (IBM) continue to invest mightily in the C++ side of Eclipse, but I must say that I personally am not that close to the language side of Eclipse. I use Eclipse myself (on my Mac!) for just Java work. But I can get a good answer for you by pinging some of my Eclipse colleagues. Steve, do you have a deeper answer?
Steve Weaver: Chris, the answer is that our C++ support is much more robust in this version of Eclipse -- we're leveraging CDT v3. And we've brought our modeling support on a par with that for Java.
Chris Fagyal: CDT v3 still lacks many of the best features from Java...the real time visual traces, the code review stuff, etc.
Steve Weaver: That's true, but we're building the framework for more in the future -- code review for example is now part of a customizable framework that will allow us to build C++ code rules fairly easily. I think you'll find that the C++ experience in now more similar to the Java experience.
Grady Booch: Chris, do you folks mainly use C++?
Chris Fagyal: The project I am on, Future Combat Systems, at least at BAE is C++ and will be for another 6-8 years... At least we are out of the Ada dark ages.
Grady Booch: Now now. Ada helped beget C++ which begat Java. Oh, then you know Alex Bell?
Chris Fagyal: I know of him...A friend of mine at BAE works directly with him. I've read his paper and your response as well regarding death by UML.
Grady Booch: He he, yes, that was a fun article. (Sorry for the name dropping, but Alex is the architect on the Boeing side -- I think I've got that right -- for the future combat system...
Chris Fagyal: Yes he is...Scott Edgerton on the BAE Side...
Grady Booch: ... and as a taxpayer and citizen, I hope you guys are successful. So, thank you for all you are doing! (I said pretty much the same thing to the folks who wrote the software for the CT scan machines that saved my life.)
Chris Fagyal: Steve: Thanks for your input. I'll be pinging you guys more at RUC this summer. Grady: thanks.
Grady Booch: Sure.
Chris Fagyal: It's a long process, but things are going well. Hope to see you at RUC [Rational User Conference] this coming year Grady. We missed you last year.
Grady Booch: I'll not be at the RUC again, sorry...tis my 30th wedding anniversary. By the way, a bit off topic, but I've been doing a lot of work with the gaming industry these days, and that community is more C/C++. They too are just now moving to Eclipse (well, some of them).
Grady Booch: Any other SOA/product questions? We have about 5ish minutes before we have to close down.
Frodenas: A more specific question, on mainframes (in my case, IMS/PLI/DB2) we used the paradigm screen-transaction-screen. Changing this to be SOA compliant is very hard, as you can't reuse most of your legacy code. And if you try to reuse them, you become very inefficient (MIPS consumption!). It's more easy to webify. Apart, there are lots of organizational behaviours to change. Any recommendation? (And calling IGS [IBM Global Services] is not a valid answer.)
Grady Booch: Call IGS. Ooops, wrong answer. The first question I'd ask is an architectural one: Why do you want to use SOA at that level? This is what I meant earlier about the Ajax/SOA combination. SOA can provide much of the glue in the infrastructure and Ajax can offer up the dynamics of the stuff on the edges, but I'd need to understand your architecture a bit better.
Rbhagat: Will RAD7 work with WID 6?
Steve Weaver: Not at the moment. WID and RAD7 are based on different versions of Eclipse, so they cannot share an Eclipse shell.
Rbhagat: Thanks.
Bill Higgins: Grady, are there any systems you've studied as part of your Handbook of Software Architecture which have given you insights into the problems that the SOA initiative is trying to solve?
Grady Booch: Actually, none yet, Bill. There are several systems I've started to dig into that are using SOA as an architectural mechanism. One happens to be a banking system, but that's all thus far. So, to partly answer your question, there are few systems I've studied thus far for the handbook that have used SOA in a big way, but there are many for whom SOA is a good architectural pattern to consider as their systems evolve. And indeed, that's where most organizations are these days -- at the cusp of that decision point.
Michael O'Connell: Any final question?
Frodenas: Grady, last question, any plans to develop and integrate the Rational toolset with a central metadata repository? You know, reuse, more depth impact analysis, ...
Grady Booch: Well, we should perhaps set up a chat with Grant Larsen and his work on the asset manager. The short answer is...there's more to tell you about.
Chris Fagyal: Any insight from any of you into the progress and future of Jazz? To use a pun, the hour-long seminar last year at RUC got me "jazzed."
Grady Booch: As to the progress and future of Jazz... Bill's part of the development team, and I'm working a bit with the Jazz team on the collaborative side of things. There will be an editorial in an upcoming issue of Dr. Dobbs Journal that I wrote about collaboration, which will tell you a bit of where my head is, and alphaWorks [http://www.alphaworks.ibm.com/] is launching a CDE (collaborative development environment) section that has a longer article. So, go peek there.
Michael O'Connell: Looks like we've come to the 60 minute mark. Grady, again many many thanks for taking time to answer questions today. Thanks to everyone for joining today's chat.
Grady Booch: G'day all!
| 
