Celent Says

Like Doctors, Enterprise Architects Should Do No Harm

Benjamin Moreland
Insurance Experts' Forum, September 20, 2010

Many people believe that the Hippocratic Oath states that a doctor is not to leave a patient in worse condition than before they treated them. While it doesn’t state that explicitly, it is clearly a goal of any conscientious doctor. Enterprise architects should follow a similar mantra of not leaving a system in a worse state than before they attempt a fix. While there are many differences between doctors and architects (hopefully a doctor wouldn’t consider amputating an arm and replacing it just because a mechanical one could serve better), there are many similarities when architects plan for a core system fix or modernization.

Many architects are quick to consider rip-and-replace solutions for core legacy systems. Today’s distributed applications are integrated with other supported or process-related systems; or leverage legacy components or systems used by other applications. Similar to treating a body ailment, there are many dependencies and complications that can arise if the entire picture is not taken into consideration.

I am reminded of the series “House,” in which—in many episodes—the patient becomes much worse before they truly understand what the ailment is and are able to fix it. In these shows, the patient is already in critical condition ,and the doctor didn’t have the opportunity (or time) to research and do the advance planning to understand all the implications of decisions made in the hope of healing the patient. Many architects are placed in the same position when a premium-bearing application goes down. However, this should not be the case during design.

Similarly, there are too many instances in which architects and developers jump on the latest and greatest bandwagon, trying to force everything into the new standard or methodology, when the existing solution works just fine. When modernizing a new core system, upgrading most of the interfaces is a fine objective and can provide great benefits, especially through re-use. But there are instances where leveraging an existing point-to-point solution as-is works just as well, and is much less costly. As the Hippocratic oath does explicitly state, “I will prevent disease whenever I can, for prevention is preferable to cure.” Used in the right circumstances, this should apply to architecture as well.

This blog has been reprinted with permission from Celent.

Benjamin Moreland is a senior analyst in Celent's insurance practice, and can be reached at bmoreland@celent.com.

Readers are encouraged to respond to Ben using the “Add Your Comments” box below.

The opinions posted in this blog do not necessarily reflect those of Insurance Networking News or SourceMedia.

Comments (0)

Be the first to comment on this post using the section below.

Add Your Comments...

Already Registered?

If you have already registered to Insurance Networking News, please use the form below to login. When completed you will immeditely be directed to post a comment.

Forgot your password?

Not Registered?

You must be registered to post a comment. Click here to register.

Blog Archive

The Other Auto Insurance Telematics Shoe Drops

Progressive's decision to charge Snapshot drivers more if their driving data indicates higher risk has started the industry down a road of data-driven adverse selection.

Core Transformation – Configuring in the Rain

The whole point of core transformation is that changes at the micro level can be used as a stimulus for changes at the macro level.

6 Ways to Develop a Productive IT-Business Dialog

Relationship management 101 for keeping IT and business on the same page.

Unified Digital Strategy: Succeeding in the Digital Revolution

A unified digital strategy recognizes that all business strategies and technologies touch the customer in some way and that a one-size-fits-all channel model is obsolete.

Agile and Continuous Delivery in a Regulated Environment

Just because a development team is doing continuous delivery or packaging releases into two-week sprints doesn’t mean that code is being moved to production.

Dealing with the COBOL Brain Drain

Documentation on aging systems often is akin to tribal knowledge, and the potential for things to go bump in the night increases as these environments face generational transition.