Nanoblog

Alfresco+Liferay Meetup I -- Installment I: General Trip Report, On the Edge of Life and Death ;)

I just got back yesterday from my trip out to California for the Alfresco + Liferay Meetup which took place at the Liferay HQ on July the 18th. I think the Meetup was a huge success, and our surveys indicate the same! We had an impressive turnout – clearly there is tremendous interest in these two open source product / communities!

First I would like to give thanks to Alice Cheng who organized all of the logistics and made sure everything went well. Also a special thanks to Luis Sala who really brought everyone together and was the shepherd for the organizers and presenters. Last but not least a huge thank you to Liferay, Alfresco, and our sponsors (Rivet Logic, Ice Faces, and Cignex) who provided talent and funding – we could not have done this without them.

Before I kick in to my first (but not the last) Meetup report let me tell you about some of the more personal aspects of the trip. Three bits of information

The first bit of info has to do with my sleeping habits. Generally speaking – I have a habit of not sleeping :) Well, that is not entirely true – but I do not sleep much. With the time change and getting things prepped for our gig – I actually didn’t sleep. I left Boston for CA on the 17th at 4:30am and didn’t sleep until I leaned against the window of plane on the way home. Getting things set up on the 17th and the Meetup itself were both very exciting and I didn’t feel tired until very late in the day on the 18th – after about 3 tons of chicken fingers and too many soda’s which eventually have the opposite effect that one or two sodas have. If I seemed a bit crazy or out of my mind – I probably was :)

Second:  My presentation afforded me with what was for me, to date, the most challenging issue to overcome when speaking than any other I have yet faced. I’ve had to power through people talking, cell phones ringing (again and again), deal with hecklers and all sorts of other stuff before but this one takes the cake. Thanks to Alice I left early to set up for my presentation. I had a lot of setup to do. I planned to give a talk and a few demos. I connected to our staging server to show our current setup, loaded my tomcat Alfresco Liferay configuration, opened the 22 URL’s I needed, I opened my presentation, and got the seats and projector ready. Just as I was beginning to kick things off, a gentleman plugged in his computer to the same socket I had everything plugged in to and I suppose we pulled a few too many Amps – I am not sure but we lost power for several minutes. (Not his fault of course) No breaker was thrown as we did get power back without changing a fuse or resetting a breaker. Anyway, with the exception of putting the seats in order I was back to square one in terms of preparation and the room was filling up. That was pretty nerve wracking. I kept thinking – I am going to have to whiteboard this off the top of my head – eek!! Everyone stayed and we got through the talk and had some good discussion afterward. Thanks to everyone for your patience!

Third (and best of all) I woke up in Boston with an imprint of the plane’s window molding pressed nicely in to my face, deplaned (I like that word for some reason) and headed out to get a cab. Jumped in to the cab. “Christian Science Monitor” I said to the cabby as we headed off. “Mass ave right?” the Cabby responded to me. “Yep, that’s it” I replied as I drifted off looking for a new window to sleep against. The cabby was talking to someone on his cell phone.  Now if you have driven in Boston, you know we will stand on the gas pedal and slam on the breaks to gain a few feet. (We will even drive the wrong way in wrong lane -- which is apparently legal in bean town as long as you are in reverse)  People drive fast here, people stop fast here. Well I remember the feeling of acceleration as we pulled on to the highway and comfortable hum of speeding towards the big dig tunnels. I even remember thinking – wow we are coming up on that cab pretty fast. We were but the cabby didn’t seem to notice until we were almost sitting in trunk of the cab we were barreling down on.  Once his depth perception kicked in, my driver slammed on the breaks. We slowed down very fast but there was no way we were not going to hit the cab in front of us – at the last moment my driver bailed to the lane on our right and we managed to miss the immediate threat. The only problem was that nasty old issue of two objects trying to occupy the same space at the same time (they can't!!) and so we smashed in to another cab on the side, bounced off it and then swerved around until all parties came to a rest. No one was seriously hurt that I could tell at the time and our cars could all still be driven. There was some heated exchange – my cabby proclaiming it was not his fault – clearly – it was and is his fault, an exchange of information and finally the quiet ride back to the Monitor. I thought seeing Brian Chan, Ed, the many other Brains and Mikes of Liferay, meeting David Caruana, Peter Monks of Alfresco,  seeing my Friends and Colleagues from Rivet Logic, Kaplan, Alfresco, Liferay and meeting and making many others was exciting and that loosing power during my presentation was terrifying. This cab ride was both exciting and terrifying!! 

Anyway – Back to more important topics: THE MEETUP! 

Demo Highlights:

Liferay demonstrated their new Enterprise Packaging / Repository capability.

This functionality allows IT Shops, ISPS, SI’s and the community to create Liferay components (Portlets, Themes, and Layouts), upload them to a central repository and make them available for download. The repository helps the portal administrator manage versions and encapsulates messy install details inside automated install machinery.

Brian Chan, Chief Architect of Liferay said that Liferay is looking to position itself as the “Operating System of the Enterprise.” This kind of functionality is a step in that direction.

This functionality arrives in version 4.3 along with other improvements and features.

Alfresco demonstrated their new Web Scripts functionality.

Web Scripts allow you to expose Alfresco Repository and Alfresco Web Client like functionality outside of your repository. Like what? Documents, Versions, Folders, Workflow, Saved Searches, Ad-hoc Searches, Discussions, and Taxonomy.

David Caruana (Alfresco Chief Architect) and Luis Sala (Alfresco Sr. Director of Solutions Engineering) demonstrated some beautiful AJAX driven UI exposed inside an Liferay Portlet for browsing the documents inside your repository. They also showed a custom AJAX driven interface for managing your tasks and uploading new content.

What is involved? A custom URL, a little XML descriptor, Javascript, and a Freemarker template. You don’t have to be a hardcore java programmer to build web scripts!

Web scripts are well suited for creating custom interaction with your repository, outside of the web client but they can be used for a lot more.  Download Alfresco version 2.1 and check it out.

Hot Topics:

Of course there was a lot of talk about the individual products. Both Liferay and Alfresco have a lot to offer! Each product packed the house when demonstrating their latest and most salient features. The other topic on everyone’s mind was Alfresco Liferay integration. There where two packed sessions dedicated to this topic – I think we could have held a captive audience for even longer!

Mike Vertal of Rivet Logic hosted the initial conversation. He asked the first and most important question. Alfresco + Liferay Integration: what is it? Well it depends on who you ask and what they need. Mike in his presentation and I during mine both suggest that if you are going to work with these two products and try to bring them together, you must ask yourself what are the components and features of each product that are core and which are context as they relate to the problem you are tying to solve. We examined integration of the two products in general as a group.

Mike gave us four major categories of implementation to begin with. I would file them under two major categories:

• Light Integration

• Deep Integration

Light Integration

• Alfresco Web client as a portlet. Alfresco can currently be deployed in to Liferay and its Web Client (in its entirety) can be accessed as a portlet.

• Portlets that expose Alfresco resources including documents, workflow, searches, tasks, discussions, metadata, categories etc. Some portlets exist for exposing this today. Alfresco Web Scripts promises to make exposing these resources and creating this type of light integration much easer.

Deep Integration

• Alfresco as the store for Liferay resources:

o Communities

o Page Layouts

o Theme Definition and Resources

o Layout Definitions

o Profile

o Preferences

Alfresco as a store is a bit of an over-simplification -- where things are stored is not really the issue.  There are several variations on this deep integration. Mike gave two, which I have collapsed to one.

Deep integration is the interesting and difficult problem to solve. We had some really interesting discussions on the subject and I want to come back and post another blog with a single focus on this subject. I think there are many factors in bringing these two products together, not all of which are technical in nature. Since there are plenty of technical hurdles we’ll stick to them in the next discussion.

All in All it was a Fantastic, Exciting, Terrifying, Mind Expanding, Super experience! I am really really glad I went.  It was worth every second (I know; I was awake for each one) and every penny and I hope you will consider going to our next meetup -- I won't be offended if you don't want to share a cab :)

