SES becomes eTechSuccess

When I restarted Software Engineering Strategies last year I had planned to incorporate as an LLC at the beginning of 2009. I submitted all my paperwork and then was told by the North Carolina Secretary of State that the word “engineering” is reserved for those companies licensed by the North Carolina Board of Examiners for Engineers and Surveyors. They in turn required the company to have 2/3 ownership by certified professional engineers.  My options were to request a letter of non-objection to using the E word, to become certified and then licensed, or to change the identity of my company. I chose the latter. So what to name my new and improved company?… I had not been 100% satisfied with the SES name because I was doing a lot more then offering strategies on software engineering. So I went back to my web site and read the opening sentence “My passion has been the application of emerging technologies to successfully solve real world business problems.”  The first rename was to call it Emerging Technology Services but while the LLC was not in use in NC the domain names were hard to come by. Finding a good domain name these days is a struggle. So the next variation was Emerging Technology Success because I thought a key experience I had was the successful application of an emerging technology. The statistics I quoted on my website are “Over a period of nine years while I was the practice executive we had approximately 2000 engagements with customers. These could range from small two day workshops up to multi-year development projects. Of these 2000 engagements approximately 100 were considered "Troubled". This meant that the project had slipped and the contract profitability was at risk and/or customer satisfaction was bad. Of these 100 Troubled projects all were eventually resolved. We never had a contract canceled due to our failure to perform. “ So a key idea was taking an inherently risky technology and being able to successfully deliver an application that provided business value. So Emerging Technology Success it was. But the words just did not trip off the tongue and I imagined people trying to type  jbaker@emergingtechnologysuccess.com   so I contracted it to eTechSuccess and it sounds pretty cool. I also added the little wave logo to the business card and website to symbolize waves of technology. It reminded me of the times when I was a young boy on vacation in Florida. We stayed on the Atlantic side and I really liked playing in the surf. But when the surf was high it felt like the waves would keep crashing on me and I would barely recover from one when the next would try to topple me over. Eventually I learned a strategy for coping with the surf just like over many years of working with emerging technologies I have learned how to successfully ride a new wave of technology.

Failure to Launch

When I attended the Cloud Camp last November I had run a session called "Failure to Launch" which was members of the audience talking about their early experiences with Cloud Computing. I was looking for some lessons learned and possibly some unique risk factors associated with Cloud Computing. What I heard was that projects in the cloud are influenced by factors common to most other emerging technology projects. The best example was given by Uri Budnik of RightScale. He had to keep the customer anonymous but did share the following:

Name of Project - Planned Major News Event for major news media 

Project Dates - Project began three weeks before hard news deadline

Technologies used - AWS EC2, RightScale, HAProxy, DNS round robin, Mongrel, My

What happend? - The system was unacceptably slow in early versions and could not be improved. Some of the content would not load. The customer introduced a last minute architectural change the morning of the event that required rollback in order to launch. 

Lessons Learned - Need more through testing.

I heard some similar profiles from other participants about classic software engineering problems...  scope creep, lack of testing, lack of communication with stakeholders, unrealistic schedule expectations.

In the Clouds

Last week I attended the Federal Cloud Camp in Chantilly VA. This event had over 150 people attending. It is an un-conference with people from the audience able to propose a topic for discussion. Over the five hour conference there were 5-6 five minute lightning presentations from the sponsors and then three time slots with four rooms being used = 12 presentations from the participants. Yours truly lead a session on "Failure to Launch - lessons learned from early experiences in Cloud Computing". I will post a seperate blog on that in a few days. In addition to running my session, I attended a session on Hadoop / map reduce and one on applications for the cloud.

I heard some discussion over exactly what Cloud Computing is, comparing and contrasting with SaaS, Utility computing, Grid computing, and Autonomic computing. I believe most agree that Cloud Computing has aspects of all these plus the characteristic of server transparency to the application and user.

The Hadoop session had some users who were experimenting with the technology. For example, one individual from DOD had taken 23 Playstation3 and was running map/reduce between the systems and also on each of the cell co-processors. 

During the Cloud applications session there was a lot of discussion about how to improve applications. One speaker thought having stateless applications improved portability wihile another thought that middleware could manage state transparently to the application.

My general observation is that Cloud Computing is still embryonic with a need for standards developed to allow application transparency accross Clouds provisioned by different vendors.

The Pampered Pooch

