From Open Sustainability
Scope of this Content
The FISDev Architecture provides the technology solution framework to support the open-sustainability methodology. The approach of the FISDev Architecture is to drive solutions development through a Conceptual Architecture Framework that is based on the SAFE Architecture Framework from the MIKE2.0 Methodology. This architecture goes across applications, data, and infrastructure and was designed to accommodate the inherent complexities of a highly federated organization. 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 technologies. It is particularly focused around information and infrastructure. The FISDev Architecture provides an overlay on the SAFE Architecture, specifically as it will be applied in the course of implementing the Sustainability Governance Framework in a complex organizational environment.
FISDev uses this 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 Solutions reference aspects of the Architecture as part of the approach to implementation.
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. Using the FISDev Architecture helps align projects to a target vision for the future and help to take the complexity out of the myriad of vendor choices.
Advantages of the Architectural Approach
The advantages of the FISDev architecture include:
- Provides a holistic, integrated approach to architecture
- Part of 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, the FISDev Architecture is an excellent way to get started on a large scale transformation program toward sustainability.
In an ever-changing landscape of products and vendors, the of the architecture is to help take complexity out of some very complex decisions.
How FISDEV relates to the Complete Enterprise View
FISDev applies to the Technology stream of the Complete Enterprise View. The Technology Stream is represented through the Conceptual Architecture. I
Technology Domain for Enterprise Information Management
FISDev Architecture provides a technology solution framework that goes across applications, data, and infrastructure and was designed to accommodate the inherent complexities of a highly federated organisation. FISDev Architecture 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.
In representing the FISDev Architecture, we have tried to avoid what we believe is one of the pitfalls of many of the conceptual architectures we see: 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. We call these Foundation Capabilities. Therefore, we begin the explanation of FISDev Architecture with a description of the Foundation Capabilities for Infrastructure and Information Development. Foundation Capabilities for Infrastructure Development include some of the most common technology capabilities required for implementation projects.
Relationship to the Overall Implementation Guide
There are a number of aspects that make up the approach to Architecture. The Overall Implementation Guide provide the Phases, Activities and Tasks that are used to deliver the overall project lifecycle related to architecture. The FISDev Architecture also provide reusable templates for projects with further detail around specific problems.
The definition and realisation of the Architecture takes places at multiple points throughout the 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 architecture is defined for purposes of specific implementations and ties closely with the specific design and development activities that occur.
Phase 1 - Sustainability Blueprint - Risks and Opportunities
During the Risks and Opportunities Phase, 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 and how it relates to Sustainability 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 - Sustainability Blueprint - Solutions
The Technology Assessment and Selection steps 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 strategic requirements for the solution from a technology capability perspective
- Defines the technology architecture and product direction
- Puts standards and technical infrastructure in place to support the solution 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 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. Relational Data Models refer to off-the-shelf models as well as data modeling tools.
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 - Sustainability Roadmap and Foundation Activities
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 FISDev Architecture can be directly applied to a number of best practice 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 Commercial, off-the-shelf 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 software solutions – e.g. the representation of the Extract, transform, and load (ETL) solution using Informatica.
- 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:
Overview of the Major Components of the SAFE Architecture
Conceptual Architecture for Enterprise Information Management
The FISDev Architecture provides the initial starting for projects and can be iteratively used to select and refine potential vendors. The Conceptual Architecture is expressed through many views, inline with the task outputs from the FISDev Methodology. This model shows a Strategic Conceptual View, that is focused on highlighting Foundation Capability components.
- Foundation Capabilities for Infrastructure Development
- Foundation Capabilities for Sustainable Infrastructure includes platform technologies for hardware and databases, base communications technologies for network infrastructure and the database platform itself. It also includes integration-focused technologies for batch and real-time integration. Many security technologies can be classified as an infrastructure foundation capability, as can the technical operations and monitoring environment. Requirements related to greatly increasing disk space, real-time access to information, improved data security and event-based business analysis all have a significant impact on the Foundation Capabilities that are required for Infrastructure.
- Foundation Capabilities for Information Development
- Foundation Capabilities for Information Development are the basic capabilities required to model, investigate and resolve data issues. Foundation Capabilities for Information Development still involve some fairly new technologies, illustrating the relative emergence of this area. From the perspective of the FISDev methodology, this is the most important technology area.
- Enabling Technologies of the SAFE Architecture
- Enabling Technologies provide advanced capabilities to implement next-generation capabilities along the technology backplane of infrastructure and data. Enabling Technologies include a number of new technologies and are implemented through best practices in Information Management (Information Development).
- Common Services of the SAFE Architecture
- The Services Oriented Architecture (SOA) is enabled by an underlying set of Foundation Capabilities and Enabling Technologies and is critical for enabling next-generation business capabilities in a distributed environment. Implementing a Services Oriented Architecture that is focused on Enterprise Information Integration as well as Enterprise Application Integration requires Enabling Technologies. Enabling Technologies supplement a Services Oriented Architecture by facilitating complex data mediation scenarios, providing active and shared metadata, modelling data in motion and enabling optimisation of business processes and the SOA environment. Services Oriented Architectures have typically been developed more for application integration, and are only now coming to the forefront for data integration. They provide reusable capabilities that are loosely coupled from one another; Web Services are only the most recent form technology that is used to construct Services Oriented Architectures, technologies from the mid 90’s such as DCOM and CORBA were the first generation of technologies that supported these functions.
- Enterprise Business Management
- Enterprise Business Management covers 3 major areas. All these technologies are considered advanced capabilities in the area of Business Management. They are focused respectively across process, information and function but tie together streams of each.
- Enterprise Content Management
- Enterprise Content Management provides a more unified approach for looking at unstructured data. It covers the areas of Collaboration, Document Management, Digital Asset Management and Content Management – all areas that have been revolutionised by the Internet age. As 80% of the data in most enterprises is typically unstructured, it is an area of major importance. Closely integrating the different domains of Enterprise Content Management with one another as well as with more structured forms of data is a solution area that continues to undergo rapid degrees of change and evolution.
- Information Formats
- The flow of information across applications and the Technology Backplane and from sources external to the organisation can take on many forms. These Information Formats are generally grouped into 3 major categories: Structured Information, Semi-Structured Information and Unstructured Information. Whilst modelling techniques for structured information have been around for some time, semi-structured and unstructured information formats are growing in importance due to the growth in web-based technologies. As up to 80% of the information is a typical organization is unstructured, this must be an important area for focus as part of an overall information management strategy. It is an area, however, where the accepted best practices are not nearly as well-defined. Data standards provide an important mechanism for structuring information. The MIKE2 methodology puts a major focus on the use of standards to reduce complexity and improve reusability.
- Information Repositories
- Common or Shared Information Repositories are used to support reporting and analysis across the enterprise. Typically they are populated by hundreds of downstream feeds from the production environments. Most of these downstream feeds have just evolved over time with little documentation to support maintenance. They are a major barrier to the transition from legacy systems to new production environments.
- Reference data and master data can be used to support operational or analytical processes. This information is typically represented across many systems; data mastering rules for how this information is synchronised are critical to ensuring the integrity of the overall information environment. Many organisations have a warehouse environment that is an example of a shared repository of corporate information. It will receive feeds from both private (application) data stored and shared repositories.
- Business Intelligence
- Business Intelligence involves the analysis, presentation and delivery of information to business users. The Business Intelligence environment is greatly enhanced by more advanced Information Management capabilities, which can be used to enable event-based decisions and analysis. Foundation Capabilities are essential for ensuring the quality of information that is presented, ensuring ease of access and the performance of the Business Intelligence layer meets the needs of the user community.
- Enterprise Applications
- Enterprise Applications are typical 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. Enterprise Applications have typically been implemented in silos although there are an increasing number of successful enterprise-wide packages implementations .
- These implementations are usually aligned with the major business pillars of the enterprise. For the most part they are transactional systems and are often the sources for many subsequent downstream feeds for reporting and analytics.
- Composite Applications
- A Composite Application usually does not have persistent data of its own. The application uses information from other application data stores or enterprise platforms. A Composite Application is formulated from services available via the common services layer and is likely to contain its own workflow, which uses a repository of transient information. Composite Applications “pull together” existing assets to deliver a larger, more significant capability and may contain capabilities at the integration layer and from an OLTP application. Their implementation provides a significantly advanced capability.
