The Spaces Between

As a systems integrator our greatest value is in understanding the ins and outs of “the spaces between” our clients existing systems, but expect stares as blank as a freshly cleaned whiteboard when offering such an explanation. How then do we describe our craft?  Engagements generally start with an implied question from our prospects… “How can you possibly help us when we know so much more about our business and systems than you”? Telling a new client who has spent years or even decades grappling with their very specialized workflows and unique data that, “data is data to us”, comes off as either ignorant, insulting, or both. How many times have you ended a conversation with a client and thought to yourself, “they simply don’t know what they don’t know”. More importantly, how many times do you think they were thinking the same thing about you?

It is much easier to explain [and bill for] boxes, cylinders, screens, circles, and even clouds, than it is the lines and arrows that connect, or at least should connect them. It is within theses “shapes” that our clients live and work, but in the spaces between that they need us most. In their eyes lines depict connections, but therein also reside workflows, dependencies, and logic, or more often than not, the lack thereof. It is also often in these spaces that the most important, and often unstated and hidden customer requirements lurk. We win customers when we see, understand, and have solutions we can articulate for these hidden problems. 

This brings to mind recent interactions with a few new Armedia prospective clients listed below. What they share is one-of-a-kind technology ecosystems that evolved over many years but that have become increasingly dysfunctional, while at the same time their user experience expectations have risen dramatically. 

• ·        A Health Sciences company developed systems to manage a speakers’ bureau, and solutions to help pharmaceutical and medical device manufacturers manage clinical trials. In the process, they also created a software maintenance nightmare.

• ·        An international program that manages independent educators, and uses systems that require no fewer than 13 separate user names and passwords to access. They maintain several web based systems, each built “in a vacuum” by different providers, and each created without coordination under a common architecture .

• ·        A Health System that provides care for a patient population of nearly one million people, they are suffering under authentication, interoperability, duplication, and maintenance issues that together manifest in cascading user experience shortcomings for patients, practitioners, and staff alike.

We will never fully appreciate the history, evolution or the politics that contributed to their current state, and we will never know these businesses like they do, but with the right approach we should be able to gain their trust and help them as they strive to answer the increasing loud chorus from their constituents, “please make your systems work together, now!”

We as integrators are confident we can help them, but how do we gain their confidence? The buying pattern they are comfortable with is to purchase software directly from independent software vendors (ISV’s) and then attempt to hold them accountable. The challenge is that one cannot “buy” the interoperability they need from an ISV. What they seek is “not available in pill form”. One must adopt an approach that fosters interoperability and then must build a system to support it, and for that, integrators like us are the only way. If the answers resided internally or via ISV’s, then the issues would already have been addressed.

Is your EMR holding you hostage?

Consider “Nirvana Health System” (fictionalized) a nearly 1000 bed system in the City of Nirvana that has 7000 employees, 7 hospitals, 200+ doctors on staff, with another 800 or so who independently perform services in the area. Historically they have done what all Hospitals do, that is, they have purchased commercial off the shelf (COTS) systems to run their business, manage patient care, and even market their services on-line. This approach largely met their needs for years, but now after a series of acquisitions, recent and looming changes to their reimbursement model, and myriad technology challenges that result from the shift from “Hospital” to Health System” they are now at a cross-roads.  These systems may have performed fairly well independently, but they were never designed or intended to function as one, the vendors who supplied them have run out of answers, and Nirvana is suffering the consequences. 

Nirvana has successfully standardized on Epic, one of the tier one vendors, as the primary electronic medical records (EMR) vendor at the main hospital, but they desire a single view across the entire patient experience. Patients in Nirvana receive services without consideration for Nirvana Health’s desire for a comprehensive patient record. Most will likely receive some health services beyond the reach of the EPIC, often simply by receiving care at a nearby doctor’s office not using Epic. So why don’t they just demand that EPIC integrate with other EMR systems? No doubt Nirvana and countless others have. But for EPIC to do so is counter to EPIC’s commercial interest. To do so effectively makes the patient record portable, and by extension the EMR system as well. Machiavellian principles of self-interest have proven themselves out in healthcare information technology (HIT). The only way out for today’s Health Care Systems is to for them to wean themselves from reliance on any one software vendor for any critically required systems.  

  

One way we recommend that Nirvana and others who face similar challenges introduce effective portability and reduce vendor lock-in is through adoption of standards across an array of disciplines, one specific recommendation would likely be for them to adopt a Service Oriented Architecture (SOA) yet SOA is largely a foreign concept to them, not to mention the notion of web services (WS) and enterprise services buses (ESB). SOA is not a product, but a philosophy. As described in OASIS SOA Reference Model’s definition, SOA is a model for “organizing and utilizing distributed capabilities”, and especially “capabilities that may be under the control of different ownership domains”. Nirvana will likely never fully control all the patient access points, certainly not soon enough to reach their stated timelines, and the SOA approach places a layer between the applications they rely on and the user experience they desire. 

