Cloud Computing: Be agile and productive when scaling

Check out this video from RightScale by Michael Crandell, CEO and Founder of RightScale. You will learn about Cloud Computing on the cost and schedule fronts. These guys do get it right and I am definitely recommending them. Hey, he also talks about use cases for the Cloud!

Presenting solutions supporting business needs to business

This is also available as a PDF on philippeback.eu There are lots of quick wins that are achievable by using today’s freely available technology. For example, there are FOSS (Free Open Source Software) technological solutions that can bring a lot of value to businesses at very low operational costs. In today’s so-called « crisis », moving away from CAPEX (Captial Expenses) to OPEX (Operational Expenses) is a good thing. No more upfront large investment, just seize the opportunity and keep the solution enabling its capture alive as long as needed. But there is a challenge when it comes to convey the benefits of such solutions to the business people. Case in point, there is are very nice CMSes (Content Management Systems), Blog Engines, CRM (Customer Relationship Management) Systems, DMS (Document Management Systems) but it may appear like it takes forever for an organization to consider, let’s not even talk about implementing them.

So you tought you were heard…

I was talking the other day with a senior Sales Executive for a major integrator firm just back from a technical conference. He told me that the presenter got a lot of applause for his performance. When I asked about what people understood from the message, he told me that people had no clue of what it was really about. The crowd was just pleased to listen to the presenter (a big name in the industry). Maybe nobody wanted to look like a fool and faked understanding. Obviously, sales are not really going to occur from there.

So, talking « tech » to business people is not going to cut it. How then can we convey the fact that the solution is indeed matching business needs? As people may nod giving a false sense of understanding, we need to attack the issue from another angle. Let’s put ourselves in the shoes of the business person. The business person is going to think in terms of business outcomes. He is not interested in systems per se. These systems are going to be enablers or roadblocks towards achieving these outcomes. So we must focus on how business needs are met. Answers must be provided to the following questions : Why? So what? What’s in it for me? How is the business better off? What’s the ROI to be expected? Is there a roadmap to get there? What about getting people excited about this? Can you show it to me? Where is the picture drawn at 30,000 feet? Unless the features of the solutions are mappable to answers to these questions, there is no hope in getting buy-in. So, key advice:
  1. establish a list of key business targets that are being part of the identified business opportunity
  2. articulate the key advantages of the solution in business terms
  3. articulate answers to « What’s in for me as a <BusinessUserType> ? »
  4. draw a roadmap of the key elements of the actions targetting the opportunity along with milestones aligned on quarters
  5. articulate how the solution acts as an accelerator for achieving the outcome
  6. explain how the needs are met by the solution
  7. have a revenue model that shows how benefits are accrued over time
  8. explain how people will be brought onboard when it comes to using the solution!
Having these elements in place will definitely improve the positioning of the solution provider as a partner with business acumen worth talking to. © 2009 by Ir Philippe Back, All Rights Reserved

The UI/CI/CC/UC Path

All of these acronyms stand for the

"Unconscious Incompetence > Conscious Incompetence > Conscious  Competence > Unconscious Competence"

path. All this started with a discussion on a mailing list about Agile Modeling some time ago. People like most of the ones I read from on that list are at the Unconscious Competence level and are exploring the limits. Hence they tend to be "pragmatic"... (e.g. Scott is telling us to be agile and piles every possible diagram, writes a long thing about O/R mapping, can use ERWin for DB refactoring etc). So, a supersmart, well rounded, efficient approach is fine for those who have already achieved Unconscious Competence. But for those people that still need to make the transition between Conscious Incompetence and Conscious Competence, clear definitions and separations of concerns are needed to aid them in making through this step. Yes, but... how to be pragmatic if you are unsure about the underlying foundation ? What about understanding the subject matter to a sufficient extent so that you can make educated decisions and then bend whatever rule you want because it's the pragmatic thing to do ? Maybe this is what most agile practicioners do... As for the quote, it's not a quote as such, it's related to the NLP (for Neuro Linguistic Progamming) ideas that my wife practices (and me too by the way). There is also a relationship with creativity workshops I followed in the past. My wife is working on how to apply stragies that work, how to model behavior. Her scope is on how to teach kids about strategies that work. She's pretty good at that. So, when we model successful people, we find that they have strategies that work and if we apply them, it will work for us too (usually it boils down to working consistently in a smart way and having a good network, along with ongoing marketing, but it helps having some clues on the details 😉 ). In that respect, when we learn something, there are *always* those 4 stages present. This is also linked to what I call the valley of dispair:
The Dip or "Valley of Despair"

