September 11 Happened In This Decade

These past couple of years have been so oppressive on most of us that’s it’s hard to remember other significant events that happened just a few years ago. As we approach 2010 and we at Xpediant Solutions wish you all a Very Happy and Prosperous New Year, I thought it might be good to take a moment and review the momentous events of this past decade, some of which are emblazoned in our memories forever because they changed the very fabric of our country and others which fizzled out of the news after their 5 minutes of fame.

Do you remember Y2K? The ultimate scare that the country would come to a standstill as the century turned. Yes, that happened in this decade. Turns out nothing happened. Developers raked in millions of dollars in re-programming fees and all was well with the world. 2000 also brought us the presidential nominations of George Bush, Jr. and Al Gore of the Republican and Democratic parties respectively. Year 2000 was the year of hanging ballot chads that caused a vote recount in Florida declaring George Bush, Jr. as the new President.

2001 is the year etched in our memories forever. September 11 happened in 2001. We all remember where we were, what we were doing, and how we felt when two planes collided into the World Trade Center in New York City and killed nearly 3,000 people. America was changed forever. Planes became deadly weapons, travel changed forever, the backbone of the American economy broke down and has cascading effects till today. America attacked Afghanistan in 2001, the Patriot Act was signed, Apple released the iPod and Harry Potter became the most watched movie in the world.

In 2002 the country focused on security. Homeland Security unveiled colored terrorism alerts that we see posted at airports even today. The bombing of an American night club in Bali took place in this year. On a lighter note the American Idol program was released this year and we all became familiar with Simon’s insults and Paula’s gestures.

The highlight of 2003 was Secretary of State Colin Powell’s case against Iraq which urged the President to send troops to fight Saddam. The words “shock” and “awe” became part of our vocabulary as we sat and watched our soldiers obliterate Iraq. We lost and found Saddam Hussein in this year. 2003 also brought us the death of all astronauts aboard the space shuttle Columbia which disintegrated while re-entering the earth’s atmosphere. The SARS scare happened this year and face masks became a fashion statement. In this year Martha Stewart went to prison and her location was nicknamed Camp Cupcake and California elected Arnold Schwarzenegger as its Governor.

Anyone remember John Kerry and Howard Dean? Yes, they campaigned on the democratic ticket, then Kerry flip flopped and Democrats did not stand a chance. Bush, Jr. was re-elected President. 300 people died in a terrorist attack on a train in Madrid, former President Ronald Reagan died at age 93, the world was outraged at the atrocities encountered at the Abu Ghraib prison, ten more Eastern European countries joined the European Union and the Boston Red Sox swept the World Series against the St. Louis Cardinals.

Secretary of State Condoleeza Rice became the first black woman to hold this post in 2005. Pope John Paul II passed away in April this year, and Mahmoud Ahmadinejad was elected president in Iran beating popular Rafsanjani. Those of us in Houston can never forget that Katrina happened this year. Katrina not only impacted New Orleans, it also changed the demographics of Houston forever.

2006 saw the death of another former US President, Gerald Ford who died at 93. 2006 was the year of scandals. Dick Cheney shot hunting partner Harry Whittington, former representative Randy Cunningham went to prison for conspiracy and tax evasion, Representative Mark Foley resigned after sexually explicit emails and instant messages were found in his name, and pastor Ted Haggard admitted to having solicited a male prostitute for sex and drugs.

2007 was characterized by peace, war and dog fighting. Yes, dog fighting. This was the year quarterback Michael Vick was convicted of dog fighting and served 18 months in prison, this is also the year Al Gore and Rajendra Pachauri won the Nobel Peace Prize for their work on combating global warming. In 2007 Brittney Spears finally “lost it” and shaved her heard in front of Paparazzi. In this year Virgina Tech University lost 32 students to a single disturbed student who opened gun fire and Pakistan lost the last of the Bhutto family (Benazir Bhutto) to a bomb attack.

What can we say about 2008? This was the year the economy started to really tank. First Lehman Brothers went bankrupt, then AIG asked for a government bailout whose use came under investigation when lavish managements trips were uncovered on the books. 2008 saw worldwide political upheaval with Fidel Castro resigning in Havana, Cuba, Robert Mugabe of Zimbabwe being forced to share his victory with his rival when his victory was considered fraudulent, and former Bosnian Serb leader Radovan Karadzic was arrested on charges of genocide.

The now famous words “hunker down” did not apply only to our experience with Hurricane Rita but have become synonymous with how we have spent 2009. Most of us have hunkered down; accounted for the things we are thankful for and tightened our belts with the hope for a better year next year. 2009 brought us shock and awe when we heard of Ocatamom and her octuplets, the economy hit American auto makers hard and Detroit became a ghost town, Sarah Palin decided to resign as Governor of Alaska and bask in the media limelight with her “social” activities, balloon boy’s parents apologized for the publicity stunt they tried to pull by alleging their son had flown away in their hot air balloon, but maybe the best thing that has happened to date is that the Health Care Reform bill passed on Christmas Eve with a 60-39 vote. Whether or not this bill will change America’s health care system still remains to be seen.

This article has been excerpted from several videos by Newsweek magazine that highlighted events in this past decade from 2000-2009. If you would like a complete list of all events and author opinions please visit the site at www.newsweek.com

Corporate Communities

Major brands are still failing at online communities and social media. Sounds like an opportunity. Get the report...

Are Social Media tools the bane of content management's existence?

