System Evolution

Vol. 4 No. 8 – October 2006

System Evolution

Interviews

Business Process Minded

A new paradigm created to empower business system analysts by giving them access to meta-data that they can directly control to drive business process management is about to sweep the enterprise application arena. In an interview with ACM Queuecast host Michael Vizard, Oracle vice president of product development Edwin Khodabakchian explains how the standardization of service-oriented architectures (SOAs) and the evolution of the business process execution language (BPEL) are coming together to finally create flexible software architectures that can adapt to the business rather than making the business adapt to the software.

Business Process Minded - Transcript

Transcript of interview with Edwin Khodabakchian, vice president of product development at Oracle

This is a transcript of Business Process Minded, our Queuecast interview with Edwin Khodabakchian, vice president of product development at Oracle.

MICHAEL VIZARD: Hello, and welcome to the this edition of the ACM Queuecast with your host, Mike Vizard. Joining me today to talk about business process management is Edwin Khodabakchian, Vice President of Product Development for Oracle. Welcome, Edwin. How are you?

EDWIN KHODABAKCHIAN: Good morning. Thank you for having me.

Large Scale Systems: Best Practices

Time again companies moving to build large scale systems and networks stumble over the same problems. In an interview with ACM Queuecast host Michael Vizard, Jarod Jenson, the brains behind the Enron Online trading site, talks about the best practices he emphasizes now that he is the chief architect for Aeysis, a consulting firm that specializes on advising clients on how to build manageable high performance systems.

Large Scale Systems: Best Practices - Transcript

Transcript of interview with Jerod Jenson, Enron Online

This is a transcript of Large Scale Systems: Best Practices, our Queuecast interview with Jarod Jenson, formerly of Enron Online and now chief architect for Aeysis.

MICHAEL VIZARD: Hello, and welcome to this edition of the ACM Queuecast with your host, Mike Vizard. That's me. Today we're going to be talking about performance tuning issues as they relate to really high performance systems in general, and how everything we touch is getting more and more complex. Joining us today to discuss this issue is Jarod Jenson, who was formerly a technical architect with Enron On-Line, and today is the Chief Technical Architect for Aeysis, a consulting firm that specializes in business critical applications and related performance tuning. Jarod, what are the most common mistakes people make when they first start running into performance issues on really complex systems?

JAROD JENSON: Well, there are several of them, aside from just causing the problems themselves through sort of happenstance or intention. Probably if I break down the list into a few elements, the most common problems, number one would have to be that they never had a good test harness for doing performance analysis to begin with. So a lot of times they run into these problems in production, which will reduce your ability to debug the problem. So test harness is the number one thing. That's how these problems get into production. Probably the second thing is everybody's going to deny it's their problem, right? "Hey, our app works when we tested it over here in development," or "The network looks good," or "The system looks good." You know, it's always that. Everybody up front is going to deny it, so it takes a little while just to get some ownership around the problem. I guess next will probably be that people don't use the tools that they have at their hands. So you'll walk into a problem and say, "Okay, give me the data you've collected to date," and everybody will be like, "Well, we have the metric that shows it's slow," but they haven't collected the data from just the tools that come with the OS or the metrics they get from their own QA systems that come with the applications or networking sniffers or packet analyzers or anything. I guess probably the next thing, as they start getting through these others, is they fail to eliminate things that are complete improbabilities, so they're chasing this ever-widening universe of things, and they don't go through the list and say, "You know what? It can't be this particular thing over here." Or, conversely, they don't recognize things that are appropriate probabilities for causing the performance problems. I guess maybe the last thing in the list, once you get through all of these, would be just the lack of patience. In doing these on a day-to-day basis, I've sat and just watched -- you know, stared at a sniffer for literally three hours, no moving, no lunch, no food, no water, just literally staring at a sniffer and solved a problem. So there's got to be some patience associated with it and knowing that you've got to get back in and dig into this data numerous times. That would probably be my top five list, I guess.

A Conversation with David Brown

This month Queue tackles the problem of system evolution. One key question is: What do developers need to keep in mind while evolving a system, to ensure that the existing software that depends on it doesn’t break? It’s a tough problem, but there are few more qualified to discuss this subject than two industry veterans now at Sun Microsystems, David Brown and Bob Sproull. Both have witnessed what happens to systems over time and have thought a lot about the introduction of successive technological innovations to a software product without undermining its stability or the software that depends on it.

A Conversation with David Brown

The nondisruptive theory of system evolution

