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