Category Archives: Technology

It’s Still All About the Pentiums, Baby!

It was exactly 3724 days ago today, or 10 years, 2 months, and 10 days ago today that Weird Al Yankovic proclaimed that It’s All About the Pentiums. I wonder if he knew that when he proclaimed:

 

My new computer’s got the clocks, it rocks

But it was obsolete before I opened the box

You say you’ve had your desktop for over a week?

Throw that junk away, man, it’s an antique

Your laptop is a month old? Well that’s great

If you could use a nice, heavy paperweight

 

that the trend was only just starting and that ten (10) years later it would still be about the latest generation of the Intel Processor (the Core 2 Duo), that your database would still be a disaster, that windows would still take a “day-and-a-half” to boot up, or that, regrettably, supply chain managers would still be king of the spreadsheets?

I’m wondering because 3724 happens to be the RFC on The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture. The end-to-end principle just happens to be the core architectural guideline of the internet. Addressing concerns of openness, reliability, robustness, user choice, and ease of new service development, the end-to-end principle, which was originally a question of where not to put functions in a communication system to insure that applications could survive partial network failures, is still as relevant as it ever was. While not a standards proposal, like most RFCs, it put forward some good questions as to how the internet should evolve, questions which are becoming increasingly important with the rapid proliferation of the internet across a wide range of wired and wireless devices on which you will want to seamlessly access your supply chain applications.

Simply put, you’re going to want to be able to run your apps whether you’re working on your server, working on your desktop, working on your laptop, or working on your mobile, and you’re going to want to be able to do it using an open architecture built on open standards. This is because you don’t want to be spending thousands upon thousands of dollars for proprietary products that use proprietary APIs on each platform that do nothing more than convert your data from proprietary format A to proprietary format B so your mobile can talk to the server. You just don’t.

So remember, it’s all about the pentiums, baby.

If Software Development Outsourcing is Too Agile, You’ll Be Kayaking Over the Waterfall

A recent article on “how agile methodologies help software development outsourcing” over on SourcingMag.com had some very good points on how agile software development can help you with your software development outsourcing. However, having lived through the Agile Craze in IT, I know that you can overdo it and actually hinder your development processes and development outsourcing.

 

Let’s start by review the positives put forward by the article:

  • Methodology Fit
    The ability to make continuous process changes and improvements is a boon to two organizations trying to synch their processes for the first time.
  • Bridge the Communication Gaps
    Frequent release-and-review cycles can help to bridge communication gaps.
  • Perfection is Iterative
    No one gets it right the first time. Only the lucky get it right the second time. Just about everything of significant technological complexity in this day and age takes at least three attempts to get right — and when you’re talking software, thirty attempts (behind the scenes) isn’t uncommon …
  • Building Expertise
    You can move your development to an organization that has built a number of similar systems in the past.
  • Responsiveness to Change
    Requirements and processes change continuously … more frequent iterations allow for faster revisions of requirements and code-bases.
  • Quality
    Faster feedback generally means that problems are identified – and solved – sooner in the development process.

Now we’ll look at the negatives that can result if you’re not careful:

  • Methodology Fractured
    While the ability to make rapid changes can be beneficial when trying to synch processes, they can also break processes that are working well.
  • Deepening the Communication Chasm
    Frequent release-and-review cycles that lead to constant improvements can give you the illusion that the communication gap is bridging when in fact the chasm underneath is deepening. The successive improvements could be due to trial-and-error and luck and not have anything to do with communication improvements. Plus, an over-focus on feature-function might cause you to ignore relationship building, which is critical if you are ever going to truly bridge the communication gap, especially with offshore development organizations in India, China, and Poland, for example.
  • Running-in-Place
    The faster you respond to change, the faster the change requests start coming in. If you’re not careful, you’ll start to cycle through changes until you’re back with what you started with — after months of wasted effort.
  • Lack of Robustness and Flexibility
    If you only measure quality by “how close the end-user design is to what you envisioned”, or “how many of your test cases run bug free”, you might miss the fact that the code is an unmaintainable mess of spaghetti that you’ll never be able to maintain, update, or modify again. Very Bad Code is a regular by-product of overly-aggressive agile development cycles with too many iterations. Building good code requires building a good, stable, underlying architecture that does not change. Just like you can’t use the frame of a three-story house for a 6 story office building, you can’t use an architecture for low-volume EDI message exchange for a high-volume real-time XML exchange. If you adopt a high-frequency agile development cycle and don’t take the time to get the right framework and software architecture up-front, the developers end up having to hack the code every iteration to make their changes and after five or six iterations you have a tangled mess that even a development guru won’t be able to make heads or tails of.

