When IT executives try to develop a comprehensive enterprise data architecture, they may quickly find themselves aiming at a moving target.

TechRepublic member Robert McIntosh initiated a discussion on the topic at CIO Republic by noting that “the really key challenge is to define the enterprise architecture and implement it before the business has moved on.” IT projects are often based on business requirements drawn up months, or even years, earlier, McIntosh said, so it’s quite a challenge “to keep the enterprise pinned down for long enough to bring the enterprise architecture into reality.”

Create a living document
In the online discussion, John Tieso, presidentof Tieso & Associates in Arlington, VA, agreed with many of McIntosh’s points, but he also said that “the architecture should be a living document that is reviewed, updated, and discussed each time there might be a data impact.” One problem Tieso sees is that organizations feel rushed to make a change; then, “quickly skim over process and get deeply into guessing about data requirements, rather than doing the job right.” Of course, Tieso pointed out, no one will be willing to own up to why the bad code was written.

Information engineering also needed
Several members invoked the precepts of the information engineering approach advocated 20 years ago by experts such as Clive Finkelstein and John Zachman. IT consultant and minister Thomas Burlew trained with Finkelstein in 1980 and found that his method “includes change management, so that the living architecture document grows as the enterprise grows.”

In fact, TechRepublic member kostta calls the Zachman framework the most useful tool for creating a comprehensive description of the enterprise data. Like other members, he also recognizes that business changes make the process more difficult. His formula for success: “Use the urgencies of the business to drive funding; use the Zachman framework as the project scoping tool to keep you in a strategic posture. then, carve out specific projects with tight project management to actually get the work done.” Kostta facetiously added, “Simple, right?”

The real driver
Rick Orthner, who works in business analysis and policy development, reminded fellow TechRepublic members that “systems development is an engineering process and requires appropriate vigor. Yes, it is partly art, but so was engineering (i.e., building bridges) a few hundred years ago.” He believes that in most organizations, IT is driven by hype and lacks the proper level of discipline. In hammering out the enterprise data architecture, there’s a danger that business will be driven by IT—as it has been too often in the past. But Orthner is optimistic about the future and predicted that “the next generation will finally learn that the business must drive IT.”

What’s your framework?

Are you using an “old school” information engineering approach, or do you have different methods to develop enterprise data architecture? Do you have tips to help colleagues deal with constantly changing business requirements that impact data? Join the discussion and share your thoughts.