I will be presenting at the MIT SPAM Conference 2009

Well, this is not really a posting about how applications are like people - its just an FYI that I will be presenting at The MIT Spam Conference 2009 being held at (surprise) MIT. It is a two day conference on March 26-27, 2009.

You can register (sponsor and MIT funded - no charge) by emailing the chair, Kathy Liszka Professor, Computer Science University of Akron, at mailto:liszka@uakron.edu?subject=SC2009

The agenda is reasonably technical and is as follows: (I hope to see you there!)

Thursday March 26, 2009
9:30 a.m. breakfast

10:00 a.m. chair opening
Kathy Liszka / Bill Yerazunis

10:15 a.m. keynote
Robert Bruen: ICANN Policy Enforcement

10:45 a.m. keynote
Garth Bruen: The Future of Anti-Spam: A Blueprint for New Internet Abuse Tools

11:15 a.m. paper
Adrian McElligott: Email Permission Keys

11:45 a.m. lunch

1:30 p.m. paper
Claudiu Musat: Spam Clustering Using Wave Oriented K Means

2:00 p.m. paper
Sebastian Holst: Account-free” Email Services to Combat Phishing, Brand Infringement, and Other Online Threats

2:45 p.m. paper
Nathan Friess: A Kosher Source of Ham

3:15 p.m. paper
Didier Colin: A Selective Learning Model For Spam Filtering

3:45 p.m. presentation
Rudi Vansnick: Is Spam in Europe easier to handle ?

6:00 p.m. reception
Courtesy of ComCast

Friday March 27, 2009
9:00 a.m. breakfast

9:30 a.m. paper
Tim Martin: Phishing for Answers: Exploring the Factors that Influence a Participant's Ability to Correctly Identify Email

10:00 a.m. paper
Reza Rajabiun: IPv6 and Spam

10:45 a.m. workshop
Adrian McElligott: How to integrate Email Permission Keys in to an existing Spam Filter in 5 easy steps

11:15 a.m. paper
Henry Stern: The Rise and Fall of Reactor Mailer

11:45 a.m. lunch

1:00 p.m. presentation
Andra Miloiu Costina: Do humans beat computers at pattern recognition?

1:30 p.m. paper
Cesar Fernandes: An Economic Approach to Reduce Commercial Spam

2:15 p.m. paper
Alexandru Catalin: Phishing 101

2:45 p.m. paper
Areej Al-Bataineh: Detection and Prevention Methods of Botnet-generated Spam

How many bones are in your software?

How many bones are in the human body? Well, it turns out that it depends. You see, there are 206 bones in adults and up to 350 for infants. During the very early years, the architected for rapid growth and flexibility. As a child matures, some of the bones fuse together (like the skull and hip) to provide protection and stability required for the long haul – and the overall bone count drops to the 206 bones that most adults have.

Software solutions are not all that different. Early days, when a particular architecture or solution is first seeing the light of day – communication, authentication, workflow, information management, etc. have to be configured, optimized, and integrated to reconcile system capabilities with environmental constraints and operational requirements. As the solution stack matures, many of the underlying components, for all practical purposes, fuse.

When considering a prospective solution/architecture – make sure it has the flexibility to account for the rapid change that you know has to come as solutions are rolled out AND the adaptability to harden itself to optimize for stability and security – too many moving parts (which may be perfect as requirements are identified) will become a liability as protection and stability become overriding requirements for “the long haul."

Best of breed always looks most attractive “on paper” and perhaps even in early phases of deployment. Over time, there is a lot to be said for tightly integrated ecosystems that come “pre-certified” for interoperability.

Does that mean that we can look for “terrible two’s” and “adolescent rebellion” analogs in application development lifecycle management?

You bet.

It nice to be head of the curve (i suppose)

I just noticed the following article in PC Magazine on candidates and spam…. entitled Palin Wins 'Spam Debate,' As Does Obama published on 10.03.08. In this article, they marvel at the fact that Palin got 5 to 6 times the spam as Biden.

Well, for those that read my previous posting on SEPTEMBER 13 - they would have learned the same thing (and a bit more about the likely origins of some of that spam.)

Here is another article - Be Especially Alert For Bank Phishing Attacks also in PC MAG that talks about increased phishing attacks on banks - now this information i do not publish as openly, but i will repost my comment on this article... I wrote

"We can track email traffic on a variety of financial institutions - we have seen 5 specific attacks on the banks listed here in the past 3 days - these generated many 100's of thousands of emails being sent from over 100 diferent IP addresses based in over 35 countries - again, all of this traffic stemmed from only 5 coordinated attacks."

