Architecture and Design

• Architecture and Design are also called as work product.
• They consists of one or more ‘informal diagrams’ together with supporting text describing the major related concepts.
• Architectural and Design involves inputs, processes, and outputs
• Inputs
• Requirements
• What is to be solved
• Qualities
• How “good” is it?
• Assets
• What is available
• Outputs
• Architecture
• Viability
• Architecture and design both focus on the content and the context of the target system, ensuring that it does the right things and does things the right way.
• Architecture: Nodes and components = “black boxes”
• Design: Nodes and components = “white boxes”
• The architecture of a system describes the structure and behavior of its parts.
• An Architect defines the models and guidance needed to model IT or business systems to meet the business intent.
• When the system meets its specific requirements is called design.
• When it is designed in the right way is referred to as its architecture.
• The parts of an IT system are its software and hardware elements, interacting with the IT system’s human and IT system users
• This simple framework can be extended, enabling us to see a repeating pattern across the scales which includes followings processes
• Requirements
• Architecture
• Design
• Architecture can be at any scale, and the scale is defined by the characteristic dimension of the architecture’s elements.
• It defines the structure and behavior of the elements of a system.
• The elements of an amplifier are its tuner,cables, and remote controls. It can also include the power supply, and the circuit board.
• The elements of a circuit board are its resistors, fuses, and integrated circuits.
• The elements of an integrated circuit are transistors and other components.
• Based on the scale we can determine
• Above that scale are the ‘requirements’ of the world in which the system sits.
• At that scale is the ‘architecture’ between the elements of the system.
• Below that scale is the ‘design’ of the insides of the elements of the system.
• IT system’s requirements are modelled as interactions with actors and other upstream and downstream systems.
• IT system’s architecture’s elements are components and nodes, and so on.
• IT system’s design model includes the insides of components, nodes, messages, and connections.
• Architecture helps us to validate the accuracy of our system
• Architecture is documented under architecture guidance that helps ensure our system is a good system.
• Architecture guidance includes:
• Reuse the work as much as possible. 
• Tried and tested parts
• Tried and tested structures of parts (reference architectures)
• Principles and patterns that help ensure the architecture is created in a good way
• Architecture can be defined as artefact where the architecture of a system describes its overall static structure and dynamic behavior. 
• It models the system’s elements, the externally manifested properties of those elements, and the static and dynamic relationships among them.
• The artifacts present models of the target IT system.
• They can be driven by models of the broader business system, of which this target IT system is a part.
• The target IT system must meet the specific business requirements placed on it.
• They can be guided by artifacts documenting architectural principles, patterns, and building blocks.
• The target IT system must meet the wider architectural requirements placed on it.
• It is also used by Enterprise Architects at the enterprise scale as they plan transition initiatives which may be elaborated by the IT Architect.
• Architecture when defined as a discipline
• Architecture is an engineering discipline that studies methods of designing IT systems that provide a solution of a business problem. The solution must satisfy functional and non-functional requirements in a way that best balances competing stakeholders concerns and must take constraints into account.
• Difference between architecture and design
• Architecture is creating a structure.
• Design is detailing the content.
• Methods of software delivery
• SPM for AI
• JavaAD for Java app development
• Methods define the approach we used to deliver a work product.
• Define how our deliverables meet with clients requirements and what work products we need to create.
• Role of architecture
• Acts as a solution blueprint that can be reviewed and validated.
• Communication tool for stakeholders and teams for future reference for maintenance and change, developing related systems and integration.
• Delivery Environments: Input into the delivery environments’ design and specification, tools and platforms of choice for solution.
• Delivery Planning: Starting point for developing the project plan (Waterfall delivery), solution and feature backlog (Agile delivery),resource requirements and team structure
• Estimates: Starting point for cost estimation.
• Enable parallel development by understanding how inter-component dependencies can and should be managed
• Foundation for commercial agreements.
• Foundation for Declaration of Understanding and segregation of responsibilities between various parties.
• To communicate to the sponsor and external stakeholders a conceptual understanding of the intended IT system.
• To provide a high-level shared vision of the architecture and scope of the proposed IT system for the development teams
• To explore and evaluate alternative architectural options
• To enable early recognition and validation of the implications of the architectural approach
• To facilitate orientation for new people who join the project
• For example an Architecture diagram for a system onboarding suppliers can be as follows.
• 
• Need of Architecture
• Both Functional capabilities and Non-functional requirements and Service Levels may be contractually binding.
• Failure to achieve targets may result in financial penalties for the IT provider, and/or a loss of business for the client
• If an architecture that meets the specified requirements cannot be established it is a red flag.
• The sooner this is known the better for all the stakeholders
• The effort expended should always be proportionate to the risk and return involved.
• Without a developed architecture, it is rare that all significant risks are known and well understood
• Lack of architecture means that there is no basis for solution cost and delivery time estimates.

