IT Architecture from A to Z: Theoretical basis. First Edition. Vadim Aldzhanov
Чтение книги онлайн.
Читать онлайн книгу IT Architecture from A to Z: Theoretical basis. First Edition - Vadim Aldzhanov страница 6
• IT department hardly acts in IT infrastructure or acts passively (upon request only);
• Managerial staff is concerned in minimum investment;
• Service or department within the business unit (administration, finance) or overseen position in the organizational structure of the company.
Establishment or “optimization”
The company builds end-to-end business processes using common data and information systems. Whenever possible, it centralizes subdivisions’ business processes and functions in centralized information systems according to previously described operational models. The main symptoms of this stage of development are:
• The IT department is important;
• IT department strategy partially meets business requirements;
• Manageable IT department budget;
• IT department responses reactively to business requirements;
• Managerial staff is concerned in getting business benefits in the short term;
• A dedicated department in the organizational structure of the company, but the IT manager is not a part of the board of directors.
Mature
Reuse of existing business processes and components to create new services and opportunities. Proactive IT is an integral part of the business. The main symptoms of this stage of development are:
• The IT department is a strategic organization resource;
• IT department strategy integrated into the company’s business strategy;
• IT department budget considered as business investment;
• IT department acts proactively to business requirements;
• Managerial staff is concerned in long-term business investment;
• IT department is a part of the company’s organizational structure, CIO is a member of the board of directors.
Each of these stages has pros and cons. The IT development stage should correspond to that of the company. Experience has shown that to skip at least one of the stages is difficult since it requires huge amounts of resources (time, money, human resources etc.), and the effect will rather be to the contrary. Most companies grow stage-by-stage. The company transits to the next stage when the leadership of the company realizes or the severity of the issues arisen:
• Issues of supporting the growth and business changes
• Duplication of business processes
• Multiple platforms and systems
• Dissatisfaction with the current IT state.
Criteria of choosing a methodology
Since the methodologies vary a lot, one should set criteria to compare them.
The completeness of the taxonomy defines the suitability degree of the methodology for the classification of various architectural artifacts or whether fully focused on the Zachman framework.
The completeness of the process defines how detailed the process of creating the enterprise architecture is.
The guide to reference models defines the usefulness of the methodology in creating an adequate set of reference models. The FEA methodology is almost entirely focused on this.
The practical guide defines the degree of implementation of the speculative idea of the enterprise architecture by the methodology and shaping the culture in which this architecture will be used. The Gartner methodology is almost entirely focused on this.
The readiness model defines the degree of assessment of the efficiency of using the enterprise architecture in various departments by the methodology.
A business orientation defines whether a methodology focused on using technology to increase business value, where business value defined as cost reduction or revenue increase.
The management guide defines the degree of methodology usefulness in understanding and creating an effective management model for an enterprise architecture.
The partitioning guide defines the usefulness of the methodology in effective partitioning the enterprise into departments, which is very important in managing complexity.
The availability of the catalog defines the efficiency of the methodology to create a catalog of architectural assets to be used in the future.
Neutrality towards service providers defines the likelihood of being tied to a specific consulting organization when implementing a methodology. A high rating means a low degree of attachment to a particular organization.
The availability of information defines the quantity and quality of free or relatively inexpensive materials on this methodology.
The time of recouping investments defines the duration of your using this methodology before you can build high business value solutions on its basis.
Enterprise Architecture can be built using various methods and practices. This book briefly discusses some of them and focus on one of them:
•“Zahman Framework” is the earliest and most well-known methodology. It is ideal to “classify” architectural elements.
•“TOGAF (The Open Group Architecture Framework)”, designed for “building processes” is widely known and spread, largely due to its openness.
•“Gartner” is a methodology for expert analysis by using “best practices”.
•“FEAF” is an architecture building methodology using the “service oriented” approach.
When building an IT Enterprise Architecture, one should highlight the following states of the organization’s architecture:
• “As-is” or “Baseline Architecture”;
• “Transition Architecture”;
• “To-be” or “Target Architecture”;
• “Enterprise Architecture Management Plan & Roadmap”.
In general, the Enterprise Architecture represents a transition plan from the “Ongoing” to the “Future” state of the organization. The architectural project lasts for several years and initiates many IT projects. These projects will have different duration, different start and end dates. They need to be grouped so that changes in business and IT would take place at the right time, with minimal risk and no compatibility issues. Therefore, architecture can transit from one operational state to another several times as an architectural project lasts. The intermediate state is called the Transition Architecture.
Enterprise