Social media, most call it a buzz word and it may be, but it is a different way of sharing information than before. Social media tools such as blogs, wikis, RSS feeds, photo sharing sites, entertainment platforms are used not only for communication but collaboration, multimedia sharing, sharing reviews and opinions, entertainment platforms, and integrating information. It's the new way people work.

If content management is the process of identifying, capturing, classifying and storing content so that it can be easily accessed by others and if social media is the new way of capturing and sharing information then Houston...we might have a problem.

Organizations now realize the impact of social media tools on information sharing within the organization. Major organizations have blogging staff, CEOs have personal blogs they populate regularly. It helps them disseminate information to their customers, potential customers, investors and media and it is a means for them to get feedback unfiltered and unsolicited. Many of these blogs have important information, information you can refer to later but how and where do you store it? Blogs are not the only tool companies are using to share information. Internally they are using wikis, collaboration sites, social networking sites, and even opinion sites to gauge what their customers are saying about them. With all these disparate applications in use, each sharing valuable content how should a company or should a company make an attempt at storing and sharing some of this information with others?

One viewpoint is to carefully analyze the kind of information being shared. Some information is perishable. It is valuable only to the two people sharing it at the time it is shared in. Gleaned and rewritten and stored out of context not only is that information useless but might also be dangerous if decisions are based on it without contextual knowledge. Recognize those kinds of information and let them be. Part of having a usable content management system is knowing what not to put in it. No doubt you might lose out on a couple of valuable nuggets that you could have stored, that someone could have captured and maybe even benefited from, but in the big scheme of things the payoff wouldn't be worth the effort.

For all other "harvestable" information, the most efficient way to capture the information is to assign someone to do it and that someone is NOT the author. Gather some base metrics of what it takes to harvest and formulate a piece of reusable content from the social media tools in use. Use those base metrics to figure out how many people you need or how many man hours you need to glean the information. Yes there is some process work in there too. Like the content has to be cleaned and formulated and in the end vetted by the author before it's posted on the company site for employee use but this process is far more simplistic than the one you would have to create to encourage the author to create the piece of content because their core competency is not writing, it's being an engineer or a chemist or an architect and encouraging them to write reusable content will take at least twice as long and they see no value to themselves in doing it. Yes, they will freely share the information with their peers but that's because they are learning as much from their peers as they are sharing but when you ask them to formulate a piece of content into a reusable artifact suddenly you might as well be talking Greek.

So it raises the argument whether organizations should have content management at all? For now, Yes! because our tools are not cohesive enough for us to be able to find all information about a topic regardless of the tool it was shared in. We are not savvy enough yet to automatically create institutional histories of work done in the past, we have just started getting comfortable sharing but our technology is not sophisticated enough to know on its own what is and isn't valuable to others in the company. All these things are very possible, and likely even exist but they haven't hit mainstream yet and until then we need to identify, capture, classify, store and disseminate information for our organizations.

Common IT Architecture Mistakes

Can anyone guess what one of the most common issues mid to large size organizations have, technically speaking?

Too much technology!

What I mean by this is that organizations acquire or build systems in silos based on the needs of a certain part of the company. Sometimes even within a business unit or division you will find instances of duplicate applications that were initiated by different people within the organization. This usually happens because there is no strategic group that focuses on the overall technical strategy and needs of the organization.

It may be too late for most organizations to start from scratch to build out a comprehensive architecture plan, primarily because it's cost and time prohibitive. But it's never too late to review what you have and ensure that going forward, all technical decisions that are made, are made with the intent to align existing technology with new requirements and to standardize the purchase or creation of all new applications.

Technical architecture should be reviewed at two levels. The hardware level, do I have enough servers, are they networked, do I have redundancy, etc, and the software level which is more what I am referring to, that is, what applications do we already have, what are each of their functions, which parts of the organization use them, which parts of the organization need the same functions and how you can align future enhancements and capabilities so that you can leverage the use of these existing applications. Within this, you should also review the choice of platforms being used for development to ensure that you are not locking yourself into a technology that prohibits integration with other technologies. Here are some article links that will guide you at the strategic level:

The Most Important IT Architecture Issues Today

Sotware Architecture

An Introduction to Software Architecture

Software Architecture: Using Viewpoints and Perspectives

It's almost the end of 2009. If you are considering software enhancements for next year, it is imperative that you take some time to think through your objectives at a strategic level and map out your software development plan going forward.

The economy is certainly stabilizing, but we still don't have money to burn!

Reorganizing for Growth

I recently came across an article titled Reorganize for Growth and I thought that was interesting because typically reorganization has a negative connotation. People think organizations reorganize because something is not working, and they are right. But what comes after the organizational structure is fixed is growth. This particular story is about Kraft Foods. If you wish to you can read the full story here. I had one major takeaway from the Kraft story that I will share at the end of this post.

When I read the Kraft story though I thought, Kraft has tangible products, they have assets and inventories, and they have business and consumer customers so they have physical entities that they can reorganize around. For instance decentralizing certain product line decisions back to the business units that own them rather than going to corporate to make a decision about a product corporate knew nothing about was a change that made a big difference to Kraft.

But what of services organizations that don’t really have widgets to organize around. Let’s take an example I am very familiar with and that is an Information Technology (IT) organization. One might start an IT organization by dividing people into New work (new applications or new functionality) and Support work. This organization is purely financial but may not necessarily benefit the end customer. The new work is classified financially into revenue and capital expenses and can be amortized by the company whereas the support work is considered operational expense and categorized as a cost of doing business and therefore a direct hit to an organization’s bottom line. Guess what, the customer for the new work and support work is the same. But when he/she approaches the IT organization they don’t get seamless service. They have to deal with X person for new functionality, and Y person for bug fixes and God help them if it's not clear whether the new functionality is in fact new or a build on an existing functionality that was just recently built. They will go around in circles for days before anyone figures it out.