Connectedness and Coupling

I want to argue that connectedness is the fundamental feature of successful systems.
I also wish to posit that connectedness is a fundamental feature of failing systems.

The difference between success and failure is a matter of “coupling.” You may think of coupling defined as “how things are connected.”

 Connectedness sounds like risky business, why not just avoid it?

 Consider almost anything you can think of – without connectedness, it is inconsequential... The best content in the universe not distributed is certainly not king [“content is king”]. A lone transistor, the foundation of our modern, technology assisted world is itself nothing useful unless connected to many other transistors. Neurons, businesses, computer systems, communities, examples abound: nothing much interesting happens until there is connectedness.

 
Why is this? Connectedness brings on what we call “network effects.” Network effects are basically the appearance or emergence of new properties of a thing (a whole) that none or only some of the involved parts share. So the saying goes: “The whole is greater then the sum of its parts.” You may imagine that a crowd has properties that an individual does not, a brain properties that a neuron does not, a circuit properties that an electrical component does not and so on and so on.

 Clearly connectedness is “good” thing.

If connectedness is so great than why do we find so many examples in which failure seems directly related to “this being connected to that.” Why to business units want autonomy? Why do programmers dread “spaghetti code?” What are the short comings of public transportation? Air conditioners, automobiles and aerosols cause climate change?  Clearly connectedness can be troublesome stuff. Not all network effects are “good” or “desirable.”

 Making the network work for you:

The key to prosperity is the creation of so-called “virtuous cycles” – catalytic processes that build, one iteration upon another. Each additional input’s potential magnified and managed by presence of others.

 Magnified and Managed?

 In order to for a catalytic process to be “virtuous”, it must not produce unwanted effects. Chain reactions taken to extremes can be devastating. Think global warming. The design of the atom bomb leverages a chain reaction to unleash in terrible violence the power behind the elegance of E=MC^2. Feedback is the processes of taking the output of a system and “feeding” it back in to the system as input. It is uncontrolled feedback that almost certainly leads to undesirable outcomes.  Experience with feedback has taught us that we must include gates, valves if you will, that allow us not to accept the feedback in to a system as input when we have reached certain thresholds. Systems that have this ability are generally capable of balancing themselves. You may not that our planets ecosystem is in constant search of balance – good or bad for human survival. Thus it is up to us to consider with great care of the network effects, the pressures we put upon the Earth.

 
We understand that in order for one thing to be influenced, magnified and also managed by the presence of other “nodes” or members of the network, it must be connected to them. The secret to deep management of the network is in the coupling of on thing to another. It at the point of coupling the nature/processes of systems turns from virtue to vicious.

 
The absence of connectedness is almost certainly a recipe for failure. Traversal of the landscape of connectedness is to dance with care, the subtle balance between prosperity and devastation. In order to leverage network effects we must of course have a network. In order to make sure that all network effects are “desirable” we must examine how things are connected to, not connected to, and are “gated with” one another. 

