bannerbanner
IT Architecture from A to Z: Theoretical basis. First Edition
IT Architecture from A to Z: Theoretical basis. First Edition

Полная версия

IT Architecture from A to Z: Theoretical basis. First Edition

текст

0

0
Язык: Английский
Год издания: 2018
Добавлена:
Настройки чтения
Размер шрифта
Высота строк
Поля
На страницу:
4 из 9

Strategy of Infrastructure Building

Architecture choice strategy

As a solution architecture, one can consider the following:

• On premise infrastructure;

• Cloud based infrastructure;

• Hybrid architecture.


“On-premise” implies that IT assets are physically located within the organization. Benefits:

• IT infrastructure is located within the organization and controlled by organization’s IT employees.

• Relatively low operative expenditures of IT infrastructure.

• Solution autonomy and higher security.

Deficiencies:

• Relatively high capital expenditure in IT infrastructure.

• The introduction of new services, or surges of existing services are difficult to plan.

• The need to hire IT specialists to maintain physical servers, network equipment, and so on) leads to additional costs.

• Indirect costs for IT engineering systems.


“Cloud based” implies that IT assets are located in the “cloud”.

Benefits:

• Relatively low capital expenditure in IT infrastructure.

• High level of planning of maintenance costs for IT infrastructure.

• Good communication, linear relationship between the resources used and their cost.

• Easiness to implement new solutions and expand existing IT services.

• No need for additional staff.

• No need for indirect engineering costs.

Deficiencies:

• Relatively high operative expenditures of IT infrastructure.

• Higher requirements for Internet bandwidth and backup channels.


“Hybrid” architecture provides combined solutions.

Benefits: The benefits of the first two solutions are used.

Deficiencies: A higher capital and operative (CAPEX and OPEX).


Recommendations for selection:

“Cloud based” solution is more preferable for initial projects, small organizations, organizations with developed geography and so on. “On-site” solution is more preferable for well-developed organizations, financial institutions, organizations where access to the Internet is not a business requirement. “Hybrid” solutions can supplement the IT infrastructure and replace some components of the IT architecture.


Infrastructure platform choice strategy

If you choose “On-premises” as deployment infrastructure, there are the following options:

• Physical servers as a foundation;

• Virtualization platform as a basis;

• Mixed infrastructure with no dominance.


“Physical servers” implies that IT services are located on physical servers. Benefits:

• Relatively low capital expenditure of IT services for small solutions;

• The resources of the physical server are fully allocated to the tasks of a particular service.

Deficiencies:

• The complexity of maintenance as the infrastructure grows;

• Deployment and recovery speed.

• Sub-optimal use of computing resources.


“Virtualization Platform” implies that IT services are located on the virtualization platform as virtual machines. Benefits:

• Relatively low operative expenditures of IT infrastructure.

• The platform is de facto standards for the deployment of “On-premises” solutions.

Deficiencies: Relatively high capital expenditure in IT infrastructure.


Recommendations for selection:

“Physical servers” solution is more preferable for small, isolated or remote IT services, or high volume systems. For all other cases, it is better to use a virtualization platform.


Choice strategy for data storage system

If you choose “On-premises” as deployment infrastructure, there are the following options:

• Physical servers and Direct-Attached Storage (DAS);

• Centralized Data Storage System, i.e. Network Attached Storage (NAS) and Storage Area Networks (SAN);

• Distributed Data Storage System, i.e. Digital Data Storage (DDS) and Software-Defined Storage (SDS).


Physical servers implies that the data is located on physical servers.

Benefits:

• Relatively low capital expenditure of IT services for small solutions.

• The resources of the physical server are fully allocated to the tasks of a particular service.

Deficiencies:

• The complexity of maintenance as the infrastructure grows.

• Deployment and recovery speed.

• Sub-optimal use of computing resources.


Centralized Data Storage System (NAS, SAN) implies that the data are located on a single data storage system partially or completely. DSS is a single complex consisting of controllers and disk storage racks.

Benefits: Relatively low operative expenditures of IT infrastructure.

Deficiencies: Relatively high capital expenditure of IT infrastructure.


Distributed Data Storage System (DDS, SDS)” implies that the data is distributed between different physical servers. A storage system is a complex distributed within the network and consisting of data controllers and disk storages.


Recommendations for selection:

“Physical servers” solution is more preferable for small, isolated or remote IT services, or high volume systems. For all other cases, it is better to use a virtualization platform.


Strategy of choosing the manufacturer

