The Case for an Enterprise Architect in your Data Governance Program
When I think about information architecture, I cannot help but compare it to the various forms of architecture in the physical world. Structures range from simple tents and tarps to soaring sky scrapers. In fact the original version of this entry started as I thought back on the scrap-wood tree houses we built as kids and compared them to the modern buildings we live and work in now.
Many applications at the core of some enterprises were built in a similar ad-hoc manner as those tree houses, built for a specific purpose and appropriate for the time. Subsequently, the ad-hoc systems and point solutions were extended, modified and remodeled in an effort to prolong their lifetime and value. This was good as long as the architecture was improved along the way. More often than not this was not the case as only new features and functions were added.
The systems were often left with a good looking exterior, but at the core it lacked the structure and robust architecture needed for continued growth. Upon close examination there were the cracks in the foundation and core architecture that inhibit the ability to swiftly and efficiently scale the system. The flaws were due in part to the absence of an architectural vision and road-map, likely because the architecture role was delegated to someone not dedicated to the task. Hence the result today is a tremendous amount of chaos in many enterprises.
John Zachman addressed the problem this way:
“This is what is killing Enterprise Architecture… every computer programmer, systems designer, software architect, solutions architect, technology architect, computer operator, PC owner, data architect, database architect, network architect, business analyst, systems analyst, enterprise architect, service architect, object architect, project manager and CIO calls whatever they want to or maybe, whatever they are doing, “Architecture.” It is chaos. No wonder we don’t have Enterprises that are coherent, integrated, flexible, dynamic, interoperable, reusable, aligned, lean and mean and working.” – John Zachman, Yes, “Enterprise Architecture Is Relative” BUT It Is Not Arbitrary, 2009
At WaMu, I used to quip that if you peeled back all the layers of technology that built up over the years, you would eventually find that it all relied on a monkey with an abacus sitting in the bottom of the WaMu tower. Even the CFO of WaMu acknowledged that given the choice we would not have built our systems that way, but the systems had evolved to that state by thousands of very good decisions for the time.
Eventually though, there comes at time to acknowledge the flaws in your architecture and take action to resolve the problems that are holding you back. The first step in that process needs to involve engaging an Enterprise Architect, then laying out a new foundation for the enterprise information system and making the move from the homestead environment into one built on a that solid foundation. With a solid architecture in place, the business of information governance is simplified and the ability to operate a nimble business is assured.
__________________________________________________________
Thanks for stopping by. My writing is intended to take a lighter look at Data Governance, and toss in some pragmatic advice along the way. If you are interested in more information on how to implement Data Governance in your organization, please contact me via LinkedIn or the email address below.
Regards,
Tom Jesionowski
![]()
RSS feed for comments on this post. TrackBack URI