Daniel Koger

Tag: Problem Solving

  • When Replacement Was Not the Right Solution

    Work Experience series banner introducing career stories, professional lessons, and reflections from a career in technology and business.

    One of the easiest mistakes in technology is to assume that replacing an existing system is the same as solving the customer’s problem.

    During an assignment, I traveled to Oslo, Norway, as a presales solutions architect.

    The company I was working with provided hosting services to small businesses and individual customers. Its existing hosting environment was built around Linux and other open-source technologies.

    The company had an established customer base that was well served by its existing technology. It wanted to expand its services by adding capabilities based on Microsoft technologies.

    From the technology vendor’s perspective, the opportunity initially appeared straightforward: replace the existing environment with its own products.

    But that was not what the customer actually needed.

    Its existing customers were loyal to the services and technologies they already used. Forcing those customers onto a different platform could have put much of the hosting company’s existing business at risk.

    The real question was not, “How do we eliminate Linux?”

    It was, “How do we add new capabilities without destroying what already works?”

    My architectural recommendation was to keep the existing Linux environment for the customers who wanted it and add a separate environment for customers whose needs were not currently being met.

    The client was very pleased with the recommendation. It differed from the original expectations, but insisting on a complete replacement could have jeopardized the opportunity.

    By allowing the technologies to coexist, the hosting company could protect its existing business while expanding into a new market. The technology vendor could also gain business it otherwise might not have won.

    That experience reinforced an important lesson: the responsibility of a solutions architect is not simply to promote a preferred product.

    It is to understand the customer’s business, preserve what is already working, and recommend the solution that creates real value.

    Sometimes the best solution is not replacement.

    Sometimes it is coexistence.

  • When the Lesson Plan Was Not the Real Need

    Work Experience series banner introducing career stories, professional lessons, and reflections from a career in technology and business.

    Working in technology gave me the opportunity to experience many different cultures and to see how people lived and worked in countries with very different resources.

    One experience that comes to mind was traveling to Huế, Vietnam, in 1997 to teach database design at a hospital.

    The hospital had requested the training materials in advance. When I arrived, I discovered that the doctors had already read and memorized them—and had used the books to create databases without receiving any instruction.

    At that time, computer access within the hospital was limited primarily to doctors, and they were understandably proud of the opportunity to use the technology.

    Before the hospital had an electronic database, patients were responsible for bringing their written medical records with them to every visit.

    The doctors’ effort was impressive, but the books alone had not taught them how to connect database-design principles with the actual work of the hospital. They had theory on paper, but no instructor to help them translate that theory into a practical design.

    The problem was not a lack of intelligence or effort. They had done remarkably well with the resources available to them. The problem was that reading a book was not a substitute for seeing how information moved through the hospital and understanding the work the database needed to support.

    So we set the books aside.

    For the next two weeks, we walked through the hospital with the nurses. We asked them to show us what they did, how information moved through their work, where problems occurred, and how electronic data might make their jobs easier.

    The focus shifted from teaching database theory to understanding the people, processes, and needs that the database was supposed to support.

    If we could make life easier for the nurses, we could improve the experience of the patients and, as a result, help the doctors as well.

    We did not accomplish the original lesson plan.

    But we accomplished what was needed.

    That experience reinforced a lesson I have carried throughout my career: good data design does not begin with a textbook, a tool, or even a data model.

    It begins with listening to the people who perform the work and understanding the problem that needs to be solved.