defraine/EA Interviews.md

Guide d'interviews

Adapter les listes de contrôle

Se concentrer sur les zones à haut risque et les différenciateurs attendus (et émergents). Pour chaque question de la checklist, comprenez la question elle-même et le principe derrière la question. Pour chaque réponse, recherchez :

Demandez leur avis aux experts en la matière
Corrigez les questions de la checklist pour votre usage
Gardez à l'esprit la nécessité d'une rétroaction au Comité d'architecture

Examens de conformité de l'architecture

Comprendre clairement les objectifs de ceux qui sollicitent l'examen; et rester sur la bonne voie en livrant ce qui a été demandé. Par exemple, ils veulent généralement savoir ce qui est bien ou mal avec la conception en cours du point de vue de l'architecture ; et non ce qui est bien ou mal avec la méthodologie de développement utilisée, leur propre organisation de travail, leur propre gestion de projet, etc... Il est facile de s'éloigner et de discuter de sujets qui sont intéressants et peut-être utiles, mais ce n'est pas ce qui est demandé. Si vous pouvez éclairer une partie du système mais qui n'est pas utile à l'examen, faites le plus tard.
S'il devient évident au cours de la discussion qu'il y a d'autres questions à régler, qui n'entrent pas dans le cadre de l'examen demandé, faites-en part au président de la réunion. Un plan pour traiter les problèmes peut ensuite être élaboré en fonction de leur degré de gravité.
Restez "scientifique". Plutôt que: "Nous aimons voir de grandes bases de données hébergées sur ABC plutôt que XYZ.", Dites des choses comme: "Le temps d'arrêt associé aux environnements de base de données XYZ est beaucoup plus grand que sur les environnements de base de données ABC. Par conséquent, nous ne recommandons pas l'hébergement de type M et N systèmes dans un environnement XYZ. "
Posez des questions «ouvertes»; c'est-à-dire des questions qui ne supposent pas une réponse particulière.
Il y a souvent des questions controversées parmi ceux qui sollicitent un examen, que vous ne connaîtrez probablement pas d'avance. Une approche dépersonnalisée des discussions peut aider à combler les écarts d'opinion plutôt qu'à les exacerber.
Traitez les personnes interrogées avec respect. Ils n'ont peut-être pas construit le système «tel qu'il devrait être», mais ils ont probablement fait de leur mieux dans les circonstances où ils ont été placés.
Aidez l'examen à devenir une expérience d'apprentissage pour vous et les présentateurs.
Les examens doivent inclure des activités d'évaluation détaillées par rapport aux architectures et doivent garantir que les résultats sont stockés dans le continuum d'entreprise.

TOGAF

Architecture Requirements Specification

The Architecture Requirements Specification provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. An Architecture Requirements Specification will typically form a major component of an implementation contract or contract for more detailed Architecture Definition.

As mentioned above, the Architecture Requirements Specification is a companion to the Architecture Definition Document, with a complementary objective:

The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architect
The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture

Typical contents of an Architecture Requirements Specification are:

Success measures
Architecture requirements
Business service contracts
Application service contracts
Implementation guidelines
Implementation specifications
Implementation standards
Interoperability requirements
IT Service Management requirements
Constraints
Assumptions

Architecture Definition Document

The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project and for important related information. The Architecture Definition Document spans all architecture domains (business, data, application, and technology) and also examines all relevant states of the architecture (baseline, transition, and target).

A Transition Architecture shows the enterprise at an architecturally significant state between the Baseline and Target Architectures. Transition Architectures are used to describe transitional Target Architectures necessary for effective realization of the Target Architecture.

The Architecture Definition Document is a companion to the Architecture Requirements Specification, with a complementary objective:

The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architects
The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture Typical contents of an Architecture Definition Document are:

Scope Goals, objectives, and constraints Architecture Principles Baseline Architecture Architecture models (for each state to be modeled): Business Architecture models Data Architecture models Application Architecture models Technology Architecture models Rationale and justification for architectural approach Mapping to Architecture Repository: Mapping to Architecture Landscape Mapping to reference models Mapping to standards Re-use assessment Gap analysis Impact assessment Transition Architecture: Definition of transition states Business Architecture for each transition state Data Architecture for each transition state Application Architecture for each transition state Technology Architecture for each transition state

Architecture Landscape

The Architecture Landscape holds architectural views of the state of the enterprise at particular points in time.

Standards Information Base

Overview

The Standards Information Base provides a repository area to hold a set of specifications, to which architectures must conform. Establishment of a Standards Information Base provides an unambiguous basis for Architecture Governance because:

The standards are easily accessible to projects and therefore the obligations of the project can be understood and planned for
Standards are stated in a clear and unambiguous manner, so that compliance can be objectively assessed

Types of Standard

Legal and Regulatory Obligations: these standards are mandated by law
Industry Standards: these standards are selected by the enterprise for interoperation and sharing across enterprises, but also fall outside of the control of the enterprise and therefore must be actively monitored.
Organizational Standards: these standards are set within the organization. These Standards require processes to allow for exemptions and standards evolution.

Standards Lifecycle

Standards do not generally exist for all time. New standards are identified and managed through a lifecycle process.

Proposed Standard: a potential standard which has not yet been evaluated for adoption
Trial Standard: a potential standard which has not been tried and tested to a level where its value is fully understood. Projects wishing to adopt these standards may do so, but under specific pilot conditions, so that the viability of the standard can be examined in more detail.
Active Standard: a standard defines a mainstream solution
Deprecated Standard: a standard is approaching the end of its useful lifecycle ; Projects that are re-using existing components can generally continue to make use of Deprecated Standards. Deployment of new instances of the Deprecated Standard is generally discouraged.
Retired Standard: a standard is no longer accepted as valid within the landscape ; in most cases, remedial action should be taken to remove this standard from the landscape. Change should only be accepted as a part of an overall decommissioning plan.

All standards should be periodically reviewed.

Standards Classification within the Standards Information Base

Standards within the Standards Information Base are categorized according to the building blocks within the TOGAF content metamodel. Each metamodel entity can potentially have standards associated with it (e.g., Business Service, Technology Component).

Standards may relate to "approved" building blocks (e.g., a list of standard technology components) or may specify appropriate use of a building block (e.g., scenarios where messaging infrastructure is appropriate, application communication standards are defined).

At the top level, standards are classified in line with the TOGAF architecture domains, including the following areas:

Business Standards:
    Standard shared business functions
    Standard role and actor definitions
    Security and governance standards for business activity
Data Standards:
    Standard coding and values for data
    Standard structures and formats for data
    Standards for origin and ownership of data
    Restrictions on replication and access
Applications Standards:
    Standard/shared applications supporting specific business functions
    Standards for application communication and interoperation
    Standards for access, presentation, and style
Technology Standards;
    Standard hardware products
    Standard software products
    Standards for software development

Architecture Compliance

An Architecture Compliance review is a scrutiny of the compliance of a specific project against established architectural criteria, spirit, and business objectives.

Purpose

The goals of an Architecture Compliance review include some or all of the following:

First and foremost, catch errors in the project architecture early, and thereby reduce the cost and risk of changes required later in the lifecycle

This in turn means that the overall project time is shortened, and that the business gets the bottom-line benefit of the architecture development faster.
Ensure the application of best practices to architecture work
Provide an overview of the compliance of an architecture to mandated enterprise standards
Identify where the standards themselves may require modification
Identify services that are currently application-specific but might be provided as part of the enterprise infrastructure
Document strategies for collaboration, resource sharing, and other synergies across multiple architecture teams
Take advantage of advances in technology
Communicate to management the status of technical readiness of the project
Identify key criteria for procurement activities (e.g., for inclusion in Commercial Off-The-Shelf (COTS) product RFI/RFP documents)
Identify and communicate significant architectural gaps to product and service providers

Apart from the generic goals related to quality assurance outlined above, there are additional, more politically-oriented motivations for conducting Architecture Compliance reviews, which may be relevant in particular cases:

The Architecture Compliance review can be a good way of deciding between architectural alternatives, since the business decision-makers typically involved in the review can guide decisions in terms of what is best for the business, as opposed to what is technically more pleasing or elegant
The output of the Architecture Compliance review is one of the few measurable deliverables to the CIO to assist in decision-making
Architecture reviews can serve as a way for the architecture organization to engage with development projects that might otherwise proceed without involvement of the architecture function
Architecture reviews can demonstrate rapid and positive support to the enterprise business community:
    The Enterprise Architecture and Architecture Compliance helps ensure the alignment of IT projects with business objectives
    Architects can sometimes be regarded as being deep into technical infrastructure and far removed from the core business
    Since an Architecture Compliance review tends to look primarily at the critical risk areas of a system, it often highlights the main risks for system owners

While compliance to architecture is required for development and implementation, non-compliance also provides a mechanism for highlighting:

Areas to be addressed for realignment
Areas for consideration for integration into the architectures as they are uncovered by the compliance processes