I’ll be back in a bit with a closer look at coupling.

Open Source Distilled - err at least this is what I think at the moment

·        The Internet has changed everything. Accept it.

o     Massive Connectivity is changing the way people engage and approach everything. Including business.

·        Open Source is not (in and of itself) about

o     Community

o     Intellectual Property

o     Commoditization

o     A business model (services versus product)

o     Openness

o     Standards

o     Vendor lock in

o     Choice

o     Quality

·        Good Open Source has all of these attributes but none of them define what open source IS. Open source is just a specialization of a larger movement initiated by the birth of the Internet.

(The telegraph, railroad, air travel, mail, phone, and electric systems etc all part of the pie but it is reasonable to say the internet is the birth of a new era)

·        The Internet creates connectivity, availability of resource and freedom to leverage and do.

o     The world is adapting to, and assimilating with this. Your kids are more assimilated now then you will ever be – it’s a natural thing – and a reality.  There are those who understand and those who do not.  There are those who can accept and those who cannot. There is a difference between understanding and accepting.

§        We resist emotionally

§        We resist philosophically

·        The Internet is only the beginning.  Technology and connectivity have been growing steadily but the shape of the curve is about to change. This point is stated (rather dramatically) in “The Singularity”.

o     Today’s Internet is accomplishing much – for such a weak solution.

o     Modest improvements would yield incredible growth – semantic web.

o     The Internet as we know it is weak and temporal. The freedom and opportunity it creates is real and permanent.

Back to open source.  Open source will be as successful as much as those involved recognize what is going on.  What defines the success of open source?  That’s not easy to say.  One measure is obviously success in the commercial world.  Its not the only measure.

Commercialism is great. Serve more then your own interests.  You are temporal. Your effects can be long lasting. Businesses will have to adapt and embrace the way people are changing and engaging or go extinct. Some open source companies get this. Some don’t.

Get A Clue

Unless you live in a hole, you are aware that the Internet has broken the distance barrier and has made our planet a small place. What you may not be fully aware of, is the ways in which it [The Internet] is changing the people (markets) who are connected to it. If you have been paying attention to the youth (most likely to your kids) you will notice that they belong to websites like friendster.com, myspace.com and other online social networks.  They are always online, they are always connected.  How many of your children carry cell phones? 

People are heavily connected, heavily engaged: forming communities (also called social networks).  These communities are growing and they are changing the way people think, the way engage businesses, and the world.  Online communities are about communication, participation and sharing. They are large, and in and of themselves have the ability to make decisions and move market trends. Community members are educated and motivated by other members. Massively connected social communities are extremely powerful and they are coming in to their own as a mainstream construct.

Many CxOs are oblivious to this happenance.  Even if they know about it, they cannot understand it.  The face of the world is much different then the world in which we grew up.  The level of connectivity and community is growing faster then the rate at which we can assimilate it.  Most of us have emotional resistance to these changes. We are way outside of our experience and comfort zones. How many CxOs really understand why open source is a successful movement? I am not saying we are old. I am saying the rate of connectivity growth is no longer arithmetic in nature. Sooner or later we will loose the ability to see the future by the observation of the past (trends). The geometry of the trends are about to change. The future will not relate to the past in the way which we are used to.

Children are growing up connected to the world.  They have access to levels of information you and I could not have dreamt of when we were their age, and they are comfortable with it.  The reality is that they are a different breed then we are.  With much more information available, individuals  are BETTER INFORMED and expect to PARTICIPATE in ways most of us do not.  They will expect the companies and organization that they interact with to respect the fact that they are better informed.  They will expect the companies that they deal with to participate in a much more personal way.

We are talking about a level of community involvement, honesty and transparency which most companies today cannot fathom, and are simply not prepared to cope with. We are talking about companies with a much more real, human face. What does this mean for companies? No more sales pitches. Communities know as much as vendors, likely more. Conducting business behind corporate walls is looked down on. Informed communities demand honesty and transparency. They expect a face to face communication with business leaders. They expect to define the market.  They expect to guide the company.

 

Community is about community; it shuns that which is not community. If business wants to be successful in the future they need to change the way they perceive themselves, the way in which they approach and engage the “market”, and engage with the world. They must become part of community or fade.

Clue Train

If Open source doesn’t change the way we think about business then it is a waste of our time.

The crossroads of mediocrity and greatness

If open source isn’t changing the way we think about business then we are wasting our time. We are in business. We should be thinking about business. How can my business better serve my customers, my community, my planet, etc? How can I better serve my business in its mission to serve? When we look for ways to better serve and do business, whether we like to admit it or not we often find ourselves chasing after small potatoes, in pursuit of greatness, achieving mediocrity. “Staining out gnats and swallowing camels (Mat 23:24)”. I am not saying that open source is a gnat; by all means it should not be. Camel or gnat: ideology and wishful thinking will not define this; performance will. Business owners beware. How you approach open source will dictate the constitution of the impact open source makes on your business. I contend that open source applied to traditional business approaches will cost more then it is worth.

 

ERP, .com, and Open Source – rubber bullets

Is there a silver bullet to the application of OS? No, of course not; there is no such thing as a silver bullet (outside of the movies and beer commercials). Make no mistake, there are businesses looking for the elusive silver bullet. There are quacks and matchstick men that willing to sell these organizations exactly what they want (to hear). If we are honest with ourselves we can admit that we are all generally pain adverse and for many of us it is better to believe in a lie for the short time it provides relief. If you think open source is going to solve your problems simply for the fact that is open source and appears to be with in your price range; you can’t afford it. If you fall in to this category, the way in which open source may impact the way you think about business is generally that you will have learned (through much pain) that there are no silver bullets. It is likely, like many of us, you have tasted this bitter lesson before, and you may taste it yet again.

 