The second organizational layer comes in roles. Both new work and support work requires a project manager, a business analyst and developers. They both work for the same customer on the same product but they are completely separate teams reporting to different managers. Do you see a problem here?

The third layer is a built on the second because it too has to do with roles. Certain skills within roles can be distilled. A project manager and business analyst have the skills to work on any project, new or existing. Should they be organized in such a way that there is a pool of business analysts that project managers can chose from regardless of whether they are needed for new work or support? If that happens then business analysts are effectively leveraged no doubt, but they will spend a lot of time capturing hours spent on each project since one could be a capital expense and another operational.

Because of these complexities and shared responsibilities was born the matrixed reporting structure. Have you ever been part of a matrix reporting structure? It is a mess most of the time. Trying to keep one boss happy is bad enough, now you have two or even three that you have “dotted line” accountability too.

Every IT organization I have known has tried reorganizing (sometimes annually) around these three scenarios or a combination of them. And each time the only thing the reorganization does is create “activity.” And then things get messed up again. This brings me back to the one thing I picked up from the Kraft article that I said I would share with you at the end of this article and that is; while reorganizing structural, cultural, and operational changes must be made together because they influence one another.

Have you reorganized your IT group lately? If so, please share why and along what lines did you chose to align the group to?

Meaningful Use of Information

The health care debate related town halls have given the media enough sensationalism for all of us to be exposed to it on a daily basis. But try and actually find clear information on what the American Recovery and Reinvestment Act of 2009 covers and you will find yourself frustrated and annoyed with the lack of clarity around the topic.

So as usual I abandoned the government sites and started reading posts made by experts, vendors and people like you and me; each one trying to either understand the Act or extract one piece of information that makes a business case for a product or service. I started scanning for the term information technology and came across the Health Information Technology for Economic and Clinical Health Act, which is part of the 2009 American Recovery and Reinvestment Act of 2009. Through this Act the government has allocated $20 billion to health care information technology. It’s intended to achieve widespread adoption of health care IT systems and to enable electronic exchange of information to create a seamless, paperless exchange of information between health care providers, patients and the government. A portion of this $20 billion is allocated to providing incentives to physicians ranging from $40,000 - $65,000 if they can display meaningful use of health care technology systems. There is also a mention of saving the government $10 billion through improved quality of care, reduction of medical errors and duplicative care.

But wait…there is a catch! The twist to this allocation is that health care providers have to demonstrate “meaningful use” of certified electronic health record technologies (EHR). My first reaction was oh no…..here we go again, the health care IT industry will have to reinvent itself as EHR technologies.

“Meaningful use” is defined in the legislation as:

• Using certified EHR technology that includes electronic prescribing. The certification would be conducted by the National Institute of Technology (NIST)
• Using EHR technology that allows electronic exchange of health information
• Eligible professionals must submit information on clinical quality measures and other measures selected by the secretary of the Department of Health and Human Services (HHS).

There doesn’t seem to be much clarity around specifics of reporting meaningful use but health care providers are anticipating that the Department of Health and Human Services will provide specifics and clarity about what they will need to do to demonstrate meaningful use. Most providers will have one year – 2010 – to finish EHR implementation and put the infrastructure, applications and training in place to be eligible to receive as much of the incentive money as possible.

There are also some stringent requirements around security. For example, records cannot be sold, the penalties for violations have been increased, data must be encrypted and providers must keep an audit trail of whom they have shared information with.

So, what does this mean for information providers? There are numerous packages in the market that offer simple medical book keeping for small offices, there is off the shelf software for filing electronic claims, and then there are institutional health care administration packages for hospitals and hospital systems.

The “meaningful use” clause will require vendors to create a complete package or solution for health care providers. This includes networking capabilities for doctors, a patient portal where a patient can access their medical records electronically, and a feedback loop where patients have an opportunity to rate their physicians. The intent is to give incentives to providers who think of their practice as outcome driven rather than service oriented.

You can find the American Recovery and Reinvestment Act of 2009 at http://thomas.loc.gov/cgi-bin/query/F?c111:8:./temp/~c111rCLY0v:e181205:

Is Talent Overrated?

“People who do the common things in this life uncommonly well will command the attention of the world!” --George Washington Carver

My friend recently mentioned that she had read this book called "Talent is Overrated" where the author proposes that people are not necessarily born with a specific talent, some may have a physical advantage (such as height in the game of basketball) but for the most part a person's talent is the result of hard work, perseverance, and 10,000 hours of practice in the least.

Talent is the natural ability to do something better than most people can do it. This ability is fairly specific, it's innate, you are born with it, and if you are not born with it, you can't acquire it.

Based on this definition, author Geoff Colvin argues that Tiger Woods was not born with an innate ability to play golf. Tiger's father put a baby size putter in Tiger's hand at the age of seven months, propped him in a high chair in the garage and entertained him for hours by hitting golf balls into a net. By age four Tiger was taking golf lessons under professional teachers and played his first international competition at the Walker Cup after seventeen years of intense practice. Colvin goes on say that when asked about Tiger's phenomenal ability to play golf, both father and son cite the same reason: hard work.

