SOA projects are constantly beset by clashing business and technical agendas. Perhaps it's time to pull out the enterprise architect's best tool for addressing these conflicts: the Zachman Framework.
For those in the Enterprise Architecture space, the Zachman Framework is one of the most illustrative guides for gauging the relevance of technology projects to business requirements. The framework consists of a matrix that addresses six communication questions essential to understanding the role of technology to the enterprise -- the what (data), how (function) where (network), who (people), when (time), and why (motivation). The Framework was designed by John Zachman, at IBM in the 1980s, and has been refined since then.
It encourages architects and IT managers to look at technology projects from a variety of viewpoints -- not just technical, and not just business, but all viewpoints. And that's a good thing to keep in mind for SOA -- which also tends to be beset by clashing business versus technology agendas.
Can the Zachman Framework also serve as a guide for SOA efforts? Or can SOA help enterprise architects master the questions that the framework poses? Ron Schmelzer says yes on both counts, and explains how it all comes together in a recent post.
Ron points out that since the Zachman Framework helps companies organize and prioritize the various perspectives on SOA just as well as it does for enterprise architecture in general.In fact, applying service-oriented principles may help guide EA, he says.
That's because "Zachman laid out the overall map, but didn’t provide a guide for prioritizing your route through the Framework, or a way for determining which parts of the Framework are more important to you than others," Ron says. Every company has a different story, and different sets of priorities.
Here's where SOA comes in. "The iterative approach to SOA offers enterprise architects an architectural roadmap that tells them where to start, what’s important, and which way to go," Ron says. "Applying the Zachman Framework to SOA, therefore, can help architects develop techniques for organizing IT and people’s relationship to it so that the organization can respond to change, and leverage change for competitive advantage."
(Image source: Wikipedia)