The latter point identifies the ongoing change and adaptability of the architectures to requirements that may be driven by indiscipline, but also allows for changes to be registered by faster moving changes in the operational environment. Typically, dispensations (see 44.1.4 IT Governance) will be used to highlight these changes and set in motion a process for registering, monitoring, and assessing the suitability of any changes required.

Timing

Timing of compliance activities should be considered with regard to the development of the architectures themselves. Compliance reviews are held at appropriate project milestones or checkpoints in the project's lifecycle. Architecture project timings for assessments should include:

Project initiation
Initial design
Major design changes
Ad hoc

The Architecture Compliance review is typically targeted for a point in time when business requirements and the Enterprise Architecture are reasonably firm, and the project architecture is taking shape, well before its completion.

The aim is to hold the review as soon as practical, at a stage when there is still time to correct any major errors or shortcomings, with the obvious proviso that there needs to have been some significant development of the project architecture in order for there to be something to review.

Inputs to the Architecture Compliance review may come from other parts of the standard project lifecycle, which may have an impact on timing.

Steps

Identify responsible part of organization and relevant project principals.
Identify Lead Enterprise Architect and other architects.
Determine scope of review.
- Identify which other business units/departments are involved.
- Understand where the system fits in the corporate architecture framework.
Interview project principals : use checklists.
Analyze completed checklists.
- Review against corporate standards.
- Identify and resolve issues.
- Determine recommendations.
Prepare Architecture Compliance review report.
Accept review and sign off.

Architecture Compliance Review Checklists

The following review checklists provide a wide range of typical questions that may be used in conducting Architecture Compliance reviews, relating to various aspects of the architecture. The organization of the questions includes the basic disciplines of system engineering, information management, security, and systems management. The checklists are based on material provided by a member of The Open Group, and are specific to that organization. Other organizations could use the following checklists with other questions tailored to their own particular needs.

The checklists provided contain too many questions for any single review: they are intended to be tailored selectively to the project concerned (see 42.6 Architecture Compliance Review Guidelines). The checklists actually used will typically be developed/selected by subject matter experts. They are intended to be updated annually by interest groups in those areas.

Some of the checklists include a brief description of the Architecture Principle that provokes the question, and a brief description of what to look for in the answer. These extensions to the checklist are intended to allow the intelligent re-phrasing of the questions, and to give the user of the checklist a feel for why the question is being asked.

Occasionally the questions will be written, as in RFPs, or in working with a senior project architect. More typically they are expressed orally, as part of an interview or working session with the project.

The checklists provided here are designed for use in individual architecture projects, not for business domain architecture or for architecture across multiple projects. (Doing an architecture review for a larger sphere of activity, across multiple business processes and system projects, would involve a similar process, but the checklist categories and their contents would be different.)

Hardware and Operating System Checklist

Software Services and Middleware Checklist

Describe how error conditions are defined, raised, and propagated between application components.
Describe the general pattern of how methods are defined and arranged in various application modules.
Describe the general pattern for how method parameters are defined and organized in various application modules. Are [in], [in/out], [out] parameters always specified in the same order? Do Boolean values returned by modules have a consistent outcome?
Describe the approach that is used to minimize the number of round-trips between client and server calls, particularly for out-of-process calls, and when complex data structures are involved.
Describe the major data structures that are passed between major system components.
Describe the major communication protocols that are used between major system components.
Describe the marshaling techniques that are used between various system components. Describe any specialized marshaling arrangements that are used.
Describe to what extent the system is designed with stateful and stateless components.
Describe how and when state is saved for both stateful and stateless components.
Describe the extent to which objects are created, used, and destroyed versus re-used through object pooling.
Describe the extent to which the system relies on threading or critical section coding.
Describe the approach and the internal documentation that is used internally in the system to document the methods, methods arguments, and method functionality.
Describe the code review process that was used to build the system.
Describe the unit testing that has been used to test the system components.
Describe the pre- and post-condition testing that is included in various system modules.
Describe the assertion testing that is included with the system.
Do components support all the interface types they need to support or are certain assumptions made about what types of components will call other components either in terms of language bindings or other forms of marshaling?
Describe the extent to which big-endian or little-endian data format problems need to be handled across different platforms.
Describe if numbers or strings need to be handled differently across different platforms.
Describe whether the software needs to check for floating-point round-off errors.
Describe how time and date functions manage dates so as to avoid improper handling of time and date calculation or display.
Describe what tools or processes have been used to test the system for memory leaks, reachability, or general robustness.
Describe the layering of the systems services software. Describe the general number of links between major system components. Is the system composed of a lot of point-to-point interfaces or are major messaging backbones used instead?
Describe to what extent the system components are either loosely coupled or tightly coupled.
What requirements does the system need from the infrastructure in terms of shared libraries, support for communication protocols, load balancing, transaction processing, system monitoring, naming services, or other infrastructure services?
Describe how the system and system components are designed for refactoring.
Describe how the system or system components rely on common messaging infrastructure versus a unique point-to-point communication structure.