• Aspects of IT Architecture
• Functional
• Operational
• Build Time
• Run Time
• A problem's architecture can be divided into a number of dimensions
• Functional aspect and Operational aspect
• Application level and Technical level
• Physical perspective and  Logical perspective
• Physical Architecture defines the infrastructure part.
• For Example type of systems.
• Role of Architect
• An Architect defines the structures of solutions and architectures to address client business problems.
• The Architect understands client needs and business constraints, works in levels of abstraction, applies industry knowledge, and leverages appropriate business elements and information technology to address those needs.
• The solutions are include business, enterprise, or IT architectures and can include systems, applications, and process components.
• They may involve the application and its integration of a broad variety of products, technologies and services, and various architectural styles and Domains.
• Basically work of an Architect can be defined into following areas
• Listening to clients
• Understanding business requirements
• Negotiating feasible requirements and scope
• Forming detailed definitions of solution structures
• Construction
• Guiding team
• Architect supports two distinct dimensions
• Enterprise Architecture (EA) and Solution Architecture (SA)
• Business Architects “do” Business Analysis at both EA and SA levels
• IT Architects “do” IT Analysis Mostly at the SA level
• Business Architecture (BA) and IT Architecture(ITA)
• Enterprise Architects “do” Enterprise Analysis across both BA and ITA.
• They often own guidance at the SA level
• Solution Architect create solutions to business problems within IT Architecture
• Architects and Technical Specialists
• Architects:
• Define solutions to client business problems.
• Results include systems, applications, and process components.
• Focus on the front end of the solution life cycle. 
• They act as an client consultant.
• Technical Specialists:
• Develop proof of concept, design, develop, build, test, and implement systems.
• Have depth understanding of products, offerings, and services within their Specialty.
• Architecture Process has basically 3 phases
• Rquirements
• Functional Requirements
• Non-Functional Requirements
• Solution
• Validation and Verification
• Validation is more of Functional Tests
• Unit
• System
• System Integration
• User Acceptance
• Verification is more of Non Functional Tests
• Stress and Volume
• Failover and Recovery
• Disaster Recovery
• Security and Penetration
• The four basic types of requirements 
• Functional Requirements (FRs)
• Answers the question of "what" the solution’s sponsor needs
• Tend to be "descriptive" or "qualitative“
• Are capabilities needed by users of the IT solution to fulfill their job
• These are documents the agreed business functions and IT systems will support.
• Functional requirements describe what the system will do from a number of perspectives based on architectural implications.
• Sources of Functional requirements can be as follows
• Customer Wants & Needs
• Business Process Model
• Use Case Model
• The Use Case Model is a way of grouping all the use cases in scope for a particular solution (or solution domain for large solutions) and presenting them as a single model (or a reasonably small number of models).
• A Use Case Model can be seen as a summary of the Use Cases in scope.
• A Use Case consist of main scenario together with one or more alternative.
• Main Scenario
• The system request the suppliers detail.
• The user supplies, the address and phone number of the supplier along with its due diligence information.
• The system, validates address and phone number.
• The use case ends successfully.
• Alternative
• Non unique supplier name.
• Postal code should match Country.
• The user select Country from list.
• Country code in phone number should match the Country selected.
• The use case ends successfully.
• Use Case Specification
• Use cases expand the requirements by describing interactions and behavioural details.
• They are different from the user stories which capture high-level requirements from the user point of view.
• Business Rules
• Epics and User Stories
• Users
• Business Roles and Locations
• System requirements.
• Business processes are a way of documenting functional requirements without concern for automation
• Business process modeling, system context, and use case modeling help to bridge between business architecture and IT architecture.
• Functional requirements in agile methodologies are typically defined in terms of Epics, User Stories, and Themes.
• Epics represent large, complex requirements that usually need to be brokenn down into smaller stories before development.
• User stories are short descriptions of system requirements from the perspective of a user or stakeholder.
• Themes are groups of related user stories that are organized together for prioritization and planning purposes.
• Non-Functional Requirements (NFRs)
• Define the expectations and characteristics that the IT system should support
• Might be runtime (performance or availability) or non-runtime (scalability or maintainability)
• Tend to be “prescriptive" or "quantitative"
• Documents the agreed service levels for the IT system.
• Non-Functional Requirements define “how good” the solution should be.
• Non-functional requirements, define how good expectations and characteristics of the target system.
• They can be of value to the user of the system, which are called as runtime non-functional requirements.
• Can be empirically tested.
• Studied as systems service level characteristics.
• Also known as observable qualities.
• They can be of value to the operator of the system which are called as non-runtime non-functional requirements.
• Cannot be measured easily and may rely on other project metrics.
• Also known as non-observable or development time NFR's.
• The “adjectives” that can be applied to the “nouns and verbs” that describe the system’s functional requirements
• How secure, how fast, how many users…
• How portable, how scalable, how safe…
• Non-functional requirements are often thought to apply only to the operational viewpoint.
• Designing a solution to meet a number of NFR involves resolving a number of opposing forces.
• Designing a Solution to meet a number of non-functional requirements involves resolving a number of opposing forces. Resolution of two or more opposing forces from below results in a solution to a problem.
• Functional requirements
• User/Runtime non-functional requirements.
• Performance (of the system as it operates currently)
• Does the system respond fast enough to user actions
• Can the system support suitable numbers of concurrent users
• Can the system support enough transactional throughput
• The degree to which a system or component accomplishes its designated functions within given constraints, such as speed, accuracy, or memory usage.
• Volumetrics
• Is the system capable servicing expected number of users
• Is the system capable of storing/ processing expected volumes of data.
• Volumetrics for the data entities that exist within the target system that, although relatively static, are likely to have a significant impact on the overall sizing of the target system.
• Impact may be static example number of suppliers,their bank accounts, due diligence data etc.
• dynamic like throughput, response time.
• Security
• Can the system identify and prevent unauthorized access?
• Authentication, Authorisation, Confidentiality, Integrity, Non-repudiation of origin, delivery.
• Authentication is Validation that the party is who they claim they are.
• Authorization is Validation of rights a user (or process) has to access information or to perform actions on resources
• Integrity is Quality that ensures the immutability of data
• Confidentiality is Protecting data from disclosure to unauthorized parties
• Non-repudiation is Strong evidence of authenticity of the sender and Strong evidence of delivery of message to the receiving party.
• The ability to protect an IT system against malicious use while at the same time allowing legitimate use
• Security is sometimes referred to as:
• Safety
• To reduce or eliminate danger, anxiety, and risk or liability
• Protection
• To defend against attacks and fraud
• Assurance
• To ensure correct and reliable operation; to enforce identity and ownership
• Usability
• Can visually or hearing impaired people use our system
• Do the system’s user interfaces measure up to best practice usability benchmarks
• Guaranteed delivery (e.g. of transactions), idempotence.
• Availability
• What is the maximum length of unscheduled outage the business can tolerate
• A measure of readiness for usage, whenever, and for whatever purpose
• Systems may be unavailable.
• At scheduled times, whether this is for maintenance, backup, or business reasons
• At unscheduled times, when something breaks
• Systems should support
• High availability
• 95%, 99% etc
• Continuous operations
• Continuous availability
• Manageability
• How straightforward the system is to maintain, whether this is tob ensure appropriate levels of functional or nonfunctional requirement
• Scheduling and Temporal
• Time constraints imposed by business process.
• Schedule of events which drive processing.
• Monitoring and Instrumentation
• Requirements for special facilities, functions, tools which are necessary to operate and manage the system.
• Logging and timestamping
• What will be logged, and what will drive the timestamps to enable effective use of logs
• Non-runtime non-functional requirements.
• Can it scale?
• How easily the system can be expanded to accommodate growth in the future.
• A system’s ability to increase/decrease in size according to changing workloads, such as an increase in user numbers.
• Vertical scaling (“scaling up”) is Adding additional resources into the machine:
• Adding more memory
• Using more or faster process
• Horizontal scaling (“scaling out”)
• Spreading the load across more machines
• May require a “load balancer” or “redirector” to distribute requests between the computers.
• Is it compliant?
• Whether it conforms to the regulatory environment, e.g. privacy, SOX, Anti Money laundering, anti Terrorism Financing laws, international Sanctions
• Can it be maintained?
• The ease with which the system can be changed, whether for bug fixes or to add new functionality
• Can it be managed?
• The ease with which the system can be reused, deployed, and tested, started up, and shut down
• Is it environmentally sound?
• Whether the system will harm users, including physical harm, as in medical systems, or financial harm, as in accounting systems, or other forms of harm
• How well the system utilizes resources, and its effect on the environment
• Is it portable?
• Moving the application to other operating systems, application containers, or different hardware.
• Is it reliable?
• The probability that a component will fail, and the nature of that failure.
• It should pass resileance testing,Chaos Testing,Cow space testing.
• Compliance and auditability 
• Data that needs to be provided for audits that may be required in support of legal actions
• Regulatory and legal
• System functions and/or operational parameters needed to enable statutory compliance
• Archiving, backup and recovery
• What is the data history kept “active” and what can be archived
• What is the data retention period for archives?
• Disaster Recovery
• Recovery Point Objective (RPO), Recovery Time Objective (RTO)
• Supportability, Maintainability
• Requirements for special facilities, functions, tools which are necessary to operate the system, and support its users
• Localization
• Languages supported
• Usability
• Parameters defining how easy it is to use the system
• Environmental
• safety
• Business constraints
• Technical constraints
• Constraints
• Given those things that cannot be changed within the scope and lifetime of the project(infrastructure)
• Factors, such as available skills, budget, and operational limitations in the enterprise architecture
• Architectural guidelines and standard technologies.
• Documents, the agreed constraints under which the IT system will be designed, deployed, and operated.
• Constraints are limitations imposed upon a solution.
• They can be imposed by the business or from within IT.
• “It must be done this way.”
• “It must conform to this legislation.”
• “We only have skills in these areas.”
• Constraints can be Imposed by the business
• Adherence to externally imposed business legislation (for example., data protection)
• Driven by available business capabilities (for example, end user skills)
• Examples
• Regulatory
• Governmental, legislative, and other rules relating to the operation of IT systems or with which IT systems must comply
• Organizational
• What is the organization that the system must be deployed into, and what special requirements does this introduce?
• Geographic
• What geographic regions will the system operate in, and what special circumstances do they dictate?
• Risk willingness
• How willing is the client to take risk?
• Marketplace factors
• Such as competitor offerings, cost of goods or services in the domain this system operates in, and so on
• Project
• Time - How long can it take to design, build, and deploy the new system?
• Resource (people and budget) - What is available for the project?
• Scope – What functionality must be built?
• Constraints can be Imposed from within IT
• Use of standard parts and approaches (patterns, reference architectures)
• Reuse of existing upstream/downstream systems.
• Examples
• Development skills
• What skills are available for the development and support of the new system, in both the client and delivery organizations?
• Existing infrastructure
• Is there any existing infrastructure (both hardware and software) that must form part of the new solution?
• Technology leadership
• What new technology should or should not be considered?
• IT architectural standards
• Principles, building blocks, patterns, and reference models that will apply to the new system.
• Implementation constraints
• Code development constraints such as:
• Implementation languages
• Policies for database integrity
• Resource limits
• Operation environment'
• Library/SDK License issues.
• Imposed by the project context
• Be the project manager’s best friend
• How long will it take?
• How much will it cost?
• Future Requirements
• Describe how the system might change in the future, whether these are functional or nonfunctional enhancements.
• Identify potential/significant future requirements of all types, based on both business and technology opportunities that might impact architecture.
• Change cases
• Describe how the system might change in the future, whether these are functional or non-functional enhancements.
• Future changes that might affect the architecture include
• New and modified business processes and goals
• Adaptation of the system to new technologies
• Changes in the profiles of the average user
• Changes in the integration needs with other systems
• The wider project environment the rich is the source of requirements and constraints.
• External Environment
• Laws and regulations
• Legal liabilities
• Social responsibilities
• Technology base
• Labor pool
• Competing products
• Standards and specifications 
• Public culture
• Enterprise Environment
• Policies and procedures
• Parent corporation issues
• Legacy systems
• Enterprise architecture
• Standards and specifications
• Local culture
• Guidelines
• Domain technology
• Project Environment
• Directives and procedures
• Plans
• Tools
• Metrics
• Enterprise Support
• Resource management
• Project reporting
• Brand support
• Training
• Infrastructure
• A solution architecture will have many stakeholders who are potential sources of requirement specification.
• A stakeholder in a solution architecture is someone with interest in or concerns about the realization of the architecture.
• Users needs and technology change as time passes
• As the system evolves, requirements become clearer
• External changes to the environment make requirements obsolete of create new requirements
• Change might be needed to manage require conflicts between different stakeholders
• Requirement Sources
• An Enterprise Architecture defines a set of governing principles, patterns, standard building blocks (ABBs), and reference architectures, together with architecture compliance processes.
• It provides the long-term strategic IT objectives that an IT solution should support
• The principles and standards with which the solution must comply
• Appropriate reference architectures to be followed
• Governance structure for review and approval
• Business cases influence architectural decisions.'
• Investment drivers will affect choice of technology.
• Key required features such as a “single customer view” to provide better customer service will affect data placement, legacy access, etc.
• Ongoing support costs, such as a single point of contact for support, have an impact on system management capabilities and so on.
• Project context is the set of objectives and assumptions used to frame the solution.It defines following areas
• What are the business objectives the project is supposed to meet?
• What are the baseline technology assumptions?
• What are the relationships (dependencies) with other ongoing or planned projects
• Assumptions implied or stated in the proposal or Statement of Work (SOW):
• In-scope application functionality
• Service level agreements
• Customer infrastructure assumptions
• Product or vendor assumptions
• Development environment assumptions
• Requirements Organization
• Requirements are then organized into functional requirements, non-functional requirements, constraints, future requirements as discussed above.
• Requirements are dynamic and require careful management throughout a project’s life cycle
• Requirement organisation includes following objectives
• Understand the source of requirements.
• Manage the scope of the project and establish requirements baseline.
• Verify that all requirements of the system are fulfilled by the implementation and that the application does only what it was intended to do.
• Balance, competing requirements prioritization and conflicts
• Manage changes to requirements and SSB project impact of a change in our requirement.
• Assess impact of a failure of a test on requirements.
• Requirements must be organised and managed and to end throughout the project life-cycle.
• Requirements must be prioritized in order to deliver the appropriate project scope.
• High: Essential Many requirements depend on this one, or it is considered of high value to many stakeholders. We should delay release if not ready.
• Medium High: Important to the effectiveness and efficiency of the system. Lack of inclusion may affect customer or user satisfaction, but release will not be delayed due to lack of this item.
• Medium Low: Impact is to lesser used parts of the system, but those parts will be significantly hampered.
• Low: Useful in less typical applications, will be used less frequently, or reasonably efficient workarounds can be achieved. 
• An architecture helps us to define requirements in following aspects
• Usability requirements
  
