How to Perform an Architectural Review

So, here I sit in the terminal at O'Hare International Airport, waiting for my flight back home to Texas.  I am here on business to perform an architectural review of an existing system that manages what we call the "pay and chase" process.  The two parties involved in "pay and chase" are health care providers and health care payers.  Sometimes payers overpay providers for services, and want that money back.  My company offers products and services that make this possible, and I just spent three days learning all about it.

The reason I didn't know about it before is because the "pay and chase" system is brand new to our company, having just recently been acquired.  Of course the big issue now is determining how to integrate it into our overall suite of products and services, and for us on the I.T. side, how to homogenize and leverage it's functionality to the rest of our offerings.  So, guess who does that kind of work?

So there I was, tasked with developing a "road map" for homogenizing several disparate systems to maximize our economies of scale and scope, with nary a clue on what those systems do, let alone what they are composed of.  So I decided the best course of action was to perform an architectural review. This way I could begin to get my head around just how I might approach its integration with the overall enterprise, how it might leverage existing systems, and be leveraged by those existing systems.  Who knows, if I do my job well, I just might create some new business possibilities..

So, if you ever find yourself in a situation like this, and need to learn what you have to work with, I recommend the following items, all tailored to explore the breadth of a system; depth can come later.  No point in trying to add flesh to something you don't have a skeleton for.  Without a framework, details just "float" meaningless...

• Identify the system's major components and their roles
• Identify the relationships/dependencies between those components
• Identify the inputs into, and outputs from those components
• Determine the major business objects of the system
• Identify any process workflows in the system.  Are they synchronous?  Asynchronous?
• Explore the security model of the system
• Explore how the system scales

And again, only after gathering these critical "big picture" items, can you then begin to decompose them into smaller and smaller parts.

Finally, one last word of advice.  DO NOT DISPARAGE THE SYSTEM!!  Do not, under any circumstance, utter words that make it sound like you do not approve.  All this will accomplish is to keep the folks you are dependent upon for information, silent, fearful and defensive, which is not the environment you need to create to get the best information.

Let's face it, it is almost cliche that we always believe that everyone else's software sucks, and that ours is awesome.  Even though the architecture you reveal may be very poor, you do not know the circumstances and environment in which it was designed and developed.  I've seen countless systems that I believed were sub-par, and the vast majority of them were designed and developed under the pressure of an artificial sales deadline (see my post "You Sold What?"), which we all know puts intense pressure on IT team to cut corners.

If anything, acknowledge this reality, and watch those you are working with become your best friend, eager to help you understand the "as is", so you can work towards a better "go forward".