Its nice to be ahead of the curve I suppose... but only if someone is listening.

Presidential SPAMPAIGN 2008

Presidential Spampaign 2008

It turns out that the volume and character of spam can offer a kind of twisted view into the zeitgeist of this election season.

Using the qi-fense phishing-net service that combs through over 17 million emails every day, I took a look at the spam traffic for the week of September 6th.

That week was notable for a number of reasons. First, both presidential candidates hit the road with their newly anointed VP nominees. Second, both parties paused and then re-ignited their campaigns as part of their observance of 911. What can peering into the SPAMiverse tell us about all of this?

Is Biden irrelevant?

Of the roughly 40 thousand pieces of spam that referenced one or more of the nominees during the week of September 6th, only 4% of the traffic referenced Biden in any way. Whether the email was genuinely political in nature, positive or negative, or simply tried to hijack their name recognition to push a casino or a knock-off watch, 96% of the spam made no mention of Biden (as compared to Palin who was mentioned 5 times more often!).

McCain and Palin get equal billing?

McCain barely gets more attention than his running mate, Palin. Palin got over 10 thousand spams that userped her name - McCain just broke 11 thousand.

Obama is no celebrity

While Obama gets the lion’s share of spammers’ attention, the combined republican ticket gets 43% more references than their democratic rivals Obama and Biden compbined.

Political Campaigns dominate political spam

While there are plenty of sleazy spammers trying to capitalize on the election season, there is one trend that is hard to ascribe to typical spammers pushing casinos and mail order prescriptions – let's call it the 911 pause.

The 911 pause

A breakout of the volume of spam by day shows a curious pattern between September 9th and September 12th.

On September 11th, spam email for each of the candidates plummeted by between 36% and as much as 57% (for Palin). This is unlikely to be a coincidence, because the email blasts rebounded on the 12th again with spammer references more than making up for the one day pause.

It may be notable that McCain has somehow won an extended grace period – his spam volume only climbed 9% after the 11th versus Palin who spiked by over 100% on Sept 12.

So when the political parties claim to be completely removed from the email smears that clutter your email – don’t believe it. McCain and Obama gave a cease and desist order for 911 and their campaigns listened – even those elements that they deny as their own.

The soul of a new application

Are some applications inherently good or evil - can that really be in their DNA?

Can exposure to toxins during an application's gestation cause defects? Are QA teams like pediatricians?

What about an application's environment? Can a good application go bad?

If so, can applications be rehabilitated or must they simply be quarantined or euthanized?

Can the company an application keeps be a good (or bad) influence on its behavior? Its 10PM - do you know where your application is?

What about diet? Do you know the appetite (for data) required to keep your application at its prime? What happens if your application eats too much – can an application get fat on content? Does it have a coronary or just get slow and lazy? Do your applications have built in restraint or are they fundamentally gluttonous?

What about corrective surgery? Are you against adding limbs post-partum (instrumentation)? Perhaps if it is for health reasons and not just for aesthetics? Are UI facelifts superficial – or do we treat pretty applications nicer than the ugly ones? If so, what’s wrong with a little nip and tuck as an application gets along in years? Would we tolerate the eccentricities of the iPhone if it looked like a motorola razor?

Enterprise Sales and 18 ways to be a better waiter

I recently led some sales training for our team and stumbled across these tips on how to be a better waiter on wikihow.com - it fit so perfectly into how to be a great enterprise software sales person - i used the analogy throughout the day -

... (the italicized text are my little comments when i think one was necessary)

1. Learn everything you can (nuff said)
2. Never fight over tables with other waiting staff. (dont fight over territories)
3. Learn the menu as soon as possible (know what you are selling)
4. Learn your regular customers' names as soon as you can.
   ◦People love having a regular place to go to, where you know what they like to eat and you call them by name.
5. Develop a file system for your regular customers (learn the organization)
6. Do one thing at a time.
   ◦Don't count on finishing writing the order down as you walk to the order counter. Do it now! (stay organized)
7. Break down the "wall" between you and your customer.
   ◦Depending on the situation, sit down at the table to take an order, squat down to take a child's order, shake hands, …
8. Always be clear about your order.
9. Be tactful about questioning customers.
   ◦If you feel you must question why a customer is making a special request, be tactful