Sigh – What the heck is open source?

Some see open source as the marketing strategy of the moment. These are the folks who dump IP on a service like SourceForge and declare they are open source. We wish you luck. When you rely on “cheap” marketing to sell your product it is likely that you don’t have a product which truly serves your customers, your community, your planet; it serves only you. You add no value.  It is unlikely that a company could really exist on this approach and for those that can  we hope you have made / stolen the money you need to survive after your quackery is exposed. Dishonesty is not a sustainable model.

 

One question I ask myself time and time again is “what is open source?” Is open source about software, about IP, about community, about choices, about commoditization, about freedom (love, and liberty), about a focus on services rather then product, about catching more flies with honey then with vinegar?

Is open source about software, about IP?

Sun Microsystems is showing the world that open source, defined or not, is a concept which can be applied outside the realm of software. Sun is quick to admit it gets open source, but they are not saying what it is that they get about open source: and yes … they get it.

 

Is open source about community?

Of course you need community, but community doesn’t make open source. Oracle has OTN, Microsoft has MSDN, and Digital had DEC-Net. Community is necessary for open source but it doesn’t make open source.

 

Is open source about choices and commoditization?

Of course open source creates choices, and hastens commoditization. Are we really excited about something which is nothing more then a catalyst for the inevitable? If such is the case we are “swallowing camels...”

 

Is open source about freedom?

If open source is about freedom (as in free love) then it has a limited scope in business. No respectable CxO expects to get something for nothing. They are business men! They don’t expect to give something for nothing.  They don’t expect open source to give something for nothing either. If open source is about freedom (as in liberty); then great … as long as that liberty can be leveraged to increase business.   Liberty for the sake of liberty can remain on the roster of drunken late-night fraternity discussions along with Zeno's conundrum.

 

Is open source about a focus on services?

If open source means only that we focus on services rather then product for generation of revenue then the question becomes motive. Why would anyone give up a revenue stream? Of course they would, if giving it up meant more revenue. If you think commoditization, and increased customer options is the key to selling services then I ask only how long is it until your services are sidelined by another competitor?

 

There companies which view open source as a way to show case product via an open source community version with the intention to up-sell them an enterprise grade product. These companies are attempting to “catch more flies with honey then with vinegar”.  They are using open source as a carrot. These companies are leveraging open source. They are building a support structure that they don’t pay for. They are encouraging further development outside of their own. This is a sound approach. It certainly works (MySQL, SugarCRM, GreenPlum, Alfresco), are proving this. The bottom line is that the honey is bitter sweet to the community. Many of these organizations are in total control of what is considered for inclusion in the product (not the community). The company tends to come across as a benevolent organization and not a whole lot more. These companies see how open source can be used to generate / increase business. They get open source … sort of.

Don’t feel bad when others “Exploit” Open Source

Don’t feel bad when others “exploit” open source. Don’t be afraid to “exploit” open source. Businesses exist largely to make money. I am of the firm belief that businesses should exist for much more noble pursuits, revenue being the means to an end, but that’s me. The companies who have found a way to give to the community and leverage the community as a mechanism for generating / increasing business should be applauded. I firmly believe that if open source were only about freedom then no one would be able to make a dime on it, and it would remain in the realm of the bored and curious.

Open Source that makes a difference means Change in the way we think about business.

 

The companies that get open source are making money because of open source. There seem to be two fundamental approaches in play (with a many of variations / combinations).

• Community      / Professional Versions (SugarCRM, Alfresco, MySQL, Redhat, etc)
• Services      (Jboss, Liferay, Alfresco, MySql, Redhat)

 

There is endless debate about whether a company should only sell services versus sell a professional version (which includes non community code). I don’t see either of these two approaches or their blends as a problem. I think they may both indicate that traditional business approaches are being applied to open source. The issue is not that these companies will not make a profit; it’s that they are not going to make the kind of profit as the companies that are breaking the mold.

 

When an organization releases all of its IP and makes its revenues on services, it is not a given that gets open source. In deed, it may indicate that it doesn’t understand business because they are giving up sales revenue! As an OS Business -- you release 100% or your IP, it’s because it makes business sense to do so! This is likely because you realize the IP is not what is going to generate the most business.

 

When an organization uses open source as a carrot intended to up sell enterprise customers it may indicate that they do not understand open source. They understand it as leverage but not LEVERAGE!

 

The question is not whether to sell product, services, etc. This is a red herring! Companies that get open source realize the following:

 

Open Source is the STICK (CROP) not the CARROT!

 

IBM and Sun Microsystems have made this discovery and laid it out for the rest of us in plain sight. Seeing; we see not!

 

Focusing on the carrot is straining at gnats and swallowing camels. IBM has given away flag ship products and IP. In return it enjoys the benefit of huge services revenue and increased adoption of other flagship products.  IBM enjoys the comfort of sitting on almost every major standard initiative. They are in control, lashing away with the crop while you chase the carrot. IBM raised itself from the dead through this discovery.

 