The kind of intense practice that Colvin refers to in his book is not just a routine repetition of the same act over and over again but rather what he calls deliberate practice. Deliberate practice, a term coined by Anders Ericsson is characterized by several elements. It is activity designed specifically to improve performance, often with a teacher's help; it can be repeated a lot; continuous feedback on results is available; it's highly demanding mentally; and it isn't much fun.

I know you've zeroed in on the last point. Deliberate practice is no fun. Colvin explains that the reason it's no fun even though it's an activity you generally enjoy doing is because in deliberate practice you intentionally seek out what you don't do well and keep trying to improve it rather than continually practicing what you already do well. The good news about deliberate practice is that it's difficult, which means most people won't do it. So if you are willing to do it, it will distinguish you from the rest all the more.

So how would one apply the principles of deliberate practice to an organization? Here Colvin talks about the principles of great performance. He admonishes that the global economy, the move from financial capital to human capital has left no place for subpar performers to hide.

The primary principle of great performance within an organization is a true commitment to developing people by:
--understanding that each person in the organization is not just doing a job, but is also being stretched and grown
--finding ways to develop leaders within their jobs
--understanding the critical role of teachers and feedback
--identifying promising performers early
--understanding that people development works best through inspiration, not authority
--making leadership development part of the culture.

A great organization consists of great performers. And great performers have one key characteristic, passion. They are intrinsically motivated. When creative people are focused on solving a problem, the focus is the solution and not what the solution will do for them personally. Extrinsic motivators also play an important role in great performance. Not all work is creative all the time, rote work like documentation, accounting, communication, etc is not exciting or enticing but still needs to be done. In this case extrinsic motivators can go a long way in keeping people motivated.

According to Colvin, organizations typically fail at motivating their employees because they are prescriptive. You are assigned a project, you rarely ever have an opportunity to select your own project. Feedback is rarely constructive, nonthreatening, and work-focused. It tends to be personal and accusatory.

In conclusion, Colvin has tried to create a link between deliberate practice, great performance, creativity, passion and ultimately accomplishment. On a personal level he has provided some models for deliberate practice that are worth looking into.

From a software perspective I came across an interesting application of deliberate practice. Mark Needham, a software developer writes on his blog about the possibility of using design coding dojo sessions to deliberately practice good coding techniques. According to Needham "areas of practice for future coding dojos could be: Refactoring a code base, using tiny types, coding in a functional way, and so on." An interesting thought...

We would love to hear your thoughts on talent, practice, deliberate practice, design coding dojo sessions or any other concept you find interesting in this review.

Are we done grieving...time to be more creative

On May 29, 1953, Mount Everest was conquered as Edmund Hillary of New Zealand and sherpa Tenzing Norgay of Nepal became the first climbers to reach the summit.
Fifty-six years later America's struggle to climb out of the economic downturn makes Mount Everest look like a mound of dirt. But let's not focus on the negatives. There is nothing I could write here about the economy, about the debate on government intervention, about lost jobs, or pay cuts that you haven't already read or heard somewhere else.
My focus this past month was on reading. I wanted to be inspired by stories of people accomplishing things rather than reading about how we have less money and how we can't do as much. I had two favorites this past month. The book Do Less, Achieve More by Ching-Ning Chu and the June 2009 issue of Fast Company Magazine.
My article in this newsletter is a synopsis of Chu's book, I hope you find it valuable even if it's just a mild reminder of all the things we should be doing anyway. From Fast Company, here are a few brief descriptions of Fast Company's 100 Most Creative People:

#1 - Jonanthan Ive, Senior VP of Industrial Design at Apple (of course). Ive defined his overarching design principles as "simplicity, accesability, honesty, and enjoyment."
#14 - J.J. Abrams, Founder, Bad Robot Productions. Director of Lost, Alias, and Star Trek. Need we say more.
#43 - Neri Oxman, Presidential Fellow, MIT Media Lab - She is into biomimicry. She is not trying to make a copy of a natural form she is trying to mimic the process nature uses to create something. "We're playing God a little bit," Oxman says.
#47 - A.R. Rahman, Composer - he has reshaped Indian pop music by adding influences from jazz, reggae, and Western classical music. "Jai Ho" (Slumdog Millionaire) was downloaded 100,000 times on iTunes.

You can read more detail about these and the other 96 most creative people at Fast Company's Site.

Sincerely,
Farida Hasanali

Solutions in the cloud

Everywhere I turn or read these days, I run into the idea of 'cloud computing'. I guess it's the term of the moment - the latest IT jargon with the most spin. I've even added to this cacophony by giving an internal discussion / presentation to my company last week over this very topic.

To get a somewhat accurate idea of what cloud computing is, go to wikipedia here.

For those of us who've been around for a number of years in this IT world, we recognize that cloud computing is just more spin and fodder for headlines. In fact, cloud computing is not a technology at all. It's a way to describe computing capabilities without owning and managing the IT resources. So, it's just a handy umbrella term for referring to that computing paradigm collectively.

Many wonder and I've been asked how 'cloud computing' differs from other similar terms like web hosting or data centers or even timesharing. My answer is that all these ideas / technologies are all collectively (along with other stuff) part of cloud computing - not different from it. In other words, if you're doing web hosting or you have your database housed offsite, you are doing cloud computing.

As a company, we've been looking at how we can leverage the cloud computing paradigm for our clients. We believe there is substantial potential for using cloud computing technologies such IaaS (infrastructure as a service) or PaaS (platform as a service) to reduce the cost barrier for introducing or modernizing enterprise applications in an organization as well as moving the cost for these technologies from a capital expense budget item to an operating expense budget item (essentially amortizing the cost of these computing technologies - similar to purchasing electricity a the local utility).