Applications Checklists

Infrastructure (Enterprise Productivity) Applications

Business Applications

Application Integration Approach

Information Management Checklists

Data Values

Data Definition

Security/Protection

Hosting, Data Types, and Sharing

Common Services

Access Method

Security Checklist

Identification/Authentication: Diagram the process flow of how a user is identified to the application and how the application authenticates that the user is who they claim to be. Provide supporting documentation to the diagram explaining the flow from the user interface to the application/database server(s) and back to the user. Are you compliant with corporate policies on accounts, passwords, etc.?
Authorization: Provide a process flow from beginning to end showing how a user requests access to the application, indicating the associated security controls and separation of duties. This should include how the request is approved by the appropriate data owner, how the user is placed into the appropriate access-level classification profile, how the user ID, password, and access is created and provided to the user. Also include how the user is informed of their responsibilities associated with using the application, given a copy of the access agreement, how to change password, who to call for help, etc.
Access Controls: Document how the user IDs, passwords, and access profiles are added, changed, removed, and documented. The documentation should include who is responsible for these processes.
Sensitive Information Protection: Provide documentation that identifies sensitive data requiring additional protection. Identify the data owners responsible for this data and the process to be used to protect storage, transmission, printing, and distribution of this data. Include how the password file/field is protected. How will users be prevented from viewing someone else's sensitive information? Are there agreements with outside parties (partners, suppliers, contractors, etc.) concerning the safeguarding of information? If so, what are the obligations?
Audit Trails and Audit Logs: Identify and document group accounts required by the users or application support, including operating system group accounts. Identify and document individual accounts and/or roles that have superuser type privileges, what these privileges are, who has access to these accounts, how access to these accounts is controlled, tracked, and logged, and how password change and distribution are handled, including operating system accounts. Also identify audit logs, who can read the audit logs, who can modify the audit logs, who can delete the audit logs, and how the audit logs are protected and stored. Is the user ID obscured in the audit trails?
External Access Considerations: Will the application be used internally only? If not, are you compliant with corporate external access requirements?

System Management Checklist

What is the frequency of software changes that must be distributed?
What tools are used for software distribution?
Are multiple software and/or data versions allowed in production?
What is the user data backup frequency and expected restore time?
How are user accounts created and managed?
What is the system license management strategy?
What general system administration tools are required?
What specific application administration tools are required?
What specific service administration tools are required?
How are service calls received and dispatched?
Describe how the system is uninstalled.
Describe the process or tools available for checking that the system is properly installed.
Describe tools or instrumentation that are available that monitor the health and performance of the system.
Describe the tools or process in place that can be used to determine where the system has been installed.
Describe what form of audit logs are in place to capture system history, particularly after a mishap.
Describe the capabilities of the system to dispatch its own error messages to service personnel.

System Engineering/Overall Architecture Checklists

General

What other applications and/or systems require integration with yours?
Describe the integration level and strategy with each.
How geographically distributed is the user base?
What is the strategic importance of this system to other user communities inside or outside the enterprise?
What computing resources are needed to provide system service to users inside the enterprise? Outside the enterprise and using enterprise computing assets? Outside the enterprise and using their own assets?
How can users outside the native delivery environment access your applications and data?
What is the life expectancy of this application?
Describe the design that accommodates changes in the user base, stored data, and delivery system technology.
What is the size of the user base and their expected performance level?
What performance and stress test techniques do you use?
What is the overall organization of the software and data components?
What is the overall service and system configuration?
How are software and data configured and mapped to the service and system configuration?
What proprietary technology (hardware and software) is needed for this system?
Describe how each and every version of the software can be reproduced and re-deployed over time.
Describe the current user base and how that base is expected to change over the next three to five years.
Describe the current geographic distribution of the user base and how that base is expected to change over the next three to five years.
Describe how many current or future users need to use the application in a mobile capacity or who need to work off-line.
Describe what the application generally does, the major components of the application, and the major data flows.
Describe the instrumentation included in the application that allows for the health and performance of the application to be monitored.
Describe the business justification for the system.
Describe the rationale for picking the system development language over other options in terms of initial development cost versus long-term maintenance cost.
Describe the systems analysis process that was used to come up with the system architecture and product selection phase of the system architecture.
Who besides the original customer might have a use for or benefit from using this system?
What percentage of the users use the system in browse mode versus update mode?
What is the typical length of requests that are transactional?
Do you need guaranteed data delivery or update, or does the system tolerate failure?
What are the up-time requirements of the system?
Describe where the system architecture adheres or does not adhere to standards.
Describe the project planning and analysis approach used on the project.