This month Queue tackles the problem of system evolution. One key question is: What do developers need to keep in mind while evolving a system, to ensure that the existing software that depends on it doesn’t break? It’s a tough problem, but there are few more qualified to discuss this subject than two industry veterans now at Sun Microsystems, David Brown and Bob Sproull. Both have witnessed what happens to systems over time and have thought a lot about the introduction of successive technological innovations to a software product without undermining its stability or the software that depends on it.

David Brown began his career in computing with the disruptive innovation brought about by the microprocessor generation: first on the SUN project at Stanford University and then as a founder of Silicon Graphics. He has now worked for more than 14 years on the Solaris system at Sun, where nondisruptive innovation (evolution and sustainability) is critical. Both the length and breadth of Brown’s career give him a unique perspective on systems and how they evolve. Brown led the Application Binary Compatibility Program for Solaris and discusses how new functionality is introduced in that system without breaking existing applications.

Kode Vicious

Saddle Up, Aspiring Code Jockeys

Dear KV, I am an IT consultant/contractor. I work mainly on networks (Im a Cisco Certified Network Associate) and Microsoft operating systems (Microsoft Certified Systems Engineer). I have been doing this work for more than eight years. Unfortunately, it is starting to bore me. My question is: How would I go about getting back into programming? I say getting back into because I have some experience. In high school I took two classes of programming in Applesoft BASIC (archaic, I know). I loved it, aced everything, and was the best programming student the teacher ever saw. This boosted my interest in computer science, which I pursued in college. In college, I took classes in C++, Java, and Web development (HTML, XHTML, JavaScript). I did great and had fun. For various reasons, I ended up leaving college and becoming a network administrator, and for the past eight years have been doing this and that and everything else IT-related. But I haven't been programming. The extent of my programming work experience is with MS Excel macros (yuck!) and basic VB coding in Microsoft Access. So how could I start becoming a programmer? Visual Studio 2005? Java? Eclipse? I enjoy self-learning and have found that achieving certifications gets my foot in the door. Is there a particular suite that I could get certified in to get my newly desired career going?

Saddle Up, Aspiring Code Jockeys

A koder with attitude, KV answers your questions. Miss Manners he ain’t.

This month KV offers advice to readers considering careers as full-time coders. He suggests that new programmers learn everything they can by reading magazines, journals, and Web sites. And what better place to engage in such learning than this very column? It might be a while before we publish our deluxe, hardcover Kode Vicious Compendium, so until then we suggest you visit http://www.acmqueue.com, where we’ve archived all past KV columns for quick and easy reference.

Dear KV,

by George Neville-Neil

Articles

The Heart of Eclipse

A look inside and extensible plug-in architecture
ECLIPSE is both an open, extensible development environment for building software and an open, extensible application framework upon which software can be built. Considered the most popular Java IDE, it provides a common UI model for working with tools and promotes rapid development of modular features based on a plug-in component model. The Eclipse Foundation designed the platform to run natively on multiple operating systems, including Macintosh, Windows, and Linux, providing robust integration with each and providing rich clients that support the GUI interactions everyone is familiar with: drag and drop, cut and paste (clipboard), navigation, and customization. You can think of Eclipse as a "design center" supported by a development team of 300 or more developers whom you can leverage when developing your own software.

The Heart of Eclipse

A look inside an extensible plug-in architecture

DAN RUBEL, INSTANTIATIONS

