You will be redirected in 30 seconds or close now.

ColdFusion Authors: Yakov Fain, Jeremy Geelan, Maureen O'Gara, Nancy Y. Nee, Tad Anderson

Related Topics: ColdFusion

ColdFusion: Article

System Thinking

System Thinking

It is not enough to do your best; you must know what to do, and then do your best."
- W. Edwards Deming

In several recent CFDJ articles, I've described software architecture as akin to model building. In both designing software models and building scale models, it's important that the model be internally consistent as well as sufficiently rich to encompass the desired behaviors of the real-world system.

For example, if you want to create a model car, you will want to ensure that it's internally consistent (turning the wheels does not cause the hood to open, for example) and rich enough so that if, for another example, we open the hood of the car, we see a model engine.

Software, of course, isn't nearly so visual as a scale model - a fact that makes the discipline of software architecture difficult: when you set about building a software version of a model car, all the construction occurs in your mind. The problem is that brains aren't particularly good at storing large amounts of complex information, so our species has developed writing and drawing as ways of documenting our thoughts. Software architects employ a variety of tools to translate the invisible to the visible - from cocktail napkins to UML diagramming programs.

But static scale models themselves are not capable of doing the real work needed to provide benefit to users. A superficial object model analysis may determine that we need (for example) both a Car and an Engine object, but this alone doesn't specify how the two will work together.

Identifying objects isn't enough; we must make sure that those objects interact properly. And that's precisely the definition of a system: a group of interacting, interrelated, or interdependent elements forming a complex whole.

In my simple example of a Car and an Engine, it's simple enough to see their relationship, but the more complex an application is, the more it must do, or the more likely it is that our application will change over time, the more important it is that we build a system that is flexible enough to withstand the shocks of future changes - that we have thought through the best ways for our objects to interact.

Too often though, a software application is seen as a solution to a specific problem. We (hopefully) find out what users want and then build it for them. But this approach misses a key ingredient of virtually all software requirements - that the requirements themselves will change as the business environment changes.

In more stable times, software could be built and counted on to run without alteration for years, even decades. But the pace of change has accelerated to a point where software is often out of date before it is even released (and this is a large cause for the high degree of software failure). Therefore the need for good systems analysis is greater now than ever.

But how shall we design systems for future environments, which, by their very nature, are unknown? Over many years of building software, we have found that the most successful software (in terms of longevity) has certain common features, such as information hiding, encapsulation, and loose coupling. A great deal of theoretical understanding has been gained from the study of both successful and failed software systems.

Does such theoretical knowledge help those of us in the trenches, though? It does - both in the design of modern languages such as Java and, of more immediate use, in the rise of concrete guidance on how to design flexible systems of object interactions. Such guidance is known by the term, design patterns.

Design patterns are unique in that they offer help on deciding how objects should interact - how, in essence, to create mini-systems that are maintainable. If that sounds too abstract to you, consider a design pattern in a field different from our own. (Apologies to our international readers who may not be that familiar with the American pastime, baseball.)

A Practical Example
By a wave of my magic wand (handily kept for just such occasions), you have been turned into the shortstop for your favorite baseball team. (If you've ever read the wonderful book, The Year the Yankees Lost the Pennant, or seen the movie based on it, "Damn Yankees," you'll recognize the situation: a regular guy suddenly becomes a major league player. In the book, there was some soul-dealing involved with the devil; luckily your situation has no such dangers.)

You've got the fans, the salary, and (most profitably) the endorsements. But alas, you lack experience. There are limits, it seems, to even the most magical of wands and some things cannot be granted; they must be learned.

As you take the field, you try to recall the games you've seen on television, hoping for some guidance. You search for memories of other shortstops you've seen, trying to remember whether the shortstop stands between first and second base or second and third base. Since the second baseman is already somewhere between first and second base, you casually jog to the empty spot between second and third. When no one laughs, you breathe a sigh of relief: one hurdle passed.

You find yourself hoping that the opposing batters will hit long fly balls that will be fielded by outfielders. The first batter is up and does exactly what you were hoping - almost: on the first pitch, he hits a long fly ball - so long, in fact, that it easily clears the right field wall for a homerun.

