Architecture and Diagrams
The Best practice IT Standard is:
An architecture team that owns data, infrastructure and applications architectures supported by architecture guidelines and a technical architecture catalogue. A technical architecture catalogue is essential; it helps with products standardisation, reduces product redundancy, sets product strategy and guides purchasing decisions. Architecture principles are also required.
Not every IT department has an architecture function, although at minimum IT architecture works on a set of principles that guide the use and deployment of all IT resources and assets across the company. They are developed to make the IT environment as productive and cost-effective as possible. The principles are used in several different ways.
To provide a framework within which the company can start to make conscious decisions about IT.
Formulation of hardware and software evaluation criteria.
Assessment of existing IT Systems and future strategic product mix.
Cost Savings from deploying standardised, integrated hardware and software.
When an architecture function is absent, the lack of corporate data models and applications architecture constrains ITs ability to support the business decision making process adequately. IT becomes focused on responding to tactical business requirements creating a discontinuity between business and technical strategy.
There are three types of IT architectures and guidelines
1. Application. Applications guidelines and catalogue.
2. Technical. Hardware, Server, Desktop and Systems software guidelines.
3. Data. Database Tables, Records, Fields, Naming definitions/dictionary.
Performance Assessment
1. Is there an architecture function or team?
2. Are there technical architecture diagrams in place?
3. Are there applications architecture diagrams in place?
4. Are there data architecture diagrams in place?
5. Is there a technical products catalogue in place?
6. Who does the architecture manager report to?
7. How is work gated through architecture for approval?
8. How is architecture integrated with team processes?
9. Are technical specifications documented? (These should define IT hardware configurations, systems and applications software configurations and supporting network configurations.
10. Is the overall technical architecture of a solution matched with the defined requirements?
11. Are projects supported with an end-to-end design study, to cover areas such as performance, recovery, disaster recovery and operability?
12. Are project technical risks assessed?
Sample Tasklist
1. Document technical procedures for systems backup and recovery.
2. Establish an Architecture function.
3. Review IT management team composition to add an Architecture Manager.
4. Include a process to technically assure subcontractors’ development and test environments.
5. Define and implement a means of performance prediction and performance management for new systems.
6. Determine further works required and scope out.
7. Break down the scope of work to the task level, ready for loading into the change management project schedule.
Diagrams
The Best practice IT Standard is:
The use of diagrams to assist the work of different teams. Diagrams provide visual references that are quick to interpret and are particularly useful for planning purposes such as equipment changes, new deployments, capacity, and topology management. With an architecture function in place, diagrams can be produced using common standards and toolsets. Otherwise, teams can develop their own diagrams using a common tool such as ‘Visio’. Diagrams are only useful if their level of detail is fit for purpose, and they are kept up to date; otherwise, their value is questionable.
Diagrams are produced in three levels with each level being an explosion of the former.
Level 1. The highest level, the macro view, is used for scoping and high-level planning.
Level 2. Intermediate level, detail view, used for deployment planning.
Level 3. The lowest level, maximum detail view, is used for capacity management.
Performance Questions
1. Are there applications development diagrams?
2. Are there WAN / LAN diagrams?
3. Are there infrastructure server diagrams?
4. What tools are in use to create diagrams?
5. Are diagrams up to date?
6. Are diagrams available on all three levels?
7. Determine diagramming needs of each team.
8. Who owns the production and maintenance of diagrams?
Sample Tasklist
1. Appoint one or more diagramming resources as roles.
2. Investigate a standard diagramming tool.
3. Produce diagrams.
4. Add a step to appropriate processes to update diagrams.
5. Consider having architecture own the tool and diagramming standards.
6. Determine further works required and scope out.
7. Break down the scope of work to the task level, ready for loading into the change management project schedule.