The strategy for choosing software and hardware determines the approach to the choice of manufacturer, standardization, and so on.

The following options can be considered:

• Use of a limited list of manufacturers;

• Use random list of manufacturers.


Using a specific manufacturer for each category of IT assets implies using hardware and software standards within the organization.

Benefits:

• Implementing IT asset standards simplifies providing an organization staff with IT assets;

• It facilitates the implementation and maintenance of IT infrastructure, and increases the level of the organization’s information security.

Deficiencies: Relatively high cost and dependence on the manufacturer/supplier.


Using a random manufacturer implies use of recommendations instead of hardware and software standards within the organization.

Benefits: Relatively low cost and promptness in procurement of IT assets.

Deficiencies:

• The process of providing an organization staff with IT assets is more sophisticated and takes longer;

• It complicates the implementation and maintenance of IT infrastructure, and

• reduces the level of the organization’s information security.


Recommendations for selection:

The first licensing option is recommended is recommended to organizations with close integration and dependence of business and Information Technology or a large number of employees.


Licensing strategy

The licensing strategy determines the approach to licensing methods. The following options can be considered:


Using an “Enterprise” license agreement with the annual software update. Licensing is an ongoing IT process.

Benefits:

• Greater flexibility of licensing.

• Maintaining the high level of IT infrastructure and information security due to using updated versions of systems and solutions.

• Systems are upgraded smoothly, with no surges in requirements of IT, human resources or time.

Deficiencies: Relatively high cost.


Purchasing commercial off-the-shell retail versions with no software update. Licensing “upon request”.

Benefits: A relatively cheaper option.

Deficiencies:

• Less freedom in licensing.

• The level of maintaining IT infrastructure and information security is reduced due to using not the most updated versions of systems and solutions.

• Systems are upgraded in jumps (every three, four years), and require additional IT resources, people, and time.


Recommendations for selection:

The first licensing option is recommended to organizations with close integration and dependence of business and Information Technologies.


The strategy of building engineering systems

“On premise” and “Hybrid” solutions demand to determine the engineering system requirements. The engineering systems requirements for may include:

• Physical requirements for the premises of the data center, server room, data cabinets etc.

• Requirements for a Structured Cabling System (SCS).

• Requirements for redundancy, reservation and so on.


Testing strategy

Testing is one of the important elements when building an IT architecture. Testing questions have to be identified at the design stage. There are the following platforms:

•“Test or Development” is a platform with individual IT services deployed which is used to develop services or adjust IT service elements.

•“Pre-production” is a smaller “Production” platform containing all the components of the IT architecture. It is used to test the interaction of IT services and allows emulating troubleshooting, estimating performance, and so on.

•“Production” is a platform with detailed computing resources providing IT services.


Recommendations for selection:

Various solutions can be implemented depending on the business requirements and the organization’s financial capacity. A detailed description is further discussed in this guide.


Redundancy strategy

Defining the redundancy level of IT infrastructure components indicates the requirements for duplication of components. It can be reviewed as follows:

• Components of engineering systems (channels and communication cables, switching racks, etc.). Reservations (duplication or redundancy) at the level of critical elements, such as:

• Channels and communication cables (two or more in different stacks),

• Excessive number of operating points (ensures the organization growth and backup).

• Device components (server, switch, and so on). Duplication at the level of critical elements such as:

•Processors (two or more),

• RAM (two or more),

• HDD (two RAID1hard drives + one backup)

• Network cards and adapters (two cards with one or more ports)

• Power supply units (N+N or N+1)

• IT service components. Backup at the device level and the type of their inclusion. For example:

• Two servers in a failover cluster

• Two servers performing the same function (two domain controllers)

• Two servers performing different functions in the normal mode, but can assume the neighboring function in the case of a failure (File server and print server. In case of failure, one can install the function on a neighboring server).

• Geographically separated devices within the site. Allocating a pair of devices in different racks, rooms, or buildings within the same site.

• Geographically separated devices at the site level. The allocation of a pair of devices on different sites.


Determining the backup level depends on the business criticality of failure or downtime. It is analyzed within Risk Management, formalized in documents on equipment standards.


Backup and Archiving Strategy

Backup systems and archiving IT infrastructure may define the following requirements:

• System components must be installed on dedicated physical elements (servers, storage, and so on)

• Backup and archiving systems on the same components can be combined.

• Access rights to (automatic) backup accounts should not provide an opportunity to delete data or overwrite them.


Backup building strategy

