Architecture and Design Workstream
The Solution Architect defines the overall end-to-end solution and is the most senior design role for the project. This is a high level, macro design and it defines the requirements of the components of the solution without necessarily defining how those components will be delivered. The “how” is defined by the remaining architecture team. Working with the Business Representative high level requirements are defined in order to provide an overall capability and scope for the solution. For example, “provide enterprise wide reporting and analysis for 5,000 users distributed globally with an operational uptime of 99.999%”.
The architect works with the organisation’s enterprise architecture group to make sure that the proposed architecture conforms to the principles and guidelines of organisation’s enterprise architecture. A key responsibility is to define the high level guiding principles of the solution. These guiding principles are used to offer a framework for the solution that ensures consistency across all technology stacks so that they interoperate. For example, data should be pushed to the data warehouse rather than pulled from source systems, the user base is international and so Unicode is the standard character set.
The Solution Architect works with the project manager to estimate the cost of the project, to produce the project plan and identify resource requirements for the project team and has a good understanding of the delivery method of a BI project. The Solution Architect may also define the long term strategy and road map for Business Intelligence within an organisation that aligns with the organisations overall business strategy.
The main deliverable is the Solution Architecture Document which defines,
- the main components of the BI solution,
- an overview of the software and technology used
- strategies and guiding principles for analytics, data integration, data management
- systems management strategy including configuration management, quality management, backup and restore, security, deployment and operations
The Solution Architect is required to validate the functional requirements from the Business Analysts to make sure that what is being requested is in scope and can be delivered. Deliverables from the Technical Architect, Data Integration Architect, Information Architect and Analytics Architect are approved by the Solution Architect.
- Solution Architecture Document
Technical Architect or Infrastructure Architect
The Technical Architect is responsible for defining the architecture for all technical aspects of the solution involving hardware, software, networks and storage. This includes defining the physical infrastructure, network architecture and deployment architecture.
Technical Architects typically conduct a sizing exercise to determine how much infrastructure is required to support the solution including hardware, storage and network usage. They define the required versions of software to use and ensure compatibility across the different products. They would also define the backup and recovery strategy, system resilience and failover design. This is captured in the Technical Architecture Document.
A second deliverable is the Infrastructure Deployment Guide which fully describes the steps required to build the system. In some cases this is written by the System Operations Team if they themselves are responsible for the deployment.
- Technical Architecture Document
- Deployment Guide
Data Integration Architect
The Data Integration Architect is responsible for the design of the data integration layer of the solution. Typically, they are an expert in the chosen data integration technology and through experience has a good understanding of what is achievable and what is not. The DI architect defines practices, standards and methods to be used by the DI development team and this is documented in the Data Integration Standards Guide. This includes topics such as naming standards, design patterns for common integration processing, use of bulk loading technologies, error management and failover process.
The DI architect also defines the DI operating framework which is the standard template structure that all ETL process must follow, such as, how the data integration processes will log records processed, process duration and error management. This is documented in the Data Integration Framework Document.
The DI Architect works closely with the data modeller to understand the data structures required to be populated and with the Business Analyst and Source System SMEs to understand the business processes and source data.
The DI architect approves the technical specs produced by the Data Integration Development team.
- Data Integration Framework Document
- Data Integration Standards Guide
The Information Architect is responsible for the design of the data structures and data layers that make up the data warehouse. This role is at the centre of the BI project and the Information Architect is required to work closely with many other project members. Working with the Business Analyst the Information Architect defines the subject areas that form the solution’s data model and a key aspect is to identify the entities that are common to two or more subject areas. This is documented in the High Level or Conceptual Data Model.
The Information Architect works with the data integration architect to understand the data structures required by the data integration processes. Similarly working with the Analytics Architect they identify the data marts that will be required by the solution.
The Information Architect works with the Technical Architect to produce estimates for the sizing of the data warehouse. The Information Architect defines the standards for data modelling in the Data Modelling Standards Guide; this includes content such as naming conventions for schemas, columns, abstract data types and standards for common data structures.
- High Level Data Model
- Data Modelling Standards Guide
The analytics architect is responsible for the architecture and design of reporting and analytical layer. The analytics architect works with the Business Analyst to understand the solution requirements, to select suitable solutions and propose new solutions. Understanding requirements is not a case of documenting everything the user asks for but is more of a dialog between the analyst and the architect to design a suitable solution that addresses the business problem. For example, consider the following conversation,
“I need a report that lists all my clients and their current balance and payment type”.
Although this seems simple enough a good analytics architect would dig deeper to find out why this report is required:
“What do you need the report for?”
“I need it to understand which customers owe us the most amount of money that aren’t using an automatic payment method so I can chase them up”.
And then propose a better solution:
“What about a dashboard that shows the top 10 customers by outstanding debt that aren’t using an automatic payment method and that shows history of late payment so that you can focus on the ones who are always late”
At all times scope must be focussed on delivering the business case.
The architect also produces the Analytics Standard Document which defines the standards and methods to use when developing the analytical components of the solution. For a SAP Business Objects project this would include standards around which product to use in a given scenario, for example, Crystal Reports for operational reporting, Web Intelligence for ad hoc analysis. The standards document would also cover universe development, for example, when to use contexts instead of views, object naming conventions, standard hierarchies and finally it covers report design including standard look and feel.
Another deliverable of the Analytics Architect is to define the security model that governs and controls user access to the system functionality and the data. Some data maybe sensitive and should not be made available to all users. This model is developed with the Business Analyst who would discuss security requirements with the business community. If this security model is complex, it should be documented in the Access Layer Security Model.
The Analytics Architect is expected to be an expert in the chose BI technology and so would work with the Technical Architect to assist with the deployment and configuration of the system and the server sizing exercise.
- Analytics Standard Document
- Access Layer Security Model