Sun Microsystems recently released a new chip design to open source. It is not enough to commend the genius of this design. Take a processor that works, recognize that the floating point functionality is a waste of power, cycles and money for nonscientific computing and simply do away with it resulting in a blazingly faster processor that consumes less power (half) and costs less. Obviously, engineers and business people should learn a valuable lesson concerning complexity. Sun is thinking outside of the box in terms of hardware and business. By putting the new architecture in the public domain Sun is opening up business opportunities with fabrication facilities on off shore locations that may not be practical or even legally available to them under a traditional model.

Sun has shunned the carrot and taken up the crop.

 

For those companies which are truly willing to lay their models "on the altar" and change in their hearts, open source is working wonders. The rest of us are eating the scraps from the masters table or traveling down the path of self deception and destruction.

The Problem with Commercial Open Source Software

So you are the CxO of an Open Source Company?  What is your game plan?  How can you make this company be successful under the open source paradigm?

What makes Open Source tick? Is it really the free software? Is it community? I have been at conferences and in discussions when this question has been thrown around. Inevitably someone says “Software development just is software development. It’s community that makes open source different.” Opponents of this view quickly point out that Microsoft, seen as a major cold shoulder in the open source community has a large development community called MSDN (Microsoft Developers Network). In fact MSDN is the largest, most active developer community there is.

People who point to community as the value of open source are on to something. But it is not really the presence of community that is different; it is the mentality of the community. There is something distinctly unique about open source community vs. MSDN.  Successful open source communities have something that doesn’t exist in the MSDN. It’s what some call “The inventor’s spirit”.  Microsoft has a large community to support engineering based on existing Microsoft engineering. Design and practices are essentially handed down from Microsoft on high. Articles explain and discuss Microsoft technology and strategy but there is little room to influence direction (to invent) from the community at large. If you want to change the direction of Microsoft or Oracle, get out your wallet and hope it is got more girth then their other customers.

Open source gives developers the chance to give their time and effort to a product. The amount of latitude given to invent on the product scales from a forked modification / additions of existing software to full design and vision voice. In most open source products, developers attain the right to contribute as inventers with higher levels of influence by demonstrating a level of commitment and insight. In many examples of well known open source products, the emphasis is on engineering.

The commercial part of commercial open source is always in danger of standing in the way of this model. After all product vision is always tied to some revenue component. For example “we will focus on this feature or drive the product in this direction because there is more profit to be made in that direction.” COSC (Commercial Open Source Companies) must be careful in balancing what their clients need versus what their community needs.

If COSC is not thinking about its community it is not Open Source. It is a ploy ridding the open source bubble / wave. If a COSC is not making the community its priority then it may be open source but it’s a failing model.

A community of inventors is the only successful model there is in the open source world. COSC would do well to understand this and modify their practices to leverage this working model. The benefit of being part of the OSS community is that you are looking to spread your visionary, engineering, documentation, support and quality control responsibility and risk around. Vision, engineering, documentation, support, and quality control are all in their own right, hard work. The only thing that is truly a match against the barrier of hard work is something we might call passion. Passion is not something you can bottle, it is no commodity. However, there is one demographic that seems to have more passion then any other: inventors.

Inventors will watch the sun rise and fall several times in one sitting while working to make their invention come to life. Every manager wishes their employees had that kind of dedication to their work but it is rare. You might find it at JPL, Langley or Bell Labs. Exactly, these are all examples of inventor havens. I know of another example of an organization where the individuals work a 16 hour day then come home and willingly work another 8: The Apache Foundation.

COSC will only reap mediocre benefits of open source unless they are able to create a community of inventors.

To create such a community of inventors:

• Be "free as in beer." The open source model that works is services. There is no good hybrid approach to this. Anything less then free (as in "free beer") is seen as Shareware, crippleware, and the like. Remember: Perception is reality. The open source community is unforgiving when it comes to the perception of a product in this space.

My friends and I have a saying that goes like this: “The ‘C’ in ‘CIO’ is for ‘Chicken’. Anyone who has money to give in the first place (A real business); will give it to you for support. Don’t play games with them and force them to do what they will already do. CIOs need to support what the put in place.  Don't worry, its a given in 9 out of 10 cases.

• Let go of the control on product vision. Take IBM and Eclipse as the primary example. Let the community drive the vision for the product. Maintain a strong presence in the community so that the company’s vision is well represented. IBM is one of OSS's biggest contributors, but they definitely assert the IBM position and direction.  They are making open source work for them.

• Focus on revenue without focusing on revenue. COSC is a new model. Think laterally; it is not enough to think outside the box, burn the box down.  OK so you made the jump to the OSS business model.  It's not traditional - stop trying to make it traditional.

• Play well with other open source products. Spring framework is demonstrating mastery in this space. Spring is a framework that seems to bring together all kinds of other frameworks. This model is not to be ignored! Make sure you can plug your product in to other open source products. Make sure you can plug other open source products in to yours.

• Support your community. The community is your number one customer, ALWAYS. There is no bigger, more valuable customer.

• Breed experts on your software. The more experts there are, the more traction you will have, the less support you will need to maintain. If every committer on your product works for you, you are doing it wrong.

• Anything that is not your core problem domain: give away. There is another OSS community working in that space. Contribute there. Don’t be an island of engineering. It is bad form. Give your engineering wider exposure by giving it to other products.

• A large community is the goal. Large communities are hard to build. Large projects are hard to build communities around.

Large projects are a folly. When a project has a large scope it usually indicates that it should be several small projects. This is a concept familiar to software engineers. Some of those smaller projects have nothing to do with the problem domain of the overarching project; give them away.

