Develop System Infrastructure Design Plan

Understanding architecture requirements

Architecture is from the Latin word architectura, which is formed from the words for architect.
Depending on the context, architecture can refer to:
 any man-made building or structure
 the flow of information on a Web page
 the planned design of any kind of system
 a systematic arrangement of information or ideas

The term architecture can refer to either hardware or software, or to a combination of hardware and
software. The architecture of a system always defines its broad outlines, and may define precise
mechanisms as well.
Architecture is overall structure of the system. it is the structure, including the principles and guidelines
governing their design and evolution over time.
The architecture of a software system defines that system in terms of computational components and
interactions among those components.
Architecture focuses on how the major elements and components within an application are
used by, or interact with, other major elements and components within the application.
Various organizations define systems architecture in different ways, including:

 The fundamental organization of a system, embodied in its components, their relationships to each
other and to the environment, and the principles governing its design and evolution.
 A representation of a system, including a mapping of functionality onto hardware and software
components, a mapping of the software architecture onto the hardware architecture, and human
interaction with these components.
 An allocated arrangement of physical elements which provides the design solution for a consumer
product or life-cycle process intended to satisfy the requirements of the functional architecture and the
requirements baseline.
 An architecture comprises the most important, pervasive, top-level, strategic inventions, decisions,
and their associated rationales about the overall structure (i.e., essential elements and their
relationships) and associated characteristics and behavior.
 A description of the design and contents of a computer system. If documented, it may include
information such as a detailed inventory of current hardware, software and networking capabilities; a
description of long-range plans and priorities for future purchases, and a plan for upgrading and/or
replacing dated equipment and software.
 A formal description of a system, or a detailed plan of the system at component level to guide its
implementation.
 The composite of the design architectures for products and their life-cycle processes.
1
Develop System Infrastructure Design Plan

 The structure of components, their interrelationships, and the principles and guidelines governing their
design and evolution over time.

Key characteristics of an architecture requirement

 It should describe a necessary change to components in an architecture. This might mean adding
new components, removing outdated ones, replacing or improving components, or changing the
way in which they are organized and how they work together.
 It should include the reasoning or motivations behind the change.
 It should explain why the existing components are inadequate, limiting or constraining
 It should outline the available options for future architectures that address all concerns.
 It should explain the benefits, value, risks, costs, opportunities, constraints, and future
options associated with each alternative.
 It should outline any alternative routes to close the gaps and get from the current to the target
architecture.

Understanding the System

Information systems are the support structure for meeting the company’s strategies and
goals.
MIS Strategy needs to be aligned with the Business Strategy. New systems are created
because employees request them. New systems are created to obtain a competitive
advantage.
New Systems Development – …who?
When developing a new system, you have 3 “who” choices…
 In sourcing – IT specialists inside your organization
 Self sourcing – do-it-yourself approach many end users take with little or no help from IT specialists –
mainly for smaller systems – excel / web / access based
 Outsourcing – a third-party organization (i.e., let someone do the work and pay them for it)

Principles
A principle is a law or rule that has to be, or usually is to be followed, or can be desirably followed, or
is an inevitable consequence of something, such as the laws observed in nature or the way that a
system is constructed.
The principles of such a system are understood by its users as the essential characteristics of the
system, or reflecting system's designed purpose, and the effective operation or use of which would be
impossible if any one of the principles was to be ignored.
Function
In information technology, the term function (pronounced FUHNK-shun ) has a number of meanings. It's
taken from the Latin "functio" - to perform.
2
Develop System Infrastructure Design Plan

1) In its most general use, a function is what a given entity does in being what it is.

2) In C language and other programming, a function is a named procedure that performs a distinct service.
The language statement that requests the function is called a function call .

The system function executes an internal operating system command, or an .EXE, .COM (.CMD in
Windows NT) or .BAT file from within a C program rather than from the command line.

The system function finds the command interpreter, which is typically CMD.EXE in the Windows NT
operating system or COMMAND.COM in Windows. The system function then passes the argument string
to the command interpreter.