Success with a SOA initiative will require strong support by executive leadership at Nirvana, but will put in place the foundation upon which Nirvana and others like them will be able to address the requirements of today and the unforeseen challenges of tomorrow.  When Nirvana and others like them realize the cure they seek does not come from a pill they can buy, but rather from a new approach that removes their reliance on any vendor, they will prevail, and perhaps we will have yet another new customer. 

An Open Agile ITIL RUP Waterfall Challenge... or, Building Software as if your Life Depended on It

How do we avoid what philosopher George Santayana warned of when he said, "Those who cannot remember the past are condemned to repeat it”. Today's platforms, frameworks and methodologies all help us learn from the past, and can go a long way to help assure our optimum success, but what would your approach be if your life depended on it.? Should it, does it, differ from your current approach, and what about the rest of your team. Is everyone on board? Is there a shared vision?
Consider this...do the following kinds of statements mean the same thing to everyone involved in your projects?
“We're a RUP shop”, ”They are CMMI level three”, ”This is an ITIL project”, “Our team is Agile”, “This client RFP specifies a Waterfall approach”.
RUP is a process framework whose creators intended it to be extended and individualized. CMMI levels are attained with great effort, but there is no assurance that they are adhered to or even appropriate in each project. ITIL is a vast collection of codified practices across multiple disciplines. “Agile”can just mean “we're flexible” or it can suggest a strict adherence to SCRUM. A Waterfall approach, one iteration and you’re done. Really? You and your team are all in the same boat, but are you sure you are all on the same page?
Danger sharpens the senses. What would your teams approach be … if your lives depended on it? How would you heed Mr. Santayana's warning? Would you all be in it together?
The Challenge:
Imagine an AP headline reading, “First Three Teams of Five to ‘Barrel Drop’ Niagara Falls in a Single Home Made Vessel Win 1 Million Dollars Each”. Not completely unrealistic given the proclivities of the today's occasional uber wealthy eccentric, and you may find the stories of some of the early Niagara barrel drop pioneers both tragic and fascinating. But what might we learn from them, and how might they apply to us?

In October 1829, Sam Patch, who called himself “the Yankee Leapster”, jumped from a high tower into the gorge below the falls and survived; thus began a long tradition of daredevils trying to go over the Falls. On October 24, 1901, 63-year-old Michigan school teacher Annie Edson Taylor was the first person to go over the Falls in a barrel as a publicity stunt; she survived, bleeding, but virtually unharmed. Soon after exiting the barrel, she said, “No one ought ever do that again.”


Does Annie Taylor’s warning sound familiar? By the way, several later daredevils did not fare so well, and it wasn’t until 1989 that a team of two successfully made the plunge, and by successful I mean they lived to tell about it, once they paid their fines and where sprung from jail.
How dis-similar is this fictitious challenge to the last internal project or RFP your team agreed to take on, knowing full well of the perils that await you, and of the rule bending you might engage, in order to assure your teams’ success? In both cases success depends largely on user and sponsor acceptance of the project deliverable. The aforementioned eccentric billionaire will only pay up if your team goes down together. And remember, if you spend more than a million bucks, or other teams “barrel drop”, er,....go live first.... then your team’s prize is zero, not to mention the consequences of being first to deliver, but with a tragically flawed design. What approach would you take? Would you take lessons learned, and not learned, from Sam Patch, Annie Edson Taylor, and those who followed them over the waterfall.
As I studied the fate of many a Niagara daredevil I marveled at how dissimilar each of their designs were, and wonder how closely each of their approaches mimicked current software development methodologies. From pictures I studied of actual “barrels” used in both successful and unsuccessful attempts, it appears none of them borrowed or learned much from those before them.
In one tragic example, a daredevil attempted to repeat his successful Niagara plunge elsewhere, but he failed to adjust his requirements properly to the new environment.
On July 2, 1984, Canadian Karel Soucek from Hamilton, Ontario successfully plunged over the Horseshoe Falls in a barrel with only minor injuries. Soucek was fined $500 for performing the stunt without a license. In 1985, he was fatally injured while attempting to re-create the Niagara drop at the Houston Astrodome. His aim was to climb into a barrel hoisted to the rafters of the Astrodome and to drop 180 feet (55 m) into a water tank on the floor. After his barrel released prematurely, it hit the side of the tank and he died the next day from his injuries.

source: http://en.wikipedia.org/wiki/Niagra_Falls
source: http://www.bay-journal.com/bay/1he/people/fp-taylor-annie.html

