• People are the foundation of any company’s activity. If people cannot do, do not know how, do not use, do not participate, do not want to or do not do something, everything else is useless. If you have forgotten about people, you have to forget about the results.
• Artifacts. Working people must achieve predetermined results. They also create artifacts enabling to share information, discuss objectives and issues, save ideas for later implementation, monitor the achievement of results, etc.
• Processes. In order to achieve results, people must do the right things in the right sequence. All people make mistakes, but if they follow predetermined processes, the likelihood of errors decreases, and their consequences can be easily eliminated. Processes help turn good ideas into results. So, one cannot just shrug off them lightly.
• Management. Architectural practice is doomed to failure without proper management. One should determine the framework and rules of practice beforehand, taking the standard processes, artifacts, roles, etc. as a foundation. It is very dangerous to make up the rules as the game is on. People will be disoriented, processes will fail, the results will be wrong and at the wrong time.
Figure: Architectural Practice Management using “TOGAF”
Architectural practice management is required to exclude the common mistakes made by people working on a task or project. People are unlikely to achieve results if they:
• go too deep in the theory and research;
• do useless work;
• make long preparations before commencing the work;
• re-invent the wheel;
• “optimize” their work instead of doing it;
• theorize too much;
• Search for someone to blame;
• find themselves the smartest ones;
• avoid unpleasant work.
The approach to the architectural practice management consists of six main elements:
• Methodology is the main element of the approach. It defines the company’s processes for developing, updating, and implementing the Enterprise Architecture, their roles and responsibilities.
• Artifacts include a set, templates and rules for filling in the documents, tables, diagrams, used for description of the Enterprise Architecture.
• Standards are the standards, laws and rules of business and IT used by the company. These can be international standards, Russian standards, standards of the industry, region, and company.
• Best practices and ready-made models are proven ways to implement solutions, tested in your or in other companies.
• Regulations and rules are the documents describing the goals, objectives, organizational structure, rules of work and the boundaries of architectural practice. They contain the rules of work with other subdivisions, and architects’ authorities. The regulations should be integrated with other company regulations, especially those of the IT department.
• Managerial impact by practice managers are aimed to ensure practical results in the company. One needs to plan, get people to follow processes, start architectural projects, resolve conflicts, monitor intermediate results, etc. No elements will work being unmanaged.
First, the order of implementation of architectural practice includes development of all these company’s elements from scratch – that is a very difficult task to do. Therefore, one needs to take the existing methodologies and adapt them according to the company’s needs. Secondly, the practices should be introduced gradually, as a part of the practice development. The introduction of each element should be a real value for the practice. Third, one should keep a balance between bureaucracy and personal initiative. Finally, do not be afraid to experiment and try new approaches. If they are valuable, describe them in the regulations and use them in your next projects.
TOGAF Key Documents and Templates
To implement the TOGAF methodology, the question arises: what is the minimum set of documents required to maintain an architectural project? Extra documents mean extra time and funds. From my own experience and theory (during preparation for certification), the minimum set can consist of eight documents:
• The Main Methodologies are Templates, Business Principles, Goals, Drivers, required to understand the company’s mission, goals, and strategy and register the business principles. See Template “TOGAF 9 Templates, Business Principles, Goals, Drivers.doc”
• Architecture Principles are the rules to guide the work on architecture. Architectural decisions are made based on these principles. Principles need to be formulated based on TOGAF examples. Using principles when working on architecture has proven its effectiveness. See Template “TOGAF 9 Template Architecture Principles.doc”
• Architecture Vision is a high-level description of the desired end product of an architectural project. So, these are the results to achieve. Description of the solution of the problems and tasks to start the project for. This document is important for interaction with the project sponsor and other stakeholders. See Template “TOGAF 9 Template Architecture Vision.doc”
• Statement of Architecture Work is an agreement between the sponsor and the project team on the implementation of the work. It includes all the frameworks, restrictions, assumptions, terms, budget, and project rules. It designates the project manager and states his/her rights and responsibilities. Addendum includes the architecture vision as a description of the project framework. See Template “TOGAF 9 Template Statement of Architecture Work.doc”
• Architecture Definition is a presentation of the current and target architecture and covers each of the architectural domains i.e. business, data, applications, and technology, as well as an analysis of the discrepancies between the current and future state. See Template “TOGAF 9 Template Architecture Definition.doc”
• Architecture Requirements Specification is a document providing a quantitative view of the requirements, restrictions, suggestions, and measurable criteria that must be met during the implementation of the architecture. See Template “TOGAF 9 Template Architecture Requirements Specification.doc”
• Transition Architecture. The implementation of the target architecture has several stages. Each intermediate state must be workable and valuable. This document groups projects for each of these stages. See Template “TOGAF 9 Template Transition Architecture.doc”
• Implementation and Migration Plan is a consolidated implementation plan for projects aimed to achieve the target architecture. It also includes benefits, scope, timeframe, cost, risks, and milestones of projects. See Template “TOGAF 9 Template Implementation and Migration Plan.doc”
Such set of documents can be done rapidly and in a cost-effective way. If you are going to use third party services, I recommend to include one more document – an architectural contract. This is an agreement between architects and IT project executives. See Template – “TOGAF 9 Template – Architecture Contract.doc” When accepting a project, it will be easier for you to get the desired result if you have agreed on it beforehand.
Management Strategy
When forming an IT Strategy, one can determine the strategy on “Technological Architecture” and “Information Systems (Services) Architecture” of some IT infrastructure components, as well as recommendations on choosing solution. To understand the problems of the business and translate them into the IT language, you can use the method of “problem tree – solutions”. As can be seen from the diagram, business formulates its problems in the language of business. The task of the CIO is to translate the business language into a technical language, for the further development of IT projects and setting tasks for the IT department staff In order for business and IT to understand the need to demand from each other, it is necessary to define criteria for achieving goals and objectives, as well as metrics for their measurement.
“Problem – Solution Tree”
Financial control strategy
A financing strategy may foresee an organization’s behavior in IT financing. In particular, it is desirable to have a financial strategy on issues such as:
• cost of the solution as a priority when choosing an IT project solution, even if it affects the functionality. Solution capabilities must meet business requirements with minimal cost;
• focusing on the use of free software;
• balancing by cost or functionality.
For example, the cost of leasing circuits for different branches of the same bank may differ depending on the distance or geographic location. Let us say that the cost of a 10 Mbps channel (which is a standard and sufficient IT requirement) for a regional branch costs 500 USD. The city branch can get the speed of the channel up to 100 Mbps for the same cost. This branch has a current standard speed of 10 Mbps for about 100 USD a month. The average cost of a communication channel for all branches is about 250 USD. The leadership should have a certain strategy regarding this issue, i.e. provide branches with an opportunity to increase speed within the average cost, maximum cost, or leveling all up to the established channel speed (10 Mbps).
Outsourcing in the implementation and maintenance of Information Systems and projects should be used whenever possible. The capabilities and potential of the IT department staff should be increased.
Administrative strategy
The strategy of changes may foresee the organization’s behavior when changing in requirements, etc. As an example, let’s consider the situation when the number of employees remains unchanged, while the speed of Internet access has dropped significantly due to intensive use. As a solution, the bandwidth can be increased, that will affect the costs accordingly. This issue will periodically occur until it reaches the critical point. Another solution is “repressive” method, i.e. having analyzed the network traffic, the IT department determines that the misuse of the Internet has increased. Some administrative controls may lead to improvement of Internet speed without increasing the costs.
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.