Framework
A framework is often a layered structure indicating what kind of programs can or should be built and how
they would interrelate. Some computer system frameworks also include actual programs, specify
programming interfaces, or offer programming tools for using the frameworks.
A framework may be for a set of functions within a system and how they interrelate; the layers of an
operating system; the layers of an application subsystem; how communication should be standardized at
some level of a network; and so forth. A framework is generally more comprehensive than a protocol and
more prescriptive than a structure.
Problem solving
Problem solving consists of using generic or ad hoc methods, in an orderly manner, for finding solutions
to problems. Some of the problem-solving techniques developed and used in artificial
intelligence, computer science, engineering, mathematics, medicine, etc. are related to mental problem-
solving techniques studied in psychology.
Problem solving strategies
Problem-solving strategies are the steps that one would use to find the problem(s) that are in the way to
getting to one's own goal. Some would refer to this as the 'problem-solving cycle'. (Bransford & Stein,
1993) In this cycle one will:-
Recognize the problem, define the problem, develop a strategy to fix the problem, organize the knowledge
of the problem cycle, figure-out the resources at the user's disposal, monitor one's progress, and evaluate
the solution for accuracy.
The following techniques are usually called problem-solving strategies

 Abstraction: solving the problem in a model of the system before applying it to the real system
 Analogy: using a solution that solves an analogous problem
 Brainstorming: (especially among groups of people) suggesting a large number of solutions or ideas
and combining and developing them until an optimum solution is found

3
Develop System Infrastructure Design Plan

 Divide and conquer: breaking down a large, complex problem into smaller, solvable problems
 Hypothesis testing: assuming a possible explanation to the problem and trying to prove (or, in some
contexts, disprove) the assumption
 Lateral thinking: approaching solutions indirectly and creatively
 Means-ends analysis: choosing an action at each step to move closer to the goal
 Method of focal objects: synthesizing seemingly non-matching characteristics of different objects
into something new
 Morphological analysis: assessing the output and interactions of an entire system
 Proof: try to prove that the problem cannot be solved. The point where the proof fails will be the
starting point for solving it
 Reduction: transforming the problem into another problem for which solutions exist
 Research: employing existing ideas or adapting existing solutions to similar problems
 Root cause analysis: identifying the cause of a problem
 Trial-and-error: testing possible solutions until the right one is found
Identify the project
What is project?
A project is a temporary endeavor undertaken to accomplish a unique product or service
with a defined start and end point and specific objectives that, when attained, signify
completion.
It has a well-defined objective stated in terms of scope, schedule, and costs.

Project is:-

 Any unique endeavor with specific objectives

 With multiple activities
 With defined precedent relationships
 With a specific time period for completion

Essential characteristics of projects

For projects to be properly conceived, the characteristics below must be clearly defined:

◦ Objectives

◦ Expected outputs

◦ Intended beneficiaries

◦ Planned lifespan
4
Develop System Infrastructure Design Plan

◦ Extended outcome of the project

◦ Principle stakeholders

◦ Financial plan and source of financing

Who are the stakeholders?

 Governments
 Contractors and subcontractors
 External customers
 Suppliers
 Top management team members ,resource manager, internal customers, and
management peers

What is a Project Manager?

Process Responsibilities
 Ensuring that the solution is of acceptable quality.
 Proactively managing scope to ensure that only what was agreed to is delivered,
unless changes are approved through scope management
 Defining and collecting metrics to give a sense for how the project is progressing and
whether the deliverables produced are acceptable.

People Responsibilities

- General management skills needed to establish processes and make sure that people
follow them
- Leadership skills to get the team to willingly follow your direction (team building,
motivational)
- Sets reasonable, challenging and clear expectations of people (proactive verbal and
written communication)
- Hold team members accountable for meeting the expectations (performance
feedback)
What can go wrong in a Project?

5
Develop System Infrastructure Design Plan