Backup component is one of the important elements when building an IT architecture. It relates to the information security, fault tolerance and recovery. The fault tolerance can be as follows:

• Fault tolerance at component redundancy level;

• Fault tolerance at the level of duplicating elements;

• Fault tolerance within the site;

• Fault tolerance with geographically distributed site.

Approaches for Enterprise Architecture Implementation

When designing company’s architecture, one should not start with developing a strategic architecture. The “Top-Down” approach (Strategic Architecture Segment Architecture Solution Architecture) is certainly the most widely spread and has many benefits:

• The general development vector of the organization is understandable.

• Less confusion on the segment and solution level.

• General rules and approaches are implemented at the organization level, and then spread to the segments and solution level.

• Common information systems and services are reusable within the company at the segment and decision level.


“Enterprise Strategy”


The main idea is the movement from “Generic-to-specific”, as well as continuous improvement of the IT architecture is based on business requirements. However, other approaches are also available:

“Bottom – Up” (Solution Architecture Segment Architecture Strategic Architecture), i.e. from the solutions of specific architecture design to strategic architecture. The company starts with a solution architecture. Before the project commences, the solution is being worked out and described. Then come higher levels of Enterprise Architecture. This method allows get a quick value from the Enterprise Architecture methods. However, there is a likelihood of dispersal of various architectural solutions without a strategic architecture foundation. It will take time and resources to bring them to a common denominator.

“From the Segment” (Segment Architecture Solution Architecture and Strategic Architecture) will be useful for the companies to solve problems in a particular division, launch a new business, or if the company is not ready for large-scale implementations of Enterprise Architecture and wants to practice more. It will help test ideas in one department or business direction. One needs to choose the company approach depending on the goals and terms of their achievement.

Your company’s information systems are likely to be far from being perfect. However, denying and redoing will be very expensive and take a lot of time. The value of such an initiative is much lower than zero. An experienced architect will fix the problems of integration, information security, infrastructure, and make the system be more valuable for the company. The process will be applied through slow and precise modifications. He will solve specific problems, instead of “doing all the right things.” Replacing the system is a major change for the company requires strong arguments.

The next important question in the implementation of building Enterprise Architecture is whether you should hire consultants or do everything yourself (MAKE or BUY)? There is no clear answer. Everything depends on the specific organization, goals and capabilities. For example, let’s imagine a situation:

We sign a contract with a respectable company “SUPER DUPER CONSULTANTS & Co.” A few months later we receive a set of documents called “The architecture of the BANANAS & Co company”, which contains the right system, many charts, descriptions, and so on. It can be called a “turnkey” solution. It is so tempting, isn’t it? It might be expensive, but prompt, professionally done, facile and flawless.

Using external resources, other people’s experience and knowledge is certainly one of the fastest ways to achieve results. However, there are a few drawbacks:

• The transition plan will be suspiciously similar to the list of product and service provided by this respectable company. Any external contractor within the project will sell other goods and services. This is a common practice and one of the main laws of sales.

• You will have only a set of documents, not an architectural practice. You will have a description, but all the processes, people, and management will be gone as the consultants leave.

• Your people will never have a chance to try, since consultants will do all the job and use a new experience and knowledge with a new customer. Your specialists will be paper architects. They will not have a key skill – the ability to make technical decisions.

In my opinion, building processes in an organization requires strong, competent, and capable managers, who have theoretical and practical skills, are familiar with the company’s culture and interested in transferring experience and knowledge to their colleagues and employees. They must play a major role and be the driving force of the organization.

I would recommend involving external consultants, but I would not give 100 percent of architectural work to outsourcers. The company should own not only the results of projects, but also people, knowledge and experience. Therefore, your staff being supervised by an expert to guide them must perform most of the work. Project implementation must include resources for training employees because the biggest life lesson is that “practice is blind without theory while theory is dead without practice.”

Enterprise Architecture Implementation Tools

What tools should be chosen and how to develop Enterprise Architecture? Today’s market offers dozens of tools, from free to expensive ones. Implementing some of them can cost hundreds of thousands dollar. I recommend using free or cheap tools whenever possible (if not available) for the following reasons:

• At the very start of architectural practice it should prove its effectiveness, therefore, significant investment and lost time will be a serious obstacle to create it.

• At the initial stage, it is better to use simple and familiar tools that do not require additional implementation and training. Success is determined by the implementation speed.

• One needs to gain experience and get his/her first results in order to shape adequate requirements for an expensive system.