How does your organization view cloud computing?

What's Your Persona?

I recently read a blog article by Kas Thomas called "Programmer Personas". Apparently, some time ago when developing Visual Studio, Microsoft spent a good deal of time classifying programmers into different personas in an effort to better design the developer user experience ("What is an End User Software Engineer?"). The personas Microsoft identified were (I copied these descriptions from Kas's blog post):

• THE SYSTEMATIC DEVELOPER: Writes code defensively. Does everything he or she can to protect code from unstable and untrustworthy processes running in parallel with their code. Develops a deep understanding of a technology before using it. Prides himself or herself on building elegant solutions.

• THE PRAGMATIC DEVELOPER: Writes code methodically. Develops sufficient understanding of a technology to enable competent use of it. Prides himself or herself on building robust applications.

• THE OPPORTUNISTIC DEVELOPER: Writes code in an exploratory fashion. Develops a sufficient understanding of a technology to understand how it can solve a business problem. Prides himself/herself on solving business problems.

Generally speaking, these classifications are rather broad, but I think I can fit most programmers / developers into one of these classifications.

Do you do the same for your customers / clients when you design your software? Probably not. However, given the fact that more emphasis is being placed on user experience all the time AND the fact that identifying user roles / groups is a core requirement of BPM-related projects, you should.

For your next project, take time at the front end (plan it in) to classify your users and design / build your application to cater to these user personas. It will make your application better, and more importantly, your application will be better received by your users.

Supersize Me

Recently, while preparing for a new engagement, I was re-familiarizing myself with Oracle because the application(s) I will be working with require an RDBMS and the client has chosen Oracle.

So, because I have experienced Oracle installations in the past, I decided not to install Oracle on my laptop. Instead, I planned to install it on a virtual machine (vm).

Now if you've ever worked with vms, you know the first thing I had to do was create the vm... (if you haven't worked with vms, I recommend you check out VMWare). Just for completeness, the vm system was planned to be Windows 2003 R2, the latest version of Oracle, and Vignette Records and Documents v7.3.1.