The Dip or "Valley of Despair"

When someone moves to the conscious incompetence level, a whole new field of knowledge opens and it is usually pretty frightening. The time it will take to master the field is unknown and this generates great stress. This challenges the homeostatis of the being. So, there is a tendency to step back and stay off the new field (easier to avoid pain than to work towards gaining pleasure). Add to this the external environment where people who are still at the unconscious incompetence level always try to drag that someone back to them... Furthemore, learning the new skill takes energy and is usually less effective than doing things the way they always have been done in the organization (at that moment, the individual is experiencing the dispair, doubt about the new way is experienced etc). No wonder that it's difficult to decide to learn for good despite those calls. From there, several strategies are available : 1) keep on pushing like mad ("I'll do it, I'll do it, ... whatever it takes) This usually leads the individual to burn out and shoot the messenger kind of reaction towards the person. The person cannot stand staying on a plateau level for too long and call quits. 2) jump to another topic constantly This way, the conscious competence level may sometimes be reached by luck but usually leading to a dillettante style. Knows a bit about everything, brags, talks all the time etc. No quantum leap in personal performance. 3) decide to be intrinsically motivated and walk the talk on real problems, enhancing the practice believing that the time will come without becoming a bigot of the practice. Conscious competence builds up and at one moment, the person realizes that a jump to inconscious competence happened. (Without noticing, usually opening new perspectives). As an additional tought, when knowledge increases, it's like the radius of a circle. And the unknowns increases like 2 * PI * R ... The more one knows, the more unknowns there are. But, the person becomes much more sensitive on a lot of subjects. As a sample case, look at the career of Peter Coad where he started on design [handbook], moved to more conceptual things [archetypes], worked with a vision [together], and then know works as a strategist  (environment=design, beliefs=vision, transcending|identity=strategy). [He's one of my role models on the software envisioning front (well, as is Ivar Jacobson , as is Jim Rumbaugh whose OMT is the first method I used to move away from messy arrows and boxes, and Grady Booch with the "Managing the OO project" book).] I guess that this is a natural path to what some call "enlightment". Maybe can we reach some kind of it through software engineering or "architecture" of systems (like 4+1, form & function as I do see in some talks). One of the rules of NLP is that the mind and body are a cybernetic  system (which is also function and form). In my courses, I find myself more and more talking about beliefs and what would be the business case for UML (benefits vs costs). This makes very interesting talks. This may be a consequence of the unconscious competence mode... starting bending the rules and asking questions, pushing the boundaries, understanding the trade offs and beliefs that were in the minds of the creators.

Fun with requirements from Borland

They may have quite bad tools but they can make a fun video about requirements engineering. Also cool: Let's get ROFL:

On API Design from Google

I always have had a great interest in how to design a proper API. This is not only code-related. The issues at hand are really linked to how to express things clearly, concisely, and with purpose. At Google (and Microsoft for that matter), there is really a great amount of insights available. Check this video on API design: Google Video has the most insane amount of videos on these subjects. And still, I see a ton of crappy designs that seem to follow no rule at all, as they would have been designed by monkeys typing random characters (by that, meaning, no modularity nor responsibiliy concept showing up, tearing objects apart just to reassemble them after). Thanks God, there are places where people know the craft. Also, if you want more Josh Bloch (this guy is a true genius on Java), check out this (ok, this is getting hardcore):

New PHP Podcast: DPC Radio

I am using quite a wealth of PHP applications and do some development with the language too. If you are like me, please check DPC Radio. The feed is at: http://feeds.feedburner.com/dpcradio and the first episode lives here .