ECLIPSE is both an open, extensible development environment for building software and an open, extensible application framework upon which software can be built. Considered the most popular Java IDE, it provides a common UI model for working with tools and promotes rapid development of modular features based on a plug-in component model (figure 1). The Eclipse Foundation (http://www.eclipse.org) designed the platform to run natively on multiple operating systems, including Macintosh, Windows, and Linux, providing robust integration with each and providing rich clients that support the GUI interactions everyone is familiar with: drag and drop, cut and paste (clipboard), navigation, and customization. You can think of Eclipse as a “design center” supported by a development team of 300 or more developers whom you can leverage when developing your own software.

by Dan Rubel

The Long Road to 64 Bits

"Double, double, toil and trouble"... Shakespeare's words (Macbeth, Act 4, Scene 1) often cover circumstances beyond his wildest dreams. Toil and trouble accompany major computing transitions, even when people plan ahead. To calibrate "tomorrow's legacy today," we should study "tomorrow's legacy yesterday." Much of tomorrow's software will still be driven by decades-old decisions. Past decisions have unanticipated side effects that last decades and can be difficult to undo.

The Long Road to 64 Bits

Double, double, toil and trouble—Shakespeare, Macbeth

JOHN R. MASHEY, TECHVISER

Shakespeare’s words (Macbeth, Act 4, Scene 1) often cover circumstances beyond his wildest dreams. Toil and trouble accompany major computing transitions, even when people plan ahead. To calibrate “tomorrow’s legacy today,” we should study “tomorrow’s legacy yesterday.” Much of tomorrow’s software will still be driven by decades-old decisions. Past decisions have unanticipated side effects that last decades and can be difficult to undo.

For example, consider the overly long, often awkward, and sometimes contentious process by which 32-bit microprocessor systems evolved into 64/32-bitters needed to address larger storage and run mixtures of 32- and 64-bit user programs. Most major general-purpose CPUs now have such versions, so bits have “doubled,” but “toil and trouble” are not over, especially in software.

by John R. Mashey

Curmudgeon

You Can Look It Up: or Maybe Not

Chasing citations through endless, mislabeled nodes
Many are said to have said, "If I can't take it with me, I'm not going!" I've just said it, but that hardly counts. Who, we demand, said or wrote it first? It's what I call (and claim first rights on) a FUQ (frequently unanswerable question, pronounced fook to avoid ambiguity and altercation). Yogi Berra's famous advice was "You can look it up," meaning, in fact, "Take my word on this." He knew quite well that few had the means or patience to wade through the records. Nowadays, of course, as we quip in Unix, it's easier done than sed. The portmanteau wep for grepping the Web, now realized and refined in countless search engines, lets us take up Yogi's challenge at face value with a few simplistic keystrokes and mouse-clicks. Yet, as I aim to indicate, life - at least the life of serious scholarship - is not a bowl of Googles.

You Can Look It Up—Or Maybe Not

Chasing citations through endless, mislabeled nodes

Stan Kelly-Bootle, Author

Many are said to have said, “If I can’t take it with me, I’m not going!” I’ve just said it, but that hardly counts. Who, we demand, said or wrote it first? It’s what I call (and claim first rights on) a FUQ (frequently unanswerable question, pronounced fook to avoid ambiguity and altercation). Yogi Berra’s famous advice was “You can look it up,” meaning, in fact, “Take my word on this.” He knew quite well that few had the means or patience to wade through the records. Nowadays, of course, as we quip in Unix, it’s easier done than sed.1 The portmanteau wep for grepping the Web, now realized and refined in countless search engines, lets us take up Yogi’s challenge at face value with a few simplistic keystrokes and mouse-clicks. Yet, as I aim to indicate, life—at least the life of serious scholarship—is not a bowl of Googles.

Seeking earliest attributions has serious applications for etymologists and sociolinguists. Related questions of establishing priorities also loom large, litigable, and expensive in patents and intellectual property disputes. Indeed, it has emerged as part of a newish science called citationology, of which more anon. Take the proper noun Google and its derived parts of speech: verbal (“As I was a-Googling”); adjectival (“Google morality”); improper noun (“There’s nothing like a nice Google.”). You may think, with good reason, that the origins of Google have something to do with the incredibly large number googol (the 10100 spurious matches planted by advertisers), or with the act of goggling (the bulging or squinting [Middle English] eyes as the spurious matches scroll by). My own preferred etymology is the googly, a sneakily-bowled cricket ball that spins in the opposite direction to that expected by the batter.2 All of which hints at the perceived dangers of naively scanning the Web. Even with enlightened Boolean modifiers, literal strcmp()-type char-string matches are, indeed, too damned literal. As Dr. Walter Martin (the original Bible Answer Man) used to say, “Text without context is pretext.” And context cannot yet be conveniently, decently parsed and automated.

by Stan Kelly-Bootle

Interviews

IDEs in the Age of Eclipse

In this edition of the ACM Queuecast hosted by Mike Vizard, Oracle's chief architect for tools and middleware Ted Farrell talks about the role of IDEs in the Eclipse open source era, and why developers still need IDE tools to better leverage a wide variety of middleware assets and take a more modular approach to building complex business applications.

In this edition of the ACM Queuecast hosted by Mike Vizard, Oracle's chief architect for tools and middleware Ted Farrell talks about the role of IDEs in the Eclipse open source era, and why developers still need IDE tools to better leverage a wide variety of middleware assets and take a more modular approach to building complex business applications.

Articles

Breaking the Major Release Habit

Can agile development make your team more productive?

Keeping up with the rapid pace of change can be a daunting task. Just as you finally get your software working with a new technology to meet yesterday's requirements, a newer technology is introduced or a new business trend comes along to upset the apple cart. Whether your new challenge is Web services, SOA (service-oriented architecture), ESB (enterprise service bus), AJAX, Linux, the Sarbanes-Oxley Act, distributed development, outsourcing, or competitive pressure, there is an increasing need for development methodologies that help to shorten the development cycle time, respond to user needs faster, and increase quality all at the same time.

by Damon Poole