At this morning's general session, the first keynote was given by Ted Neward of Neward and Associates, who returned to Jazoon to help us consider "Rethinking the Enterprise". Neward has attended many technology conferences over the past few years, and has heard the same kinds of questions repeatedly: what web framework should I use? What persistence API? What scripting language?
He feels that sometimes with these questions people are really asking, "what will make me current with popular technologies so that I am sufficiently relevant to avoid being outsourced?", while in other cases, they are an attempt to discover the current "right answer" with respect to all technology questions. Rather than answer the questions immediately, he posed a set of mathematical and logical problems in return.
Each problem he posed was solvable using skills learned during the early school years, and yet studies have shown that many highly educated people have great difficulty in solving them -- the reason being that, in school, one is normally posed problems in the context of the skill being studied and it is much more clear what technique to apply to solve the problem. Neward suggested that we as technologists often treat what we learn through training classes similarly, learning to apply the latest tool we have learned to all problems we meet. He described this with the phrase, "the problem and its solution are never far apart" and suggests that this is natural, tying it to the basic processes of human cognition and problem-solving. This might be stated as a paraphrase of the old saying: "when you've just learned about hammers, everything looks like a nail."
So, returning to the question of how to rethink the enterprise, Neward proposed some guidelines:
- Resist the temptation of the familiar Every project is different -- customers, rules, features, needs, users, views, etc. so consider this in evaluating solutions.
- Reject the goal of reuse until you've written the same system thrice. Neward recognized this as controversial but believes that it is justified.
- Befriend the uncomfortable truth: be cynical and question assumptions Apply this to open source projects just as you would for-profit commercial offerings.
- Eschew "best practice" Neward believes that these are often simply attempts to avoid thinking, and some claim that sticking to "best practices" merely ensures that nobody is better than average.
- Embrace the "perennial gale of creative destruction" This is essentially the garbage collection of stale approaches.
- Create your own evaluation function for each tech/pattern/practice: context matters
Learn about new technologies and leave your comfort zone, consider the benefits and drawbacks of the various technological choices with respect to the specifics of your problem.
His overall answer? There is no answer...go rethink enterprise for yourself!
In the second keynote address of the morning, Roy T. Fielding, Chief Scientist at Day Software, and formerly Chairman of the Apache Software Foundation, examined the concept of "Open Architecture." At last year's Jazoon, Fielding walked us through the concepts of Representational State Transfer (REST) as discussed in his dissertation. This year's talk was somewhat parallel, in that he took his themes from a friend's dissertation: "Open Architecture Software: A Flexible Approach to Decentralized Software Evolution", by Peyman Oreizy of the University of California at Irvine in 2000.
Fielding was interested in exploring the proper kind of architectural choices to make in the context of Open Development, which was characterized as emphasizing community, taking advantage of the scalability obtainable through internet-based virtual organization, and adapting to the volunteer nature of its contributors. He also mentioned Conway's Law, which might be summarized as "system design tends to reflect the communication structure of the organization that creates it." When considered in the context of Open Development and the inevitability of change, it seems clear that some form of decentralized software evolution will be necessary or the system will very likely become quickly obsolete.
To illustrate this, a number of successful open source projects were considered, including GNU Emacs, the Apache HTTP server, the Linux operating system, the Mozilla Firefox web browser, the Eclipse IDE, and Apache Sling. The significant commonality found amongst these projects is that each has a software architecture that is designed to promote anarchic collaboration through extensions while preserving control over the core interfaces.
The challenges of this approach include the tricky nature of making the trade-off between adaptability and consistency, choosing the appropriate points in the system architecture to place the "plug-in" interfaces, and ensuring consistency (for varying definitions of "consistency": this might be in terms of data loss, response time, resource starvation, deadlocks, etc.) across third-party modifications.
Peyman Oreizy's approach was described as:
- Expose your architecture to third parties.
- Allow third-parties to evolve the application by changing its architecture.
- Verify changes against semantic annotations on the system module with the assistance of external analysis modules.
Fielding concluded by observing that the Open Source projects that have survived and prospered recognized the importance of designing an open architecture and the value of decentralized software evolution: this has differentiated the best from the obsolete!