I learned many of these daredevils had used the non-iterative one shot “waterfall approach” that Winston Royce first described and warned us about in a software development article he wrote in 1970. He neither endorsed nor named this approach, but only observed that it had become prevalent as software started being used by people other than those who had written it. Winston thought it was a bad idea, instead favoring an iterative approach, but waterfall non-the-less became the adopted standard of the United States Military, and later, the standard of Governments, consultancies, and companies throughout the world.
source: http://www.youtube.com/watch?v=X1c2--sP3o0
An “If your life depends upon it” approach:
If it is your team chasing the one million, or even three million dollars for doing the plunge three times in a row, would you use a pure waterfall approach to go over the waterfall, or would you gather all of the collective knowledge of your team and leverage a hybrid approach?
My money, and life, is on an Open, Agile, ITIL, RUP Waterfall hybrid approach. I grant that this does appear perhaps an attempt to string together as many buzz words as possible in an effort to sound cleaver, but I suggest you may be surprised to recognize that even if your most successful projects fall squarely in one camp, they do borrow from the rest, even waterfall.


Open: No romance for “not invented here, or by Microsoft, etc”. An open source approach frees a team to borrow well documented and rigorously tested code from the community and use it without the burden of procurement or finance. There is little or no hard cost to trying multiple options, and creating solutions using open source projects as tools and building blocks.
There are currently over 250,000 projects available on Sourceforge, complete with user generated reviews and adoption metrics giving the user helpful information about each project, and world class commercial support available for most enterprise offerings.
Similarly, there are numerous options for canisters [barrels] that could be dug out of salvage yards and re-purposed for the barrel drop “application”. How about old brewers casks or refinery tanks that could be fortified and made habitable. They are already built and readily available, I bet we could even get a bunch of specifications regarding strength and durability that would give us clues as to which is most suitable. Think “Junk Yard Wars”.
source: http://www.tv.com/junkyard-wars/show/6391/summary.html

Perhaps not a direct correlation to the open source movement, but close. How many web applications are there out there that are “pure Microsoft”, yet leverage the open source Hibernate project for persistence? Uh, pretty much all of them.

Agile: We could study the successes and failures of previous Niagara drops, treating those as initial iterations, and continuing with an iterative approach, tossing a few of our own iteratively developed designs over the Niagara after having equipped them with crash test dummies and sensors borrowed from nearby abandoned automotive plants. Unless it is a complete failure, our first prototype eventually becomes our production model, presumably with minor changes and additions in subsequent test iterations all the way up until “production”, and then perhaps even between drop [iteration] two and three.
This notion was first explained to me by an old friend and colleague, Jon Kern, who in 2001 co-authored the Agile Manifesto. He and that cadre have come a long way since, and we owe them much. Words to live and work by, and in this case, literally. Reprinted below verbatim.

We are uncovering better ways of developing software [barrels]by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software [barrels]over comprehensive documentation
Customer [inhabitant]collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

And regarding testing, and the Agile/”Extreme” notion of build the test before the code, well, Niagara Falls itself is the test, and it certainly is already built.

source: http://en.wikipedia.org/wiki/Test-driven_development
ITIL: The Information Technology Infrastructure Library delves into some pretty specific managed service delivery disciplines with a collection of well documented practices, but at its core it is a simple framework for producing repeatable results. ITIL prescribes an approach where one enters and addresses lowest hanging fruit in a continuous cycle of Strategy, Design, Transition, Operation, and Continuous Improvement.
Just makes too darn much sense not to use the ITIL foundational framework to approach this challenge. Keep in mind we are planning for a second and third drop. ITIL owes much to W. Edwards Dimming.

RUP: Rational Unified Process is an iterative process framework which supports a one size and shape does not fit all approach to process, but does provide a standardized language around which groups can define and communicate their approach. We owe the term “Use Cases” to my old boss, Ivar Jacobson, one of the “Three Amigos” of RUP. He once told me that he blamed the term on his poor English skills, stating that what he really meant to say was “usage” cases. Creating a shared understanding the desired usage of a deliverable is central to success in delivery, and is a central element of RUP, and if RUP is not “Agile”, it is certainly iterative, and with RUP, everyone agrees on what the definition of “is” is.

Waterfall: One shot at requirements analysis, design, implementation, testing (validation), integration, and maintenance? No thank you. But on the other hand, how much iteration is required? Seems in this case the requirements are fairly binary. A reasonably safe and reusable Niagara barrel suited for five occupants and built on a low budget. Hence the statement which I have heard often repeated has some validity here, “a waterfall approach is best in situations where the requirements are well defined and unlikely to change”.

We think Annie Taylor took a pure waterfall approach (pun unavoidable) no evidence to the contrary exists. But would you?

Proxy War in Open Source - Best Article