• Network requirements
• IT management requirements
• Functional and operational aspects which involve system context
• Use case models which involve change cases.
• Non-functional requirements which involves constraints.
• Security and privacy requirements.
• Future organisation, scope and requirements.
• Requirements matrix
• Requirements tracebility matrix.
• Requirements can classified into
• User stories
• Prototype
• Business event list
• Customer wants and needs
• Process definition
• Subject area model
• Stakeholder request
• Requirement gathering helps us to understand the project overall context.
• Business direction
• Project definition
• Business case
• Decision model
• Technical environment
• Standards
• Current organisation description.
• SMART Requirements
• Specific
• Unambiguous, consistent, and at the appropriate level of detail.
• Measurable
• Possible to verify that a requirement has been met, so include success criteria
• Attainable
• Technically feasible and within the art of the possible
• Realizable
• Realistic given all the constraints (e.g., resources, skills, time, infrastructure)
• Traceable
• Linked from conception through specification, design, implementation, and test
• A requirement must form a complete sentence
• Avoid using abbreviations unless they are defined.
• Make consistent use of one of the following verbs:
• Shall, will, or must to show mandatory requirements
• Should or might to show optional requirements
• Could or would to show desirable requirements
• They must contain the success criteria and be measurable and testable.
• Must contain a unique reference ID
• It should refer to supporting material and not duplicate information.
• Avoid:
• Ambiguity (instead, write as clearly and explicitly as possible)
• Wishful thinking (such as “100% reliable,” “totally safe,” and so on)