Build small communities around small projects. The larger community will emerge as a few members of each small community cross over.

Large products should almost be nothing but open source configuration. Pulling together small products in interesting ways.

• Attract Inventors. Make sure they are given the latitude and longitude to invent.

So you are the CxO of an Open Source Company?  What is your game plan?  How can you make this company be successful under the open source paradigm?

What makes Open Source tick? Is it really the free software? Is it community? I have been at conferences and in discussions when this question has been thrown around. Inevitably someone says “Software development just is software development. It’s community that makes open source different.” Opponents of this view quickly point out that Microsoft, seen as a major cold shoulder in the open source community has a large development community called MSDN (Microsoft Developers Network). In fact MSDN is the largest, most active developer community there is.

People who point to community as the value of open source are on to something. But it is not really the presence of community that is different; it is the mentality of the community. There is something distinctly unique about open source community vs. MSDN.  Successful open source communities have something that doesn’t exist in the MSDN. It’s what some call “The inventor’s spirit”.  Microsoft has a large community to support engineering based on existing Microsoft engineering. Design and practices are essentially handed down from Microsoft on high. Articles explain and discuss Microsoft technology and strategy but there is little room to influence direction (to invent) from the community at large. If you want to change the direction of Microsoft or Oracle, get out your wallet and hope it is got more girth then their other customers.

Open source gives developers the chance to give their time and effort to a product. The amount of latitude given to invent on the product scales from a forked modification / additions of existing software to full design and vision voice. In most open source products, developers attain the right to contribute as inventers with higher levels of influence by demonstrating a level of commitment and insight. In many examples of well known open source products, the emphasis is on engineering.

The commercial part of commercial open source is always in danger of standing in the way of this model. After all product vision is always tied to some revenue component. For example “we will focus on this feature or drive the product in this direction because there is more profit to be made in that direction.” COSC (Commercial Open Source Companies) must be careful in balancing what their clients need versus what their community needs.

If COSC is not thinking about its community it is not Open Source. It is a ploy ridding the open source bubble / wave. If a COSC is not making the community its priority then it may be open source but it’s a failing model.

A community of inventors is the only successful model there is in the open source world. COSC would do well to understand this and modify their practices to leverage this working model. The benefit of being part of the OSS community is that you are looking to spread your visionary, engineering, documentation, support and quality control responsibility and risk around. Vision, engineering, documentation, support, and quality control are all in their own right, hard work. The only thing that is truly a match against the barrier of hard work is something we might call passion. Passion is not something you can bottle, it is no commodity. However, there is one demographic that seems to have more passion then any other: inventors.

Inventors will watch the sun rise and fall several times in one sitting while working to make their invention come to life. Every manager wishes their employees had that kind of dedication to their work but it is rare. You might find it at JPL, Langley or Bell Labs. Exactly, these are all examples of inventor havens. I know of another example of an organization where the individuals work a 16 hour day then come home and willingly work another 8: The Apache Foundation.

COSC will only reap mediocre benefits of open source unless they are able to create a community of inventors.

To create such a community of inventors:

• Be "free as in beer." The open source model that works is services. There is no good hybrid approach to this. Anything less then free (as in "free beer") is seen as Shareware, crippleware, and the like. Remember: Perception is reality. The open source community is unforgiving when it comes to the perception of a product in this space.

My friends and I have a saying that goes like this: “The ‘C’ in ‘CIO’ is for ‘Chicken’. Anyone who has money to give in the first place (A real business); will give it to you for support. Don’t play games with them and force them to do what they will already do. CIOs need to support what the put in place.  Don't worry, its a given in 9 out of 10 cases.

• Let go of the control on product vision. Take IBM and Eclipse as the primary example. Let the community drive the vision for the product. Maintain a strong presence in the community so that the company’s vision is well represented. IBM is one of OSS's biggest contributors, but they definitely assert the IBM position and direction.  They are making open source work for them.

• Focus on revenue without focusing on revenue. COSC is a new model. Think laterally; it is not enough to think outside the box, burn the box down.  OK so you made the jump to the OSS business model.  It's not traditional - stop trying to make it traditional.

• Play well with other open source products. Spring framework is demonstrating mastery in this space. Spring is a framework that seems to bring together all kinds of other frameworks. This model is not to be ignored! Make sure you can plug your product in to other open source products. Make sure you can plug other open source products in to yours.

• Support your community. The community is your number one customer, ALWAYS. There is no bigger, more valuable customer.

• Breed experts on your software. The more experts there are, the more traction you will have, the less support you will need to maintain. If every committer on your product works for you, you are doing it wrong.

• Anything that is not your core problem domain: give away. There is another OSS community working in that space. Contribute there. Don’t be an island of engineering. It is bad form. Give your engineering wider exposure by giving it to other products.

• A large community is the goal. Large communities are hard to build. Large projects are hard to build communities around.

Large projects are a folly. When a project has a large scope it usually indicates that it should be several small projects. This is a concept familiar to software engineers. Some of those smaller projects have nothing to do with the problem domain of the overarching project; give them away.

Build small communities around small projects. The larger community will emerge as a few members of each small community cross over.

Large products should almost be nothing but open source configuration. Pulling together small products in interesting ways.

• Attract Inventors. Make sure they are given the latitude and longitude to invent.

Enterprise Integration

Traditional Integration

Before discussing “Enterprise” integration it may be helpful to speak about traditional integration.