Folks,
I wish to pass along this article written by Steve Lohr, The New York Times. It stands alone as the only sane piece I have found on the subject in a sea of drivel and sensational fear mongering. Thank you Steve for this well written informed contribution...and for the refreshing lack of reference to the myth that the Java "sky is falling".

http://tinyurl.com/36tjwnu


Doug Bock
Atlanta, Georgia, USA
Wide Open Consulting

What do ITIL, Alfresco Dining, and Enterprise Open Source Software have in Common?

A new client of ours recently asked me why I had pursued ITIL v3 certification ( Information Technology Infrastructure Library). Actually, she was more direct than that. “Doug, why is it relevant?” She asked this within the context of our discussion on the types of implementations we deliver in our enterprise open source consulting practice. She was quite satisfied with my answer, but only after I cited a specific engagement where another client of ours is beginning to offer an enterprise content management (ECM) system as a managed service to a diverse set of business units across their global organization.

A fresh set of empowered stake holders found themselves inheriting and a series of legacy ad hoc design and deployment decisions that resulted in initially poor performance, a lack of clarity amongst the business users regarding the value the ECM system, and a somewhat demoralized yet highly competent development staff. To date they had only been able to point to limited successes in a fraction of the business units the system was ultimately intended to serve. The new team discovered that there was significant lack of knowledge and abundant misinformation amongst the target business units about the capabilities of the system. Perhaps vendors of alternative offerings had tainted their view, perhaps they had seen a deployed system that had been configured for another business unit, and assumed that what they saw there was all that would be available to them. Comments were coming from business users like....”oh, it has a Wiki”, “oh, it can replace a shared drive with a 5015.02 certified electronic records management repository”, “oh, .....Google like search...we did not know it could do that” …. and all this, several months after the system became available.

Clearly the relationship between the IT department and their internal customers will benefit from the development of a services catalog, a central concept within the ITIL framework. Not rocket science, heck, not even computer science, just simply the development of a standardized list of what they offer. Imagine these two scenarios:

First scenario, customer view – with ad hoc services:

You come to my house hungry, and I offer to cook you something to eat, you have never eaten my food so you don't know if I am a good cook, and you are a picky eater. That is this the business units view of the IT group responsible for ECM at this client, and only a few have even tasted my food, and even fewer have looked in the fridge or pantry to see what is really available.

Second scenario, customer view – with services catalog:

We go to a well known restaurant drive through, famished and on a limited budget, with 30 minutes left on our lunch break. I order a “number #1”, and you, being a picky but hungry customer, order a number #3 with cheese, hold the tomatoes, mayo on the side, and super size that please with extra ketchup. We both get exactly what we expected.

Scenario one is where they are now, scenario two is where we feel they need to be in part via a services catalog as suggested by ITIL.

That was looking at the challenge from the business users view, now lets consider the applications development and operations teams that are expected to deliver and maintain the system for the business units. Clearly, setting up a RACI matrix will help everyone understand their role, and drive successful outcomes. Setting up a configuration management data base system (CMDBs) will record configuration items (CI) and details about the important attributes and relationships between CI's will improve overall results. Let's take the same example, but from the view point of the two kitchens and their chefs, one at my house, the other, at the other end of the drive-through pick up window. Imagine again these two scenarios, this time focusing on the development team and RACI:

First Scenario, delivery team view – ad hoc services:

Your hungry ( customer ) so I (developer) decide to whip up an omelet for you. I grab some eggs, butter, cheese....and tomatoes. I arrive proudly at the table minutes later with my creation, you smile politely, and quietly pick out the tomatoes, and eat around their remnants as best you can.

Second Scenario, delivery team view – with responsibility assignment matrix:
(This one takes longer to describe. A lot of effort went into distilling a menu down to 9 main choices and....over 20 billion served.)-

First, the person who takes your order knows their role, they are responsible ( the R in RACI) for taking your order, and then placing the items cooked by others into your bag, then delivering them to you, and finally, taking your money accurately.

If they routinely give incorrect change, mess up orders, or are too slow, then their boss, who is accountable ( the A in RACI ) will take corrective action up to and including termination.

If there is a highly belligerent customer, the order taker knows they should consult the manager ( the C in RACI ) who may chose to intervene in dealing with that customer.

Finally, when an order takes longer than the company defines as acceptable, then according to policy the meal should be comped or discounted, and a record of this action is made... “Hey boss, I gave that customer a free burger with their meal, it took so long because the cook cut his finger and we all got backed up”....and the boss is informed ( the I in RACI).

Again, scenario one is where they are now, scenario two is where we are helping them move, in this case via RACI, which predates but none-the-less is part of the ITIL framework.