The major cause of project failure is not the specifics of what went wrong, but rather the
 lack of procedures
 lack of methodology and
 lack of standards for managing the project
Project Requirements
 Requirements answer the following questions regarding the AS IS and TO BE states
of the business (who, what, where, when, how much, how does a business process
work)
Types of Requirements
Regulatory: Internal and external; usually non negotiable
Business: needs of the sponsoring organization; always from a management
perspective
User: What the users need to do with the system or product
Functional and Non Functional : What the system needs to be able to do to satisfy
the business and user needs in terms of function and functionality
Technical: How the system needs to be designed and implemented to provide
required functionality and fulfill required operational characteristics.
Project acceptance criteria
 Acceptance: the formal process of accepting delivery of a product or a deliverable
 Acceptance Criteria: performance requirements and essential conditions that have to
be achieved before project deliverables are accepted
Acceptance Criteria for the given project deliverables (or products) have two critical
characteristics:
1) They need to accomplish with Specifications, according to Cost and Time restrictions
(Project Success Criteria).
2) The deliverables must be accepted by others (Project Success Factors).
Project Success Criteria
 These are defined as the qualitative or quantitative criteria by which the success of a
project is judged. For example, Success Criteria may be:
 Delivered within Time and Budget tolerance
 Delivered to Specifications
 Customer Satisfaction rating achieved
 Health and Safety adhered to
 Business Benefits realized
 Increased market share
 Improved productivity
Project Success Factors
Clear project mission

6
Develop System Infrastructure Design Plan

Top Management support

Client consultation
Committed project personnel
Monitoring and feedback mechanisms
Clear communications
Adequate resources

Project Deliverables
Deliverables are "outcomes" produced as a result of project tasks, activities and decisions, and as such,
they must be identified, specified, designed, scheduled, produced, tested, accepted and implemented.
Deliverables are produced throughout the project management process, and may be interim or final.

Project deliverables are the planned results for the project, consisting of products, services and related
outcomes.

A deliverable is a product or service that is given to your client. A deliverable usually has a due date and
is tangible, measurable and specific.

A deliverable can be given to either an external or internal customer and satisfies a milestone or due date
that is created and produced in the project plan. A deliverable can be a software product, a design
document, a training program or other asset that is required by the project plan.

The Systems Development Life Cycle –SDLC

 Systems development life cycle (SDLC) is a structured step-by-step approach for

developing information systems.
 7 distinct phases, each with well-defined activities. Also called a waterfall methodology,
 An approach in which each phase of the SDLC is followed by another, from planning
through implementation.

SDLC as a Waterfall Methodology

Phase 1: Planning

Planning phase - create a solid plan for developing the information system
Three primary planning activities:
1. Define the system to be developed – or determine which system is required to
support the strategic goals of the organization
Businesses typically track all proposed systems and prioritize them based on
business impact and critical success factors
Critical success factor (CSF) - a factor which is critical the success of the
organization.
7
Develop System Infrastructure Design Plan

This process allows the organization to strategically decide which systems to build
and the order in which to build them.
In the previous example – build the Web Self help first and then the Web Agent
application, etc.

2. Set the project scope

- clearly defines the high-level system requirements
– Overview of what the project needs to accomplish
– The defined link with the business goals
• Scope creep - occurs when the scope of the project increases
• Feature creep - occurs when developers add extra features that were not
part of the initial requirements
- Project scope document - a written definition of the project
scope and is usually no longer than a paragraph.
3. Develop the project plan including tasks, resources, and timeframes

Project plan –

– defines the what, when, and who questions of system development

– defines all activities to be performed
– defines the individuals, resources, and time required to complete each activity
Project manager - an individual who is an expert in project planning and management,
defines and develops the project plan and tracks the plan to ensure all key project
milestones are completed on time
Project milestones - represent key dates for which you need a certain group of activities
performed
Phase 2: Analysis

