High Level Design

Balaji BandiCISCO, GNS, JUNIPER, LINUX, SECURITY, Uncategorized, VMWARE

This is the document that sets out the Conceptual and Logical views of the solution. The purpose is not only to describe the solution, but to show at a high level how the solution fits together and how it fits within your organisation. The organisational fit can be overlooked when people focus too much on the technology, particularly new technologies. It is also important to set out how the business will support a new solution e.g. are new skills and additional training required, to ensure the operational cost is appropriate.

As with other architectural documentation I will use parts of the TOGAF phases as I believe these are most appropriate for this type of document. The parts I use for a High Level Design are Business, Data, Application, and Technology. However the High Level Design will cover more than just these TOGAF phases.

Conceptual and Logical Views

The High Level Design sits at the Conceptual and the Logical levels of abstraction for a project. The diagrams and descriptions should focus at this level. The separation can be confusing to new architects. The simple rule I apply is that at the Conceptual level you do not have servers etc., but have objects which are familiar to the business people, such as buildings, people etc. At the Logical level you will have servers, workstations by their role, but do not show the multiples that are to be deployed to provide high availability.

To demonstrate this we will use a fictional new financial management solution for a business e.g. SAP or Oracle Financials, which is to have the safeguard of a standby site. The solution will have users at several sites performing different roles and accessing different types of backend system at a primary site. The standby site will provide disaster recovery capability and business continuance in the event of a serous outage or loss of service at the primary site.

The Conceptual view of this will show the locations for the people and both data centres, with explanation of what is performed at each. This will include the main roles performed by the users at the office locations. The Logical view will show the types of components to be used and the main technologies to be applied at these locations. Not simply Oracle or SAP but which parts of the products to provide which roles, e.g. General Ledger, Asset Management, Accounts Receivable, Reporting, etc. For the user workstations these are shown by the type of role they perform (Sales and Distribution, Financial Management, etc.) and grouped to indicate the different node types. The node type indicates that different software or hardware may be required. For example an Office Workstation may be the standard PC used within the business and capable of being used for a wide variety of the roles (S&D, FM, etc.). Additional special node types can be the Analysis workstation, Upload workstation, and BACS workstation that require additional software or hardware. If virtualisation technology is used the workstation nodes still apply as these indicate the different packaged builds for that type of role.

High Level Design Content

The High Level Design audience is both Technical and Business. This can be difficult as the business may not understand all of the technical aspects. However it is necessary to show that the main drivers and objectives have been addressed, and convey this in language that the business understands. It is also important to state early in the document were the solution is proposing a change of direct for the business, such as a move to a managed service or the use of a cloud service.