Since we use vms quite frequently, I have a set of commonly used "base" vms with the operating system (OS) already installed (and a few development tools like Adobe PDF Reader, WinZip, and Eclipse), so I just started with that. I built these vms with 10GB hard disk. That makes the vm fairly easy enough to copy (to either a shared drive or a 16GB flash drive and large enough to load the software we work with. So far, that has been workable... that is, until now.

The Oracle 11g download (Windows 32-bit) is 1.73 GB in size.. AND, it's a ZIP file. That's the installation file! I'll spare all the details of getting this monster software installed. However, to get it into the vm, unzipped, and installed, I had to remove all 'other' software installed except the OS and when it was done (btw, I installed the standard edition, not the enterprise edition), I was left with less than 200 MB free! After deleting the ZIP & installation files and configuring a new, basic database within Oracle, I was left with 1.67 GB free out of 10 GB. That's right, just the OS and the 'standard' edition of Oracle - more than 8GB disk space required.

And there's wonder in the industry why software development is so difficult...

Exactly how much is 8 GB anyway? Does anyone really have a good feel for this number? Or is it just a number? Trying to wrap my head around 8 GB reminds me of my high school days trying to understand Avogadro's number. In case you don't know what that is, look here. Avogadro's constant is 6 x 10e23... that is 600,000,000,000,000,000,000,000 (or about that much).

So, 8 GB seems relatively small compared to that, but still it's a hard number to conceptualize... 8,000,000,000 bytes (and a byte is 8 bits). So, this is the equivalent of about 8,000 uncompressed novels or about 10 2hr movies.

When I think back on my career, I'm floored by these numbers - these sizes. We have definitely supersized ourselves in the IT industry. We need to go on a diet, but not just a diet of size - a diet of complexity. If we did that, software quality would go up because there is a direct correlation between complexity and software quality.

Stop supersizing your code.

Windows Registry Nightmares

I remember Windows (and DOS) before it had a registry... Do you remember? Remember the the Win.ini and the System.ini files (and Autoexec.bat and Config.sys)? Seems like a lifetime ago - and for some of you I guess it is...

At the time, configuring Windows sure was simpler. Simpler and easier. Simpler and easier and LESS RISKY.

Not so anymore... Today, the venerable INI files have been (mostly) replaced by the Windows Registry.

Have you tried editing the Windows registry manually. Go ahead. On Windows XP or Vista, try to uninstall an application - or better yet, a Windows installed service - manually. I dare you!

What's that you say? I must be crazy? That's insane? No one is dumb enough to try that? Well, I tend to agree with you. I consider myself a fairly experienced PC/Windows guy, but even I think twice before using REGEDIT.

But I do use REGEDIT.
Why? Because I have to.
Why? Because lots of software uninstalls poorly...
And I'm fed up with it!

This behavior reminds me of the bad 'ole days of "DLL hell". Anybody remember that? Where a software would install a DLL with the same name as a system DLL, or worse, it would install a system DLL that was the wrong version? Inevitably, it would screw up your system (in weird ways) and was masterfully difficult to troubleshoot.

And no, "DLL hell" hasn't gone away, but it's gotten better - or at least now it has to share the infamy with "Windows registry purgatory" (Wrp).
(Made that up myself... you think it'll catch on?)

For those of you who have not experienced Wrp (pronouced 'warp'), let me shed some light on this phenomenon. But first, read this to see what the Windows registry is so I don't have to spend a week relating my limited knowledge of the Windows registry.

In the Wikipedia article, near the bottom, there's a somewhat inconspicuous bulleted list item under the heading Advantages and disadvantages:

• "Any application that does not uninstall properly, or does not have an uninstaller, can leave entries in the registry. Over time the computer suffers "Software Rot" as the registry fills with left-over and possibly malfunctioning entries."

This is the nasty bugger... This is the root of my pain.

Why doesn't software written for the Windows platform clean up after itself well? Is it really that hard?

Ok, yes, it is kinda hard - especially if you register COM controls and/or Windows services. But, that should be part of the price of selling software on the Windows platform in my opinion.

This is the kind of software engineering I alluded to when I wrote about "Leaf Blower Coders". Face it,

the job is not done until all can be undone.

So, why is this a pain? I mean, really... all that's happening here is that there are orphaned registry entries that can't *do* anything and while it may bloat the registry, it's just a nuisance, right?

WRONG! Very WRONG!

As consultants, integrators, and custom solution providers, it is often common for clients to ask us to install software for them - usually on DEV or QA platforms. We act as experts and the client watches and learns as we show them how their software is loaded and configured. It's also not uncommon for us to be asked to *re-install* software that has been installed incorrectly, or we ask the client to *re-install* software themselves to insure that they have learned how to do it correctly. And THAT is when the uninstall becomes oh-so important.

It's in these *re-install* moments that orphaned registry entries can wreak havoc, I mean REALLY BAD BAD juju, on your day. I won't bore you too much more with details because I've rambled enough already, but orphaned registry entries (and really, *any* orphaned stuff) left hanging around after an official uninstall will cause untold problems with re-installing software - nearly always ending up with a failed install (or worse, an install that appears to work, but you don't find out it really doesn't work until much later after you've spent too much time trying to figure out why the software seems buggy).

So, here's my newest plea to Microsoft platform software vendors...

Please, please read the whys & wherefores of the Windows registry design and use - here, here, and here are good places to start. Take the time to map out all the registry entries your software makes when it installs and over the lifetime your software is installed (as well as any other configuration changes your software makes to the system as a whole). Document that in your software documentation. And then create a stand-alone uninstaller that reliably, repeatably removes them. We, your users and partners, need help to keep the Windows registry beautiful and tidy for future generations. Thank you.

Java Coding Guidelines - Part I

Does your company have a standard or set of coding style guidelines for writing Java code? Have you ever tried to write one?!?

From past experience, I'd recommend against it. Instead, I'd point you and your Java developers / programmers to Sun's Code Conventions for the Java Programming Language. This guideline has been vetted over many years and the entire JDK mostly follows it. As a result, most Java programmers are familiar with them, and Java code that follows these guidelines is generally readable by all Java programmers.

That being said, I'm going to ignore my own advice and begin writing a Java Coding Guideline for Xpediant. "Why?" you ask...

Well, I believe that Sun's guidelines are good, but incomplete. Remember, Sun's audience was much larger than Xpediant's audience, and therefore, had to be agreed to by a much more diverse group. Being smaller in size, we have the luxury of espousing and enforcing more specific coding practices - hopefully enhancing the quality, consistency, and effectiveness of our services.

So, where should I start? How does one go about crafting such a document?

Well, I believe the first thing that needs to be done is to create a vision - the same thing I would do for any new project.

Yikes.

Hm... Well, we are an integration and consulting company that works with and customizes software products that are Java-based, so it stands to reason that our Java code should be integratable with those products. And our projects generally deploy into enterprise-level production systems so the code should be high quality, production-ready. And since it's very likely we'll eventually turn over the code to the client to support, our code needs to be supportable and maintainable by other programmers.

So, the vision is:

To write a set of Java Coding Guidelines that:

• Enhances Xpediant's ability to write, test, deploy, maintain, and reuse its Java codebase.
• Consistently and seemlessly integrates with the Java codebase of the software products Xpediant's vendor partners create and sell.
• Consistently and seemlessly integrates with Xpediant's clients' existing and new Java codebase.

Next, I'll explore the most basic Java guidelines - get the easy stuff out of the way first!

Unstructured Business Process(es)

Recently I came across a blog post that discussed the concept of unstructured business processes. You can find it here.

So, what is an unstructured business process (I hear you thinking)... Read on.

Internally here at Xpediant, I've always talked about dividing business processes into two types: linear and collaborative. Linear processes possess a set , pre-determined path of execution where one activity (step) is dependent upon the previous activity completing. In other words, the process is step-wise (and may loop or branch) and has a clearly delineated execution path from start to finish. Collaborative processes are ill-defined processes where the path of execution is non-deterministic, the order of execution is not defined and the only requirement for completing the process is that all activities have completed (either normally or abnormally, but 'done' nonetheless).

So, structured versus unstructured processes is the same set of concepts (with better names that are broader, more encompassing). It turns out, I'm not the only one that sees things this way (and, by the way, I know it is not the only way to segment business process types). There are several others that discuss the inherent differences between structured and unstructured processes as the blog entry noted above discusses.

One idea that spurred some thought for me was the suggestion that the relative number of structured versus unstructured business processes is analogous to the amount of structured versus unstructured data in the corporate world, which by the way is about 1:10. That ratio suggests that there is *large* market opportunity of unstructured business processes for BPM vendors to tap.

But as I thought about it more, the idea of BPM vendors addressing unstructured business processes was potentially antithetical to the processes themselves. In other words, the idea of applying a BPMS to an unstructured business process would inherently change the unstructured process into a structured (or at least partially structured) business process. So, it seems to me, the nature of the business process is altered and the process is no longer unstructured - walls are built that the process must work within.

That may or may not be a good thing. As I thought about it more, a potential opportunity with unstructured business processes is to reign them in and move them towards a more formalized (structured) process. In fact, this is the very point for applying a BPMS to a business process - structured or not. Formalization of the business process provides the opportunity to make the process reliably repeatable which can be measured and analyzed. This in turn provides the opportunity to manage the process, possibly making it more efficient.

However, it seems to me that in this same group of unstructured business processes there are processes that won't lend themselves to the application of a BPMS. That their unstructured nature is exactly what makes them work - the process itself depends upon and is enhanced by the unstructured, dynamic application of the work.

So, while there may be a large market opportunity with unstructured business processes, it's smaller than the whole set by some amount. Not only that, when choosing which process to apply a BPMS to, care and consideration of the nature of the business process is critical to the success of the project.

Response: OJT is Dead; Long Live Training

I've got to rant. Recently, I was forwarded a link to a blog post by Anne Thomas Manes that poses the notion that SOA is dead. After reading this post, I had to respond:

Obituary: OJT

OJT met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession. OJT is survived by its offspring: mentoring, coaching, experiential learning, Observational learning, and all other training approaches that depend on “hands-on” efforts.

Once thought to be the savior of business, OJT instead turned into a great failed experiment—at least for most organizations. OJT was supposed to reduce costs and increase agility on a massive scale. Except in rare situations, OJT has failed to deliver its promised benefits. After investing millions, businesses are no better than before. In many organizations, things are worse: costs are higher, projects take longer, and work is more fragile than ever. The people holding the purse strings have had enough. With the tight budgets of 2009, most organizations have cut funding for their OJT initiatives.

It’s time to accept reality. OJT fatigue has turned into OJT disillusionment. Business people no longer believe that OJT will deliver spectacular benefits. “OJT” has become a bad word. It must be removed from our vocabulary.

The demise of OJT is tragic for business. Organizations desperately need to make training improvements to their work force. Training is a prerequisite for rapid integration of people and business processes; it enables situational development models, such as mentoring; and it’s the foundational architecture for experiential and observational learning. (Imagine shifting aspects of your business to the cloud without training between on-premise and off-premise work.) Although the word “OJT” is dead, the requirement for training is stronger than ever.

But perhaps that’s the challenge: The acronym got in the way. People forgot what OJT stands for. They were too wrapped up in silly debates (e.g., “what’s the best job?” or “Skilled vs. Unskilled”), and they missed the important stuff: training.

Successful OJT (i.e., training) requires disruption to the status quo. OJT is not simply a matter of deploying new people and building friendships with other employees; it requires training. And it requires a massive shift in the way business operates. The small select group of organizations that has seen spectacular gains from OJT did so by treating it as an agent of transformation. In each of these success stories, OJT was just one aspect of the transformation effort. And here’s the secret to success: OJT needs to be part of something bigger. If it isn’t, then you need to ask yourself why you’ve been doing it.

The latest shiny new buzz-word will not make things better. Incremental training projects will not lead to significantly reduced costs and increased agility. If you want spectacular gains, then you need to make a spectacular commitment to change. Like Bechtel. It’s interesting that the Bechtel story doesn’t even use the term “OJT”—it just talks about training.

And that’s where we need to concentrate from this point forward: Training.

Yes, that's a parody (not the real blog post). Interesting, no?

In my mind, Ms. Manes' post was nothing short of a call to arms for evangelists, marketing types, and the media to come up with a shiny new buzz-word (or words). SOA (the term) is dead, so we need a new term. Something new to write about - to market, to hype.

We don't need no more stinkin' buzz-words.

My apologies if you find this offensive, but if I were working for a business that decides on a budget based upon media hype (or denouncement, as the blog post suggests), then I don't want to work for that business. Business decisions - and by extension business cases - need to be based upon solid, quantifiable information, not hype. A business cannot hope to survive by investing millions (as the post claims) in unwarranted, unsubstantiated claims of vendors and media. I have a higher (and experienced-based) expectation of the budgetary decision process.

What about you? What do you think? Does your experience indicate that the arrival of a project proposal on a business manager's desk with the moniker SOA make the proposal DOA? I would hope not!

A Call for Agreement

Can the BPM industry please stop 'defining' what BPM is? Please? Pretty please?

Am I the only one who's noticed that every time someone - an individual or a software vendor or a consultant or a book writer or etc... - talks about BPM, the first thing that's discussed is "What is BPM?".

I even caught myself doing just that as I was drafting a newsletter article recently. Ugh!

I know why we do it. We hear different ideas about BPM all the time that oftentimes don't line up with what we think we know about BPM. So, before we delve into what we have to say about BPM, we feel we have to "set the stage" (so to speak).

Why don't we have one definition? Why don't we all agree? Presumably we are all trying to do the same thing, right? So, if we all have the same goal, then we should be able to state it.

From now on, can we all please reference ONE definition for BPM and reference it? May I suggest wikipedia? Here's the BPM entry.

Now, if you have something you want to add, do it there. Let's discuss it, agree to it, and start using it. I will be happy, you will be happy, and most importantly, clients/customers will be happy they have a centralized reference.

By the way, looking at this entry in wikipedia, does anyone know how to eliminate the proposed merger of BPM and BPI entries? Maybe I should define BPM and BPI for you...

Professional Development

This past December 2008, our company held an 'all-hands' meeting day. Basically, we all came together in our main office in Houston to get together before the holiday vacations and do a little internal training and networking.

I gave a presentation to all our consultants about professional development. While I believe there was interest in the topic, I think the presentation was received with bewilderment and a collective "huh?".

Have you ever volunteered for something and then been given the list of expectations after-the-fact (kinda like signing up to send out the church volunteer schedule only to find out that you are really responsible for managing the entire schedule - from finding the volunteers to facilitating communications to filling in for no-shows)? Yeah? That's the response I saw on the faces of our consultants.

I wasn't upset about the reaction. That's happened to me before - I used to be a corporate Java programming and software engineering instructor, and have seen worse reactions as I presented material. But, the reaction did make me think and assess ("inspect and adapt" as the agilists say).

So I did my own personal retrospective of sorts. It's taken me a couple of weeks to process what I can only describe as guarded "what the?" for what I had to say.

Here's my retrospective results:

We simply had mismatched expectations, and that is a communications failure - my communications failure.

I failed to adequately describe what the presentation was about. I just told everyone I would talk about professional development (like I just wrote above). That's it. So, miscommunication happened.

I believe the expectation of our consultants was that I would talk about "How to be professional as a consultant". You know, guidance on proper consultant behavior on and off a clients' site, and ways for managing your time and relationships with a client.

I certainly talked some about that, but my presentation was broader - I came ready to talk about "growing professionally" (not just as a consultant). I included discussion about proper consultant behavior, but also included skills training and company responsibilities as a professional.

Wow. That's really different perspectives. But, they can both be concluded from the same base idea, "talk about professional development". I really missed the mark communicating within my own organization.

So, what's the moral? "Don't let Bill present to our consultants anymore..."

I hope not. Or, maybe I do... Hm...

No, that's not my take-away.

My learning is that communication, whether formal or informal, whether verbal, written, or otherwise has a lot to do with success, especially as a consultant. It is one of the pillars of wisdom for consultants, and affects most, if not all best practices for consultants (and really, for professionals as a whole). Bad communication is the bane of professionals. We all need to develop and keep refining our ability to communicate. It's in our best interest and our customers' best interests too.

So, I'll add communication skills to my "Professional Development" presentation (and at the same time, try to come up with a better title!).

Do you have any good stories about miscommunication that lead to unexpected circumstances? I bet you do!

Leaf Blowers

Have you ever seen those guys who cut grass that use a leaf blower?

As I was taking my usual walk the other day, one of them was blowing leaves and grass clippings across the sidewalk into someone's flowerbed - out of sight, out of mind.

That kind of behavior really gets to me. And it's not just landscapers that exhibit this lack of judgment.

I am seeing this kind of behavior with software engineering and application development professionals - especially as the complexity of coding increases.

Here's what I mean.

Software code can be generally thought of as either internal or external with respect to other aspects of a system, specifically if your company is a software vendor. The external code is the code that the source is available and the internal code is the code that the source is private.

What I've noticed is that internal code, if you decompile it, oftentimes looks like the flowerbed where the leaves and grass clippings were blown. It seems that some software engineering professionals allow their code to get cluttered with bad or ill-designed code that has been swept under the mat of abstraction and encapsulation (to use object oriented terms), and left there - out of sight, out of mind.

I urge software professionals and vendors to clean house. Your code needs some spring cleaning. Dust out the cobwebs and sweep under the mats. And then, put in place some best practices (continuous integration with unit tests would be a good start) that will help keep the leaves out of your flowerbed.

Just promise me one thing... Don't be a leaf blower.

Year 2009...Looking Back...Looking Forward

As 2009 unfolds, it’s clear that enterprises with a forward-thinking approach and a solid grasp of technology trends will have a distinct competitive advantage. In an economic downturn companies that invest, develop and capitalize on technologies that decrease cost while increasing efficiency and effectiveness will have an opportunity to increase significant market and mind share with new and existing customers.

Even though the media is overwhelming us with consistent bad news and a doom and gloom outlook for 2009, I am fairly optimistic about the innovative spirit that makes us the leading economy in the world. There is a reason that investors all over the world flocked to the US Dollar at the height of economic downturn a few months back.

The technologies that companies will be looking to employ in 2009 range from Software as a Service (SaaS), virtualization, Web 2.0, document management, social networking to video collaboration. Other areas such as Portfolio Management, Business Process Management (BPM), Service Oriented Architecture (SOA), Enterprise Mobility, and Risk & Compliance will continue to stay on the radar for the next few years.

I also believe that companies that commit to applications developed using content management, collaboration, portal, SOA and BPM frameworks will not only find new opportunities/markets but also cost savings that are important for the short term.

To quote Edward Cornish “ The future of every organization, nation, and individual is filled with uncertainties, and our task in dealing with the future is to recognize the fundamental uncertainty in human activities but not allow that uncertainty to make us act without due consideration to the possibilities and probabilities.”

As we move into a year that may offer both sobering downturns and heartening recoveries, let us take this advice to heart and act with due consideration and thoughtful optimism.

Looking back 2008 has been a good year for Xpediant – our customers are happy, we have deployed mission critical systems on time and under budget, kept our annual revenue consistent from 2007 and had most of our customers renew or extend our contracts into 2009.

From all of us at Xpediant, Thank You for your patronage, we Wish You A Very Happy New Year, be safe.

Sincerely,
Qusai Mahesri