Regarding the CMDB's, this is analogous to the framework provided to the fast food restaurant franchise owner which supplies most of what they need to run the business, from fryers of an exact size with automated temperature control, and bags of fry's pre-measured to fill the basket, to a set menu, building plans, standard employee policies, and even standardized point of sale (POS), labor management and financial systems. In an IT setting, leveraging ITIL's notion of a CMDB is a worthy goal, but it is not always the first goal. More on CMDBs' at: http://en.wikipedia.org/wiki/Configuration_management_database

Effective use of the ITIL framework demands an understanding of where a project is at a given point. If we had been working with this client when the setting up of an ECM was just an idea, rather than 2 years into a struggling project, our initial emphasis would have been on strategy and design. But in this case everyone involved, including us, needed a quick win, short on arm waving, and long on tangible results. Job one, remove the visible warts that caused the business users that were actually using the system the most grief. Job two, set the stage for successful role out to other business units, and in so doing improve the moral of the beleaguered delivery team with the most effective ointment of all, success.

So when is leveraging of a services delivery framework useful? Whenever the risks of confusion regarding the delivery of that service outweigh the effort required to invoke the framework. If the offering has a managed service component, whether you are outsourcing any, all, or none of it, it behooves you to present the offering in the language of your target audience. The notion of a services catalog (menu) service level packages (menu items) and the creation of service level agreements (external contract) and organization level agreements (internal contract) is spelled out in ITIL and provides a simple framework for just that. Enterprise open source application vendors tend to interact first and most often with the developer community. This makes it hard for the message to reach the business users that these systems are often very powerful and frequently at least on par with the closed source systems with which they compete. Immense war chests funded by license fees create effective marketing machines for closed source vendors that intentionally contribute to the fog, but a services catalog can help lift it.

Viewed in its entirety, ITIL provides logical common sense framework to help guide us through strategy, design, transition, operation, and continuous improvement in the delivery of IT services, and we are hard pressed, at least in our practice, to find situations where leveraging these principles does not help our clients succeed, whether we chose to attach the ITIL label or not, and regardless of where our current situation dictates that we should begin. But keep in mind that too say leveraging ITIL is a recipe for “best practices” is like saying putting two pieces of bread around some ground beef is the best way to make a burger. We have to create our own best practices within the context of the situations we face. When we put some ground beef between two pieces of bread we end up with a sandwich. Whether we end up grabbing a burger from a bag, or dining alfresco on steak tartar, toast points, and capers depends on the chef.


Doug Bock is a Principal at Wide Open Consulting and is available at:

doug@wideopenconsulting.com
404-290-1981

Is there life without Sharepoint?

A few weeks ago I spent the entirety of an entirely beautiful Saturday cooped up in a Microsoft building in Alpharetta, GA with 200 or so Sharepoint integration partners and Microsoft representatives, with the goal of coming away with a greater knowledge of Sharepoints capabilities relative to the myriad of open source technologies we are likely to employ in our projects, chief among them Alfresco. How do they compare? What silver bullets does Microsoft possess to put Alfresco in its place? I still don't know, and I am pretty sure Microsoft doesn't either. I make this leap after asking more than several people at the event how they thought Alfresco stood up to Sharepoint. None had ever even heard of Alfresco, and equally remarkable, none could present a cogent explanation of what was better about Sharepoint 2010 than previous versions. Don't get me wrong, I am sure there are “things” that are better.

To be fair, I did find a list of 2010 improvements online in a blog by “Sharepoint Joel”, many of which where mentioned at the aforementioned wasted Saturday. Hold on to your seats, this is some earth shattering transformational stuff, and clearly, your enterprise won't survive without it. http://tiny.cc/dbshu

Ah, but I did learn one thing of value... while the new 2010 offering is “better”, “really”, the Sharepoint 2010 BPOS cloud offering has a significantly truncated feature set. So I sacrificed my gorgeous Spring [ the season ] day to bring you this take away.

