This section covers the Q&A for the frameworks and nonfunctional requirements domain. An architecture framework provides principles and practices for creating and using the architecture description of a system. It structures architects' thinking by dividing the architecture description into domains, layers or views, and offers models-typically metrics and diagrams-to document each view.
This section also covers the solutioning of NFRs, providing insights into how they will be addressed in the solutioning phase. This section covers the key NFRs that are most critical for any project. For each NFR, it provides the various alternatives pertaining to the solution and the design principle that needs to be applied to achieve the desired outcome, for example, high availability, scalability, or reliability.
Enterprise architecture frameworks drive the creation and governance of enterprise architecture. A framework is a collation of best practices, principles, and practices for creating the architecture definitions. It structures the thinking of architects by segregating the architecture into domains, layers or views, tiers, and models. The components of a framework provide guidance in three main areas:
- Descriptions of architecture deal with documenting the enterprise from various viewpoints. Each view describes one aspect of the architecture; it includes entities and relationships that address specific concerns of the key stakeholders.
- Methods for designing the architecture deal with processes that the SMEs adapt. The EA methodology is composed of different domains, and deep-dives into lower-level processes consisting of fine-grained tasks. A process is defined by objectives, inputs, activities, and outputs. This would be complemented via approaches, tools, principles, and practices.
- Organization of architects is the guidance around the team structure consisting of governance, skills, experience, and training and enablement.
The Open Group Architecture Framework (TOGAF) is an enterprise architecture framework that defines a comprehensive approach to planning, architecting, implementation, and governance of enterprise architectures.
TOGAF defines the enterprise as four architecture domains: business, application, technology, and data. It consists of a methodology for defining an architecture in terms of building blocks and is an iterative process. It also contains a set of tools, vocabulary, standards, principles, and compliance tools. TOGAF contains an iterative methodology for defining enterprise architecture, called Architecture Development Method (ADM). TOGAF needs to be tailored before adopting it for an organization, and this is a one-time activity:
Figure 1: Four architectural domains
Probability indicator: 
The ADM is the core entity of the TOGAF framework. This is the methodology for defining organization-specific enterprise architectures. ADM is a framework that provides repeatable processes for defining and implementing organization-specific enterprise architectures. ADM establishes the architecture framework, developing and governing the architecture content. These activities are carried out in an iterative cycle, facilitating the transformation of their enterprises in response to business goals. The ADM is described as a number of phases within a process of change, illustrated by an ADM cycle graphic. Phases within the ADM are as follows:
Figure 2: TOGAF ADM
Probability indicator: 
TOGAF consists of the following four architecture domains:
|
Domain |
Description |
|
Business architecture |
The business strategy, business processes, governance, and organization. |
|
Data architecture |
The logical and physical data assets, and data management resources and tools. |
|
Application architecture |
A blueprint of application systems, interactions, and relationships with the business processes. |
|
Technology architecture |
The infrastructure's capabilities to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, and communications. |
Table 1: TOGAF Domains
Probability indicator:
Enterprise continuum is a framework for structuring the organization's architecture assets and provides guidelines and methods for classifying architecture assets, also describing how they can be leveraged. This is based on assets such as models, standards, frameworks, and patterns that exist in the enterprise and in the industry at large, and also which the enterprise has created while developing the architectures. The architecture repository is a structure of a physical instance of enterprise continuum.
Figure 3: TOGAF architecture repository
Probability indicator:
The following is the list of TOGAF certified tools:
|
Tools |
Description |
|
Troux platform |
The Troux platform defines a best-in-class tool in each critical capability area, delivering the information capabilities required to understand the relationships between IT and business and answer key business questions. |
|
ARIS |
This is a modeling tool for business process analysis and management. It supports different modeling standards such as Business Process Model and Notation (BPMN), Event-driven Process Chains (EPC), organizational charts, and process landscapes. |
|
iServer |
iServer is a unified software platform that provides an easy-to-use, collaborative modeling tool that extends Microsoft Office and Visio. Core components include a Microsoft Visio interface, a powerful repository for architecture, process and governance models; and a range of tools for presentation, analysis, and decision making. |
|
System architect |
IBM rational architect is an EA tool leveraged to model businesses and IT applications and databases that support them. System architect is leveraged to build architectures using various frameworks, including TOGAF and Zachman. |
|
ABACUS |
ABACUS is a tool used for enterprise architecture and process modeling, and supports key frameworks. ABACUS includes multiple architecture alternatives and runs calculations for each alternative metric such as cost, agility, performance, and reliability. |
Table 2: TOGAF tools
Probability indicator:
The Zachman framework is an EA framework that provides a methodology for defining an enterprise according to a 6 x 6 architecture matrix. This framework was initially developed at IBM by John Zachman. The columns of this framework consist of questions like why, how, what, who, where, and when. The rows consist of questions such as contextual, conceptual, logical, physical, and detailed.
Zachman framework provides views for various roles, including planners, owners, designers, builders, and contractors. This creates a holistic view that enables different stakeholders to view the enterprise from different perspectives:
Figure 4: Zachman framework
Probability indicator: 
Agile is a methodology for organizations to produce IT solutions and products by ensuring that they bundle their solutions and products by business-driven factors, which we know as requirements, features, enhancements, and fixes. Agile is a way of building solutions and products by leveraging optimized increments that resemble the iterative and incremental methodology. The key to the Agile methodology is that it ensures that risks are at bay. The older methodologies have galvanized into Agile, and Agile is a derivative of its predecessor's best practices.
One sprint of agile includes analysis, design, build, testing, and deployment. There would be multiple such sprints across the entire project life cycle. The following diagram depicts a comparison:
|
Agile |
Traditional |
|
Incremental value and risk management |
Phased approach with an attempt to know everything at the start |
|
Embracing change |
Change prevention |
|
Delivery early, fail early |
Delivers value at the end; also fails at the end |
|
Transparency |
Detailed planning and stagnant control |
|
Inspect and adapt |
Meta Solution with tightly controlled procedures and answers |
|
Self-managed |
Command and control |
|
Continual learning |
Learning is secondary |
Table 3: Agile versus Traditional
Agile leverages light-weight methodologies such as SCRUM, Extreme Programming (XP), and Rapid Application Development (RAD). These methodologies focus on the development of solutions in an iterative manner. Scrum is also one of the agile methods, used to develop information systems iteratively. In this technique, a small team typically works on the assigned tasks for a time period of 30 days.
Probability indicator:
Requirement prioritization is leveraged to identify requirements for a given release. The requirements prioritized ensure that the risk is minimized, so high-risk requirements are implemented first. There are a number of possible business considerations, including value, cost, risk, difficulty in implementation, likelihood of success, stakeholder agreement, and urgency, each of which is described in more detail here:
- Value: This approach focuses on the business value of the requirement. The requirements that will create the greatest business value are given the highest priority. This helps to ensure quick wins for the organization.
- Cost: Implementing the least expensive requirements first or implementing requirements with the greatest return on investment (ROI), and the alternatives for this option.
- Risk: This is basically the risk associated with the requirement's implementations and will be prioritized from low to high risks.
- Dependencies: This is typically the relationship between requirements and will require the completion of another requirement first before it can be taken up.
- Regulatory compliance: These are the requirements that must be implemented to meet the regulatory policies.
There are numerous prioritization techniques that are leveraged today; we have listed some of the more frequently used techniques here:
- Cost-value approach: The principle is to determine for an identified requirement the implementation cost and the business value it provides. The key is, for the identified requirements, we assess the value or cost comparing them.
- Numerical assignment grouping: This method is based on grouping requirements into different priority groups with each group representing value for stakeholders. For example, requirements can be grouped into critical, moderate, and optional priorities. Stakeholders may also classify requirements as compulsory, very important, rather important, and not important in order to describe their importance. To prevent stakeholders from putting all requirements in one category, the percentage of requirements that can be put in each group should be restricted.
- MoScoW technique: Instead of numbers, this method uses four priority groups: MUST have, SHOULD have, COULD have, and WON'T have. With this technique, stakeholders can prioritize requirements in a collaborative fashion. The acronym represents the following:
- MUST: Mandatory
- SHOULD: high priority
- COULD: Preferred but not mandatory
- WOULD: Can be postponed and suggested for the future
- Timeboxing: Timeboxing or budgeting is leveraged when there are fixed timelines and budgets for the project. It is leveraged in projects where the delivery of the project is as important as the project being delivered on time and developed within budget. This technique is based on the paradigm that it is important to release the product with the basic product features on time rather than building all features and launching the product at a later date.
- Voting: When there are many requirements that need to be categorized, voting is one of the best ways to sort out the prioritization of requirements. Typically the requirement with the highest points will be chosen for implementation in the initial iterations.
Probability indicator:
A project charter artifact outlines the existing project and provides project manager (PM) with the confirmation to initiate the work proceedings for the project. The artifact helps the PM to communicate the stakeholders, goals, objective, IT roadmap, cost, resources, risks, and how successful completion will help the enterprise. Based on organizational culture, the charter serves a similar purpose as a business case. In large enterprises, the charter is a multi-page document written by the mid-level management after a business case has been finalized. In small organizations the charter is a few paragraphs with bulleted items and is signed by the company's senior executive. A project charter includes the following:
- Organizational goal-the drive for undertaking the initiative
- Stakeholders involved in the project and their roles and responsibilities
- Business and functional requirements of the organization to be fulfilled
- Potential risks and roadblocks
- Important milestones including the start date and end date
- Protocol leveraged by the PM to communicate with stakeholders
- Deliverables, assets, artifacts, products, processes, or services the project produces upon completion
Probability indicator:
Reference architecture is a template, methodology, practice, and standards based on a set of successful solutions in the past. These are generalized solutions depicting logical and physical architecture views, and are based on harvesting a set of patterns, standards and best practices in successful solutions in the past. This is a critical reference asset for the architecture engagements which the enterprise can implement to solve business problems. It provides multiple views to different stakeholders and is the starting point or the point of comparisons for business entities. Major artifacts of the reference architecture are methodologies, standards, metadata, documents, and patterns. Examples of reference architecture are:
- TAM
- SID
- Integration frameworks
- eTOM business processes
Probability indicator:
Benchmarking is about measuring the performance of an organization to compete in the industry. It is a strategic tool for portfolio analysis and strategic management. In this process, a company measures its policies, performance, rules, and other critical KPIs and metrics.
Benchmarking involves examining how others achieve their performance levels and understanding the processes they have leveraged. When lessons learned from a benchmarking exercise are applied appropriately, they facilitate improved performance in critical functions or in key business areas.
The application of benchmarking involves these key steps:
- Understand the existing business processes
- Analyze the business processes of the competitor, including industry standards and best practices
- Compare the current business performance with these industry standards, reference business processes frameworks, and competitors
- Identify gaps, issues, and challenges on the basis of the deep dive analysis of the earlier steps
- Plan a road map to implement the steps necessary to close the performance gap
To be effective, the benchmarking mechanism must become an integral part of an ongoing process; the goal is to stay abreast of industry best practice and trends.
There are two primary types of benchmarking:
- Internal benchmarking is a comparison of practices and performance between teams, SMEs, or groups within the same organization
- External benchmarking is a comparison of organizational performance with its industry peers or across industries
These can be further segregated as follows:
- Process benchmarking: This demonstrates how top-performing organizations accomplish a specific business process. This benchmarking data is collected via research, surveys, and interviews. By understanding how the peer performs for the same functional task or objective, organizations provides critical insight. Such information affirms and supports decision-making by SMEs.
- Performance metrics: Performance metrics give numerical standards, which are nothing but best practices against which an organization's own processes can be compared. These metrics are usually determined via a detailed survey and interviews. Organizations can identify performance gaps and issues and then conduct follow-on analyses to determine methods of improvement.
- Strategic benchmarking: This means identifying the winning strategies that have enabled high performing organizations to be successful in their market. Strategic benchmarking examines how organizations compete and is ideal for corporations with a long-term goal in mind.
Figure 5: Benchmarking
Probability indicator:
The technique to assess business value consists of defining a matrix based on a business value and a risk on the XY axis. The value index includes parameters such as compliance, financials, strategic alignment, and market position. The risk index includes parameters such as size, complexity, technology, capacity, and impact of failure. Each parameter is then assigned an appropriate weight. The index, criteria, and weights are approved by the senior management and this establishes the decision-making criteria.
This is the approach leveraged for finding the business value of user stories:
- We first decide what values (or benefits) we want to achieve before launching a project or product.
- Then we find and improve the business processes that deliver that value.
- Then we find and improve the supporting business processes that make the value delivering processes possible.
- When the team needs user stories, we take the processes with the highest value and break them down into user stories at the right level of granularity for the team's needs. The team pulls the stories, so we only generate a minimal set of user stories.
The following is the approach for business value modeling:
- Identify all the relevant stakeholders
- Define their objectives and goals for the organization's initiatives
- Establish a mechanism to measure the achievement of the organizational goals
- Identify the most important measurements and tests-Value Drivers
- Define the relationship between the different Value Drivers
- Leverage the Value Drivers to focus on and prioritize the initiatives for the organization's road map
Figure6: Business Value Analysis
Probability indicator:
Continuous Integration (CI), is creating software and testing it multiple times with every iteration. Different tools that support this methodology are Hudson, Jenkins, and Bamboo where Jenkins is the most popular one. They are integrated with version control systems and IDE. Deploying tools for Continuous Integration is very easy, but leveraging and establishing best practices for Continuous Integration methodology is complex.
Key considerations for CI:
- How often is code committed? If the code is committed once a day or week, the CI setup is underutilized and may defeat the purpose of CI.
- How is a failure handled and is immediate action taken? Do failures promote fun in the team?
- What are the steps in continuous integration?
- Compilation
- Unit testing
- Code quality check point
- Integration testing
- Deployment
- Chain testing
- Additional steps in continuous integration may take more time but result in a more stable application.
- How much time does Continuous Integration take? One option is to reduce the time and ensure that we have immediate feedback is to split the long-running tests into a separate build that runs less often.
The following are the benefits of continuous integration:
- Defects found early will cost less: When defects are found early during or after coding, it takes 10 times less to fix it compared to finding the defect at a later stage of the SDLC.
- Reduced Time to Market: Software is always tested, so it is always ready to move to the next environment.
Probability indicator:
Dependency injection is a software design pattern providing inversion of control for resolving dependencies. A dependency is an object that is injected by passing this dependency to a client and is made part of the state of the client's. Passing the object to the client, rather than building or the service, is the fundamental essence of this pattern.
Dependency injection allows a program to leverage the dependency inversion pattern by delegating to external code the responsibility of providing its dependencies. It is the injecting code that constructs the object and calls the client to inject themselves and the client is not allowed to call the injector function. The client code does not need to know the injecting code, construction mechanism and the services it is using. The client only needs to know the interfaces of the services because these define the use of services. Following are the benefits of Continuous Integration:
- Reduced dependencies
- Reduced dependency carrying
- More reusable code
- More testable code
- More readable code
Information Technology Infrastructure Library (ITIL) is a set of best practices and standards for service management, development and operations. ITIL defines a number of important concepts including checklists, tasks, and procedures that can be tailored for specific organizations ITIL goals. In the service domain, ITIL includes support desk, incident, problem, change, release and configuration management. In the service delivery domain, it includes service-level management, capacity management, and service continuity management.
The ITIL framework includes:
- Service support
- Service delivery
- ICT infrastructure management
- Security management
- Application management
- Software asset management
The benefits of ITIL:
- Develops a long term relationships with the customers by delivering efficient services that meets the business demands
- Establishes cost-efficient framework for managing demand for these the services
- Manages business change while ensuring a stable service environment
- Enables stronger alignment between business and IT
- Enhances IT service delivery and customer engagement
- Produces greater visibility of IT costs, organizational assets, and transparency
- Provide better management of organizational risk and service disruption and failure
- Enables a stable service environment to support constant business change
The barriers for ITIL:
- Little short-run payback as benefits accrue slowly over time
- Implementation is a long process requiring extensive training
- Imposing changes on the organization can be disruptive
- The predictive approach may lack flexibility
- Sustained efforts are easily disrupted by short-term needs
The capabilities of the ITIL framework are as follows:
Figure 7: Information Technology Infrastructure Library (ITIL)
Probability indicator: