Modernizing Enterprise Architecture: Address The Neurosis of IT

“TCP/IP and Ethernet will not be accepted as a valid network implementation as SNA and Token Ring are our preferred standards.” - circa 1993 by nameless corporate Information Systems expert.

I was shocked when I had heard this, and images of ostriches with their heads in the sand immediately came into mind. I was new to my career, and attempting to challenge the old masters of the all mighty Information Systems department was considered blaspheme. After that I was labeled a heretic and could not persue any sort of transformation that would modernize technology or for that matter the business. Over the years the answers were always the same:

• “That will not meet our requirements.”
• “This goes against our security policy.”
• “We do not support that {tool, technology, process}.”
• “If it ain't broke, why mess with it.”

These statements have been picking up recently from a variety of information technology professionals, and sadly from enterprise architects. To be frank, I fear that many IT departments or IT related businesses are at risk of losing relevance. The world is changing faster than ever, yet there is still this strange clinging to the old ways. The truth is that the Internet has changed business forever, but I believe the potential remains largely unexploited. Enterprise architect professionals cannot meet the demands of the next century if there is no strategy to address business transformation, device consumerization, cloud computing, mobility, and exploitation of data.

So why is IT stuck? The answer came to me while listening to a great presentation at Microsoft’s semi-annual Architecture Summit for employees. Norm Judah our Worldwide Chief Technology Officer for Microsoft Services delivered a compelling presentation on the topic of need versus desire.Over the years many of the roadblocks that were thrown up by IT were based on a personal desire of ITprofessionals and not on the actual needs of the business. This interesting duality also has forced me to think about truths versus beliefs. I thought of needs as being truths, where evidence was provided in support of the need or requirement. Desire was actually something more personal, having an emotional component that addressed a level of desired functionality.

Many years back, I was working on a large directory implementation that required domain naming services (DNS) in order to function. There was a “desired” functionality (or belief) from the DNS administrators to have the system by managed in a particular way which resulted in a structurally more complicated DNS namespace. As a result, a simple foundational DNS service had more structural elements which in turn made any solution that leveraged it even more complicated and difficult to exploit. I remember pushing my client at the time very hard on this, to examine what were the true “needs” of the DNS administrator. What was the true business need? Where was the evidence? I never got the “truths” I was looking for as I was clearly sticking a knife in someone for just asking the question. As a result, this client is stuck with a very structurally complicated solution that has limited behavioral flexibility. It satisfies the desired functionality of the IT provider but not for the consumer. The cost of the solution is now more expensive to operate, and the cost of lost opportunities because the lack of flexibility is astoundingly more.

This presents us a very interesting physiological exercise on the needs and desires of the self. Carl Jung made the following observation on the topic of Neurosis: “I have frequently seen people become neurotic when they content themselves with inadequate or wrong answers to the questions of life.”

If I may take this one step further: “I have frequently seen IT professionals become neurotic when they content themselves with inadequate or wrong answers to the questions of the business.” I have heard the following statements all within the last six months.

• “We will never use the cloud because of security.”
• “We are required to use {insert protocol here} because of our strict enterprise architecture governance.”
• “Yes we have monolithic system, but we do not have time to architect changes it so we just keep adding and re-engineering it.”
• “We do not need to talk to the business, I have been here 20 years and I know what they need.” (uhhhh, seriously?)

Of course there are real “needs” that are requirements and constraints that are well defined that relate to business policy, regulatory requirements, human safety, privacy, and security. They are usually supported by economic data around value, cost, risk, and opportunity. These are rooted in truth because there is the evidence that they are required. These constraints must be surfaced and any “complicatedness” that is introduced into the solution may be absolutely necessary. On the other hand, adding elements based on notion that is based on “desired” behavior of the technology provider has to be carefully scrutinized as to not artificially introduce complications. As a result: the desire to build something from scratch, the desire to use the coolest new thing, the desire to buy a tool, the desire to be in control, etc. These all leave behind a cacophony of spaghetti-like of solutions with a small number of business capabilities actually delivered and large number technology configurations. Yes you are stuck.

This desire fuels us to build systems that are overly complicated. I am careful not to use the word complex, as there is confusion on the definitions of complicated versus complex. Complicated systems fall in the realm of known and predictable. Complex systems are not always known and not always predictable. For example, a modern passenger airplane is very complicated due to the massive number of elements and variables, mostly of which are tightly managed and controlled. The concept of passenger air travel is very complex as many elements and variables are loosely managed and sometimes outside the possibility of control.

As an engineer I hated randomness. I wanted control. Most IT professionals are still in the world of control based on this desire. Is there really a need for control? Or is this just to satisfy a desire? As an architect, I have grown to appreciate the value of a certain amount of entropy in the systems I am involved with as this allows for emergence; and in turn plants the seeds for business and user innovation. Therefore I have to be comfortable to give up some aspects of control. Standards are important to keep complications to a minimum, but at some point, they can be stifling if they are based on the desires of the provider. I cannot tell you how often I have seen an under exploited solution because of what I call over governance. Therefore I do not mind a certain degree of complexity with respect to the user freedom. But I vigilantly question the motives of an overzealous IT professional, developer, or manager when a solution gets over-engineered due to desire.

It is my belief that enterprise architecture must propose and help build solutions that are simple, yet can evolve and be fully exploited as business demands change. This requires and understanding that discriminates needs from desires, truths from beliefs. This is a conversation that I have with my clients when discussing true business transformation. Desire comes with a price, and we clearly have to understand the cost and value associated with it. Most often, but not always, desired functionality coming from outside of IT most likely will generate value; desire from inside most likely will have an associated cost.

My goal as an architect is to generate enough desire for the consumer (business) while balancing the needs of the provider (IT). Business moves fast, and technology is moving even faster. Managing the mess in the same way we always have will clearly set us up for failure. The definition of insanity according to Albert Einstein was “Doing the same thing over and over again expecting a difficult result.”

The discipline and professionals of enterprise architecture cannot be plagued with this type neurosis. As architects we need to be advocates of the needs of the providers and the consumer’s desires of information technology. Additionally, there is a characteristic of enterprise architects that is often lacking today. The quality of selflessness is one that enterprise architects must come to terms with. Can you as an architect put the desires of your customer before your own? If we are going to address the opportunities of device ubiquity, big data, hyper mobility, and cloud computing; we must all think differently or lose relevancy like SNA and Token Ring. May I interest you in taking a transoceanic ride in a steamship? I thought so.

As always I am interested in your thoughts.

Disclaimer: The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft Corporation.