Last night I joined a crowd of 18 at the Agile RTP group, which was not a bad turnout considering it was election night. We were there to participate in a "59 Minute SCRUM" facilitated by Bob Galen of RGalen Consulting Group. After a 20 minute levelset on what SCRUM is, we divided into three teams of six and elected a Product Owner and Scrum Master. The goal of the iteration release was to deliver a compelling brouchure of high quality for a Doggy Spa called the Pampered Pooch. We had a existing product backlog of approximately 20 user stories. The timeline of our iteration was as follows:

Iteration Planning - 10 Minutes
Sprint Day 1 - 10 Minutes
Daily SCRUM Meeting - 5 Minutes
Sprint Day 2 - 10 Minutes
Sprint Review - 14 Minutes
Debrief - 10 Minutes

Our team of six members had someone with a laptop and wireless access to the printer where we were meeting. While other teams were hand lettering, cutting, and pasting. We were able to produce a polished look feel. Unfortunately, the mechanics of going from several copies of rough draft to one editor caused us to log jam and not have all the content delivered on time.

So besides the fickle nature of modern technology what lessons did I learn about Agile?
1. Achieving the right tempo of working seperately and then coming together to coordinate is critical. On a real world 2-3 week sprint the daily standup may be the right tempo but I would not preclude adhoc meetings for bringing people together for a focused purpose.
2. Having a flexible Product Owner willing to change direction based on what is being discovered is very nice to have.
3. When the team gels and works well the feeling of accomplishment is terrific and exhausting.

All in all, an enjoyable evening at aRTP.

Innovation

I have been working with a client that is improving an existing innovation program. Based on my prior work at IBM (where innovation has been a mantra for several years) and in my work on the Web2.0 phenomena I suggested that adding an external focus to the program would be a good thing. 

Examples are:

Procter & Gamble Connect+Develop

Kraft Foods Innovate with Kraft

IBM Innovation Jam

All of these have some differences but the common philosophy is that customers, suppliers, and business partners can contribute significantly to new ideas.

PLUS depending on how one manages the program the participants can feel they are "partnering" and helping to change the direction your company is taking.

Some of the challenges that must be addressed include:

Intellectual Property - P&G and Kraft encourage patent protection for the participant so that a straight forward licensing agreement can be negotiated. IBM keeps the ideas very general and uses the input more to set marketing focus.

Competitive Advantage - How much early development of products can be exposed without losing something to a competitor? Because P&G deals with specific ideas it prefers to keep the interactions 1 on 1. A participant can only see the problems P&G needs solutions for and only the ideas that he/she has submitted. IBM allows everyone to see ideas submitted but keeps the conversation at a high level.  I believe that an effective program should have tiered levels of participation. A general public forum and then an invitation only small group to take an idea further. The small group would be covered by a joint venture agreement.

Searching for Diamonds - A lot of ideas have to be evaluated in order to find the few that will be worthwhile developing into a product. Either a dedicated team of evaluators must be set up OR the community can vote for the best ideas. 

The trend is towards using the Internet to open the kimono and share innovation with a broad community.

The Perils of Prototyping

I just finished a first version of a presentation/paper on the trade offs between light weight methods and heavy methods. The light weight method is based on using an object oriented language, CRC card type discover process, and a large number of iterations between discover, build, validate. The heavy method is based on my experience with Clean room. I have not monitored enough Agile/Scrum/XP projects to capture the metrics specifically for those but it will likely fall fairly close to the OO experiences. In my Scrum Master training one of the jobs the Scrum Master performed was to insulate the smallish (4-7 developers) team from the customers. The Product Owner is the only regular contact the team has with the rest of the organization. As you can see in the paper (Go to my website and look in the papers section) my assertion is that prototypic development (and i will bet Agile as well) fails because of too many customers and developers participating in the release.

Business Inteligence

Tonight, I attended my local chapter of the Association of IT Professionals. This is a swell bunch of men and women who meet once a month to network and attend a dinner talk. This month's topic was Business Intelligence presented by Rick Styll from SAS. He is the product manager for the SAS BI portfolio. Rick covered a broad introduction to BI, the parts that struck me were the market convergence and some of his thoughts on what is coming over the horizon. As far as the convergence, he mentioned that Gartner had warned SAS a while back that there was going to be a consolidation in the market but that he had been surprised by how rapidly it had occurred. He stratified the players into four tiers:
Mega players - SAP, Oracle, Microsoft, IBM
Pure plays - SAS
Niche plays - Actuate



Some of the future trends.
Web2.0 - SAS is building a release that uses Ajax and they think a flash inerface is coming over the horizon for them.
Mobile BI - Rick says customers like the idea of a dashboard on thier Blackberry, but he does not see the use cases. In his experience, most people using SAS BI are operations types using desktops.
Visualization GUIs - new graphical formats and use of motion to present BI results.