Analysis phase - involves end users and IT specialists working together to gather,
understand, and document the business requirements for the proposed system
Analysis phase collects the business requirements without reference to technology or technical
infrastructure that will support the system
Two primary analysis activities:

1. Gather the business requirements

8
Develop System Infrastructure Design Plan

Business requirements - the detailed set of knowledge worker requests that the system
must meet in order to be successful
The business requirement states what the system must do from a business perspective.
Business requirements address the “why” and “what” of your development activities –
useful way to do this is through a JAD session – talk to everyone who will be involved in
using the system
Joint application development (JAD) - knowledge workers and IT specialists meet,
sometimes for several days, to define or review the business requirements for the system.
2. Prioritize the requirements

 Prioritizes the business requirements and places them in a formal comprehensive

document
 Users signoff on this document which clearly sets the scope for the project
 This sign off is usually one of the first major milestones for the project

Phase 3: Design
-Build a technical blueprint of how the proposed system will work
-You take the business requirements generated during the analysis phase and define the
supporting technical architecture.
Two primary activities:
1. Design the technical architecture
– defines the hardware, software, and telecommunications equipment
required to run the system
–Stand alone, Client-Server, Tiered Architecture, etc
2. Design system models
– This includes GUI screens that users will interface with, database
designs – ER Diagrams, UML Use Case Diagrams, report formats,
software steps, etc

-Starting with design, the MIS manager takes on less of an active participation role and
acts more as a “quality control” function, ensuring that the IT people are designing a
system to meet the business needs.

Modelled using an ER Diagram

An entity-relationship (ER) diagram is a specialized graphic that illustrates the

interrelationships between entities in a database. ER diagrams often use symbols to
represent three different types of information. Boxes are commonly used to represent

9
Develop System Infrastructure Design Plan

entities. Diamonds are normally used to represent relationships and ovals are used to
represent attributes. Example

Phase 4: Development

-Take all of your detailed design documents from the design phase and transform them into
an actual system.
-Two primary development activities:
• Build the technical architecture
•Build the database and programs – usually takes much longer than building
the technical architecture.
Both of these activities are mostly performed by IT specialists
Project manager needs to keep an eye on timelines and deliverables during this phase

Phase 5: Testing

verifies that the system works and meets all of the business requirements defined in the
analysis phase.
Two primary testing activities:
1.Write the test conditions
-The detailed steps the system must perform along with the expected results of each step
-Each time a test fails, a bug is entered into the Bugs database and it goes back to the
development phase to be fixed
-A typical system would have hundreds/ thousands of test conditions

2. Perform the testing of the system

-Unit testing – tests individual units of code

-System testing – verifies that the units of code function correctly when integrated
-Integration testing – verifies that separate systems work together
-User acceptance testing (UAT) – determines if the system satisfies the business requirements and
enables users to perform their job correctly.

Phase 6: Implementation

-Distribute the system to all of the knowledge workers and they begin using the system to perform their
everyday jobs.
-Two primary activities
1. Write detailed user documentation
User documentation - highlights how to use the system
2. Provide training for the system users
10
Develop System Infrastructure Design Plan

-Online training - runs over the Internet or off a CD-ROM

-Workshop training - is held in a classroom environment and lead by an instructor – best
for complicated systems
- Ongoing monitoring / tutorials – once training is complete to ensure that users are
using the system correctly.

Choose the right implementation / rollout method

 Parallel implementation - use both the old and new system simultaneously for a
while

• Plunge implementation-discard the old system completely and use the new
immediately

• Pilot implementation -start with small groups of people on the new system and
gradually add more users

• Phased implementation -implement the new system for everyone in phases

Phase 7: Maintenance

