iWire365 takes into consideration its clients existing technology as a critical step in considering its client’s needs.

Designing and building fixed and wireless networks is not a one-size fits all approach.

The complexity of building a secure future proof industrial networks is a complex task. Priorities will have to be taken into consideration, such as ensuring critical communication is provided.

We believe that clients need to be heard first and then given a recommendation road map for the proposed alternatives.

iWire365 rules of engagement include :

Network Business Case Review – Define a shared understanding of the current situation, opportunities, issues, and gaps

Feasibility Study – Qualitative and Quantitative analysis, targeted financial analysis, risk assessment, contingency planning, investment analysis, etc.

Portfolio Assessment – Leverage a workshop with key employees define a High-Level understanding of the existing network, and assets

Market Evaluation – Identify and categorize current and, potential customers and opportunities

Competition Evaluation – Identify current and potential competitors, SWOT analysis, etc.

Partnership Evaluation – Identify current and potential partnerships

Strategy – Develop an optimal strategy that leverages new opportunities and minimizes risk

Financial Analysis – Appropriate high-level financial analysis of opportunities.

Recommendation Road map – Develop a High-level recommendation road map that highlights key milestones, investment, partnerships, marketing, sales and technology critical to success.

Data gathering is the aspect of gathering information used for decision making aimed at improving learning.

Data gathering provides a benchmark to assess its network modernization program. Using input gathered from IT and business stakeholders, consultants will facilitate a workshop to elicit feedback from client organizations, to complete a Portfolio Assessment workbook. These could align with a typical RFI/RFP process as the client may have initiated already.

Components of the data gathering include:

  • Education on modernization
  • Modernization current state
  • Modernization business drivers
  • Current state of systems environment
  • Current state of data architecture
  • Current state of application architecture
  • Strategy considerations

iWire365’s System Requirements Document (SRD) is the first step in the evaluation process.

The System Requirement Document defines the functional and operational needs of each department and their consolidated system needs. The information to be gathered will be tailored to met the clients exact requirements.

Information to be provided by the client includes

  • Existing Telecom Systems
  • Operational Policies/Procedures
  • Current Network Infrastructure
  • Current Data (voice, data, video, mobility) Capacity
  • Current System Architecture
  • System Acceptance Criteria
  • Current System Cost
  • Long-range Technology and Operational Plan
  • Gathering requirements is an integral part of the delivery.
  • To group the thoughts and ideas of yours in a systematic way.
  • To group thoughts and ideas of others in a systematic way.
  • To comprehend the functionalities as well as limitations, if any, of a software package before finalizing your selection.
  • To decide whether to buy or build a solution.
  • A reference point during the duration of the project.
  • Give a basis to do testing.
  • Common Problems – Some reasons that prevent requirements gathering
  • Extremely tight deadlines that leave no time
  • Unavailability of customers
  • The organization sees gathering as a time-wasting activity
  • Assuming we are aware of customers’ needs without asking.

iWire365’s System Design Trade Off Analysis (SDTOA) supports making decisions that requires some form of deliberation and evaluation by the client.

Planning for projects involving multiple and competing outputs and stakeholders requires a collaborative effort. There is no single best technique for resolving trade-offs that involve people’s values. iWire365 tools set leverages several practical and useful multi criteria decision-making techniques which incorporate the project life cycle costs.

There are three phases to a System SDTOA
Preparation Phase

Determine if the required information and specialization (mission threads, relevant system architects, architectural documentation, system use cases) is available

Develop setups to use for evaluation

Identify the participating stakeholders

Evaluation Phase

Present the architectural and business driver presentations and predefined situations

Evaluate the situations

Post-Evaluation Phase

Evaluation team undertakes a thorough analysis of the information gathered to develop a few risk themes; these are presented to the scrutiny of system lead architects

iWire365’s Conceptual Design Document process defines technical solutions to functional requirements and will provide budgetary cost estimates for the solutions proposed.

The main idea behind the Conceptual Design is to maximize the probability of a feasible final product. Comprehensive solutions to the per-defined problem are often developed as “design options”.

The viability of design decisions or alternative options can only be confirmed if major features of the design, including algorithmic components or major sub-systems are verified by taking sub-system tests. Although positive results in these preliminary tests do not guarantee success, the clients are convinced of the design’s high probability of success when integrated. It acts as a “Proof of Concept” on a module or sub-systems level.

The framework of the Conceptual Design Document is as follows and includes:

  • Conceptual Design Summary
  • Functional Objectives and Requirements
  • Concept Combination Tables
  • Overview of Conceptual Solution Alternatives
  • System Architecture
  • Feasibility
  • Testing and Verification

iWire365’s Detailed System Design (DSD) begins the project build aspect with fully develop project work plan and prepare a detailed system design including a final cost analysis.

The blueprint serves as a framework in a RFP comprehensive specification for future processes: acquisition, installation, acceptance tests, and maintenance. The RFP is then forwarded to highly-qualified hardware vendors to determining the products that satisfy client’s system design requirements. The systems design process defines the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements.

The DSD serves as the project’s Bible and foundation for the installation and setup guide that includes:

  • Project Executive Summary
  • Introduction
  • Definition
  • Detailed System Design Standards
  • System Overview
  • Design Considerations
  • Assumptions & Constraints
  • General Constraints
  • Development Methods
  • System Architecture
  • System Hardware Architecture
  • System Software Architecture
  • Internal Communications Architecture
  • File and Database Design
  • Database Management System Files
  • Non-Database Management System Files
  • Human-Machine Interface
  • Detailed Design
  • Hardware Detailed Design
  • Software Detailed Design
  • Internal Communications Detailed Design
  • External Interfaces
  • System Integrity Controls
  • Final Cost Analysis Consulting and IT integration