10. Remove the plates, glasses, and other used items from the table as they are finished. (follow-up on support and other commitments)
11. Don't just assume when the diner is finished and wants the check. Ask if there is anything more you can get for them (When the checkbook is open....)
12. Be polite in the face of irritable, difficult and unfriendly customers
13. Don't let a bad tip ruin your shift. (don't let one deal break your stride)
14. Happy service is infectious - Happy service is infectious
15. Check back often with your tables. You'll always have that table who always seems to need something extra. (stay in touch)
16. Leave drama, bad moods and personal issues at the door.
17. Never sit around. If you have nothing to do, clean! (cold call, research, etc.)
18. Be honest about the food/kitchen practices when asked by the customer. Serious consequences can result from mis-information. Allergies and intolerance to food products or practices could result in death. (overselling will kill a relationship)

So - a great waiter… (like a great enterprise salesperson)

◦Fits the menu to the diner - and not the other way around

◦Highlights appetizing and healthful options and ingredients

◦Offers irresistible side dishes

◦Is mindful of inventory and high margin options

◦Is attentive and inquisitive without being intrusive

◦Identifies who is paying early in the meal, communicates payment options and delivers the bill

◦Does not need to know how to cook!

◦Is rewarded with a gratuity that is proportionate to the bill and their level of service

The best defense is a good e-fense

I'm advising on a new venture, qi-fense, an anti-phishing and reputation management service that filters a huge volume of real-time emails to provide early warning on phishing, reputation attacks, competitive tactics, etc. Check it out at http://www.qi-fense.com/.

I think it is very cool because of its low cost, low friction and potentially high value proposition - if you're interested in learning more (or have ideas) - LET ME KNOW (remember - ideas only have to be good - not original ;)

Thinking outside the box is no different than thinking inside

Truly different approaches to problem solving erase the box - afterall, depending on on the size of your box (and the size of your universe - string theorists can relate) thinking outside the box might actually offer fewer options than the alternative.

Is it possible to unlearn - or forget - that the box ever existed?

The many faces of software

Popular wisdom tells us that the more words a culture has for something, the more important that "thing" is to that culture. Whether its ice for the Inuit, rice for the Chinese or money to Americans - there are cross cultural examples to be found everywhere. Yet, I have always held a corollary to be that the more meanings a culture has for a single word - the poorer that culture understands the word - essentially rendering it meaningless in the most extreme examples. In fact, I wrote a collection of short stories where the title of each was derived from one of the many definitions for the word "natural" - but that is another matter all together.

What strikes me is that software is an example of both cultural importance and limited understanding. We have applications, components, widgets, binaries, executables, plug-ins... well - the list could go on for much longer and - candidly - is not at all surprising to discover that software has become an important element of our culture. What is, I think, telling, is the many meanings (and disagreements) on the definition of software. It is the disconnect and dissonance between people, organizations and processes that lead to financial, functional and operational software failure.

Software as currency – if you take a $10 bill and rip it in half – you don’t have two 5’s – you now have paper. There is an atomicity (or unit) to currency and a consensus on how it is valued – these are the essential characteristics of a currency – and the medium is truly irrelevant. Are applications simply executables? How do support, documentation and activation rights fit into the “currency of applications?” Software services, on demand application manifestation and content that encodes behavior further challenge even the basic notion of what are the ingredients of an application.

Software as a commodity – prospectors find gold and stake their claim – an assayer will assess its worth and a separate array of businesses will refine, package and ultimately monetize the gold (coins, leaf, jewelry, bullion, etc.). Well – this I think fits pretty neatly into the true life cycle of software – developers know where the interesting bits are that they develop within larger bodies of code and they know what needs protecting. The actual value of that work is typically best established by product management, line of business, etc. and the monetization is accomplished through sales and marketing - protect – analyze – monetize.

Software as an asset – tracking software is always been tough and it is getting tougher – but truly measuring the financial impact of software on a business (not based upon what was paid for the software – but on the change in value of the business that adopts said software) is so murky as to be meaningless on any general scale.

Imagine how much more efficient the software business might be if we could get all of the stakeholders in the development, consumption and adoption of software to agree on these three dimensions of software – we would move from the bartering economy of pre-history to a truly modern (and efficient) software economy…

Attention – this is not a metaphor or an analogy - application development and IT operations are really ecosystems

Central to the ecosystem concept is an idea that living organisms are continually engaged in a set of relationships with every other element in their environment. Any situation where there is relationship between organisms and their environment can be legitimately described as an ecosystem.

A system as small as an office or as geographically disbursed as a collection of digitally connected workspaces can be described and studied as human ecosystems. Now, ecosystems are often treated as lucrative sources of goods and services. Forest ecosystems produce wood and maritime ecosystems produce fish and application development ecosystems produce software.

Among the most interesting and active regions within any ecosystem are its edges – between the sea and seashore and between a development ecosystem and the IT operations ecosystems that it abuts. The points on land that define a coastline constantly shift with the tides and currents as do the points of work where end-users and applications meet.