Some of the sub sections may not be appropriate for a particular solution. However I recommend that the heading remains and that a statement is made on why the section does not apply to that particular solution. This ensures that the overall content template does not reduce over time. Architects will use previous High Level Designs as a guide to the type of content to include.

  • Introduction– The Introduction section sets out the broad boundaries of the solution at the Conceptual level of granularity. It is made up of the following sub sections:
    • Overview – The Overview section sets out a general description of the solution, the main functionality to be provided, and the timeline for implementation. Where the design approach is different to other solutions for the business this is also set out in the overview. This reaffirms to the business and the stakeholders that you have understood what the aims are and provides a business context for the technical audience;
    • Requirements – The requirements section should only list the few main requirements for the solution. These will include business requirements and any performance and volumes requirements that are key to the solution;
    • Constraints – Most solutions are constrained in some way. This is a bullet list of the main constraints of the solution. These will include both business constraints and technical constraints. However they can also include legal and standards constraints;
    • Assumptions – The solution will be based around a number of assumptions, such as the expected peak numbers of users, required level of availability, data growth requirements, access devices. This section provides a bulleted list of the main assumptions used for the solution;
    • Risks – The project will operate a risk register for project risk and mitigation action. However the solution may use components that are new or new to the organisation. This section lists the solution risks. One of the optional items to add could be a sizing risk where the size modelling has been problematic. This type of risk is often seen for new solutions where the expected level of take up can vary over a wide range;
    • Key Drivers –The drivers section includes both the key business and the technology drivers. The business drivers can include economic factors as well as changes within the business. The technology drivers will include new types of product, e.g. virtualisation, cloud opportunities, smartphone and tablet devices;
    • Principles – What are the principles on which the solution is based? These will cover general principles such as the early adoption of promising technologies. However they must cover the Business, Data, Security and Technology principles.

 

  • Architectural View– This section provides the Logical level and sets out two main operating models; the Current Operating Model (COM), and the Target Operating Model (TOM). These are described along with several other sub sections on specific solutions architecture aspects:
    • Current Operating Model – The COM provides the current or As-Is view. In some instances there is no existing COM as this is a new idea for the business. However the COM section can cover how the concept is achieved currently elsewhere or the current alternatives;
    • Target Operating Model – The TOM is the To-Be view, or the position at delivery of the solution. Where a solution is delivered in phases over a long period of time, it is appropriate to show the TOM for each phase. This provides the business with an understanding of the limitations and opportunities of the interim solution and the complete solution;
    • Analysis – This section will provide a summary of the analysis work used to arrive at the sizing. Areas with a high volume need a separate metrics model which I will cover in a future article. This summary should include any profile of activity over the day, week, or month to show expected peaks and lows. For example end of month invoice volumes. It should also cover the breakdown of the types of things so that the mix is understood. Again this could be expenses for employees, invoices for customers, payments to suppliers. This allows variation for handling to be fully assessed in the solution and peak load activity such as end of year to be quantified. Very high end of year volumes may needs additional resources to be added for a few weeks, or a reduction of service to some less critical business functions. These need to be designed in from the outset to achieve the best fit and agreement from the organisation;
    • Availability – The Availability section sets out the methods to be used in the solution to provide the level of uptime the business require. This will include a bulleted statement on the main small component considerations such as resilience from a failure of a server, network switch, user workstation, up to network circuit and data centre loss through UPS or environmental failure. The detail is part of the Detail Design, this section provides the main methods used in the solution to provide the required availability safeguards;
    • Security – Most solutions have a need to enforce security. This section will use the security principles identified in the earlier part of the High Level Design to describe how these are to be enforced. This can include reference to specific technologies used for end users and interfacing systems, such as end to end encryption using SSL. However it will also cover support security controls, such as disabling accounts for support staff that leave or change role within the organisation;
    • Scalability – The popularity of a service cannot always be determined accurately. Some solutions begin with a reduced size solution and invest in additional resources when the demand growth is proven. With commodity hardware it is possible to add more servers (horizontally scale) or to replace the existing servers with more powerful servers (vertical scale). Vertical scaling can offer a better return on licensing as the number of cores used remains lower, but is usually more disruptive. This section addresses the option as part of the whole life solution. It ensures that when the solution does need to scale up (or down if it begins with an initial registration peak) is has been addressed as part of the solution and not added later;
    • Portability – The portability of a solution can be considered for technology options. This is used to identify lock in to proprietary technologies that may not develop as the organisation expect. However I also use this section to cover how the data for the solution is migrated at the end of life of the hardware and the software. This allows mechanisms to be built in at the outset that make the migration easier;
    • Reporting – Most solutions have some reporting requirement. Even where the business is not looking to provide a range of classic reports, there will be reporting of usage such as web analysis. This section is also used to set out how this information is made available to business. If there is an existing reporting service in the business, how will that access this new data to avoid the business ending up with multiple reporting solutions;
    • Solution Administration – The administration section is aimed at the business administration of the solution not the support administration. Many solutions now have support of the key information by business areas. IT Support will look after the health of database, but a business area may be required to edit or correct invoice or payment details. Separating the administration of the business information from the IT support needs to be designed into the solution so that the appropriate roles and controls are in place.

 

  • Business Processes – Following on from the Architectural View that shows the Current and the Target Operating Models, it is important to understand the business process changes. Not all solutions introduce new business processes or change the existing processes, however where they do the business need to agree these. The section is not intended to provide the low level detail of the business processes. However it should provide the main process categories (or service), the steps in the process, and the role that carries out each step. For example this could be the Create a Supplier Service that includes processes within the solution and outside, such as the Dun & Bradstreet or similar credit checks. This helps to identify roles to be catered for in the solution design and what authority is required. I find this section helps the business understand what the solution will mean to them. It gives an opportunity for early feedback on whether the level of responsibility is appropriate;
  • Deployment View– The Deployment View in the High Level Design is focussed on the key aspects of the solution at the Logical level. This section is expanded in the Detail Design with the physical layout and component specification. Within the High Level design this describes what each of the components provides to the overall solutions. This is divided into the sub sections:
    • Business – The Business section describes each business role within the solution. However it also covers any location changes i.e. more of fewer sites, and any organisational changes, such as a restructuring of sections or departments. The organisational and location changes can have a significant impact on the project timescales and may require specialist change management. Where these are identified late in the project life they can introduce delays or result in the organisation being unprepared;
    • Data – The data section will use the outcome from the analysis to determine data volumes. However where the data cannot be held indefinitely or is to be moved to a lower tier of storage, the process to delete or archive needs to be identified. Some solutions leave the delete activity until required i.e. 4½ years in on the deletion of 5 year old data. However this produces considerable risk as the DBA’s assigned the role are not as close to the fundamentals of the design as the original designers. The detail decisions, such as what to do with old reference data, are part of the Detailed Design. However the rationale for leaving this to later must be covered in this section of the High Level Design. This section also covers the data interface where the solution is to interface with other systems;
    • Application – The application section is used to describe the capabilities that are being provided in the solution, such as General Ledger or BACS Payment. This is not the specific product features, which are covered in the Technology section. The business will use this section to help identify where some expected capabilities are missing or incomplete. This will ensure that any initial deficiencies in the solution are identified and resolved early;
    • Technology – Technology is more than the servers, networks and workstations as it also includes the software products and choice of operating systems.  Within this section I sub group these under the headings Application Software, Operating Systems, Networks, Servers, Workstations, and Peripherals. Describing within each group what is to be used and the role it performs in the solution. It is also worth listing where the component is new to the organisation. Solutions which also need development and test environments have smaller sub sections setting out each of the other environments e.g. Development, Test, and Pre-Production. For the other environments it is important to explain what it is used for and the limitation of the environment. It is particularly important to recognise that IT Support also needs access to environments for trialling patch and service pack deployments. In a solution developed by in-house teams, with a split between infrastructure component and application component development. There is often a need for separate development environments. In ensuring that all environments are covered in the design the full cost to the business will be understood;
  • Support – The support section provides the IT support elements off the solution at a high level. For mature organisations this will build of current support and monitoring practises. However these practises need to be listed so there is a clear statement of what is required.  This will highlight where the solution will require training for existing support staff, and whether an increase in support numbers is required. If the solution introduces a need for a change in the support model from a daytime Monday to Friday support to 7 days, or even a 24 hours support model, it is set out here. The support section also needs to address the expected timeline for adoption by the support team (to allow for training and knowledge transfer), and whether initial support is shared with the development team in the early months.