Whitepaper
planningIT Support for Architecture Frameworks
Introduction
Architecture frameworks have, over the years, provided a foundation for enterprise architects to deal with the increasing complexity of the IT environment and the growing sophistication of the requirements placed on the enterprise architecture team’s scope of responsibility. Whether a standard framework - such as TOGAF or Zachmann - or proprietary, organizations look to them for a way to arrive at a structure for the architecture effort that makes it understandable so that it can be communicated and, in turn, become meaningful to the organization, and, ultimately, valuable for the business.
Frameworks have also served a purpose in striving for IT/business alignment but only when properly used. The business side of things being a very individual matter to each organization, companies should, while drawing on the “best-match” standard or proprietary framework, in the end adapt the framework to the needs of the enterprise. With so many moving parts in an organization, there are just too many variables that will determine a company’s success to allow a standard framework to become dogma and potentially paralyze IT in its ability to support the business.
IEEE Standard 1471 was the first attempt at standardizing EA development that recognized that in order for IT to be aligned with business, it needed to be developed in the context of the organization or it would not be of any value to the business. In this vein, it also upholds the tenet that architectural descriptions take into account the different stakeholders in the organization. Considering the distributed structures of today’s mammoth corporations, involving all stakeholders is a crtical requirement for effective governance. Thus different architectural “views” with each view covering an identified set of system concerns, are inherent in most frameworks. “Viewpoints” are also found in some frameworks.
In IEEE 1471 Frequently Asked Questions, V 4.0 we find views and viewpoints explained this way:
“…a view is a collection of models that represents the whole system with respect to a set of related concerns. A view belongs to a particular architectural description. For example, a structural view of a system might include a model showing components, their interfaces and the classes comprising them, and a model of their dependencies and inheritance relationships. A performance view might consist of models for resource utilization, timing schedules and cause-effect diagrams…. A viewpoint captures the rules for constructing and analyzing a particular kind of view. It is a template for a view which can be reused across many architectural descriptions.”
“What is a framework?
“An EA framework is an abstract graphical representation of the enterprise or - more pragmatically - its information landscape. EA frameworks help enterprise architects classify and organize different models, facilitating better access to different viewpoints and levels of detail for a spectrum of users. They can also ease communication by clearly establishing boundaries and responsibilities, depending on whether firms adopt decentralized, centralized, or federated architect groups.“
- EA Frameworks are Mainstream, but the Landscape Remains Diverse, Henry Peyret, Forrester, July 26, 2006
Even with most frameworks embracing the views of various stakeholders, they are most often not varied enough and not detailed enough to reflect the broad range of stakeholders in large organizations. Here, meta models provide the detailed views required to truly be able to create and communicate a cohesive picture of the enterprise architecture in all of its facets. Additionally, frameworks have non-disputed advantages in establishing the semantics of EA and provide useful navigation concepts.
Nonetheless, experience has shown that these frameworks are inadequate as business support processes unto themselves. In particular, they lack the workflow concepts necessary to support a wide community of stakeholders in a collaborative planning process for advancing the enterprise architecture.
As a provider of a tool for architecture-based IT planning and management, alfabet is often asked what frameworks we support. This paper explains planningIT’s positioning with regards to most of the standard frameworks in use today.
How does planningIT support frameworks?
For a tool to be in support of a framework it must provide the ability to associate types of definitions and models with a framework classification and to determine where an object fits within a framework.
The framework support provided by planningIT may be used not just as a supplementary conceptual reference for users, but also for navigation and deep drilling into various aspects of the IT landscape. Moreover, due to the richness of the planningIT meta model such frameworks can be easily mapped in the software. A rich variety of architecture frameworks and standards including COBIT, ITIL, TOGAF and Zachman were reviewed and applied in the alfabet methodology, comprising naming conventions, objectives, reports and processes, to name a few.
Before we start looking at the individual frameworks, it is important to understand the EA processes supported by planningIT and the architectural elements it takes into account to effectively fulfill the processes. In the sections that follow, the reader will then be able to easily correlate planningIT to the specific framework.
planningIT’s Logical Inventory holds all of an enterprise’s EA and EAMrelevant information: corporate strategies and goals, and objects associated with the business, technical, information and systems architectures. Each object holds information on its relation to other objects in the system allowing different views on the architecture. All objects – current and planned - are also associated with time dimensions, important when planning new architecture solutions and assessing their impact on other architecture elements (and vice versa) at different points in time. This is essential for transparency and control in an enterprise running multiple parallel transformational projects.