I think there is genuine insight to be mined as we try to navigate the constantly changing social, technological, regulatory, economic and organizational impact of applications across the biosphere. Ecosystem classifications, functionality and biodiversity topics, the edge effect in ecosystems, studies on invasive species and traits of invaded ecosystems, … all have striking – and I think useful – parallels worth exploring to better manage the health and vitality of the application-dependent ecosystems that we all inhabit.

...and perhaps i will have the patience to jot some of these down here in the coming months...

I have been studying the point-of-work in this light for a few years now - and it clearly holds a true duality of purpose and form (like a wave and particle - but that is another post). Does the point-of-work hold the key to transforming (and aligning) the application supplier and consumer ecosystems? Therein lies the mystery - and only mother nature knows for sure.

Technology is Never replaced - Technology is Always displaced

in the early 80's IBM announced the arrival of the paperless office
in the early 90's databases were going to replace file systems
in the late 90's the clicks were replacing bricks
and today "clouds" are replacing installed applications

Well, electronic documents were transformational - but my office is still filled with paper
Databases are everywhere - but so are files
Lets not even talk about clicks and bricks
...and for the current cloud evangelists - well - look up a little quote from George Santayana...

Of course each of these developments were transformational - but new technology - like new culture - like the next layer of geological sediment - will always be additive.

An Application Security Haiku

Footprints' reflection
Opportunities' shadow
Application Risk

Applications are people too - more examples

I am on the plane on my way to RSA Europe in London and my skill of being able to sleep on any flight seems to have abandoned me. I’ve finished my airplane book (Hundred-Dollar Baby by Robert B Parker) and I can’t bear to watch the animated movie about surfing penguins in Hawaii – and so I have pulled the laptop down from the overhead to log some more musings on why applications are people too.

Applications are people too because…

Process, Technology and Value are to applications as Mind, Body and Spirit are to people. The ultimate goal is to achieve and sustain a perfect balance.

For wellness (process/technology or mind/body), the same mix of preventative, detective, monitoring and treatment strategies must be applied. Finding your way (spiritual/value) requires a view that is bigger than oneself.

It takes village to raise us properly. While it only takes a programmer and a machine to produce an application (like two parents…) – without context, guidance and support from the broader community (product mgmt, sales, etc) – what chance does an application have?

Our strongest characteristics are not inherently strengths or weaknesses – it is the environment or context that makes them so. An outgoing social personality can be someone’s greatest strength or their undoing depending on whether they are in sales or working for the NSA. An application that grabs all available memory to speed its processing is wonderful for a video editor and will create havoc for your background search indexer.

…and with security on my mind for this week’s conference…There are no good guys or bad guys – only supervised and unsupervised (this is an exact quote from a FBI agent that I still recall from a meeting in 1984 when I worked for IBM in their internal security group). The point here is that when you are thinking about security – do not have a double standard – one for the bad guys and one for the good guys – have a consistent approach that includes monitoring, verification and auditing.

Each of these examples just scratch the surface of course – it's the drilling down into these parallels that I think can provide some interesting heuristics that can help make the most of application investments and/or dependencies…

…gotta go, my lasagna bolognaise is coming down the aisle – yum – love that airline food!

Here's a quick example - the Peter Principle

The Peter Principle

Many of you will be familiar with The Peter Principle. The Peter Principle reads:

"In a hierarchy every employee tends to rise to his (or her) level of incompetence."

Software companies package, promote and sell their products in the same way they promote their employees - to their level of incompetence! This is, by no small coincidence, the direct result of becoming too wedded to product lines.

My Corollary

In enterprise software markets, every vendor tends to market and license its existing products to their level of incompetence.

Of course, product incompetence manifests itself differently than the human kind. It starts out with reduced customer satisfaction, longer sales cycles, increased cost of sale, slimmer margins, and ultimately acquisition or liquidation of the company (which is ultimately the same ending as with the original Peter Principle).

The Peter Principle has many of its own corollaries, all of which have analogs in the enterprise software world.

Case One:

Peter Principle: According to Dr. Peter Drucker, work is accomplished by those employees who have not reached their level of incompetence. Thus organizations are able to function even as the Peter Principle causes some employees to accept one too many promotions.

Sebastian's Corollary: New revenue is generated primarily by lookalike customers, new products and/or custom code work arounds rather than the expansion of existing products into new markets. This does not prevent corporations from pushing outwards from core successes into new markets. In fact, Geoffrey A. Moore calls this the "Bowling Pin" strategy and it is an essential step in "Crossing the Chasm." In other words, from a hi tech marketing perspective, it is an imperative to carefully push a product to increasingly broad applications.

