>Kiwi and Enterprise Architecture

>

Most of us don’t give must thought to a company like Kiwi, founded in 1906, that makes shoe polish (you know, the ones sold in the round tins with the twist handles that prop open the lid). However, Kiwi has been remaking itself and in 2007 contributed $310 million in sales to Sara Lee Corporation.

The Wall Street Journal, 20 December 2007, reports how two years ago, Kiwi “interviewed 3500 people in eight countries about their shoe care needs” and they found that “on a list of more than 20 attributes people desired in their shoes, shine ranked merely 17th.” Kiwi went on to re-architect the company from being a shoe shine-centric one to one with a varied shoe care product line more in tune with customer needs for fresh smelling and comfortable shoes.

The Chief Executive of Kiwi states─ “‘it became clear: innovation was a key value of ours’…but innovation wasn’t enough…products had to be informed by the needs and desires of consumers.”

Kiwi’s approach was very much in line with User-centric EA. They focused on the user requirements first and foremost. Then, and only then, did they apply innovation to new products to satisfy the needs.

The company went on to develop: “’fresh’ins’ (thin lightly fragranced shoe inserts for women) and ‘smiling feet’ (a line of cushions for heels and the balls of feet, anti-slip pads and strips that can be placed behind the straps of high-heel sling-back shoes.”) Kiwi transformed itself and became “a foot care brand without losing its edge as the world’s shoe-care expert.”

How did they transform themselves?

1) Requirements gathering: They surveyed and sought to understand their customers’ needs.
2) Solution analysis and design: They consulted podiatrists and physiologists “to understand foot anatomy and how bacteria trigger odor buildup in shoes.”
3) Prototype development: Kiwi created “prototypes that customers could actually put on their feet.”
4) Marketing planning: Kiwi designed new packaging and made a new merchandising system for in store displays that grouped “their women’s products, athletic products, [and] shoe shine products by color─moves intended to make the shoe-care aisle easier to shop.”

Kiwi implemented a true User-centric EA approach to its transformation efforts. They did not let advances in foot care products drive the business approach, but rather they let the consumers and their requirements drive the business and its product development expansion. Moreover, the company focused not only on product development, but integrated a comprehensive solution to meet their consumer needs through a whole new line of foot care products (augmenting their shoe care line) and incorporated testing and marketing to ensure a successful launch. What an amazing feat for Kiwi (no pun intended)!

>CONOPS, Proof of Concepts, Prototypes, Pilots, and Enterprise Architecture

>

User-centric EA seeks to implement successful IT governance for the enterprise. As such, it seeks to ensure that new systems not only meet users’ requirements, but also that organizational investments in new IT are successful.

There are a number of ways to phase in a new system to help ensure its success for the organization.

By first developing a clear definition of capabilities (CONOPS), and moving from proof of concept to prototype and to pilot, risk is mitigated on new system implementations and more systems are successfully brought to fruition. This phased systems development approach helps User-centric EA meets it target architecture and transition plan for the organization.

  • Concept of Operations (CONOPS)—evolves from a concept and is a description of how a set of capabilities may be employed to achieve desired objectives or a particular end state for a specific scenario.”
  • Proof of Concepta partial solution to a problem intended to prove the viability of the concept. A proof of concept may involve a small number of users acting in a business (non-IT) role using the system to establish that it satisfies some aspect of the requirements for the complete solution. The proof of concept is usually considered a milestone on the way of a fully functioning prototype.
  • Prototype—an original instance of some thing serving as a typical example for other things of the same category. A prototype is built to test the function and feel of the new design before starting production of a product.
  • Pilot—an initial roll out of a system into production targeting a limited scope of the intended final solution. The scope may be limited by the number of users which can access the system or by the business categories affected or the business partners involved or other restrictions as appropriate to the domain. The intent of a pilot project is to validate that the system is working in production as designed and limiting the business exposure if it is not.”

Note: Definitions of proof of concept, prototype, and pilot project were adapted from Wikipedia. The Definition for CONOPS was adapted from Navy Warfare Development Command (public website).