Consider the supposed purpose of Enterprise Architecture (EA): “The Enterprise Architect connects the IT Organization to business goals” (Van Meter 2008). Then consider the IT budget – anticipated by one respected research organization to hit something close to $1.5 trillion by 2010 (Morgan, 2007). Put those two facts together. Shouldn’t Enterprise Architecture be the driving force of the IT function?

Along with a deep understanding of the data and meta data, data stewards must thoroughly understand the business processes needed for optimum performance. An excellent way to gain this understanding is to carefully and completely model business processes and the relevant data. Business processes represent the flow of data through a series of tasks that are designed to result in specific business outcomes. They are an important component of a data steward’s responsibility, and stewards should understand the fundamentals of modeling processes as well as data.

Remember post-mortems from the olden days? Way back when, we used to dread them because it meant that the system we just implemented was DOA (dead on arrival). Not that we had to wait until we put the system into production to know that it (and we) were in trouble. But who had the time to address the telltale signs of a system going wrong when a deadline was looming over our heads, and managers were breathing down our necks making not-so-subtle threats about our career and employment opportunities. So, the system went in, we kept our jobs, and management was content for a day (or two), until the phone went off at 3 AM. The system had crashed. It was time for a post-mortem! Management wanted to know what went wrong, when did we know it, who dropped the ball, and how could we have avoided the situation.

Whether you are beginning to develop your analytics program, or re-architecting an existing one, long term success depends on having a right-sized, sound approach, and a realistic plan.