Open Framework, Information Management Strategy & Collaborative Governance | Data & Social Methodology - MIKE2.0 Methodology
Wiki Home
Collapse Expand Close

Collapse Expand Close

To join, please contact us.

Improve MIKE 2.0
Collapse Expand Close
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 Architecture

From MIKE2.0 Methodology

Jump to: navigation, search


Scope of this Content

SAFE (Strategic Architecture for the Federated Enterprise) provides the technology solution framework for MIKE2.0. The SAFE_Architecture transcends applications, data, and infrastructure. Moreover, it was designed specifically to accommodate the inherent complexities of a highly federated organisation. SAFE covers a number of capabilities, covering

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 Summary

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: 

  • Align projects to a target vision for the future
  • Help to take the complexity out of the myriad of vendor choices around integration and information management (IM)

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:

  • In a federated enterprise, it is imperative to provide common standards to model "data in motion." In a more centralized organisation, the definitions of attributes in systems are generally more common. As a result, this effort is less (but still) critical.
  • A highly federated enterprise will generally require more complex integration. In a more centralized environment, fewer systems generally require less integration.
  • A federated enterprise will often want to enable more significant business capabilities from its integration layer. This is accomplished via building composite applications. Further, it requires significantly advanced integration focused on ensuring reusability and the building of software at an enterprise level.
  • A federated will typically face more complex challenges in managing information quality across multiple systems.

The key tenets of SAFE are to

  • reduce complexity
  • increase flexibility
  • improve reusability

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:

  • A holistic and integrated approach to infrastructure and IM architecture
  • A particular focus on metadata management throughout the architecture
  • A detailed methodology for product selection, design, and construction
  • The ability to define a standards-based, services-driven architecture
  • An approach that provides capabilities delivered progressively
  • 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 View

The Complete Enterprise View contains different streams (as depicted in the diagram below). They include: 

  • Strategy
  • Process
  • Organisation
  • Technology
  • People

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).

Enterprise views technology.jpg

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 implementation

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:

  • providing initial education with respect to the forthcoming architecture.
  • understanding the vision
  • 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 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:

  • Refining the overall requirements for IM and integration
  • Defining the technology architecture and product direction
  • Putting standards and technical infrastructure in place to support the software development process
  • Defining the overall programme delivery plan. This provides the starting point for the continuous implementation phase

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.

Krutchens model.jpg

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:

  • Conceptual Architecture View: depicts the high level logical software architecture. It provides a common model of the specific services to fulfil explicit and implied requirements. It avoids focusing on how services are delivered by software.
  • Logical Component View: describes the specific logical software components that will deliver the Conceptual Architecture. It provides sufficient detail to realise the solution (whether that solution is based on COTS or bespoke software solutions.)
  • Physical Component View: describes the specific physical software components that will ultimately deliver the Logical View. This view of the architecture shows the use of specific technology products.
  • Process View: describes how scenarios will be delivered by coordination between software components, as well as 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. IT 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 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:

  • the conceptual data model (or at least the key data domains)
  • the Conceptual Architecture for the Technology Backplane

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

Safe conceptual architecture gestault new.jpg

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.

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. These include: access management, single sign on, encryption, etc. Collectively, they 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.
The Collaboration Component provides the techniques and technologies that bring users together, 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 provided by a vendor in the form of packages. They are characterized both 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, 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 provides 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 separation of components 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

Overall metadata architecture gestault.jpg

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.

Metadata Management Foundation Capabilities
Foundation Capabilities for Metadata Management represent the basic capabilities surrounding metadata; they enable the modeling, integration, storing, distribution, and publishing of metadata to support an Information Architecture. To be sure, Metadata Management is a core component that could conceivably stand alone. Best practices suggeste, however, that the management of metadata cross each foundation capability in the Information Architecture. In other words, integration of metadata is paramount. The 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. To ensure maximum success, organizations should assess the fit and applicability of any Enabling Technology as early as possible.
Metadata Services
Metadata Services provide specific services with the goal of building reusable platform-independent metadata capabilities. In turn, these services 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 specifically for the creation and maintenance of metadata. These fall into two groups: custom-built or vendor-supplied. 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. The delivery comes in a form that both is consistent and effective for their specific end user. Unlike Metadata Management Packages, Reporting Packages do not allow the modification of master metadata. However, they can allow for the creation of governance information, including 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 represent the actual storage of metadata. They implement the basic capability of metadata storage. Metadata can be stored in a variety of formats. These include database management systems, file systems, and custom-built interfaces. Each instance has its own benefits. In any case, organizations should protect foundation metadata management capabilities from the details of storage by utilizing a transparency or abstraction layer. This is the fundamental principle of a model-driven architecture. What's more, it 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.
Wiki Contributors
Collapse Expand Close

View more contributors