Technical Architect Questions & Answer

Whether formal or informal, data modeling is an essential part of many corporate enterprise application development and data management projects.

A data model is a way of “describing what sort of data will be held and how it will be organized.” (Simsion and Witt 2004) Data models provide “a set of concepts that can be used to describe the structure of and operations on a database.” (Navathe 1992). Instead of relying on the habits of each individual project manager or database administrator, data models provide a formalized methodology for designing databases that incorporates several levels of functionality and data relations.

A well planned project has a well planned Communication strategy. The high-level items that should be covered in the Communications Plan are:
■ Introduction
■ Methods for Gathering and Storing Information
■ Distribution Structure
■ Formal Project Communication Matrix
■ Signoff Page

In project management, a project charter or project definition is a statement of the scope, objectives and participants in a project. It provides a preliminary delineation of roles and responsibilities, outlines the project objectives, identifies the main stakeholders, and defines the authority of the project manager. It serves as a reference of authority for the future of the project. The terms of reference is usually part of the project charter.

The project charter is usually a short document that refers to more detailed documents such as a new offering request or a request for proposal.

A service-level agreement (SLA) is a part of a service contract where the level of service is formally defined.

SLAs are also defined at different levels:

Customer-based SLA: An agreement with an individual customer group, covering all the services they use. For example, an SLA between a supplier (IT service provider) and the finance department of a large organization for the services such as finance system, payroll system, billing system, procurement/purchase system, etc.
Service-based SLA: An agreement for all customers using the services being delivered by the service provider. For example:
A car service station offers a routine service to all the customers and offers certain maintenance as a part of offer with the universal charging.
A mobile service provider offers a routine service to all the customers and offers certain maintenance as a part of offer with the universal charging
An email system for the entire organization. There are chances of difficulties arising in this type of SLA as level of the services being offered may vary for different customers (for example, head office staff may use high-speed LAN connections while local offices may have to use a lower speed leased line).
Multilevel SLA: The SLA is split into the different levels, each addressing different set of customers for the same services, in the same SLA.
Corporate-level SLA: Covering all the generic service level management (often abbreviated as SLM) issues appropriate to every customer throughout the organization. These issues are likely to be less volatile and so updates (SLA reviews) are less frequently required.
Customer-level SLA: covering all SLM issues relevant to the particular customer group, regardless of the services being used.
Service-level SLA: covering all SLM issue relevant to the specific services, in relation to this specific customer group.

Incident Management (IcM) is an IT service management (ITSM) process area. The first goal of the incident management process is to restore a normal service operation as quickly as possible and to minimize the impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. 'Normal service operation' is defined here as service operation within service-level agreement (SLA). It is one process area within the broader ITIL and ISO 20000 environment. Incidents are the result of failures or errors in the IT infrastructure. The cause of Incidents may be apparent and the cause may be addressed without the need for further investigation, resulting in a repair, a Work-around or a request for change (RFC) to remove the error.

Where an incident is considered to be serious in nature, or multiple occurrences of similar incidents are observed, a problem record might be created as a result (it's possible that the problem will not be recorded until several incidents have occurred). The management of a problem varies from the process of managing an incident and is typically performed by different staff and therefore is controlled by the problem management process. When its 'root cause' has been identified, it becomes a 'known error'. Finally, a request for change (RFC) may be raised to modify the system by resolving the known error. This process is covered by the change management process.

Capacity Management is a process used to manage information technology (IT). Its primary goal is to ensure that IT capacity meets current and future business requirements in a cost-effective manner. One common interpretation of Capacity Management is described in the ITIL framework
These activities are intended to optimize performance and efficiency, and to plan for and justify financial investments. Capacity management is concerned with:
1. Monitoring the performance and throughput or load on a server, server farm, or property
2. Performance analysis of measurement data, including analysis of the impact of new releases on capacity
3. Performance tuning of activities to ensure the most efficient use of existing infrastructure
4. Understanding the demands on the Service and future plans for workload growth (or shrinkage)
5. Influences on demand for computing resources
6. Capacity planning – developing a plan for the Service

1. Excessive Privilege Abuse
2. Legitimate Privilege Abuse
3. Privilege Elevation
4. Database Platform Vulnerabilities
5. SQL Injection
6. Weak Audit Trail
7. Denial of Service 8. Database Communication Protocol Vulnerabilities
9. Weak Authentication
10. Backup Data Exposure

Aspect-oriented programming entails breaking down program logic into distinct parts (so-called concerns, cohesive areas of functionality). Nearly all programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g., procedures, modules, classes, methods) that can be used for implementing, abstracting and composing these concerns. But some concerns defy these forms of implementation and are called crosscutting concerns because they "cut across" multiple abstractions in a program.

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem
The five basic concepts of object-oriented design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

1. Object/Class: A tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is created based on a class). Each object serves a separate function. It is defined by its properties, what it is and what it can do. An object can be part of a class, which is a set of objects that are similar.
2. Information hiding: The ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class.
3. Inheritance: The ability for a class to extend or override functionality of another class. The so-called subclass has a whole section that is derived (inherited) from the superclass and then it has its own set of functions and data.
4. Interface: The ability to defer the implementation of a method. The ability to define the functions or methods signatures without implementing them.
5. Polymorphism: The ability to replace an object with its subobjects. The ability of an object-variable to contain, not only that object, but also all of its subobjects.

SDLC or systems development life cycle is the complete processes involved in the development of the software application. Generally, the software development life cycle follows broadly the steps as described:

a) Project Initiation: This is the stage where the initial feasibility of the project is done with the stakeholder management and actually laying the foundation of the software project.

b) Requirements Analysis: This is the stage where the stakeholder needs are analyzed, structured and documented.

c) Software Design: The requirements captured in the previous phase are converted into a viable solution design by the analyst and the solutions team.

d) Development or Coding: The actual programming or coding of the project happens in this stage and its essential that the actual requirements have been frozen.

e) Testing: This stage involves the various testing phases such as unit, integration, system , regression testing. The final acceptance testing is done by the users so as to test that there are no gaps in the requirements they signed off and the final delivery.

f) Deployment and support: This is final “go live” stage of the project where the system is deployed on client site and maintenance and support of the system is provided for a  previously agreed upon period of time.

 There are various SDLC methodologies which have developed over the past and guide us through the software development life cycles. The major SDLC methodologies are :

1) Waterfall method – this is the original model of SDLC and was one of the most widely used systems development process till the more advances software methodologies came up. Its still used in many major software projects and as with any other methodologies has its pros and cons. It is beloved to be very rigid in its structure and is believed not to have a very client friendly approach.

2) Rapid Application development (RAD) – To counter the traditional, non agile software development processes, RAD was brought forward which involves iterative development and more interaction with the client at all stages of the project life cycle.

3) Prototyping Model – This model even though not very popular is a very useful methodology especially to the client. This is because it involves the presentation of a simplified prototype of the system based on the requirements gathered and analysed. So, based on the client's feedback on the prototype the rest of the software development process takes place.

4) Spiral model  - its an amalgamation of the waterfall and the prototyping method, in which after an initial version of the prototype is evaluated by the customer and the next version is developed. Each iteration in between follows the phases of the waterfall model.

5) Usually, a hybrid of these SDLC methodologies are also used as they are the best fit for the success of the software project. Depending upon the project time lines, cost and customer expectations, the SDLC methodology should be selected as each methodology has its own advantages and disadvantages.