Case Two:

Peter Principle: Employees, as Dr. Drucker points out, do not want to be incompetent, but when management offers promotions that put the employees into their level of incompetence, the employees have no way of knowing that ahead of time. After all, if the offer is made it is because management knows the employee can do the job competently.

My Corollary: In today's economy, with the IT market flat and the expectations set back in the late 90's long since abandoned, the few successful product lines (and the product managers that shepherd them) are under increasing pressure to milk the cash cow to the very last drop. They can rationalize this because they have no way of knowing for sure that the technology has reached its level of incompetence. For example, I would argue that this is how document management became web content management became content management became enterprise content management!

Case Three:

Peter Principle: If struggling with incompetence is a way of learning, then from an organizational or a personal standpoint, it's just a matter of equilibrium between learning and performing. Struggling with outright debilitating incompetence is not the best environment for learning. Getting just the right degree out of a comfort zone to promote growth while avoiding incompetence is the ideal.

My Corollary: Applying existing technology into new solutions should create the same kind of tension and calls for the same kind of equilibrium. The tension is between the marketing imperative to drive toward the bowling pin strategy (or some other management construct - can you say "hedgehog"?) and the suitability of a given product for a new or revised application.

How can you tell if you have pushed a product too far? There are lots of signs, but two yardsticks that have worked for me in the past sound something like this...

You know your application has been promoted beyond its competence when...

1. The amount of professional services required to install and configure the application is growing rather than shrinking
2. The performance profile of your application is degrading rather than improving
3. The ratio between the time between releases is increasing while the number of new features is decreasing

This approach can be extended to application consumers as well - just like you would want to see resumes for consultants assigned to a mission critical project - I would recommend the following be included in an application selection process (in addition to basic functional requirements of course):

1. Assure yourself that the application supplier's direction is aligned with, but not irrationally wed to, the application being proposed
2. Recall the Peter Principle for applications - success is not necessarily transitive. Check references like you would a prospective employee - don't just ask about their satisfaction - verify skills and organizational fit.

I have to confess that in my rush to get at least one post out - i borrowed heavily from an earlier column I had authored for The Gilbane Report way back in 2002. The material here is fundimentally different, but if I had not been the original author - this would have qualified as plagerism.

I have not contributed to the site for sometime - but it is an awesome site - check it out at http://www.gilbane.com/. My old columns can be found at http://gilbane.com/columns.pl.

Hello world

I spend a lot of time thinking about software – and luckily it’s actually something I like to do. What’s being built out there? Who needs what? Why is this “the next big thing”? What is wrong with these people? …and, I spend a lot of time trying build stuff that has genuine value – which I can loosely define as stuff that changes behavior for the better (people, organizations, whatever). But just how do you move from the aha! moment in the shower to changing the way people work and live?

When most people think genius, they think Einstein. Not to take anything away from The Great One, but I like to fall back on a second class of genius - one inspired, not by Einstein, but by the spirit of Marco Polo. Imagine his wonderment when he first came face to face with Chinese culture -15,000 years of religion, philosophy, science, medicine, fashion, cuisine, etc. Most would have been overwhelmed, but not my imaginary Polo - I envision him thinking, "hmmm, paper money - my friends in Venice could do something with this" or "gee, gunpowder - not just for fireworks." Polo did not invent paper money, understand the principles behind gunpowder, or even appreciate the value that the Chinese placed on them - Polo cherry picked specific artifacts and dramatically increase their value by transferring them across cultures and I would argue that the ability to pluck concepts out of their original context and into new contexts to generate new insights and improved value propositions is truly a special kind of genius. I would also argue that this second class of genius is woefully absent in the commercial software industry.

If this last paragraph was too obtuse – let me summarize it all with a mantra I take with me everywhere – to be effective, your ideas don’t have to be original – they only have to be good.

But what makes an idea “good”? Where is the most fertile ground to harvest these ideas? Without going in to why (at least right now) – my premise is that virtually all interesting and game changing insight ultimately stems from the study of people – how do we interact? how to best manage us in the workplace? how to measure and increase our quality of life? how to teach us to be more self-reliant? etc.

I am not yet entirely comfortable with the blogging format (I am afraid that I will make this read like a column or something) – but for now – I just want to put it out there that if we think of applications as "being people too" – Application Resources instead of Human Resources – we won’t have to be an Einstein to improve both an application's quality of life or longevity – and this will ultimately drive the right kind of adoption of much much “better stuff.”