Processors/Servers/Clients

Describe the client/server Application Architecture.
Annotate the pictorial to illustrate where application functionality is executed.

Client

Are functions other than presentation performed on the user device?
Describe the data and process help facility being provided.
Describe the screen-to-screen navigation technique.
Describe how the user navigates between this and other applications.
How is this and other applications launched from the user device?
Are there any inter-application data and process sharing capabilities? If so, describe what is being shared and by what technique/technology.
Describe data volumes being transferred to the client.
What are the additional requirements for local data storage to support the application?
What are the additional requirements for local software storage/memory to support the application?
Are there any known hardware/software conflicts or capacity limitations caused by other application requirements or situations which would affect the application users?
Describe how the look-and-feel of your presentation layer compares to the look-and-feel of the other existing applications.
Describe to what extent the client needs to support asynchronous and/or synchronous communication.
Describe how the presentation layer of the system is separated from other computational or data transfer layers of the system.

Application Server

Can/do the presentation layer and application layers run on separate processors?
Can/do the application layer and data access layer run on separate processors?
Can this application be placed on an application server independent of all other applications? If not, explain the dependencies.
Can additional parallel application servers be easily added? If so, what is the load balancing mechanism?
Has the resource demand generated by the application been measured and what is the value? If so, has the capacity of the planned server been confirmed at the application and aggregate levels?

Data Server

Are there other applications which must share the data server? If so, identify them and describe the data and data access requirements.
Has the resource demand generated by the application been measured and what is the value? If so, has the capacity of the planned server been confirmed at the application and aggregate levels?

COTS (where applicable)

Is the vendor substantial and stable?
Will the enterprise receive source code upon demise of the vendor?
Is this software configured for the enterprise's usage?
Is there any peculiar A&D data or processes that would impede the use of this software?
    Is this software currently available?
Has it been used/demonstrated for volume/availability/service-level requirements similar to those of the enterprise?
    Describe the past financial and market share history of the vendor.

System Engineering/Methods & Tools Checklist

Do metrics exist for the current way of doing business?
Has the system owner created evaluation criteria that will be used to guide the project? Describe how the evaluation criteria will be used.
Has research of existing architectures been done to leverage existing work? Describe the method used to discover and understand. Will the architectures be integrated? If so, explain the method that will be used.
Describe the methods that will be used on the project:
    For defining business strategies
    For defining areas in need of improvement
    For defining baseline and target business processes
    For defining transition processes
    For managing the project
    For team communication
    For knowledge management, change management, and configuration management
    For software development
    For referencing standards and statements of direction
    For quality assurance of deliverables
    For design reviews and deliverable acceptance
    For capturing metrics
Are the methods documented and distributed to each team member?
To what extent are team members familiar with these methods?
What processes are in place to ensure compliance with the methods?
Describe the infrastructure that is in place to support the use of the methods through the end of the project and anticipated releases.
    How is consultation and trouble-shooting provided?
    How is training co-ordinated?
    How are changes and enhancements incorporated and cascaded?
    How are lessons learned captured and communicated?
What tools are being used on the project? (Specify versions and platforms). To what extent are team members familiar with these tools?
Describe the infrastructure that is in place to support the use of the tools through the end of the project and anticipated releases.
    How is consultation and trouble-shooting provided?
    How is training co-ordinated?
    How are changes and enhancements incorporated and cascaded?
    How are lessons learned captured and communicated?
Describe how the project will promote the re-use of its deliverables and deliverable content.
Will the architecture designs "live" after the project has been implemented? Describe the method that will be used to incorporate changes back into the architecture designs.
Were the current processes defined?
Were issues documented, rated, and associated to current processes? If not, how do you know you are fixing something that is broken?
Were existing/planned process improvement activities identified and associated to current processes? If not, how do you know this activity is not in conflict with or redundant to other Statements of Work?
Do you have current metrics? Do you have forecasted metrics? If not, how do you know you are improving something?
What processes will you put in place to gather, evaluate, and report metrics?
What impacts will the new design have on existing business processes, organizations, and information systems? Have they been documented and shared with the owners?