Monitor and support the new system to ensure it continues to meet the business goals
Two primary activities:
1.Build a help desk to support the system users. Help desk is a group of people
who responds to knowledge workers’ questions
2.Provide an environment to support system changes:
Identifying Business Requirements
- The detailed set of knowledge worker requests that the system must meet in order to be successful.
-The business requirement states what the system must do from a business perspective
-Business requirements address the “why” and “what” of your development activities – useful way to do
this is through a JAD session – talk to everyone who will be involved in using the system.
Requirements analysis in systems engineering and software engineering, encompasses those tasks that go
into determining the needs or conditions to meet for a new or altered product or project, taking account of
the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and
managing software or system requirements.
Requirements analysis is critical to the success of a systems or software project.[3] The requirements
should be documented, actionable, measurable, testable, traceable, related to identified business needs or
opportunities, and defined to a level of detail sufficient for system design.
Identifying Requirements of the System

- System requirement is something that the information system must do or a property that it must
have. Also called a business requirement.

-Describes the hardware, software other requirements to run the given system. The system may
require the following requirements to perform the given operations.

11
Develop System Infrastructure Design Plan
-A compatible operating system.
-Available disk space.
-Database software.
-Network connections.

Criteria for System Requirements

- Consistent – not conflicting or ambiguous.

- Complete – describe all possible system inputs and responses.
- Feasible – can be satisfied based on the available resources and constraints.
- Required – truly needed and fulfill the purpose of the system.
- Accurate – stated correctly.
- Traceable – directly map to functions and features of system.
- Verifiable – defined so can be demonstrated during testing.
System Requirements can be
- Functional requirement - something the information system must do
- Nonfunctional requirement - a property or quality the system must have -Performance
-Security
-Costs
Results of Incorrect Requirements
- The system may cost more than projected.
- The system may be delivered later than promised.
- The system may not meet the users’ expectations and they may not to use it.
- Once in production, costs of maintaining and enhancing system may be excessively high.
- The system may be unreliable and prone to errors and downtime.
- Reputation of IT staff is tarnished as failure will be perceived as a mistake by the team.
Below is a five-step guide to conducting your own business requirements analysis.
Step 1: Identify Key Stakeholders
Step 2: Capture Stakeholder Requirements
Step 3: Categorize Requirements
 Functional Requirements – These define how a product/service/solution should function from the
end-user's perspective. They describe the features and functions with which the end-user will interact
directly.
 Operational Requirements – These define operations that must be carried out in the background to
keep the product or process functioning over a period of time.
 Technical Requirements – These define the technical issues that must be considered to successfully
implement the process or create the product.
 Transitional Requirements – These are the steps needed to implement the new product or process
smoothly.
Step 4: Interpret and Record Requirements
Once you have gathered and categorized all of the requirements, determine which requirements are
achievable, and how the system or product can deliver them.
Step 5: Sign Off
12
Develop System Infrastructure Design Plan
Finally, make sure you get the signed agreement of key stakeholders, or representatives of key stakeholder
groups, saying that the requirements as presented precisely reflect their needs.

Identifying hardware requirements for the target system

The server or servers that host Microsoft® Forefront® Identity Manager (FIM) 2010 server components
must meet the following minimum hardware requirements:

 An x64 -capable processor

 2 gigabytes (GB) of available hard disk space

 2 GB or more of RAM

 A monitor with a resolution of 1024 × 768

 A CD-ROM or DVD-ROM drive

The client computer that hosts the FIM 2010 client-side components must meet the following minimum
hardware requirements:

 512 MB of RAM (1 GB recommended)

 500 MB of free hard disk space

 A monitor that can display a resolution of 1024 × 768

Required Software
Each server hosting the different FIM 2010 server-side components has a different software requirement.
In this document, you will find the software requirements for each of the FIM 2010 server-side
components. If you decide to install all the server-side components on one server, you must install the
software requirements for each of the FIM 2010 server-side components on that server.
The steps, described in more detail in the following sections, are:

1. Identify Architecture Objectives. Clear objectives help you to focus on your architecture and on
solving the right problems in your design. Precise objectives help you to determine when you have
completed the current phase, and when you are ready to move to the next phase.
2. Key Scenarios. Use key scenarios to focus your design on what matters most, and to evaluate your
candidate architectures when they are ready.
3. Application Overview. Identify your application type, deployment architecture, architecture
styles, and technologies in order to connect your design to the real world in which the application
will operate.
4. Key Issues. Identify key issues based on quality attributes and crosscutting concerns. These are the
areas where mistakes are most often made when designing an application.