Similarly, Russell Stalters, BP's Director of Information & Records posts in his “Better ECM” blog, his similar frustration with a lack of knowledge transfer around Sharepoint he experienced at 2010 AIIM Expo and Conference in Philadelphia last month, this despite Microsoft's utter dominance of the event, which is the pinnacle yearly conference for all things information management ( http://tiny.cc/fffaq ). Microsoft is living in a bubble with Sharepoint, albeit a very large bubble, and one not likely to pop any time soon, but there is life without Sharepoint, yet it exists only in an alternate universe that is only now being discovered.

Open Source - No Free Lunch-revised

Wednesday, June 10, 2009

Open Source - No Free Lunch

One of the comments posted on my blog titled “Dogmatic Views on Open Source” ( http://tr.im/lUzh ) comes from Peter B…”open source is good, if you don't have any dough, but: there's no free lunch.” There is a lot of meat in Peter’s statement, yet such a statement is no doubt interpreted differently depending on the perspective of the reader. ”Open source is good”. Really? “If you don’t have any dough,” and you select a free option, and fail to achieve your goals because of a poor technology selection, then you have made an expensive mistake. Open source can be good or bad, whether or not you have any dough, and there is no free lunch, but you may end up with a better solution for your needs, and you may end up saving money, or failing. One must first ask, what are we trying to accomplish, and how ready are we to accomplish it?

Three years ago I needed an information only website, and to set up employees email addresses for an IT Governance start-up I was forming, and this was a bootstrap endeavor. I have never written a line of code in my life, nor set up a network more complicated than plugging a router into the cable box in my den, yet via a Google search I selected a hosting company, created an account, entered my credit card number, selected a few options during the registration process, and with only one call for help and 20 minutes assistance from a friend, I had successfully installed the Linux operating system, the Apache Tomcat web server, MySQL01 database and (this is where I needed 20 minutes help) installed the Drupal content management system. All in the cloud, from my home office, with under an hours’ time spent.

It was not free, but it was only about 35 dollars a month, and it enabled me to get a site up in a matter of minutes, and spend 99% of my time figuring out what our content was going to be. In this example, I was paying for web and email hosting, but I was also paying for Dream Host’s ability to offer a reliable technology stack on which to sit Drupal, which just happened to be open source(Linux, Apache, MySQL, PHP, or, the “LAMP” stack). I am not sure what subscriptions Dream Host may have invested in internally for the technologies they employ, open source or otherwise.(revised : there are now several hosted and well supported Drupal options available).

So, open source is good if you don’t have any dough. But what about Weather Channel’s CIO Brian Shield, who recently told me he runs an almost exclusively open source shop. He has dough, for him it is just as much about what he is trying to accomplish, and his web site essentially is his business. Employers may hire technologists for their skills in open source, and if a technologist has contributed to open source projects, then she probably commands even more. I would not be surprised if Brian has such talent working for him. I contend that the largest monetization of open source to date is the total of all “premiums” paid to individual developers for their knowledge and contributions either in support or creation of open source code or in helping their employers leverage open source. I contend it will always be that way. I content this is a good thing. I agree with Peter at least on this point, there is no free lunch.

So if my assumptions are true, why all the investment from angels, VC’s, and top software vendors? Open source creators are often highly motivated and highly competent. These contributors want to put out their best, and others in turn want to prove they too have something to offer, even if that is to prove they are smart enough to “break” or find fault in someone else’s creation. This creates a quality control phenomenon that cannot be reproduced inside a corporation…it is a kind of Darwinian mass collaboration fueled by simple economics and a healthy dose of pride of ownership….a great recipe for quality to be created in the most efficient manner, with an assurance of market demand baked in. These developers simply do not in-mass cook up something no one wants but them. Investors encourage [fund] open source development for one reason, to make money, but they attempt to do so in a variety of ways:

A) Drive hardware sales by building goodwill and exposure, while assuring they help drive the standards for which their products are tuned ( Sun created JAVA, IBM helped found Eclipse ).

B) Build infrastructure around which they wrap commercial service subscriptions ( Redhat funds much of the development on Linux Fedora and Jboss.org to create the open source based commercial operating system “RHEL” and the open source based commercial middleware JBoss).

C) Create business applications for which they can offer hosting and/or integrations, customization and support services ( SugarCRM is open source, and they are now a threat to Salesforce.com )

