|
Wiki Home
Members
To join, please contact us. Improve MIKE 2.0
Need somewhere to start? How about the most wanted pages; or the pages we know need more work; or even the stub that somebody else has started, but hasn't been able to finish. Or create a ticket for any issues you have found.
|
SAFE ArchitectureFrom MIKE2.0 Methodology -> You are here: Technology Backplane > Open Methodology Framework > Data Lineage > Semantic Enterprise Composite Offering > 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. Executive SummaryAny sizeable change in a large organisation is difficult and fraught with risk. It is imperative to reducing 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 a Architecture Framework known as SAFE. Using this architecture helps do the following:
An Architecture for the Federated EnterpriseAs 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 business 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 ApproachThe advantages of the SAFE architecture, implemented through the MIKE2.0 Methodology, include:
In summary, SAFE is an excellent way to get started on a large scale IM project. In an ever-changing landscape of products and vendors, SAFE helps minimize complexity when organizations face some very complicated and nuanced decisions. How SAFE relates to the Complete Enterprise ViewThe 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 MethodologyThe 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 two-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 ArchitectureDuring the Business Blueprint, the parties focus the following:
expressing the possibilities through the Future State Conceptual Architecture 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 mee th needs of the specifc project. Phase 2: The Technology Blueprint Strategic Logical and Physical ArchitectureThe Technology Assessment and Selection phase concentrates on the technical aspects of the Blueprint process. It provides the strategic linkage betwee 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 ArchitectureDuring 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 serverity 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 technlogy 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 PhasesThe 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
Toolbox
Views
Wiki Contributors
|