• Only after the practice has been launched, and experience and first results have been obtained, is it time to switch to specialized products.

What are the minimum requirements for tools? How are they supposed to help you?

• Write and edit texts, make charts and tables, presentations, etc.

• Publish them on a shared resource, regulate the access rights to information, and discuss these materials.


Below is the set of tools:

• For example you can use a standard MS Office suite to compile documents, charts, spreadsheets and presentations. MS Office offers documents templates to use. There are Visio extensions to draw all the required flowcharts.

• You can use a corporate portal, a document management system, a corporate mail system, a corporate messaging system, or a dedicated file share in an organization’s corporate network for collaboration. The choice of solution will depend on what your company already has.

Recommendations for implementation

Based on the requirements and constraints defined above, you can summarize the basic approach in building the company’s IT architecture:

• Service oriented approach to building IT architecture;

• Minimizing risks by using tested and well-proven technologies and solutions;

• Reducing costs by maximizing and optimizing the use of current IT assets and solutions;

• Reducing the complexity and heterogeneity of the existing infrastructure;

• Maximum possible rational approach to the consolidation of IT assets (hardware, software), keeping the level of user support and / or specialized systems at the periphery;

• Multiple use of IT assets (IT personnel) on projects within the company;

• Standardizing IT assets (hardware, software and solutions) to reduce the cost of ownership, complexity of maintenance and increase information security;

• Implementation of single IT policies and procedures to reduce the cost of ownership, complexity of maintenance and increase information security in the company;

• Automation of routine IT processes to reduce the cost of ownership, maintenance complexity and increase information security;

• Creating a single information security policy in the organization;

• Creating a project team with a high level of competence.


Compatibility

Wherever possible, consider the availability of existing systems and maximize their benefits. This will reduce the cost of replacement, or the implementation and maintenance of new systems.


Following the main principles

When implementing new or intermediate solutions, or launching a business (or expanding it), it is recommended to be guided by the main requirements stipulated by this document. The cost of the solution and maintenance of IT infrastructure directly depends on the choice of a solution.

Conclusion

In conclusion, it can be said that building an Enterprise Architecture is one of the most important aspects of building an effective corporate governance mechanism with the integration of information technologies to obtain the best results. Integrating IT Service Management (ITSM), Project Management Methodology (PMM), Control Objectives for Information and Related Technologies (COBIT) will enable businesses to achieve exceptional results and maximize the benefits of IT.

PROJECT MANAGEMENT

General provisions

Project management is considered as a method and a set of procedures based on adopted management principles used to plan, evaluate, and control work assignments in order to duly achieve the desired result, within the budget and in accordance with project requirements. This chapter contains the basic principles of project management, which should be taken into account when building an IT Enterprise Architecture. Any projects involving, affecting or depending on IT are IT projects. The “project” approach should be a guidance when planning, developing and implementing various IT architecture services.

Project management is a very broad topic, affecting and interwoven with various directions of activity, such as quality management, risk management, finance management, and so on. This chapter briefly describes the main aspects, methods and techniques of project management.

A project is a one-time, non-recurring activity or set of actions to be taken within specific term, and aimed at creating unique products, services, results or clearly defined goals. The signs of the project are:

•There is an exact start date. The key feature of the project is the “time component”, i.e. there is the beginning and end of the project.

•There is an exact finish date. Date of the estimated deadline for the project is to be set, but the finish date is fixed upon obtaining the final result or achieving the objectives of the project.

•The project result is unique. This is the second distinction between a project and a process or regular activity. “Unique” does not mean absolutely new for everyone, it can be unique for an organizer or team.

•The resources and budget are limited.

• The specific order of the assignments. It may imply temporary changes in the managerial breakdown and make it different from the one established in the organization.


Program differs from the project by a larger scale and possibility to consist of many projects. For example, an organization has a transition program to a centralized IT management system, which may include several separate projects.

An assignment or a set of assignments is a set of actions to be performed by one or several persons using a simple list defining a sequence of actions.

Key Aspects of Project Management

Triple Constraint or Project Triangle describes the balance between the scope, cost and schedule of the project, which affects the final result, i.e. quality. Quality is the fourth element of the Project Triangle, located in the center, and any change in the sides affects it.


“Triple Constraint or Project Management Triangle”


There is a huge difference between doing something well, fast or cheap. It is impossible to change one of the factors (funds, list of jobs, time or quality) without affecting at least one of the them. As an example:

На страницу:
4 из 9