Traditional integration techniques consisted of hard linking one key system to another in order to share information. These integration approaches required the identification of key data, which, in most cases, could be used in the replication of data from one system to another. This style of integration can occur in both manual and automated systems. The traditional approach to integration is inflexible, intolerant of change, and extremely cohesive [brittle]. When the integration in the enterprise is brittle, the enterprise itself is brittle.

The reason why integration is / was performed as in such a brittle fashion, is for the most part, an artifact of the times and the technology. Enterprises are increasingly implemented in technology and as this shift occurs, the role the technology serves in the enterprise are changing. Integration is being revolutionized.

Integration Revolution

You may be thinking that it is technology that is reshaping the shores of the integration landscape; but technology is only a means to an end. Yes, enterprises are now being implemented heavily in technology, and yes, technological advancement is making it easier to “integrate” the enterprise. However, technology such as middleware and XML are only changing how we implement integration, they are not what is revolutionizing what enterprise integration is.

What is revolutionizing integration is the business realization; that integration is not merely about sharing information between systems; integration is the substrate of the enterprise.

The realization is two fold. First, enterprise integration knits together much more then just data, it integrates the enterprise [the system]. The system is the people, processes, procedures, and assets/information within a domain. Second, because integration is the substrate of the enterprise; it is the place to monitor the pulse of the enterprise, and insulate and facilitate change within and without.

Examples of Integration in Nature

One example of integration that exists in nature, which is particularly revealing is the biological cell. Cells are composed of all kinds of components. Some of these components are more like systems (e.g. nucleus) while other components are more akin to integration mechanisms (e.g. cytoplasm and the cell wall).

Traditionally we tend to think of integration as pulling our systems together. The cell’s integration system exhibits this behavior, and something else as well. Integration facilitates growth. The cell membrane and cytoplasm are integral components in the process of cellular mitosis (process of cell division).

The Nature of Enterprise Integration

