What is Architecture Management?
The concept of architecture in IT can be subjective, despite its importance. Using the analogy of physical buildings, IT architecture sets out a blueprint, so to speak, that defines the structure of an organization’s data and IT assets. The architect’s goal is to help an organization achieve objectives, both current and future, using information technology.
Architecture management software is designed to enable architects visualize and analyze architectural solutions. They are also used for communicating architecture and business process analysis amongst diverse stakeholders. Architecture management solutions are more than just drawing tools, however. They usually make it possible to model, design, simulate, prototype, build, test, manage and trace an architectural solution from vision to completion. They map to applications, processes and data.
Architecture management software tools, according to IT Central Station members, should help keep the notoriously complicated and jargon-laden discipline as simple to manage as possible. Members warn potential buyers to make sure they understand how each vendor defines specific terms. Meanings and usage of the same term can vary across product lines and architectural communities. As part of this, the tools should supports a variety of meta-frameworks, such Zachman and Togaf 9 as well as application portfolio scoring models. Architecture management packages need to give an overview along with the ability to drill down from a bird’s eye view to the little details, and back. Traceability matters as well, because architects have to be on top of the evolving architectural plan.
Technical factors are as critical as conceptual ones. The performance of the process is an essential metric. With data modeling being important to architecture, the best architecture management products allow model objects stored to a database for analytical purposes. In this vein, native RDMBS support is also recommended.
Flexibility in technical implantation is also required. The tools have to support current and business models while allowing for future changes. Solutions have to be able to flex to support changes. That said, one major recommendation is to tie tooling to maturity – avoid buying a tool that the architecture team cannot handle at its current maturity state.