• Rambling, long sentences with arcane language

• Requirements MOSCOW
• Must (so will)
• Should (and probably will)
• Could (but might not)
• Would (but won’t)
• The system context:
• Clarifies the environment in which the system has to operate
• Puts bounds on the system
• Identifies external interfaces
• The system context can be produced as a “free form” sketch in which the meaning of the relationships between the system and its external agents is ambiguous.
• Who, or which, is interacting with the target system?
• What are they doing?
• How are they doing it?
• 
• A solution context can be based on above system context which defines solutions as follows.
• 
• Change Management
• Iterative documentation, review, and sign-off of requirements
• Well-defined and executed change management procedures
• Sufficient emphasis on developing change cases
• Ongoing evaluation of the application and the architecture
• Brain storming on joint application design is a useful way to gain agreement on requirements with all stakeholders.
• These can be of several days
• The agenda and discussions should be structured and disciplined
• Documents and related assets to represent the agenda during discussions should be well facilitated.
• Results should be in requirements agreement and deliverables
• These may include userstories, use cases, assumptions and portfolio of candidates.
• The requirement parked for future should be well, managed.
• The type of model on which development will be based should be clear
• Waterfall
• Iterative/Incremental
• Agile
• Principals for making Architecture Decisions
• Descions in Architecture help in formally document the critical choices while creation of the solution.
• Understand and agree why the solution looks the way it does.
• Make explicit the rationale and justification of the decisions made
• Help ensure the solution satisfies both functional and non-functional requirements.
• Prevent unnecessary rework throughout the solution delivery life cycle.
• Parts of Architecture decision document
• The architectural decision: Written as a statement
• Unique identifier: A unique code that unambiguously identifies the decision
• Problem statement: A description of the situation over which a choice has to be made.
• Assumptions: What is believed to be true about the context of the problem.
• Alternatives:  List of alternatives and explanations example File transfer, Messaging.
• Decision: The decision taken.
• Justification: Why the decision was made
• Implications: The consequences and impacts of the decision taken or architectural option chosen on other elements or aspects of the solution.
• Architectural Decisions are grouped together in an Architectural Decisions Register work product.
• Decisions and principles both represent some design constraint to which the solution must conform.
• Decision is at the context or Solution level that is at project level.
• Decisions are made within the context of the development of the solution’s architecture.
• Architectural principles are imposed from outside the context of the solution architecture
• Principles are part of enterprise level.
• Principles are a powerful means of ensuring that all independent solutions fit together
• Example data principles
• The guidance framework which provides support to architectural principles has following three buckets.
• Policy
• An enterprise-wide statement of how things will be done.
• Data protection, health and safety, and industry regulations
• Principle
• An enterprise-wide rule which an organization will use to make architectural decisions. 
• Example build versus by principal
• Single Sign-On versus security management principal
• Data distribution principle
• 
  