The second batter comes up to the plate, and the pitcher, shaken by such an early homerun, walks him. With a man on base, the infield (which you're part of) becomes more attentive; the second and third basemen shift their positions. The next batter takes two strikes then pops up a very short fly ball. You watch the arc of the lazily hit ball until you realize that it's coming down very close to you. You think you can catch it, but should you then throw it to first base? To second base? Back to the pitcher?

The ball descends but before it arrives, the umpire calls: "You're out!" and the batter begins to trot out to the dugout. But you haven't caught the ball, yet! When it finally lands in your glove, the pitcher is already standing with his glove toward you, waiting for you to throw it back.

Perplexed by this - does baseball have mulligans? - you glance toward the third baseman. He smiles. "Infield fly rule," he says knowingly. You vaguely remember hearing about the infield fly rule, but there's no time to think about it, for the next batter is up and you realize with horror that it's Barry Bonds.

With the first pitch, Bonds swings and connects. It's a hard ground ball - and it's headed straight at you. The ball is moving impossibly fast and it's instinct alone that prods you to put your glove out in its general direction. Smack! The ball takes a bounce and lands in your glove.

No one is more surprised than you are. But there's no time to reflect on your good fortune; the batter on first base is running with all his might toward second base. The second baseman calls out "Two!" as he's headed for second base. Confused, you pick up the ball and weakly throw it to him. He catches it effortlessly, tags the bag, and then fires a strike to first base. It's all happened so fast that you're not sure what occurred, but your teammates are headed to the dugout and one of them pats you on the back telling you that you made a good play. You've survived your first half inning of play. Welcome to the majors.

If someone were to come up to you at that point and say that you had executed the Double Play design pattern perfectly, you might think them a bit odd. And yet, that's exactly what you did. But you've never studied baseball design patterns - how could you have known what to do? The answer to this question is key to understanding how to use design patterns.

You don't set out to use a design pattern; rather you find yourself in a situation where you must make a decision. What the design pattern does is tell you, "In this situation, the following actions have a higher degree of success than any others we have discovered." In the situation you found yourself in playing shortstop, the Double Play design pattern represented the most successful action you could take.

The Reality Behind the Name
To be a good baseball player, you must study design patterns - learning when to bunt, when to hit a sacrifice fly, or when to steal. The same is true to be a good programmer: you must study design patterns so that you know about such design patterns as Observer, Adapter, and Chain of Responsibility. But just as in baseball, the important thing in software engineering is not so much the name of the design pattern, but the reality behind that name.

René Magritte, commenting on the human tendency to idolize (literally) reality, painted a now-famous picture of a pipe, under which he wrote the words, Ceci n'est pas une pipe: this is not a pipe. The name of a thing is not the thing itself, the map is not the territory, and learning the names of design patterns alone cannot provide guidance on building robust software.

In fact, the names given to design patterns can sometimes make them seem far more mysterious and complex than they are. But design patterns exist only to help you, not to act as a judge on your actions. Mastery involves learning both what design patterns exist and when each is appropriate. Only then can we use what we have learned for our ultimate goal - to craft systems that provide the power and flexibility that both we and our clients want.

If you'd like to learn more about design patterns and in particular their application with ColdFusion Components (CFCs), see the series of articles by Brendan O'Hara, "Design Patterns in ColdFusion," currently running in CFDJ, which started in the March 2003 issue. www.sys-con.com/coldfusion/article.cfm?id=577.

More Stories By Hal Helms

Hal Helms is a well-known speaker/writer/strategist on software development issues. He holds training sessions on Java, ColdFusion, and software development processes. He authors a popular monthly newsletter series. For more information, contact him at hal (at) halhelms.com or see his website, www.halhelms.com.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

IoT & Smart Cities Stories
If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of ...
DXWorldEXPO LLC, the producer of the world's most influential technology conferences and trade shows has announced the 22nd International CloudEXPO | DXWorldEXPO "Early Bird Registration" is now open. Register for Full Conference "Gold Pass" ▸ Here (Expo Hall ▸ Here)
@DevOpsSummit at Cloud Expo, taking place November 12-13 in New York City, NY, is co-located with 22nd international CloudEXPO | first international DXWorldEXPO and will feature technical sessions from a rock star conference faculty and the leading industry players in the world. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time t...
CloudEXPO New York 2018, colocated with DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one location.
The best way to leverage your Cloud Expo presence as a sponsor and exhibitor is to plan your news announcements around our events. The press covering Cloud Expo and @ThingsExpo will have access to these releases and will amplify your news announcements. More than two dozen Cloud companies either set deals at our shows or have announced their mergers and acquisitions at Cloud Expo. Product announcements during our show provide your company with the most reach through our targeted audiences.
The Internet of Things will challenge the status quo of how IT and development organizations operate. Or will it? Certainly the fog layer of IoT requires special insights about data ontology, security and transactional integrity. But the developmental challenges are the same: People, Process and Platform and how we integrate our thinking to solve complicated problems. In his session at 19th Cloud Expo, Craig Sproule, CEO of Metavine, demonstrated how to move beyond today's coding paradigm and sh...
What are the new priorities for the connected business? First: businesses need to think differently about the types of connections they will need to make – these span well beyond the traditional app to app into more modern forms of integration including SaaS integrations, mobile integrations, APIs, device integration and Big Data integration. It’s important these are unified together vs. doing them all piecemeal. Second, these types of connections need to be simple to design, adapt and configure...