Enterprise integration is the integration of the enterprise [didn't’t see that one coming]. The enterprise is the composition of its system(s). The system(s) are the people, processes, procedures, and assets/information within a domain. The question remains: what is integration?

Integration is generally thought of as a process of achieving completeness by bringing together disjoint things. It may require a kind of force to bring two distinct “systems” together. Once together, there must be a management of the forces that would cause them to separate. It becomes clear that while integration is a process of achieving completeness, it is much more. Enterprise integration is the process \ mechanism, through which enterprise forces are managed. Enterprise forces include the following:

• Inertia
• Change
• Growth
• Entropy

Enterprise integration is the process \ mechanism, through which enterprise forces are managed, it is one of the most valuable assets in an organization. Integration, while performing its primary concern of the management of se forces, is also the place to gather metrics on the enterprise (e.g. system health monitoring, BI (business intelligence).

Through an integration strategy our enterprise should be transparent. We should be able to understand and measure its current course, health, and metrics (inertia), understand and manage strategic course correction (change), facilitate distribution and acquisition of future systems (growth), and fight back the natural destabilization process (entropy). In terms of completeness; we need to be able to view the enterprise as one large system, without disrupting the ability to drill down to any particular endpoint.

Does My Enterprise Need A Integration Strategy?

Your enterprise is: The system(s) are the people, processes, procedures, and assets/information within a domain. Unless all of these things are met with a single cohesive implementation (good luck), you need integration. I submit that every enterprise needs an integration strategy, no matter what implementation they have (i.e. ERP). But that’s another topic.

Enterprise Architecture

Not blowing up on the launch pad

There is no doubt in my mind that the subject of enterprise architecture is important, relevant and necessary, but there are a few cultural things that can threaten EA efforts right on the launching pad.

• Enterprise architecture must be made and kept practical. There is nothing impressive about a subject which is a mystery to your coworkers. If they cannot understand the subject or cannot see the practicality of the effort, there is no way they can help with or have the incentive for furthering the cause.  Enterprise architecture is practical because it effects everything it involves (including the people) directly on a day to day basis [see Enterprise Architecture Distilled].  Demystify EA, and keep it practical.

• Enterprise architecture has almost nothing to do with technology. The fact that this  point is generally misunderstood is one of  leading  reasons that EA efforts fail. Most EA efforts are started by IT departments. This is natural because IT tends to feel a lot of pressure for business investments in technology to deliver on things like integration with existing systems.  In order to deliver IT finds itself asking EA related question because IT EA is only one specialized abstraction removed.  The problem with IT attempting to decipher the EA is that, as members of IT, we tend to be technologists who eat, sleep and breathe technology. This mind set has two dangerous effects: first, we spend a lot of time thinking about this or that technological solution, and less time think about the true business concerns (from a business perspective). Second, many of us cannot remove ourself from world of acronyms, buzz words (like “Enterprise Architecture”), and techspeach which doesn’t mean much or anything to the business outside the IT department. More often then not IT staff is ill equipped to  effectively communicate; rendering the effort void. When working with enterprise architecture, take off your technocratic hat. Enterprise architecture has to do with systems (automated and manual) not technology per se.

Enterprise architecture distilled

What does enterprise architecture mean? Well, let’s concern ourselves with the first word first (makes so much sense). John Zachman [the father of EA] can be quoted as saying “The system doesn’t merely support the enterprise, the system IS the enterprise“. The enterprise is composed of the systems in its domain.

 

Architecture is the practice of design.

If you translate system(s) to mean the people, processes, procedures, and assets/information, then enterprise architecture can be distilled as:

Enterprise architecture is the design [model] of the people, processes, procedures, and assets/information [system(s)] within a domain.

 

This definition gives some insight into the magnitude of enterprise architecture, but it does not overtly justify it. In many cases today, systems are defined in vacuums. We have been building enterprises this way since the beginning, why change now?

 

Technology is the latent catalyst for this change. I know that in the beginning of this article I said EA has almost nothing to do with technology, and it doesn’t. However, EA has to do with systems and as time elapses more and more of our systems are implemented with technology.  As technology gains traction as the implementation of choice, and as it grows in capability its role in terms of the enterprise is changing.  When technology began to take it's place in the business space, it was used to support business and foster local efficiencies.  Today the role of technology in the enterprise is fundamental,  and deeply en-grained.  In many ways technology does not support the business; it is the business (you are what you eat?).

With today's technology comes capability and expectation. Businesses invest huge amounts of money in IT systems hoping that technology will deliver on its promises. When these investments fall short on their promises, business wants to know why. Technology, more then other implementations is subject to entropy, yet it offers the greatest potential. Entropy cannot be stopped; it is a fact of technology. Businesses have been looking to harvest the great potential of technology, while underestimating the effort required to fight it's entropy.  The miscalculation is likely due to the fact that we have never experienced the kind of grow we have with technology, and we have not yet come to terms with the fact that it now plays a major role in the foundational space of or enterprise. Strategy is the slowing agent in terms of entropy, and the lever when it comes to realizing the promises technology has to offer.

 

Technology is not the reason to model your enterprise. Technology is only the implementation. Even a pen and paper business would do well to model their business. Models enable us to create strategies for tomorrow and tactics for today.

As the demand for greater integration, higher efficiency, and lower cost continues to accelerate it is impossible to design in local vacuums of concern and still deliver the goods. Know that these demands will never decrease; a business that can not navigate these absolute requirements will not be able to survive as the information age progresses.

What is in our way?

Enterprise architecture efforts have many things that seem to impede them.

• We never did it before, why start now?
• We don’t know how to do it.
• Once we get started, we see how difficult it is.

What is in our way; is us. What we stand to loose by impeding ourselves is practical, sane business practice, and competitive advantage.

 

Technology holds the key to leverage. To understand technology as the key to leverage, one must consider how it's role has changed in the enterprise since the dawn of the information age. We no longer simply use technology for localized improvement of a particulare process or domain (which has only a linear effect in terms of growth), we now rely on technology in such a way that it has the capability to radically effect global phenomena within the organization, it's impact is geometric, and thus paramount.  However, the promises of technology will always fall short without proper vision and planning (architecture). If a business fails to see this, they will, in this information age, cease to be a business. The sooner a business can come to the realization that it must model itself and begin to holistically plan; the more competitive advantage it will have. This is a simple issue of pay now or pay later (if your business is around later). The longer you wait to get involved in enterprise architecture, the more it will “cost” when you finally do.

Enterprise modeling

The purpose of modeling your enterprise is to gain an understanding of the current state of the enterprise. Once the current state is understood, target states (strategies) can be derived. Models/enterprise artifacts are the requisite tools for success.

Enterprise models need to be multi-dimensional. They need answer a number of basic yet important questions in relation, and in parallel with other simular questions. These questions are the kinds of questions you learned about in grade school: Who, What, Where, When, Why, How. All of them; so simple, yet we often fail to ask them in conjunction with each other (let alone capture them in a model).

 

There are many approaches to the creation of enterprise artifacts, but no standards. Some of the approaches (e.g. Zachman Framework) are more comprehensive then others. Be as comprehensive as possible, stay relevant.

Who should be involved in EA

While EA movements often have their origin in IT departments, IT is not the place where EA should take place. This is largely because technology is implementation and has nothing to do with actual EA. Enterprise architecture is a business concern and should be carried out by business folks (enterprise architects). Enterprise architecture has a cultural impact and it should. EA is of a scope and nature that has a profound impact on the strategic maneuvers of an organization and thus has implications in terms of the distribution of "power" within an organization.  Enterprise architecture efforts need to have a vast amount of visibility into an organization and should be solidly vetted by top level management.  Changes to the system(s) [the enterprise] should go through, and be granted permits by the EA staff.

That being said, technology is the implementation, and there is no getting around the fact that technology is a major player. IT should have a representative on the EA steering committee.   

Enterprise Architects

Enterprise architects are responsible to facilitate the creation of enterprise models. The work of the EA architect at the highest level is purely conceptual and model based.  This is a space is a completely solution agnostic domain. In the information age the best candidates for architects are multi disciplined (Business domain / IT Architect) professionals. In reality enterprise architecture is a cultural animal.  Architects and EA related staff are not the wielders of a silver bullet gun, but coaches; empowered to help further a culture that has profound, positive impact on an organizations ability to operate strategically.  The enterprise represents all that it effects, and all should be involved [EA as a soft skill].

 

One level down involves high level solution archetypes. Solutions remain agnostic to implementation but are defined as high level solution strategies. Assuming that systems will generally be implemented with technology, IT architects play heavily in this space.

•  High level application approach

•  Integration strategy

•  Persistence strategy

•  Physical approach

 

References

John Zachman – ZIFA (Zachman Institute for Framework Advancement)
Naor Pinto and Jim Bowen -  for their feedback and consideration

Nanoblog?

So whats in a title? Everything is going nano these days.... and so is this blog :) Not that I have any intention of making small blog entries :) TypePad's registration process asked that I carefully consider my host name... i felt pressured, buckled due to lack of domain name inspiration, and picked something.

Stay tuned