Who else is motivated to encourage open source development? Governments. One example, and you will hear more about this soon: the United States Government and The Open Source Software Institute (http://www.oss-institute.org/). They have opened up a bunch of old government projects because they simply could no longer afford to support them. If you don’t understand why and how this works, reread the above paragraph…I will likely devote a future blog just to this, for now I offer this from their website.

The Open Source Software Institute (OSSI) is a non-profit (501 (c )(6)) organization comprised of corporate, government and academic representatives whose mission is to promote the development and implementation of open-source software solutions within U.S. federal and state government agencies and academic entities.


So how does this work? IBM creates a somewhat captive audience with Eclipse, or at least they often get a shot at hardware sales. If a company is running Linux chances are very high they are paying either Redhat, or in some cases, Novell SuSe ( sometimes even via Microsoft ) for a commercially supported enterprise ready version of Linux. Companies can use the “free” Fedora” Linux, or the “free” openSuSe”, but for the most part, the “cost” of free in this case in too much risk. Most commercial operations acknowledge that the packaging, testing, patching, 24 x 7 X 365 support, standardization and indemnification they get for a subscription is money well spent, and a good bit cheaper than Sun Solaris (now Oracle) or other commercial alternatives. Ok, Solaris has been free for several years, er…but… Sun hardware is not, and I am pretty sure Solarus runs really well on Sun hardware.

As we travel up the stack, the lines get really blurry, and the decisions more divergent on who adopts, who pays, when, and why. JBoss is the most widely used application server on the planet, ahead of both IBM’s Webshere and Oracles’ WebLogic. It is also arguably the best. So why has Redhat stock, who owns the commercialized version of JBoss, not climbed to the stratosphere as companies continue to adopt JBoss for new projects, or even migrate existing applications to JBoss? Because unlike at the operating system level, consumers are much more apt to “go naked”, and use the “free” JBoss.org version instead of the “enterprise ready commercially supported” JBoss.com version. They don’t see as much risk as at the operating system level, and middleware tends to be stable because developers are much less inclined to change their configuration than operations people are to patch an operating system with the latest fix.

In the BI space the decision may be more of a comparison of bells and whistles, with SAP / Business Object, IBM / Cognos, etc. still having more eye candy and then open source contenders. In databases, more likely the aversion to open source data bases has to do with what executives are willing to lay on the line on an open source database…Oracle is still king here, but look for more and more adoption of alternatives databases co-existing along side of Oracle. I can almost hear Larry’s teeth nashing. Why again did he buy Sun, er a, MySql.

To not support open source vendors may be shortsighted, perhaps even tacky, especially if you are transitioning from a closed source solution, or delving into a project that would otherwise not have been funded. This is a case where if you have the dough, you should pony up. By the way, “going naked” is often “offending” the companies own IT Governance, and opening up the organization to legal risks. Besides, who keeps making Redhat products better? Fedora and JBoss.org contributors. Who pays for the contributor’s effort? Largely it is paid employees of a commercial open source company. If you get a “free dinner coupon”, do you still tip the waiter? I hope so.

On the other hand, many companies have looked at JBoss as an alternative to IBM or Oracle and said, “no thank you,” even after a due diligence tells them it is on par with the incumbent technically. They see the elimination of license costs and the reduction in support / subscription cost as interesting, they are even confident that they could make the move, but what holds them back is operational preparedness, or some soft but sometimes very important advantage to lassie fair. Total cost of ownership must be “total”….so what if we do all this and then our developers lose productivity because they now must work in a new and unfamiliar environment. For some even the slight prospect of this in unacceptable. What is a business partner is not on board with the whole open source thing, and you cause a 10 million dollar ripple to save 1 million dollars. Sales reps often cite the motivation for “C” level technology homeostasis as ...”oh, the IBM rep plays golf with the CIO, that is why they won’t go open source”. Maybe, but what information does the CIO gain for that loyalty? Likely it is something more valuable than the savings he would gain for a whole shift to open source. These forces collectively are why all companies fall somewhere on a close source to open source adoption continuum, with most somewhere in the middle. There is a shift, but there will always be a broad spectrum of adoption rates.

Consider the numerous attempts to make money by building companies around the support of open source projects, which have resulted in the creation of companies such as Pentaho and Jaspersoft in BI, Alfresco in content management, and MySQL ( SUN / Oracle ) and Postgres Plus ( EnterpriseDB ) in the database space. Oracle’s motivations may be around control, but the VC’s who investing in these other companies, and the entrepreneurs who founded them did so to make something great and profit greatly from it. It is not a slam dunk, and they too have found, and as Peter reminds us, “there is no free lunch”.

Your comments below are appreciated.

Wednesday, May 6, 2009

Dogmatic views on Open Source

Why begin a blog named "Pragmatic Enterprise Open Source" with an entry starting with the word dogmatic?

Since I was first introduced to the notion of open source software in the late 1990's I have become increasingly intrigued by opinions on both ends of the spectrum relative to open source, and bewildered by the dogmatism and sometimes utter irrationality with which holders of these wildly divergent opinions opine, especially when they come from leaders in enterprises with otherwise nearly identical business models.

"From which well doth he drink his kool-aide"? Sometimes the answer is obvious, others times, indiscernible. As is the case in political movements, we run the risk that the shouts of zealot's and detractors at the fringe might drown out the mass of sane and often better informed yet quieter voices in the middle. While this is my blog, I hope that if you stumble upon it and are so moved you will post a comment telling me "how wrong you are", or better yet how, "you have it almost right, but missed such and such important element."

There are many thousands of blogs, wikis, and forums that delve into the bowels of the most prolific as well as the most obscure open source projects, and in the time it took me to right this, likely another novel sized body of text on this immense subject was spawned. If you have contributed code to an open source project, and don't know what a P/L is, then I apologize, I have wasted your valuable time, and now is a good time for your to throw it in reverse and head back to your favorite development environment or aforementioned social posting site. By the way, thank you for your work!

So let's start with enterprise open source's own 800 pound gorilla.
Walk into the front lobby of Redhat/JBoss Headquarters in Atlanta, Georgia and you will be greeted by a lovely lady over whose head is posted a very large indelibly inscribed quote attributed to Mohandas Gandhi..."First they ignore you. Then they laugh at you. Then they fight you. Then you win". Judging by the size of Redhat ( ~$650 M 2008 revenue) and the several years running 30+% year over year growth, there have already clearly been some "winners", not the least of whom are the crew that grew JBoss from an idea to a sale to Redhat for $360 million in just a few short years. Redhat's current CEO left a position as COO of Delta Airlines where it is reported his 2007 earnings topped $8 million. Open source has grown up, or at least eight or ten companies have built businesses around supporting these ready for the enterprise code bases, now available packaged similarly to proprietary offerings with which they compete, sans the initial licenses costs and overhead associated with paying for 458 foot private yachts and decommissioned fighter jets. More power to Larry Ellison, but it is nice to have a choice sometimes. (revision, VMware bought SpringSource, an open source middleware company, for just under 500 million dollars in mid 2009, and they bought Zimbra from Yahoo in January 2010 ).

The time for intellectually honest debate about the commercial viability of several enterprise ready fully supported open source products is over. If you do not agree, please don't take my word for it, but do remove your head from the sand and call the CIO down the street who is likely running circles around you. Don't get me wrong, there are plenty of great reasons to run a pure Microsoft shop, or to heavily leverage IBM. But if you are running significant web applications, you are probably already using open source and are just unaware of it. If this is the case then you are likely running unsupported product, which in turn may be in violation of your own IT Governance. The good news is that there is likely someone out there who will take your money in exchange for support and indemnification of these rogue technologies, and they will do so at a fraction of the cost for proprietary products, and the quality of support will likely be as good or better than what you would get from similar closed code providers.


Today open source is in the enterprise in a pretty big way, and while the above quote from Gandhi accurately describes the "you've come a long way, baby" progress of the open source movement, it is flawed in that it suggests an end game. Open source is just an attribute, an attribute that now is affixed to products owned by and / or supported by some of the largest companies in the world, including Oracle, with its purchase of Sun / MySQL. IBM was a founder of the Eclipse Foundation, and has recently formed an even stronger relationship with EnterpriseDB, a professionally supported enterprise open source alternative to Oracle database.

Ellison may have ignored, then laughed, but he is now in fight mode, a fight he will take to his grave, which will most assuredly include open source spoils and pillage.

So save your dogma for politics, open source is in the enterprise, but so is Larry, Gates, and the rest of the usual suspects, and they have inextricably entered the game. The sourceforge.net open source repository hosts over 180,000 open source projects, with 1.9 million registered users, and 28 million annual visitors to the site. Translation...there will continue to be an increasing flow of open source projects that bubble up, harden, and become enterprise ready. The genie is out of the bottle. Rub it right and it may grant you a wish or two.

Open source is no longer just languages like PERL, Java, and Ruby, and it is no longer even just operating systems like Linux and its many flavors, or even limited to middleware. There are now viable options for many business needs that reach up the stack all the way to CRM, business intelligence, etc. There is even a huge amount of open content in education and entertainment. The wildly popular band RadioHead put a recent album on sale on-line for "free", and suggested buyers pay what they thought it was worth. The fans spoke with their pocketbooks and paid an average of 8 dollars for the download, many paying zero, and others paying much more. While RadioHeads songs are not "code", and they are not registered with Apache or GNU ( open source licensing modes ) the monetization parallels are helpful in understanding the phenomenon of open source, and in explaining why on earth someone would "give away" their IP, or even their "help" to a stranger in support of something neither of them owns.

At the level of the developer it is largely about being a part of something bigger than you, that you can be a part of...using open source it is truly a part of practicing your craft. I use this "product" because I can see it, there are no secrets, and if I want to bad enough, and I am good enough, I can even change and build upon it. Literally millions do. It is this mass participation that has made some open source products simply the best in class, regardless of how they are licensed. Most well informed technologists would put no peer next to Linux.

At the level of the CIO, she can say, I want to use these three open source products at the platform level, but I only want to buy support for those two, on top of which I will place my custom built applications, and several others I purchased from IBM and SAP, and I am going to use Oracle data base for some applications, Mysql, for some, and Postgres Plus for still others. I am running SAP / Business Objects for some of our business intelligence needs, and Pentaho or JasperSoft for still others. Maybe I will migrate my content management from Documentum to opensource contender Alfresco. For CRM, I could use Oracle on site, Salesforce.com in the cloud, or open source "SugarCRM" either hosted internally, or pay for a Saas version.

The quiet, technology agnostic open source pragmatist is the winner of this war, but that does not assure he won't be gassing up Larry's boat for his next Mediterranean cruise . What say you?

Subscribe to: Posts (Atom)