Competitive pressures and rapid change are forcing many enterprises to re-engineer.
But before senior business managers and IT professionals can hope to understand the implications of new business and IT strategies, they must first build an architecture around the process, according to one expert.
John Zachman, author of the Framework for Information Systems Architecture, spoke at Showcase Ontario in Toronto, where he discussed the importance of Enterprise Information Architectures (EIA) and the Zachman framework, which helps facilitate the communication of EIA development.
An early contributor to Business Systems Planning, IBM’s information planning methodology in the 1970s, Zachman developed the framework from observing how architecture, construction, engineering and manufacturing industries handle the construction of complex products. Zachman then applied these concepts to the design of enterprises and the computers that support them.
According to Zachman, any time you want change, “you start with a descriptive representation.” That is where the Zachman Framework comes in. A two-dimensional classification scheme for descriptive representation of an enterprise, the framework evaluates methodology or tools involved in building systems and serves as a communication vehicle to understand and decide on various trade-offs in the development process, Zachman explained.
The descriptive representations of the framework include data, function, network, people, time, motivation, scope, the enterprise model, system model, technology model and detailed representations. Zachman said it is necessary to look at how all relate to each other to “help you figure out the minimum possible set of descriptions you want to produce for any given implementation.”
And if any one is not willing to do them all, then a certain amount of risk is assumed. The only way to eliminate risk is to do the architecture and the descriptions, Zachman said, meaning that a good deal of work must be done.
“There’s no magic to doing enterprise engineering. Somebody has to do it. No machine is going to do it for you, no software is going to do it for you. Actual work is the only way you’re going to get it done. That’s the problem,” he said.
“We’d like to throw some money at this thing and hope it goes away. The fact of the matter is you have to go back to the basics…so the enterprise that figures that out, and gets back to the basics and deals with these architectural issues will likely be the ones that will be able to accommodate dramatic increases in complexity and the rate of change,” Zachman said.
“And they’re probably the ones that will be the survivors.”
According to Zachman, one of the problems facing enterprises is that they still work with mission-critical legacy systems which must change with the company as it addresses competitive pressures. Even greater is the problem that organizations face rapid change as they re-engineer to compete.
For this reason, enterprises need to start looking beyond 2000, Zachman said. “I would argue you have to do two things: you’re going to have to do architecture and build architectural representations, and you are going to have to shift into an assemble-to-order kind of environment because that’s how you reduce the time to market to virtually zero,” Zachman suggested.
“I simply don’t believe that an enterprise of any substance is going to be viable in an information age without doing this kind of thing,” he continued. “This is the gate you go through if you want to play in the game.”
According to Zachman, there are two things forcing the issue of architecture: complexity and a dramatic increase in the rate of change. Because systems are so complex and ever changing, formal records or architectural constructs are necessary.
“The problem is, historically, we had a lot of time and the rate of change wasn’t very high. We made all the changes by trial and error…also, the enterprises were fairly simple so we didn’t have to have a lot of formal descriptions.”