13
Develop System Infrastructure Design Plan
5. Candidate Solutions. Create an architecture spike or prototype that evolves and improves the
solution and evaluate it against your key scenarios, issues, and deployment constraints before
beginning the next iteration of your architecture.

This architectural process is meant to be an iterative and incremental approach. Your first candidate
architecture will be a high-level design that you can test against key scenarios, requirements, known
constraints, quality attributes, and the architecture frame. As you refine your candidate architecture, you
will learn more details about the design and will be able to further expand key scenarios, your application
overview, and your approach to issues.

You should not try to build your architecture in a single iteration. Each iteration should add more detail. Do not get
lost in the details, but instead focus on the major steps and build a framework on which you can base your
architecture and design. The following sections provide guidelines and information on each of the steps.
Identify Architecture Objectives
Architecture objectives are the goals and constraints that shape your architecture and design process, scope the
exercise, and help you determine when you are finished. Consider the following key points as you identify your
architecture objectives:

 Identify your architecture goals at the start. The amount of time you spend in each phase of architecture
and design will depend on these goals. For example, are you building a prototype, testing potential paths,
or embarking on a long-running architectural process for a new application?
 Identify who will consume your architecture. Determine if your design will be used by other architects, or
made available to developers and testers, operations staff, and management. Consider the needs and
experience of your audience to make your resulting design more accessible to them.
 Identify your constraints. Understand your technology options and constraints, usage constraints, and
deployment constraints. Understand your constraints at the start so that you do not waste time or
encounter surprises later in your application development process.

What is Software Architecture

Software application architecture is the process of defining a structured solution that

meets all of the technical and operational requirements, while optimizing common quality
attributes such as performance, security, and manageability. It involves a series of decisions
based on a wide range of factors, and each of these decisions can have considerable impact
on the quality, performance, maintainability, and overall success of the application.

14
Develop System Infrastructure Design Plan

“Architecture is the fundamental organization of a system, embodied in its components,

their relationships to each other and the environment, and the principles governing its
design and evolution.”

“The software architecture of a program or computing system is the structure or structures

of the system, which comprise software elements, the externally visible properties of those
elements, and the relationships among them.”

“Software architecture encompasses the set of significant decisions about the organization of a software
system including the selection of the structural elements and their interfaces by which the system is
composed; behavior as specified in collaboration among those elements; composition of these structural
and behavioral elements into larger subsystems; and an architectural style that guides this organization.

Software architecture also involves functionality, usability, resilience, performance, reuse,

comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns

“The software architecture of a program or computing system is the structures of the

system, which comprise software elements, the externally visible properties of those
elements, and the relationships among them.

Why is Architecture Important?

- Like any other complex structure, software must be built on a solid foundation.
Failing to consider key scenarios, failing to design for common problems, or
failing to appreciate the long term consequences of key decisions can put your
application at risk.
- Modern tools and platforms help to simplify the task of building applications, but
they do not replace the need to design your application carefully, based on your
specific scenarios and requirements.
- The risks exposed by poor architecture include software that is unstable, is unable
to support existing or future business requirements, or is difficult to deploy or
manage in a production environment.
- Systems should be designed with consideration for the user, the system (the IT
infrastructure), and the business goals.

consider the following high level concerns when thinking about software architecture:

- How will the users be using the application?

- How will the application be deployed into production and managed?
- What are the quality attribute requirements for the application, such as security,
performance, concurrency, internationalization, and configuration?
15
Develop System Infrastructure Design Plan

- How can the application be designed to be flexible and maintainable over time?
- What are the architectural trends that might impact your application now or after it
has been deployed?

