From MIKE2.0 Methodology
-> You are here: SAFE Architecture
Scope of this Content
MIKE2.0 uses an architecture-driven approach. Doing so allows one to move easily from a conceptual vision of the architecture to a set of strategic vendor products. All of this is accomplished 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.
Any sizeable change in a large organisation is difficult and fraught with risk. It is imperative to reduce complexity and simplify decisions to the extent possible. At the same time, one must still account for unspecified requirements. Keeping all of these balls in the air is the key to a strong and lasting solution design. The approach of the MIKE2.0 Methodology is to drive solutions' development through an Architecture Framework known as SAFE. Using this architecture helps do the following:
An Architecture for the Federated Enterprise
As any seasoned practitioner will tell you, it is hard to do Integration and IM well. 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 needs, technologies, and systems. Although the framework is equally valid for a more centralisd enterprise, certain aspects of the framework do not require the same emphasis:
The key tenets of SAFE are to
In a highly federated environment, the principles become even more important. They 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:
How SAFE relates to the Complete Enterprise View
The Complete Enterprise View contains different streams (as depicted in the diagram below). They include:
SAFE applies to the Technology Stream of 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).
SAFE covers a number of capabilities, varying from:
SAFE 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 that there is significant value in focusing on the core capabilities required for the vast majority of projects. These are called Foundation Capabilities. 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. Collectively, they allow for the management of the overall project lifecycle. The SAFE Architecture provides reusable templates for projects and provides detail regarding specific problems.
The definition and realisation of the SAFE Architecture takes places at multiple points throughout the MIKE2.0 Methodology. It is a three-phased approach with specific appliations for vendor selection and implementation across large organisations. However, an organization of any size can apply it. The three phases are listed below:
During the Blueprint phases (1 and 2), the organisation lays the groundwork for the forthcoming system architecture. At this point, the focus is more conceptual. By design, this is performed before finally selecting products. In the continuous implementation phases (3, 4, and 5), the MIKE2.0 architecture is refined to meet the needs and objectives of specific implementations. At this point, key parties need to participate in specific design and development activities.
Phase 1: The Business Blueprint Strategic Conceptual Architecture
During the Business Blueprint, the parties focus the following:
The initial activities of the project familiarise the team with the general concepts in Enterprise Information Management. Through the Maturity Assessments and High Level Requirements, the team garners an understanding of the required capabilities provided by the architecture. Along with the Conceptual Architecture, the team introduces some early high level solution architecture design patterns. This reinforces the team's understanding of the implementation approach. In both cases, key parties use starter sets of core materials; these are then customized specifically to meet the needs of the specific 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 provides the strategic linkage between the first two phases. Ultimately, the business-oriented IM solution developed in the first phase is tied to the supporting logical and physical architecture developed in Phase 2. Specific tasks of Phase 2 inlcude:
There will likely be multiple products selected 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 providing these capabilities is typically not a single product from a particular vendor. Rather, a number of different products (including some vendor suites) provide the capabilities.
These capabilities form the basis of a data mediation platform--or, possibly, multiple platforms. This is the critical component of the Technology Backplane Architecture. The capabilities may be driven by events or scheduling. Ultimately, they need to meet an organization's 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 result in a total of three to five products, depending on vendor. Note that some vendors combine multiple capabilities within a single product. Some vendors provide products to cover multiple areas. There is no one "right" number of products.
To be sure, the scopes of these projects are narrower than enterprise-wide implementations. At the same time, though, it may be make sense for an organization to consider at least some of its overall requirements while selecting "right" products.
Phase 3: Solution Architecture
During the Roadmap, the organization first defines specific details for an implementation cycle. Key constituents generate requirements for the first time at a level for actual software implementation. The Solution Architecture is one of the key deliverables of the overall release and, to this end, it may serve as a guide to the overall implementation program. Ultimately, the organization may be left with multiple and distinct Solution Architectures. In this event, it is essential that the Solution Architecture deliverables are explicitly linked together. Separate documents should be avoided.
The Roadmap is complemented by what are called Foundation Activities – these are focused on ensuring that the environment is ready. They should take a detailed look at the data and, in some cases, address Data Quality (DQ) issues--depending on the severity of the issues discovered. Also required at this stage is a set of high-level architecture patterns. These are essential because they provide an overview of how the Foundation Activities will actually work. These may be first introduced at a high level during the Blueprint.
The SAFE framework can be directly applied to a number of best practice architecture models. This allows for the relatively straightforward task of defining architecture aspects, possibly including 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 solid model for Solution Architecture.
For implementing solutions using the Blueprint/Roadmap approach, Krutchen’s model has been adapted to suit an approach focused on technology procurement, starting with a conceptual architecture approach. Many of the technologies across the Technology Backplane will not be custom-built. As a result, having a Blueprint model purposely designed for product selection tends 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:
In addition, Use Cases (sometimes called Scenarios) are employed to provide a unifying business view across the architecture. This approach is used to iteratively develop the architecture, considering each view in turn. The first three views are defined during the Blueprint but will be refined to greater detail during the Solution Architecture.
Key Architecture Tasks Across the Three Phases
The Future-State Conceptual Architecture lists the capabilities required in the future-state environment.
The Conceptual Architecture is displayed at a very high-level; it is presented in a form easily understood by management who have some background in technology. It merely endeavors to present what “could be” based on the information gathered during the QuickScan assessments in the first phase of the Blueprint. What's more, it will see multiple series of revisions over the course of the project. The Conceptual Architecture includes the following:
It is critical to remember that Conceptual Architecture 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
The SAFE Conceptual Architecture provides the initial starting for projects and can be used iteratively 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 the many views defined within the MIKE2.0 Methodology. This model shows a Strategic Conceptual View.
Metadata Management Architecture
Metadata is distributed 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, core level capabilities and enabling technologies aid the development of the Metadata Management component in the overall Information Architecture.
Note that all components of the SAFE architecture contain metadata. As such, this section shows the conceptual architecture within that specific context.
Potential Changes to this Foundational Solution Offering
Wiki asset search