• Guideline
• An enterprise-wide statement of best practice, giving solution architects the opportunity to adopt consistent approaches to architectural challenges.
• Example best practices to be followed.
• AI guidance
• Java coding guidance
• Parts of a Principal can be defined as follows
• Name
• A short name or title to identify the principle
• Statement
• What the principle is
• Motivation
• Why the principle is the way it is
• Implication
• The consequences of the principle both on the enterprise.
• Cautions while defining Principals and Decisions
• Architectural Decisions
• Undocumented, unclear, or ambiguous decision
• Single alternative decision
• Inclusion of design guidance and code snippets
• Missing dependencies or reference between two or more related decisions
• Decisions scattered in design documents
• Not following a standard approval process
• Putting too much information into one diagram
• Putting too little information into the Architecture
• Using too many acronyms that are not properly introduced
• Providing more technical details than required.
• Principles
• Not knowing what the enterprise’s standards and principles are, when creating the solution.
• Not discussing deviation from an architecture principle with the governance board.
• Not following a standard approval process for proposal.
• Some Solution Patterns
• Value Proposition
• Check Value Proposition.Align value to delivery schedule/capability.
• Simplification
• Simplify the Architecture.Simplify complex architectures and excessive infrastructure layers.
• Breakthrough the Design Take a different view of the applications and operational designs.
• Integrate the Facilities Integrate Service Delivery organization, reduce management overhead. Consolidate technology to make best use of the hardware, sharing services.
• Downsize processors, change platforms or introduce different platforms. 
• Assets
• Utilize existing assets including architecture components, tools, processes, components and others including external assets.
• Use existing code or legacy applications through wrappering or re-engineering rather than rewriting
• Apply a framework or a defined rigid development processes with work-product templates or a skeleton program approaches.
• Delivery
• Optimize the Application Development environment
• Optimize the Delivery Model 
• Rationalize SW/HW License Lifecycle