Goals of Architecture
- Seeks to build a bridge between business requirements and technical requirements by
understanding use cases, and then finding ways to implement those use cases in the
software.
- To identify the requirements that affect the structure of the application.

Keep in mind that the architecture should:

- Display the structure of the system but hide the implementation details.
- Realize all of the use cases and scenarios.
- Try to address the requirements of various stakeholders.
- Handle both functional and quality requirements.

Consider the following key trends:

- User empowerment. A design that supports user empowerment is flexible,

configurable, and focused on the user experience. Design your application with
appropriate levels of user personalization and options in mind. Allow the user to define
how they interact with your application instead of dictate to them.
- Market maturity.-Take advantage of market maturity by taking advantage of existing
platform and technology options.
Build on higher level application frameworks where it makes sense, so that you can
focus on what is uniquely valuable in your application rather than recreating something
that already exists and can be reused.
- Flexible design. Increasingly, flexible designs take advantage of loose coupling to
allow reuse and to improve maintainability. Pluggable designs allow you to provide
post-deployment extensibility.
- Future trends. When building your architecture, understand the future trends that
might affect your design after deployment.

Key Architecture Principles

Consider the following key principles when designing your architecture:
- Build to change instead of building to last. Consider how the application may need
to change over time to address new requirements and challenges, and build in the
flexibility to support this.

16
Develop System Infrastructure Design Plan

- Model to analyze and reduce risk. Use design tools, modeling systems such as
Unified Modeling Language (UML), and visualizations where appropriate to help
you capture requirements and architectural and design decisions, and to analyze their
impact.
- Use models and visualizations as a communication and collaboration tool.
Efficient communication of the design, the decisions you make, and ongoing
changes to the design, is critical to good architecture. Use models, views, and other
visualizations of the architecture to communicate and share your design efficiently
with all the stakeholders, and to enable rapid communication of changes to the
design.
- Identify key engineering decisions. Use the information in this guide to understand
the key engineering decisions and the areas where mistakes are most often made.

Key Principles of Software Architecture

- Software architecture is often described as the organization or structure of a system,

where the system represents a collection of components that accomplish a specific
function or set of functions.
- architecture is focused on organizing components to support specific functionality. This
organization of functionality is often referred to as grouping components into “areas of
concern.”
- In addition to the grouping of components, other areas of concern focus on interaction
between the components and how different components work together

Key Design Principles

key principles that will help you to create an architecture that adheres to established
principles, minimizes costs and maintenance requirements, and promotes usability and
extendibility.
The key principles are:
1. Separation of concerns.
-Divide your application into distinct features with as little overlap in functionality as
possible. The important factor is minimization of interaction points to achieve high
cohesion and low coupling.
-separating functionality at the wrong boundaries can result in high coupling and
complexity between features even though the contained functionality within a feature does
not significantly overlap

2. Single Responsibility principle.

17
Develop System Infrastructure Design Plan

-Each component or module should be responsible for only a specific feature or

functionality, or aggregation of cohesive functionality.
3. Principle of Least Knowledge( Law of Demeter or LoD).
-A component or object should not know about internal details of other components or
objects.

4. Don’t repeat yourself (DRY).

-Only need to specify intent in one place. For example, in terms of application design,
specific functionality should be implemented in only one component; the functionality
should not be duplicated in any other component.

4. Minimize upfront design.

- Only design what is necessary.

- If your application requirements are unclear, or if there is a possibility of the design
evolving over time, avoid making a large design effort prematurely.
- This principle is sometimes known as YAGNI ("You ain’t gonna need it").
- When designing an application or system, the goal of a software architect is to
minimize the complexity by separating the design into different areas of concern. For
example, the user interface (UI), business processing, and data access all represent
different areas of concern.

When testing your architecture, consider the following questions:

- What assumptions have I made in this architecture?

- What explicit or implied requirements is this architecture meeting?
- What are the key risks with this architectural approach?
- What countermeasures are in place to mitigate key risks?
- In what ways is this architecture an improvement over the baseline or the last candidate
architecture?

18