So while agile can be beneficial to your development outsourcing, it has to be used in moderation or the drawbacks will far outweigh the advantages.

 

 

Share This on Linked In

Sourcing Innovation Welcomes Vinimaya as New Lead Sponsor

Sourcing Innovation is pleased to welcome Vinimaya, an innovative provider of e-procurement catalog and marketplace solutions, as its newest lead sponsor. Vinimaya, which represents The Next Wave in Product Catalogue Management (PCM), has been adding new functions, new offerings, and new clients since I first blogged about them back in 2007 (shortly after they were named a Cool Vendor by Gartner).

Unlike other providers, who only support catalogs, marketplaces, punch-out, or punch-out 2.0 (where the vendor maintains a cached copy of the supplier catalogs to simulate simultaneous searching and comparison of supplier products), Vinimaya’s Virtual Internet Supplier Network solution (VISN, as in “vision”), supports simultaneous, or federated search directly from whatever catalog format your suppliers have in place — be it punch-out, on-line catalog, storefront, marketplace, database, or flat-file. Whereas most solutions force your supplier to adapt to the vendor’s format, Vinimaya’s agent-based architecture adapts to your suppliers, which is why it’s a low-cost solution for you and for them.

The proof that Vinimaya’s offering, which revolves around their SmartSearch Catalog software product, actually works is in the adoption level. Vinimaya’s client base, which includes mostly well-known, brand name, global companies from almost every vertical market, have executed over $1 Billion in online orders over the past 12 months alone. Delivered SaaS with the ability to “plug and play” with just about any e-Procurement system (e.g. SAP, Ariba, Oracle, Peoplesoft, etc.), once installed, the system not only allows you to find the product you need simply and efficiently, but also verifies that you’re paying at the contracted rates. Vinimaya’s clients sit back and watch their negotiated savings materialize with every purchase.

SmartSearch Catalog also comes with a number of unique features that enhance your efficiency and savings. The unique features include true side-by-side comparison shopping across suppliers, price audit (which will alert you whenever a price has changed or diverged from the contract price), supplier self-service catalog management (which allows your suppliers without any online capabilities to either maintain a catalog for you or create a punch-out site), and inventory checking (which checks that the item is in inventory before sending the order to the supplier). It even offers some capabilities specific to certain procurement systems (e.g. SAP Item Master Check). In the coming weeks, I plan to review the new version of the SmartSearch Catalog (a.k.a. the B2B Search Engine), as well as some of their new offerings, and if I can track down the Sourcing Maniacs, see if they have any insights from their last site visit.

Vinimaya’s bent toward innovation is no surprise when you look at the management team. CEO Gary Hare, who recently penned a piece on B2B e-Commerce right here on this blog, Orville Bailey and Richard Waugh have been thought leaders in the e-procurement space since its inception.

So please join me in welcoming Vinimaya. It’s innovative companies like them that keep this blog going.

Will the Big Shift Waves Give You The Big Shaft?

Share This on Linked In

Honestly, I don’t know the answer to this. What I do know is that I agree with the Supply Chain Editorial Staff and that graphs based on loosely defined waves don’t tell you very much. But let me back up.

