 |
|
Snake Oil-oriented Architecture
Snake oil, in its uncomplimentary form, denotes a miracle drug guaranteed to cure all that ails you, yet whose mechanisms are shrouded in inscrutable details that wither in the uncompromising light of science. As nations expanded their empires - most notably the United States in a rush to fulfill its Manifest Destiny in the 1800's - grifters would rumble into frontier towns in order to extract precious dollars from unsuspecting and ill-informed citizens, selling them secret elixirs of amazing potency. These medicine men would put on a great show for a town typically lacking in entertainment, short of the local saloon which was already so mundane to the locals. These people were looking for a release, a cure that required no effort, a turn to "modern science" that would relieve them of their sufferings and perhaps more importantly, their fear of the unknown which was vast in this unscientific age.
Alas, there continue to be snake oil salesmen (and now saleswoman), but their elixirs often take a form that's far more illusive than liquid medicine. Most modern day grifters no longer ride into town on a wagon, but rather use late night TV, well-placed "scientific" advertisements, or the Internet to ply their wares. The better-capitalized ones will fly in to town with their entourage, set up a meeting at a high-class hotel, dazzle an unsuspecting and ill-informed audience with their PowerPoint wizardry, then fly away, leaving their local representatives to rake up the cash that's been thrown on the floor. Almost immediately, these local citizens will feel wiser and stronger, simply having been exposed to these confident, polished, and well-fed men and women and their shiny brochures - why, even the articles in trade magazines proclaim that It Is Good! - but once back at work and faced with the real world, they quickly find that instituting some of these new-fangled ideas is not as easy as they were led to believe and that these elixirs are not so far-reaching as promised them. A little later, some of them will get an uneasy feeling that maybe - just maybe - there are some simple fundamentals on which their organization is not executing well, and that the whole elixir exercise was worse than useless, because it actually diverted them from their real problems while creating new ones. Far too many of those people will get over their discomfort just as soon as the next medicine show rolls into town: a little distraction now and then is always a nice way to avoid reality and give your bosses the illusion of progress.
Now, let me make something excruciatingly clear, lest you misunderstand me and thus send incendiary emails and/or impel my IBM management to take me behind the woodshed for a good thrashing: I am a strong proponent of Service-Oriented Architectures (SOA).
However, I tremble at the realization that the fundamental technical benefits as well as the costs and trade-offs of SOA are sometimes lost in the guise of Snake Oil-oriented Architecture.
IMHO, SOA's value proposition begins with the A in its acronym: architecture. There is sound, proven value in governing and growing a system's architecture; there are also hard decisions that must be made, many decisions of which cannot be known a priori (which is why a process shaped around the rhythmic incremental and iterative release of executables is so important). There are many things we already know about what constitutes a good architecture and what does not. Stripped away of all the hype, a Service-Oriented Architecture is essentially a variant of well-proven message-passing architectural patterns. The variance comes in the form that services are cleverly designed to take advantage of the Web-centric infrastructure that pervades many organizations: services allow you to send and receive semantically rich messages through firewalls.
Having said that, there follow a multitude of hard technical and process decisions that must be made, which the Snake Oil-oriented Architecture showmen often neglect to tell you about: what distinguishes a good service from a bad one? what should the granularity of a service be? when should I offer up a stateless service versus a stateful one? as for the stateful ones, how to I express their semantics, and how do I ensure their their misuse doesn't corrupt my system? how do I express the semantics of a society of services (only the most trivial services work in isolation)? how do I decide upon the semantics of the information transmitted by these services so that locally they are efficient and useful but that also globally they are consistent? how do I expose some services to some clients and hide them from others? how do I offer up variants on a service, so that different clients see a different face to that service? how do I ensure the security of critical services, such that I am confident I'm not opening up holes in my enterprise that will let the bad guys in? what services should I expose to the world, and what services should I keep hidden? where are services appropriate, and where are they not? how do I best expose services in a legacy system? who should own/maintain these services? are there alternative architectural patterns I should employ instead of services, and where, and why?
These are all architectural and process decisions, which is why I tend to emphasize the A in SOA. If you ignore the S in SOA for a moment and shine an uncompromising light on your organization's software development practices, you may come to realize that there perhaps are some simple fundamentals you need to work on first, so that you can then approach the S in SOA in an appropriate, confident manner, and derive the true value from this technology.
If you do otherwise and accept the unprovable proclamations of the Snake Oil-oriented Architecture salesmen by pouring their elixir on the aching muscles and oozing wounds of your organization's people and software assets and doing nothing else, than all I can say is that you will probably get the results that you deserve.
Oct 12 2006, 11:20:18 AM EDT
Permalink
|
|
The Most Innovative College in America
Ok, I'll admit up front that I have a conflict of interest in posting this: I'm on the university's advisory board.
The Spellings commission report recently cited Neumont University in Salt Lake City for "innovation in curriculum development and program delivery."
Congratulations, Neumont.
Oct 10 2006, 11:54:36 AM EDT
Permalink
|
|
Orbiting The Giant Hairball
Hm, that sounds a little too juicy, so I'll stick to the "big ball of mud" title.
Dennis Hamilton emailed me, pointing me to Brian Foote's web site, containing the latest version of the big ball of mud pattern as well as several others.
"Orbiting the Giant Hairball," BTW, is the title of a book by Gordon MacKenzie detailing his thoughts about creativity and the corporate world.
Oct 06 2006, 11:10:48 AM EDT
Permalink
|
|
Big Ball Of Mud
Today I was rereading PLOP 4, and in particular the chapter by Brian Foote and Joseph Yoder on an architectural pattern they call a Big Ball of Mud. There is such wisdom and insight in their work that I just had to share some passages. Please, go amazon yourself a copy of PLOP 4 (and while you are at it, order PLOP 1, 2, 3, and 5 as well) so that you can read about their entire pattern language:
Why does a system become a Big Ball of Mud? Sometimes, big ugly systems emerge from throwaway code. Throwaway code is quick-and-dirty code that was intended to be used only once and then discarded. However, such code often takes on a life of its own, despite casual structure and poor or nonexistent documentation. It works, so why fix it? When a related problem arises, the quickest way to address it might be to expediently modify this working code, rather than design a proper, general program from the ground up. Over time, a simple throwaway program begets a Big Ball of Mud. Even systems with well-defined architectures are prone to structural erosion. The relentless onslaught of changing requirements that any successful system attracts can gradually undermine its structure. Systems that were once tidy become overgrown as piecemeal growth gradually allows elements o the system to sprawl in an uncontrolled fashion. If such sprawl continues unabated, the structure of the system can become so badly compromised that it must be abandoned. ? As with anything else in the universe, counteracting entropic forces requires an investment of energy. Software gentrification is no exception. The way to arrest entropy in software is to refactor it. A sustained commitment to refactoring can keep a system from subsiding into a Big Ball of Mud. ... Some of these patterns might appear at first to be antipattterns or strawmen, but they are not, at least in the customary sense. Instead, they seek to examine the gap between what we preach and what we practice. ... Still, some of [these patterns] may strike some readers as having a schizoid quality about them. So, for the record, let us put our cards on the table. We are in favor of good architecture. Our ultimate agenda is to help drain these swamps. Where possible, architectural decline should be prevented, arrested, or reversed. ? In part, our attitude is to ?hate the sin, but love the siner.? ? Not every backyard storage shack needs marble columns. There are significant forces that can conspire to compel architecture to take a back seat to functionality, particularly early in the evolution of a software artifact. Opportunities and insights that permit architectural progress often are present later than earlier in the life cycle. A certain amount of controlled chaos is natural during construction and can be tolerated, as long as you eventually clean up after yourself. More fundamentally, a complex system may accurately reflect our immature understanding of a complex problem. The class of systems that we can build at all may be larger than the class of systems we can build elegantly, at least at first. A somewhat ramshackle rat?s nest might be a state-of-the-art architecture for a poorly understood domain. This should not be the end of the story, though. As we gain more experience in such domains, we should increasingly direct our energies to glean more enduring architectural abstractions from them.
Well said, Brian and Joseph.
Oct 05 2006, 06:05:07 PM EDT
Permalink
|
|
Yet More Patterns
Published in 2000, Linda Rising's Pattern Almanac provided a comprehensive index to the many patterns that had been documented in the software community. Unfortunately, Linda's book is now out of print. Additionally, since that time, the patterns literature has matured considerably, especially thanks to the efforts of the Hillside Group, with their writer's workshops and PLOP conferences.
While by no means as comprehensive as Linda's original work, I've now cataloged a little over 1200 patterns, and I figure I have several hundred more to add. You'll find an index to these patterns here (you'll need to be logged in to the Handbook site) where you can sort them by name, kind, and source and for each read the problem they address and the solution they offer. Several people have written to me saying that they have used this catalog often, and so over the next week or so I'll improve search within my site so that you can scan the entire site, the the patterns, and other sections.
Oct 04 2006, 06:45:26 PM EDT
Permalink
|
|
Yet More Patterns
Published in 2000, Linda Rising's Pattern Almanac provided a comprehensive index to the many patterns that had been documented in the software community. Unfortunately, Linda's book is now out of print. Additionally, since that time, the patterns literature has matured considerably, especially thanks to the efforts of the Hillside Group, with their writer's workshops and PLOP conferences.
While by no means as comprehensive as Linda's original work, I've now cataloged a little over 1200 patterns, and I figure I have several hundred more to add. You'll find an index to these patterns here (you'll need to be logged in to the Handbook site) where you can sort them by name, kind, and source and for each read the problem they address and the solution they offer. Several people have written to me saying that they have used this catalog often, and so over the next week or so I'll improve search within my site so that you can scan the entire site, the the patterns, and other sections.
Oct 04 2006, 06:45:26 PM EDT
Permalink
|
|
Good Bye, Amigo
Jim Rumbaugh has announced his retirement from IBM. I've enjoyed working with Jim over the years, and am particularly proud of what we accomplished in merging OMT and the Booch method into what became the original version of the UML.
Jim will be staying in the Bay Area and will continue to write and lecture. Farewell, Jim, I wish you well.
Sep 29 2006, 12:46:04 PM EDT
Permalink
|
|
More Patterns
I've posted several dozen more patterns in the Handbook's catalog of patterns (remember that you'll need to be logged in to the Handbook site).
Sep 19 2006, 04:13:00 PM EDT
Permalink
|
|
John Backus
Last week, on behalf of the Computer History Museum, I had the opportunity to interview John Backus, who led a team at IBM in the 1950's to produce FORTRAN. Later in his career, John pioneered work in functional programming.
John is now in his 80s, and is still a very energetic and bright man. We met at his home in Ashland, Oregon, where he lives near one of his daughters following his wife's death a little over two years ago. The purpose of our interview was two fold: the Computer History Museum continues to conduct a variety of oral interviews, and the ACM is in the process of interviewing all its Turing Award winners (John received the Turing award in 1977).
Our interview covered a wealth of topics: his recollection of the FORTRAN project, his contributions to ALGOL, his experiences at IBM, his work on functional programming (and why it failed to achieve mainstream success), and his work with many other luminaries of the time. John reported that his FORTRAN work was not well received by IBM senior management at the time (Tom Watson senior in particular) but that Tom Watson junior really got the vision for the future of computing. Much of the FORTRAN work was so groundbreaking that his team had to discover and then solve a multitude of problems along the way. Interestingly, John noted that the assumptions for which FORTRAN was created - to see if one could write efficient programs in a high-order language - are really no longer valid, although the industry is still faced with a "cesspool of complexity," as he put it.
John is still a wired guy: he's got a Palm, a Tivo, and a Dell. Currently, he's working on publishing and distributing a book his wife was working on up until her death.
Sep 15 2006, 02:03:00 PM EDT
Permalink
|
|
Reboot or "How I Spent My Summer Vacation"
That is, if you define "vacation" to include intense, non-monotonically decreasing pain, episodes of debilitating depression, and some cognitive and physical hiccups.
The good news, of course, is that which was surely going to kill me (namely, an aneurysm of the ascending aorta) has been expunged from my life. Thanks to the incredible care I received at the Mayo Clinic in Rochester, Minnesota, my demise is now more likely to come from being hit by a bus or via a tragic paper cut. As the only surviving male of the Booch lineage, since those immediately before me and after me have all died of the same condition, I owe my survival to early detection and the skill of the surgeons, physicians, nurses, and staff of the Mayo. The death of my nephew at age 20 was a gift of life to me, for it led to my being tested and that CT scan revealed I had the same condition. We were able to monitor the state of my aneurysm through 2005 and early 2006, and made the decision for elective open heart surgery at the end of May this year. This summer, as readers of this blog will know, I've been largely offline, recovering from surgery. Earlier this week, I returned to the Mayo Clinic for some follow up tests, which mark the beginning of the end of my recovery.
I had hoped for a bit more closure from those tests, but alas, that was not to be (and in that context I recall a speech by the mayor of Colorado Springs some years ago, in which he noted that, in this life, there is no closure). Physically, my surgical scars have pretty much healed although they'll never go away completely. The replacement of my aortic root took well, with no leakage or other such complications. There are unknowns with regard to my aortic valve. Technically, I underwent a modified Davis procedure, a valve-sparing replacement of the aortic root. This technique is still sufficiently new that the long term implications for my valve are unknown: will the tips of the valve wear out faster because they might rub against the Dacron graft? My left ventricle had begun to enlarge to compensate for the abnormal fluid dynamics inside my heart resulting from the aneurysm, but an echocardiogram earlier this week revealed that my left ventricle has shrunk (that's a good thing) and that my heart is actually operating more efficiently than before the surgery. I do still have some fluid around my heart that should have been absorbed by now, and that's a little concerning as it is indicative of some continuing inflammation of the heart, so I'm under yet another drug regimen to attack that issue. My endurance and upper body strength are not back to pre-surgery levels, which is not surprising given that for most of the summer as my sternum healed, I couldn't lift more than 10 pounds. Also, during this recovery, I lost over 20 pounds, mainly because I've lost much desire to eat.
Mentally, I'm pretty much back to normal, whatever that means for me. Being a person who lives in his head, the risk of cognitive decline was a very real concern, and the various studies from Duke University that I read before surgery gave me pause. During my recovery, I did have problems with concentration, the so-called pump head syndrome from being on a heart/lung machine for an extended period, but now I find that those problems are largely gone, and I'm pretty much back to where I was.
The emotional issues were the hardest. Although I knew in my head that depression after such major surgery is not uncommon, knowing it and experience it are very different things. If you are interested, the book Coping With Heart Surgery And Bypassing Depression by Carol Cohan, June Pimm, and James Jude provides the most honest discussion I've read about that element of the recovery process. Although I am an intellectual person, I'm also a whole emotional person as well. I have a propensity to melancholy as it is, and surgery then recovery greatly amplified those emotions. Happily, I am in a happier place again. Spiritually, this was period of growth and grace for me, having been surrounded by the love and care of family and friends, and - as Philippe Kruchten noted to me as as I blogged about before - having had many people in many parts of the worlds in many languages and in various systems of belief pulling for me.
It's been three months since my surgery, and I'm now starting to return to a rhythm of work. I'm back on my IBM email, and I'm starting to take on some work tasks. Most importantly, I'm using this reboot to be intentional about what I will take on and what I will shed: as I look at the long list of things I was doing before surgery, I'm stunned by how many of them just accumulated over time and really were not essential to helping me advance the practice. To that end, that I'll be returning my primary attention to the goals of the Handbook and following the evidence of existing architectures where it leads me.
I'm also starting to resume my travel. My first business trip will be to Oregon, where I'll be interviewing John Backus on behalf of the Computer History Museum, and from there I'll travel on to Ottawa to continue work with IBM Rational's Jazz project.
It's really good to be back.
Sep 01 2006, 12:59:27 PM EDT
Permalink
|
|
Status
It's been over a month since I last blogged. Yesterday was the eight week anniversary of my open heart surgery and although my incisions have healed, my body and spirit are not yet operating at 100%. I was able to start driving a couple of weeks ago (a most welcome increase in my level of independence) and can now start lifting items heavier than a gallon of milk. While it no longer hurts to cough or sneeze (indicating that my sternum has healed), it's clear that my body chemistry is still wacky. Most days my blood pressure runs around 100/60, but some days it drops to 80/50 and on those days I feel like a lump of protoplasm. Most days I'm emotionally up, but as all the physicians and literature warned me, some days I just have to crawl into my cave where I sit inconsolable.
I'm not yet back on my work email and thus I expect I've got a backlog of messages numbering in the tens of thousands. Please pardon me if i've been ignoring you, but slogging through my email is not my highest priority right now. This week, I've begun to return to research for the Handbook. As August rolls around, I'll start planning - but not yet doing - any other work activities. I hope to resume some level of travel in September.
So much has gone on in the software biz these past eight weeks: BillG has announced his retirement; Myspace.com has gained critical mass; Google continues to innovate with elements such as their windowing toolkit; IBM posted a solid quarter; Apple posted an incredible quarter; software mashups al la Web 2.0 technologies have gained traction. Still, so much is the same: developing, deploying, and operating complex software-intensive systems is still fundamentally hard; the world's current economic conditions still means doing even more with even less.
Thanks again to the people who have emailed me and snail-mailed me their greetings. I do look forward to jumping back into the fray and fighting the good fight as soon as I can.
Jul 26 2006, 01:52:30 PM EDT
Permalink
|
|
Home Again
I'm finally back home. The mile high air smells sweeter, the sunsets appear brighter, and it feels sooooo good to be back in my own bed, unencumbered by the assorted wires and tubes that had been attached to various parts of my body.
As Bill had mentioned in an earlier blog, there were some complications that kept me at the Mayo Clinic longer than I'd first expected. Specifically, my body had stopped producing red blood cells and I had a couple of episodes of irregular heartbeats.
I have such a deep respect for the medical staff at the Mayo Clinic. Dr. Thoralf Sundt was my surgeon, and his team was augmented by Dr. Enrique Gongora (his resident), Dr. Naser Ammash (a cardiologist specializing in congenital heart disease), Dr. Rajiv Purithi (a hematologist), and an incredibly competent, professional, and caring nursing staff, into whose hands I placed my life. The Mayo Clinic is so well organized that as issues arose, world-class experts were brought in immediately for consultation. It is wonderful that such an institution exists, and its reputation is well-deserved.
I continue to be amazed by the ability of the human body to heal. I still have minor aches and pains and my endurance is far from where it was before the surgery, but every day I get just a little bit stronger. My doctors advise that my recovery will take around eight weeks. I can't drive, I can't lift more than five pounds, I don't yet have the focus to sit in front of a computer, and the simple act of sneezing is a painful event. Therefore I'm doing something I've not done for about thirty years, namely, taking a summer vacation. So that my body and spirit have time to heal properly, don't expect to see me reengage in work until late summer.
I want to offer my thanks to the many people - some of whom I know, many of whom I don't - who held me and continue to hold me in their thoughts and prayers.
Jun 19 2006, 12:25:30 AM EDT
Permalink
|
|
Out of Hospital, Continuing Tests
(Bill Higgins posting on behalf of Grady)
Grady has moved out of the hospital and is in good spirits. He must remain in the area near the hospital due to continuing medical concerns and testing.
Grady would like to thank the people who wrote the software for the machines that kept him alive.
Everyone's prayers and well wishes are appreciated.
Jun 08 2006, 01:30:41 PM EDT
Permalink
|
|
Dealing With A Few Post-Surgery Issues
(Bill Higgins posting on behalf of Grady)
Grady is continuing the post-surgery recovery and has experienced some issues which have been dealt with.
He continues to be in good spirits and will be in the hospital longer than expected.
Our thoughts and prayers continue with Grady and his family.
Jun 05 2006, 02:40:11 PM EDT
Permalink
|
|
|
|
Software architecture, software engineering, and Renaissance Jazz
