Methodology (9)
The Information Technology Infrastructure Library (ITIL) is a set of practices for IT service management (ITSM) that focuses on aligning IT services with the needs of business. In its current form (known as ITIL 2011 edition), ITIL is published in a series of five core publications, each of which covers an ITSM lifecycle stage. ITIL underpins ISO/IEC 20000 (previously BS15000), the International Service Management Standard for IT service management, although differences between the two frameworks do exist.
ITIL describes processes, procedures, tasks and checklists that are not organization-specific, used by an organization for establishing integration with the organization's strategy, delivering value and maintaining a minimum level of competency. It allows the organization to establish a baseline from which it can plan, implement, and measure. It is used to demonstrate compliance and to measure improvement.
Part of IT architecture includes improving efficiencies by restructuring enterprise resources. The more system maintenance processes that you automate in the IT architecture, the greater cost savings you can realize from reduced administrative overhead and support.
- Operating system patches/updates: Most operating systems have some type of native automated patch management solution, and third-party solutions are also available.
- Application updates: Some applications have the ability to update themselves automatically, while others may be updated through logon scripts or push technology.
- Anti-malware updates and scans: Use enterprise-level anti-malware solutions that update frequently and scan regularly to improve security.
Collaboration solutions facilitate IT architecture teamwork by allowing team members to communicate, share data, and create repositories of collective intelligence, regardless of location or scheduling complications. They may decrease travel and telephone costs significantly. In IT architecture, common collaboration solutions include
- Social networking: Social networking tools, such as chat, blogs, and forums, provide new and flexible methods for sharing information.
- Groupware: Groupware allows employees to work together regardless of location by using integrated tools that facilitate communication, conferencing, and collaborative management.
- Enterprise portal: Portals aggregate content from multiple sources, bringing it all into one place for easy access and creating a single point of contact.
A good IT architecture plan improves efficiencies. When IT architecture includes consolidation and centralisation of technology resources, particularly in the data centre, resource use, document recovery, security, and service delivery will be improved; data availability will be increased and complexity reduced. Elements that can be consolidated or centralised include:
- IT personnel: Consolidate IT personnel into centrally managed, focused support groups based on need and skill sets.
- Servers: The number of physical servers can be reduced by implementing virtualisation or simply eliminating redundant functionality.
- File storage: Get local file repositories off multiple file servers and onto a centralised storage solution such as a storage area network (SAN).
- Directory services: Provide a common directory service for authentication or implement a single sign-on or federated authentication solution to bridge multiple directories.
Standardisation of technology is a common part of IT architecture projects. Standardised technology reduces complexity and offers benefits such as cost savings through economy of scale, ease of integration, improved efficiency, greater support options, and simplification of future control. Some common targets for standardisation include
- User workstation environments (SOE): This includes desktop hardware, operating system, and user productivity suites.
- Software development: Consider standardising not only programming languages, but also software development practices.
- Database management systems: Try to standardise on a single database platform, such as Oracle, Microsoft SQL or mySQL.
The Zachman Framework is an enterprise architecture framework which provides a formal and highly structured way of viewing and defining an enterprise. It consists of a two dimensional classification matrix based on the intersection of six communication questions (What, Where, When, Why, Who and How) with five levels of reification, successively transforming the most abstract ideas (on the Scope level) into more concrete ideas (at the Operations level).
The Zachman Framework is a schema for organizing architectural artifacts (in other words, design documents, specifications, and models) that takes into account both whom the artifact targets (for example, business owner and builder) and what particular issue (for example, data and functionality) is being addressed. The Zachman Framework is not a methodology in that it does not imply any specific method or process for collecting, managing, or using the information that it describes.
The framework is named after its creator John Zachman, who first developed the concept in the 1980s at IBM. It has been updated several times since
The Open Group Architecture Framework (TOGAF®) is a framework for enterprise architecture which provides a comprehensive approach for designing, planning, implementing, and governing an enterprise information architecture.
TOGAF is a high level and holistic approach to design, which is typically modeled at four levels: Business, Application, Data, and Technology. It tries to give a well-tested overall starting model to information architects, which can then be built upon. It relies heavily on modularization, standardization and already existing, proven technologies and products.
TOGAF as an architecture framework is a set of tools which can be used for developing a broad range of different architectures. It should:
- describe a method for defining an information system in terms of a set of building blocks
- show how the building blocks fit together
- contain a set of tools
- provide a common vocabulary
- include a list of recommended standards
- include a list of compliant products that can be used to implement the building blocks
The ANSI/IEEE Standard 1471-2000 specification of architecture (of software-intensive systems) may be stated as: "the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution."
However TOGAF has its own view, which may be specified as either a "formal description of a system, or a detailed plan of the system at component level to guide its implementation", or as "the structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time."
The PMBoK (Project Management Body of Knowledge) Guide is process-based, meaning it describes work as being accomplished by processes. This approach is consistent with other management standards such as ISO 9000 and the Software Engineering Institute's CMMI. Processes overlap and interact throughout a project or its various phases. Processes are described in terms of:
- Inputs (documents, plans, designs, etc.)
- Tools and Techniques (mechanisms applied to inputs)
- Outputs (documents, products, etc.)
A Guide to the Project Management Body of Knowledge — Fifth Edition provides guidelines for managing individual projects and defines project management related concepts. It also describes the project management life cycle and its related processes, as well as the project life cycle.
The Guide recognizes 47 processes that fall into five basic process groups and ten knowledge areas that are typical of almost all projects. The five process groups are:
- Initiating
- Planning
- Executing
- Monitoring and Controlling
- Closing
The ten knowledge areas are:
- Project Integration Management
- Project Scope Management
- Project Time Management
- Project Cost Management
- Project Quality Management
- Project Human Resource Management
- Project Communications Management
- Project Risk Management
- Project Procurement Management
- Project Stakeholders Management (added in 5th edition)
Each of the ten knowledge areas contains the processes that need to be accomplished within its discipline in order to achieve an effective project management program. Each of these processes also falls into one of the five basic process groups, creating a matrix structure such that every process can be related to one knowledge area and one process group.
The PMBoK Guide is meant to offer a general guide to manage most projects most of the time.
PRINCE2 is a process-driven project management method which contrasts with reactive/adaptive methods such as Scrum.
PRINCE2 is based on seven principles (continued business justification, learn from experience, defined roles and responsibilities, manage by stages, manage by exception, focus on products and tailored to suit the project environment), seven themes (business case, organization, quality, plans, risk, change and progress) and seven processes. The principles and themes come into play in the seven processes:
Starting up a project (SU)
In this process the project team is appointed and a project brief (describing, in outline, what the project is attempting to achieve and the business justification for doing so) is prepared. In addition the overall approach to be taken is decided and the next stage of the project is planned. Once this work is done, the project board is asked to authorize the next stage, that of initiating the project.Key activities include: Forming project board; appointing an executive and a project manager; designing and appointing a project management team; preparing a project brief; defining the project approach; and planning the next stage (initiation).
Initiating a project (IP)
This process builds on the work of the start up process, and the project brief is augmented to form a Business case. The approach taken to ensure quality on the project is agreed together with the overall approach to controlling the project itself (project controls). Project files are also created as is an overall plan for the project. A plan for the next stage of the project is also created. The resultant information can be put before the project board for them to authorize the project itself.Key activities include: planning quality; planning a project; refining the business case and risks; setting up project controls; setting up project files; and assembling a Project Initiation Document.
Directing a project (DP)
This process dictates how the Project Board (which comprises such roles as the executive sponsor or project sponsor) should control the overall project. As mentioned above, the project board can authorise an initiation stage and can also authorize a project. Directing a Project also dictates how the project board should authorize a stage plan, including any stage plan that replaces an existing stage plan due to slippage or other unforeseen circumstances. Also covered is the way in which the board can give ad hoc direction to a project and the way in which a project should be closed down.Key activities include: authorising initiation; authorising a project; authorising a stage or exception plan; giving ad hoc direction; and confirming project closure.
Controlling a stage (CS)
PRINCE2 suggests that projects should be broken down into stages and these sub-processes dictate how each individual stage should be controlled. Most fundamentally this includes the way in which work packages are authorised and received. It also specifies the way in which progress should be monitored and how the highlights of the progress should be reported to the project board. A means for capturing and assessing project issues is suggested together with the way in which corrective action should be taken. It also lays down the method by which certain project issues should be escalated to the project board.Key activities include: authorising work package; assessing progress; capturing and examining project issues; reviewing stage status; reporting highlights; taking corrective action; escalating project issues; and receiving a completed work package.
Managing stage boundaries(SB)
The Controlling a Stage process dictates what should be done within a stage, Managing Stage Boundaries (SB) dictates what should be done towards the end of a stage. Most obviously, the next stage should be planned and the overall project plan, risk register and business case amended as necessary. The process also covers what should be done for a stage that has gone outside its tolerance levels. Finally, the process dictates how the end of the stage should be reported.Key activities include: planning a stage; updating a project plan; updating a project business case; updating the risk register; reporting stage end; and producing an exception plan.
Managing product delivery (MP)
The Managing product delivery process has the purpose of controlling the link between the Project Manager and the Team Manager(s) by placing formal requirements on accepting, executing and delivering project work. The Objectives of the Managing Product Delivery process are:
- To ensure that work on products allocated to the team is authorised and agreed,
- Team Manager(s), team members and suppliers are clear as to what is to be produced and what is the expected effort, cost and timescales,
- The planned products are delivered to expectations and within tolerance,
- Accurate progress information is provided to the Project Manager at an agreed frequency to ensure that expectations are managed.
The key activities are: Accept a work package, execute a work package and deliver a work package.
Closing a project (CP)
This covers the things that should be done at the end of a project. The project should be formally de-commissioned (and resources freed up for allocation to other activities), follow on actions should be identified and the project itself be formally evaluated.Key activities include: decommissioning a project; identifying follow-on actions; and project evaluation review;