Recently, Deloite released “the 2009 Shift Index” which is a 142 page PDF where they attempt to define and measure the forces of long-term change and understand the deeper trends that might soon make the concept of “normal” in business a thing of the past. To this end, they defined three “waves” that they believe capture the shifts that are taking place in the global economy:

  • Foundation Wave
    changes in the business landscape, including digital technologies and the liberalization of government policies
  • Flow Wave
    the increasing pace in which knowledge, capital, and talent move across a company and around the globe
  • Impact Wave
    the business impact of the first two changes with respect to overall corporate financial performance

Then they created indices and measure the shifts. And this leaves me scratching my head. How do you prescribe meaning to a rate of change in an index with a definition that is nebulous to begin with?

That being said, some of the trends that Deloitte has been tracking, which were quantified in the report, are certainly worth noting. For example, the average Return on Assets (ROA) of US companies has decreased 75% in the last 45 years and digital technologies are being adopted at rates 2-5 times faster than previous infrastructure shifts such as the telephone and electricity. If they are relevant to your industry, the sooner you identify these trends and their potential impacts to your operations, the better off you will be. If you don’t plan for them early, you might soon find yourself among the companies that are experiencing a rapid deterioration in performance.

To that end, it’s certainly worth downloading a copy of the report and giving it a cursory read. It contains a lot of good information on a number of trends that could impact your supply chain, some of which are summarized in this recent Supply Chain Digest article on a new normal. Just don’t be afraid to shaft the shift indices with the short straw. I don’t think anyone really knows what the global business landscape will look like in 10 to 20 years, and I certainly don’t expect a magic index to shed any long-term insights.

When Will Organizations Learn That Complex Software Is Not Easy!

A recent article over on Procurement Leaders titled “software procurement blunder grounds vital military helicopters” has me fuming.

First of all, it contains the phrase “procurement blunder” when the blunder does not appear to be the fault of the Procurement department, but the fault of idiots higher up.

Secondly, it contains the statement that an organization should “cut costs by developing its own software“.

I guess I should step back a minute and summarize the article. The UK MoD (Ministry of Defense) purchased eight (8) Chinook Mk3 helicopters in 1995 from Boeing which were delivered in 2001 at a cost of £259 Million. As of 2007, they were still not deployable because they could not be flown in poor visibility or at low altitudes because they were missing key operational software. This software, which would only have cost £50 Million (which is only 2.5% of the purchase price of the eight helicopters), was not included in the purchase because the UK Treasury demanded the MoD cut costs by developing its own software.

This is just nuts in so many ways. For starters:

  • Over 90% of software projects fail to come in on time and on budget.
  • Complex software systems, especially operating systems, typically require thousands of man years to develop. Red Hat 7.1, which only has to operate a PC and not a complex military helicopter with dozens of systems and hundreds of controls, required about 8,000 man years of development effort.
  • Complex (operating) systems can only be built by senior developers, which, fully burdened (with salary, benefits, hardware, and software costs), will cost you about 200K / man year.
  • This says that 100 M (slightly more than £50) only buys you 5,000 man years.
  • Even if your programmers knew exactly what to do, it’s doubtful you could even match the market cost of an already developed system which is being amortized over a large group of buyers.
  • The only way the MoD could make the helicopters flyable was to spend untold millions stripping them down to Mk2a configurations, which also delayed their deployment for 2 or more additional years.

But, more importantly, you’re trying to save pounds by pinching pennies! That never works! It would have been much more logical to try and find ways to reduce the purchase price of the helicopters by 2.5%. For example, could the purchasers have worked with Boeing to help them execute more strategic sourcing projects to reduce Boeing’s cost in a savings-split? Could UK MoD manpower have been lent to Boeing? Since most purchasers believe in the old maxim that you can take 10% off of the cost of anything, how hard would it really have been to reduce costs by 2.5% to cover the software costs if Procurement was allowed to be creative instead of having to deal with idiocy pushed down from the top?