Saturday, December 20, 2008
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?
Wednesday, October 8, 2008
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.
Saturday, September 13, 2008
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.
A breakout of the volume of spam by day shows a curious pattern between September 9th and September 12th.
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.
Friday, September 5, 2008
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?
Thursday, July 31, 2008
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)
- Learn everything you can (nuff said)
- Never fight over tables with other waiting staff. (dont fight over territories)
- Learn the menu as soon as possible (know what you are selling)
- 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.
- Develop a file system for your regular customers (learn the organization)
- 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)
- 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, …
- Always be clear about your order.
- Be tactful about questioning customers.
◦If you feel you must question why a customer is making a special request, be tactful
- Remove the plates, glasses, and other used items from the table as they are finished. (follow-up on support and other commitments)
- 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....)
- Be polite in the face of irritable, difficult and unfriendly customers
- Don't let a bad tip ruin your shift. (don't let one deal break your stride)
- Happy service is infectious - Happy service is infectious
- Check back often with your tables. You'll always have that table who always seems to need something extra. (stay in touch)
- Leave drama, bad moods and personal issues at the door.
- Never sit around. If you have nothing to do, clean! (cold call, research, etc.)
- 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
Saturday, July 19, 2008
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 ;)
Is it possible to unlearn - or forget - that the box ever existed?
Friday, June 27, 2008
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…
Saturday, June 7, 2008
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.
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.
- ► 2012 (14)
- ► 2011 (10)
- ► July (3)
- ► June (3)