An Architecture Framework provides context and structure for the application of enterprise architecting. It provides a reference for design undertakings. Frameworks provide guidance and are not intended to be rigidly adhered to. An architecture framework needs to be customer-focused, and adaptable to a wide range of customer contexts. Organisations may:
- have their own framework;
- adopt an industry framework (e.g. government agencies complying with a government model such as the Australian Government Architecture Reference Models or the Queensland Government Enterprise Architecture);
- adopt an accepted best-practice framework such as TOGAF, apply one that is used by an IT provider; or
- they may have no formal framework at all.
The application of a framework, such as the illustrated example, provides a bridge between a customer's own architecture framework, its business operations and strategies and the architect and his/her organisation's design capabilities and reference architecture.
Adopting an Architecture Framework will allow Enterprise Architects to:
- devise designs and articulate their value in customers' business terms; and
- provide for a consistent, and therefore inherently more efficient approach to all design efforts.
Industry-recognised frameworks such as TOGAF or Zachman are intended to provide guidance for the widest possible reference, and hence need, and acknowledge, that they should be adapted for specific use. It is important to recognise that, while the focus is on the customers and an Enterprise Architect's execution of architecting practice for those customers, 3rd parties frequently play a role in the application of EA - including:
- Other ICT providers to the customer
- Customers' customers and suppliers
Effective enterprise Architecting requires the application of an ICT Governance model that is participative and collaborative between a customer and all of their primary providers of ICT Services.
Business and Operational Context
Enterprise Architecture is all about linking information and communications technology with the business, and exploiting the technologies to achieve business goals and objectives. ICT should not be totally reactive and work in isolation from planning and operational activities. Information Technology is now so pervasive that all roles within any organisation have some appreciation of its value, even if they don't understand how it works, or don't understand the difference between ICT management and architecting. ICT professionals, including architects, should be able to become engaged with the business at all levels.
- Governance is the assignment of roles, responsibilities, accountabilities and decision rights. Corporate governance is
"the system by which companies are directed and controlled". Enterprise Architecture, or at least IT management, should be recognised within those
arrangements and should be a participant in the relevant forums. Enterprise Architecture principles should link to enterprise governance and its
principles, given that principles are designed to guide decisions, and governance is about decision rights.
- Standards - including minimum and desired technical standards to be applied, processes and procedures, accreditations and skillsets
- Policies - an organisation's policies applicable to its deployment and use of ICT
- Regulation - government, ICT industry and organisation-specific laws and regulations.
A RACI matrix (Responsible / Accountable / Communicated / Informed) is an ideal tool to capture and communicate the respective involvement of all groups and / or individuals. Good practice assigns only one role / person as the Accountability for any one topic.
The 4 levels of architecture, as the primary domains of the Taxonomy.
The Business Architecture defines the Information Architecture by setting out the business strategies, demographics, functions and processes and the information needed to carry out the functions and processes to achive the goals and objectives.
The Information Architecture influences the Systems Architecture by describing where information is stored, how it is accessed and used, the levels of protection required and the format in which it is required - which shapes Systems types, configurations and features.
Systems Architectures determines Infrastructure Architecture by setting out the necessary interconnectivity between systems to allow for the necessary exchange of, and access to information.
Infrastructure Architecture is comprised of the detailed physical components (hardware, software, networks, Systems tools, artifacts and human factors) of the environment.
The architectures are described at increasing levels of detail as Arcitecture Descriptions - the Views and Viewpoints.
Descriptions, products, artifacts, models, views and veiwpoints.
Anyone with a desire to confuse themselves should explore the various uses of these terms in the many EA frameworks. A reasonable interpretation can be found in "Enterprise Engineering Planning, Foundation of Enterprise Architecture: Overview of DAF Products". For the sake of simplicity, the following interpretations are applied here:
- Architecture Description. As the name implies, the architecture described, individually or collectively, as Views and/or Viewpoints. Architecure Descriptions should include proper version controls and metadata.
- View A representation of an architecture. Architecture Views may be graphical, tabular, textual or any combination of these.
- Viewpoint. The perspective taken - for example, an End User will have a different Viewpoint than a CIO or business manager. In other words, an architecture is represented in a View that is appropriate to the audience's Viewpoint.
- Model. A logical representation of how Views fit together - typically in graphical formats, to illustrate flows and interdependencies. Models should use a consistent modelling language (a whole new world of pain to explore) or style.
- Product. An output from architecture work - including Descriptions, Views and Viewpoints but can include other related material such as schemas, glossaries, ontologies, taxonomies etc.
- Artifact. All Products are artifacts. Not all artifacts are products. An artifact can be external to the architecture work but is referenced by the architecture.
- Catalogue. A collection of like items (Views and Viewpoints should form a catalogue). A catalogue should be a logical, indexed structure that is searchable and where relationships between catalogued items is identifiable.
Architecture Descriptions are set out in accordance with the Architecture Viewpoints.
An architecture catalogue should reside in the Architecture Library - and may in many cases form the entire Library. The Library can include additional products and artifacts which, like any library should be properly indexed and cross-referenced. An Architecture Library and an Architecture Repository are effectively the same thing in most circumstances. Both can consist of softcopy and/or hard copy contents, and may be physical or virtual entities. The use of different terms may apply when there is a need for both - for example a Library being virtual instances of a physical repository, or where an Architecture Repository is one part of a wider Library.
There are useful EA-specific tools available. The Enterprise Architecture Tool Selection Guide from the Institute for Enterprise Architecture Development provides a comprehensive list and assessment guide.
Tools available include:
- Telelogic DOORS;
- ArchiMate; and
Tools for Requirements Management: a Comparison of Telelogic DOORS and the HiVe
Information Networks Division, Defence Science and Technology Organisation, DSTO-GD-0466.
External Influences on the Architecture
A catch-all for any influence external to, and outside of the control of the organisation. regulation is an external influence, but because it has a direct influence on the conduct of an enterprise it has been included under "Business and Operational Context and Governance" in the Framework.
External influences can affect each of the 4 primary Architecture domains. At a Business Architecture level, external influences can be identified from Business Strategies and their treatment of a competitve marketplace, or for government agencies, the interworking with other agencies and shared architecture frameworks, models, architectures and sourcing policies.
Customers, clients, partners and other players that comprise the extended enterprise can also influence an organisation's architecture across all domains.
Other likely influences include:
- Emerging technologies;
- Evolving standards; and
- Service providers and equipment vendors.
Effective planning for external influences can be applied through the development and application of well constructed Architecture Principles, active involvement of EA in Governance forums and the proper treatment of innovation.