From MIKE2 Methodology
Scope of this Content
SAFE (Strategic Architecture for the Federated Enterprise) provides the technology solution framework for MIKE2.0. The SAFE Architecture goes across applications, data, and infrastructure and was designed to accommodate the inherent complexities of a highly federated organisation. SAFE covers a number of capabilities, varying from those that are fundamental for the majority of project implementations to advanced capabilities that are only emerging in the area of Enterprise Information Management.
MIKE2.0 uses an architecture-driven approach that moves from a conceptual vision of the architecture to a set of strategic vendor products before moving into a solution architecture and design for each increment. Many of the tasks of the Overall Implementation Guide are architecture-specific, and all MIKE2.0 Solutions reference aspects of the SAFE Architecture as part of their approach to implementation.
Browse the complete inventory of SAFE Architecture assets.
Executive Summary
Any sizeable change in a large organisation is difficult. Reducing complexity and simplifying decisions whilst still accounting for unspecified requirements in the key to a strong and lasting solution design. The approach of the MIKE2.0 Methodology is drive solutions development through a Architecture Framework known as SAFE. Using this architecture helps align projects to a target vision for the future and help to take the complexity out of the myriad of vendor choices around integration and information management.
An Architecture for the Federated Enterprise
It is hard to do Integration and Information Management well, and in a highly federated organisation, you need to do it really well. SAFE was designed to accommodate the inherent complexities of a highly federated organisation, with a number of different business needs and technology systems. Although the framework is equally valid for a more centralisd enterprise, certain aspects of the framework will not be as key:
- In a federated Enterprise common standards to model "data in motion" - is especially important. In a more centralized organisation the definitions of attributes in systems are generally more common, therefore this effort is less (but still) critical.
- A highly federated Enterprise will generally have more complex integration requirements. In a more centralized environment, fewer systems generally result in less integration being required.
- A federated Enterprise will often want to enable more significant business capabilities from its integration layer by building composite applications. This requires a significantly advanced integration environment focused on ensuring reusability and the building of software at an enterprise level.
- A federated Enterprise will typically have more complex challenges in managing information quality across multiple systems.
The key tenets of SAFE are to reduce complexity, increase flexibility, and improve reusability. In a highly federated environment, the principles are become even more important and are a key part of moving to of the MIKE2.0 approach to Information Development and the concept of a Technology Backplane.
Advantages of the SAFE Approach
The advantages of the SAFE architecture, implemented through the MIKE2.0 Methodology, include:
- A holistic, integrated approach to infrastructure and information management architecture
- A particular focus on metadata management throughout the architecture
- A detailed methodology for product selection, design and construction
- Defines a standards-based, services-driven architecture
- Provides an approach that allows capabilities to be delivered progressively
In summary, SAFE is an excellent way to get started on a large scale information management project. In an ever-changing landscape of products and vendors, SAFE helps takes to complexity out of some very complex decisions.
How SAFE relates to the Complete Enterprise View
SAFE applies to the Technology steam of the Complete Enterprise View. The Technology Stream is represented through the Conceptual Architecture. Information Development and Infrastructure Development are the areas of greatest focus; collectively they are referred to as the Technology Backplane. Application Development is also shown in the areas of Composite Applications and BI Application Development (MIS/DSS/EIS systems).
Technology Domain for Enterprise Information Management
SAFE covers a number of capabilities, varying from those that are fundamental for the majority of projects to those that are only required for advanced implementations.
SAFEe tries to avoid a common pitfall of many conceptual architectures: being overly focused on only the new capabilities. Whilst newer technologies typically need to be explained in the greater detail, we believe there is significant value in focusing on the core capabilities that are required for the majority of projects. There are called Foundation Capabilities. Therefore, we begin the explanation of SAFE with a description of the Foundation Capabilities for Infrastructure Development and Foundation Capabilities for Information Development. Foundation Capabilities for Infrastructure Development include some of the most common technology capabilities required for implementation projects.
How SAFE relates to the MIKE2.0 Methodology
The MIKE2.0 methodology is defined through a set of Phases, Activities and Tasks that are used to deliver the overall project lifecycle. The SAFE Architecture provides reusable templates for projects with further detail around specific problems.
The definition and realisation of the SAFE Architecture takes places at multiple points throughout the MIKE2.0 Methodology and is a 2-phased approach that is aligned most closely for a vendor selection and implementation process across a large organisation. It can be, however, by applied for any organisation of any size.
During the Blueprint (Phase 1 and Phase 2), the Architecture is initially defined at a conceptual level before finally getting to the point where products can be selected. In the continuous implementation phases (Phases 3,4 & 5) the MIKE2.0 architecture is defined for purposes of specific implementations and ties closely with the specific design and development activities that occur.
Phase 1: The Business Blueprint Strategic Conceptual Architecture
During the Business Blueprint, the architecture focus is on providing initial education and then understanding the vision before finally expressing the possibilities through the Future State Conceptual Architecture. The initial activities of the project are meant to familiarise the team with general concepts in Enterprise Information Management. Through the Maturity Assessments and High Level Requirements, an early understanding of what capabilities must be provided by the architecture are understood. Along with the Conceptual Architecture, some early high level solution architecture design patterns are introduced to help the team gain an understanding of the implementation approach. In both cases, starter sets of core materials are used and then customized specifically for the project.
Phase 2: The Technology Blueprint Strategic Logical and Physical Architecture
The Technology Assessment and Selection phase concentrates on the technical aspects of the Blueprint process; it strategically ties the business-oriented information management solution developed in phase 1 to a supporting logical and physical architecture in phase 2. In particular, Phase 2:
- Refines the overall requirements for information management and integration
- Defines the technology architecture and product direction
- Puts standards and technical infrastructure in place to support the software development process
- Defines the overall programme delivery plan that provides the starting point for the continuous implementation phase
There will likely be multiple products to be selection across the Technology Backplane for the program. Some of the most important will be what are called Foundation Capabilities for Information Development. These capabilities are fundamental to the management of data standards, migration, transformation and quality across environments. The toolset which provides these capabilities is typically not a single product from a particular vendor, rather a number of products (including some vendor suites) which provide the capabilities.
These capabilities form the basis of a data mediation platform(s) which is the critical component of the Technology Backplane Architecture. The capabilities may be invoked by events or scheduling. They support batch, single record or object data management requirements. The toolset also addresses the capabilities required to manage the end to end metadata environment.
There capabilities typically align to a total of 3 – 5 products depending on vendor (i.e. some vendors combine multiple capabilities within a single product). Some vendors provide products to cover multiple areas.
Although the project is scope is typically narrower, it may be make sense to consider at least some degree of the overall enterprise requirements for such as significant product selection exercise.
Phase 3: Solution Architecture
It is during the Roadmap that the detail for an implementation cycle is first defined. Requirements are conducted for the first time at a level for actual software implementation, and the Solution Architecture is one of the key deliverables of the overall release. This Solution Architecture may guide the overall implementation program or there may multiple distinct Solution Architectures. It is important, however, that the Solution Architecture deliverables can be explicitly linked together if they are separate documents.
The Roadmap is complemented by what are called Foundation Activities – these are focused on ensuring that the environment is ready, taking a detailed look at the data and, in some cases, addressing Data Quality issues. A set of high level architecture patterns that provide an overview of how the Foundation Activities will work are also defined during this stage. These may be first introduced at a high level during the Blueprint.
Krutchen's 4 + 1 View of Architecture
The SAFE framework can be directly applied to a number of best practice architecture models for defining architecture aspects such as the Enterprise Architecture or Solution Architecture. One such model for Solution Architecture is Krutchen’s 4+1 View of Architecture. This architecture model is suggested as part of the Rational Unified Process (RUP) as an approach for providing a holistic picture of software architecture. Whether or not a project applies RUP, Krutchen’s model provides a good model for Solution Architecture.
For implementing solutions using the Blueprint/Roadmap approach, Krutchen’s model has been adapted to suit an approach focused on the procurements of technologies, starting with a conceptual architecture approach. Many of the technologies across the Technology Backplane will not be custom-built, so having a Blueprint model that purposely designed for product selection has shown to be the best approach. Krutchen’s model views the architecture from different perspectives, each of which expresses particular aspects of the solution’s character:
- Conceptual Architecture View: This view depicts the high level logical software architecture. It provides a common model of what services are provided to fulfil explicit and implied requirements of scenarios. It avoids focusing on how services are delivered by software.
- Logical Component View: This view describes that specific logical software components that will deliver the Conceptual Architecture in sufficient detail to realise the solution in terms of COTS or bespoke software solutions.
- Physical Component View: describes what specific physical software components will deliver the Logical View. This view of the architecture would show the use of specific technology products.
- Process View: describes how scenarios will be delivered by co-ordination between software components, and by interaction with external actors
- Implementation View: describes non-functional considerations relating to the implementation and distribution of the Component View on physical hardware and data communication networks. The Implementation View also considers implementation issues relating to areas such as security.
In addition, Use Cases (sometimes called Scenarios) are employed to provide a unifying business view across the architecture. This approach is used to iteratively and incrementally develop the architecture, considering each view in turn. The first 3 views are defined during the Blueprint but will be refined to greater detail during the Solution Architecture.
Key Architecture Tasks Across the 3 Phases
The Future-State Conceptual Architecture maps in the capabilities that are envisaged to be required in the future-state environment.
The Conceptual Architecture is at a very high-level and is presented in a form that can be easily understood by management staff with some technology background. It is only to present what “could be” based on the information gathered during the QuickScan assessments in the first phase of the Blueprint and will go through multiple series of revisions. The Conceptual Architecture includes the conceptual data model (or at least the key data domains) as well as the Conceptual Architecture for the Technology Backplane.
The key remember about the Conceptual Architecture is that it is a starting point to understand the possibilities. Some of the key tasks include:
Future activities may include revision the architecture and progressing to lower levels of technical detail as needed.
Overview of the Major Components of the SAFE Architecture
Conceptual Architecture for Enterprise Information Management
The SAFE Conceptual Architecture provides the initial starting for projects and can be iteratively used to select and refine potential vendors. Clicking on each of the sections below provides further detail on the SAFE Architecture. The description of the Application Domain is generalized for any application within the SAFE Framework. The Conceptual Architecture is expressed through many views, inline with the task outputs from the MIKE2.0 Methodology. This model shows a Strategic Conceptual View.
- Presentation Layer
- The Presentation Component defines how the site appears to the customer visually, either in a standard form of through their own personalised configuration and means of access.
- Information Security
- Information Security Component covers the key aspects of security - access management, single sign on , encryption, etc, that are required to ensure end-to-end information security.
- Customer Information Management
- The Customer (User) Information Management Component provides users with the ability to manage their own information - particularly within the Internet Channel.
- Collaboration
- The Collaboration Component provides the techniques and technologies that brings together users, enable dynamic content generation and provide a conversational experience through technology-based communication.
- Enterprise Applications
- The Enterprise Applications Component is comprised of OLTP Applications – either custom-built by the enterprise or packages provided by a vendor. They are characterized by a set of functions and their own private or proprietary databases for persistent data.
- Composite Applications
- The Composite Applications Component provides next-generation capabilities formulated from services available via the common services layer. A Composite Application usually does not have persistent data of its own.
- Business Intelligence
- The Business Intelligence Component involves the analysis, presentation and delivery of information to business users.
- Foundation Capabilities for Infrastructure Development
- Foundation Capabilities for Infrastructure Development Component includes platform technologies for hardware and databases, base communications technologies for network infrastructure and the database platform itself, security and integration.
- Foundation Capabilities for Information Development
- Foundation Capabilities for Information Development Component provides the basic capabilities required to model, investigate and resolve data issues.
- Enabling Technologies of the SAFE Architecture
- The Enabling Technologies Component provide advanced capabilities to implement next-generation capabilities along the Technology Backplane of infrastructure and information.
- Common Services of the SAFE Architecture
- The Services Oriented Architecture (SOA) Component provides the capabilities to support reuse, integration and componentisation across the federated environment.
- Enterprise Business Management
- The Enterprise Business Management Component covers process management, optimisation, rule management and process generation based on information events.
- Enterprise Content Management
- Enterprise Content Management Component provides a more unified approach for looking at unstructured data. It covers the areas of Collaboration, Document Management, Digital Asset Management and Content Management.
- Information Formats
- The Information Formats Component describes the types of information supported across the architecture.
- Information Repositories
- Common or Shared Information Repository Components are used to support reporting and analysis across the enterprise.
Metadata Management Architecture
Conceptual Architecture for Metadata Management
Metadata is distributed in technologies across the Application, Infrastructure and Information Development environment of the SAFE Architecture. The Metadata Management foundation capability and Active Metadata Integration for Information Development can be broken out into a specialised conceptual architecture for Metadata Management. Within the context of Information Development there are core level capabilities and Enabling Technologies that aid in the development of the Metadata Management component in the overall Information Architecture.
As all components of the SAFE architecture contain metadata, this section show the conceptual architecture within that specific context.
- Metadata Management Foundation Capabilities
- Foundation Capabilities for Metadata Management are the basic capabilities required to model, integrate, store, distribute and publish metadata to support an Information Architecture. While Metadata Management is a core component that could stand alone, management of metadata crosses each foundation capability in the Information Architecture. Metadata Management foundation capabilities provide functions to other foundational components and upward to support metadata Enabling Technology services.
- Metadata Management Enabling Technologies
- Enabling Technologies provide advanced capabilities to implement next-generation functionality along the Technology Backplane of metadata management. Enabling Technologies are not mandatory, but complement metadata Foundation Core capabilities by providing standards and pre-packaged abstraction layers to simplify implementation and deployment of Metadata Services. Enabling technologies provide implementation frameworks or approaches for foundation capabilities and often integrate foundation capabilities into a common interface. There are many standards and enabling technologies available and emerging in the industry. The fit and applicability of any Enabling Technology must be assessed.
- Metadata Services
- Metadata Services provide fine and coarse grained services to build reusable platform independent metadata capabilities to drive a Model Driven Architecture. Metadata Services are enabled by the Foundation Capabilities and Enabling Technologies for metadata that have emerged from standards bodies such as the Object Management Group (OMG), the Java Community, Vendors and other standards groups.
- Metadata Management Packages
- Metadata Management Packages are applications – either custom built or vendor supplied - specifically for the creation and maintenance of metadata. Historically, metadata management applications have been distributed and disconnected with redundant and inconsistent metadata defined across the organisation. Management Packages can be aligned in conjunction with Metadata Services model to increase reuse and consistency. Vendor supplied application metadata stores are integrated through Enabling Technologies and Foundation Capabilities to facilitate synchronisation and metadata ownership.
- Metadata Reporting Packages
- Metadata Reporting involves the delivery of metadata to information consumers and developers in a form that is consistent and effective for their specific end use. Unlike Metadata Management Packages, Reporting Packages do not allow the modification of master metadata, but can allow creation of governance information such as annotations and change requests. Metadata Reporting can take either GUI or non-GUI form depending on the required presentation format. Metadata Reporting requirements are key business drivers for the Information Development.
- Metadata Repositories
- Metadata Repositories are the physical persistence of metadata and implement the basic capability of metadata storage. Metadata can be persisted in a variety of formats including database management systems, file systems and a programmatic interfaces. Each implementation will have its benefits, but the foundation metadata management capabilities should be protected from the details of storage by a transparency or abstraction layer. This is the fundamental principle of a model driven architecture and allows metadata to be viewed by components and users in a platform independent manner.
Potential Changes to this Foundational Solution Offering
- Each component should be broken onto a separate page to allow for easier linking. Component content should be more detailed than currently on the site to better explain each of the components.
BlogMarks
del.icio.us
digg
Furl
Simpy
smarking
