Francis Dion on Software Process

OBA - Office Business Application

In Yoruba African mythology, the Goddess Oba transforms herself into a river, a symbol of fertility but also of communications between two realms.

In the world of enterprise architecture, OBA is an acronym for “Office Business Application”, a new paradigm for building composite solutions providing access to legacy applications through the productivity tools end-users are already familiar with.

The following diagram illustrate a typical OBA solution where the user leverages an enterprise data store without ever leaving the comfort of the tool he’s always used to create “reports”: Microsoft Word.

For more information, visit Microsoft OBA Developer portal.

Have you implemented OBA solutions in the pass? Are you planning on implementing one in the future? Share your experience, ask questions and post comments by using the “Comments” link below.

Books I Read in 2006

I love books in general and I love reading.

Even though my workdays are usually pretty long and busy, I make it a point to find (or rather make) time for this all-important mind-expanding activity. I do so fairly consistently, every day during my morning workout (while on my stationary bike) and quite often when I use the public transportation system.

I managed to read 8 books in 2006, all of them business or process improvement related:

• Getting Things Done and Ready for Anything by David Allen

http://www.amazon.com/Getting-Things-Done-Stress-Free-Productivity/dp/0142000280/sr=8-1/qid=1170565252/ref=pd_bbs_sr_1/102-8272931-6350569?ie=UTF8&s=books

http://www.amazon.com/Ready-Anything-Productivity-Principles-Work/dp/0670032506/ref=pd_bxgy_b_img_b/102-8272931-6350569

Simply the best productivity books I have ever read. Two of the few books I consistently reread and return to.

• Gemba Kaizen: A Commonsense, Low-Cost Approach to Management by Masaaki Imai

http://www.amazon.com/Gemba-Kaizen-Commonsense-Low-Cost-Management/dp/0070314462/sr=1-1/qid=1170565393/ref=pd_bbs_1/102-8272931-6350569?ie=UTF8&s=books

Dry material but still a good read for those who'd like to know some of the roots of lean manufacturing concepts and even Agile software development methodologies.

• Lean Software Development by Mary and Tom Poppendieck

http://www.amazon.com/Lean-Software-Development-Toolkit-Managers/dp/0321150783/sr=1-2/qid=1170565680/ref=pd_bbs_sr_2/102-8272931-6350569?ie=UTF8&s=books

Although a bit lean itself, an excellent book bridging the worlds of lean manufacturing and software development.

• What is Six Sigma? by Pete Pande and Larry Holpp

http://www.amazon.com/What-Six-Sigma-Pete-Pande/dp/0071381856/sr=1-3/qid=1170565876/ref=pd_bbs_sr_3/102-8272931-6350569?ie=UTF8&s=books

This one didn't left much of a trace. Not bad, but not particularly enlightening nor insightful nor, for that matter, useful.

• Crossing the Chasm, by Geoffrey A. Moore

http://www.amazon.com/Crossing-Chasm-Geoffrey-Moore/dp/0060517123/sr=1-1/qid=1170566054/ref=pd_bbs_sr_1/102-8272931-6350569?ie=UTF8&s=books

Now this for me was a real page turner. This should be mandatory reading for everyone involved in technology start-ups. (Eternal Gratitude to Andre Bouchard of Plannsoft)

• The Four Steps to the Epiphany by Steven Gary Blank

http://www.amazon.com/Four-Steps-Epiphany-Steven-Blank/dp/0976470705/sr=1-3/qid=1170566518/ref=pd_bbs_sr_3/102-8272931-6350569?ie=UTF8&s=books

Great cover artwork. Amateurish typesetting. Clearly lacking in proofreading. Yet this is by far the most systematic, process driven, lets-get-down-to-the-nitty-gritty book I have ever read on how to build a company from the ground up - and avoid the often fatal sin of going too early on an unwarranted and misguided marketing spending spree.

• The Business of Software by Michael A. Cusumano

http://www.amazon.com/Business-Software-Manager-Programmer-Entrepreneur/dp/074321580X/sr=1-1/qid=1170567937/ref=pd_bbs_sr_1/102-8272931-6350569?ie=UTF8&s=books

