Menu
Coping with solution diversity

Coping with solution diversity

A friend of mine told me about a sign that he saw at a mechanic's shop. It read: "We specialise in all cars, foreign and domestic." We wondered just how much specialisation that could be!

Likewise, how specialised are we as solutions integrators if we aim to provide all solutions in all configurations to all customers? We pride ourselves on having the skills and expertise to integrate the diverse solutions that our customers need. In some cases, through our efforts to satisfy all of our customers, we may not have complete expertise in the specific solution being implemented.

Customers want solutions that are specific to their challenges, but they also want the people on the team to have prior experience with that solution. However, when you start integrating products for enterprise applications, you end up with a unique mix of products that no one has used in that exact configuration. Why is this a fact? Don't many companies need similar solutions?

About 3000 companies exhibited their products at Comdex 97 in Las Vegas. Conservatively, these companies each have three products - on average - and each of those products has a new release or model every couple of years. Very conservatively, that means that there are about 10,000 products to choose from. A modest enterprise application requires about 50 additional products, ranging from PCs, NICs, routers, servers and RAID subsystems to operating systems, databases, application tools, management tools and more.

For each system you must select 50 products out of the 10,000 in our simplified IT marketplace. Of course, you won't get to choose them all - some of them will be dictated by legacy investment and customer relationships. Statistics buffs will recognise that there is only a small chance that your next $1 million deal will have an architecture you've completely implemented before.

So how do we best serve our customers in this wild and woolly market? We have to manage the risk of implementing these systems. We need to satisfy our customers' valid concern of having people on the project who've "been there, done that" - or we may not win the deal in the first place.

A very effective tool that helps manage solution diversity is something I call "model architectures". These are predesigned, pretested application foundations that help limit the permutations of products applied to your solutions. But one size does not fit all sets of requirements.

Perhaps one model architecture is targeted at highly available and highly scalable applications such as financial trading apps. Another is targeted as the standard infrastructure for a specific prebuilt application suite such as Oracle Applications, PeopleSoft or SAP.

Yet another is targeted at highly distributed companies with many small branches. These models allow you to staff your projects with people who've been there and done that. Have they done every component of the architecture before, including those specific legacy-system interfaces? No. But they have used your model architecture before for a similar customer engagement. They know what works, what doesn't, and what needs some adjustment.

By implementing these models my company provides its customers with a more knowledgeable team and reduced risk. Customers also get a better solution at a lower cost. Meanwhile, we improve our model architectures and establish a better reference base. We also deepen our skills and expertise - instead of dissipating them. Rather than "specialising" in all systems, we win by specialising in proven systems.


Follow Us

Join the newsletter!

Error: Please check your email address.
Show Comments