An extremely well documented account of the history (yes, we have one) of the software industry. His central thesis, that every software venture must choose between being a product, a service or an hybrid business, eloquently confirms and demonstrates an intuition I've had for many years. Truly excellent and relevant case studies, covering not only successes but also a lot of failed or struggling companies. Hat's off to Michael for candidly reporting on his own involvement in quite a few not-so-successful start-ups, sharing with us some key hindsight and precious lessons learned (Capablanca, one of the early world chess champions, once said the he could learn more from a single defeat than from a hundred easy victories).

• The Art of the Start by Guy Kawasaki

http://www.amazon.com/Art-Start-Time-Tested-Battle-Hardened-Starting/dp/1591840562/sr=1-1/qid=1170566995/ref=pd_bbs_sr_1/102-8272931-6350569?ie=UTF8&s=books

A guide for anyone starting anything (the book subtitle), by definition, cannot be very specific. Indeed I didn't find much substance in it to satisfy my hunger

I did, however, really liked the emphasis Guy - a true Renaissance Man if there ever was one - on the importance of being a "Mensch", which means being ethical, decent and admirable. In other words, always walk on the bright side of the Force!

Have good books to recommend on these, related or unrelated subjects? By all means, let me know!

Buy vs Build

Back when I was a corporate IT staffer, I used to hate arguments such as this one, confident in the belief (like everybody else in this business) that we could do better than anything that existed out there.

Now that I am a bit (ergh, quite a bit :-) more seasoned, my views on this topic have changed radically. Although one could point that this change of heart is more than a little self-serving considering that I am a supplier of a packaged client reporting solution, I must say that the following findings match perfectly what corporate clients I deal with are telling me with increasing conviction.

According to Gartner inc., buying packaged software (as opposed to building custom solutions) is now the dominant trend amongst corporate IT departments. Furthermore, “… build activities within organizations should be focused on quick and inexpensive ‘hits’, as well as projects that just cannot be purchased at any price”.

Here is a quick check-list to help decide whether to buy or build:

1. Can a proven, packaged solution be purchased?
2. What is the best use of development resources?
3. Does the solution or function add a competitive edge or advantage?

The last question is of particular interest to me. Contrary to what once was common wisdom, not all IT initiatives (not even most, actually) are a source of market differentiation and competitive advantage.  Therefore, businesses should focus their resources on what they do best, which is serving their customers, and leverage the R&D investments of specialized supplier for commoditized IT functions.

By the way, did I mentioned that automating the creation of business documents is a commoditized IT function in which we have invested significant R&D efforts? ;-)

Gemba Kaizen

I’ve finish reading “Gemba Kaizen: A Commonsense, Low-Cost Approach to Management” by Masaaki IMAI.

In Japanese, Gemba means “place of work” and kaizen means “continuous improvement”. The book describes how a culture of continuous improvement in the place of work (mostly but not exclusively factories) is at the heart of the Japanese miracle since the ‘70s.

While I was reading this book, I kept thinking about this scene from “The Last Samuraï” where Tom Cruise, a Westerner taken prisoner by a Japanese warriors’ community, is amazed to see how everyone there, from children to elders, spends their entire day striving to perfect themselves.

Here are some of the key concepts presented in the book:

• Quality improvements and cost reductions are compatible and should, in fact, go hand-in-hand.
• Where no standard exists, improvement cannot happen.
• The 5S (Sort, Straighten, Scrub, Systematize and Standardize) is a discipline that requires clearing out things which are not needed.
• Muda refers to anything that is wasteful and doesn't add value.
• Establishing standards, applying the 5S and eliminating the Muda are the three pillars of Gemba Kaizen.
• Takt time is the maximum time allowed to produce a product in order to meet demand.
• Cycle time is the actual time it takes to produce a product. In a functional organization, it is always inferior or equal to the takt time.
• For a process to be optimally efficient, every sub processes should be slowed down to match as closely as possible the takt time.
• There should never be a day without any improvement.
• Continuity is a key to lasting success

This is just a sample of the powerful (and sometimes unsettling) concepts offered by the author to the open-minded reader. I intend to explore some of them into more details in the coming weeks.

The material is a bit “dry” at times but I nevertheless really enjoyed reading it, not in small part because I could see the lineage between these ideas and some of the concepts behind the Agile software development methodologies. I wholeheartedly recommend it to anyone interested in Quality, Productivity and Process Improvement.