Systems Engineering SIMILAR Methodology Example

Systems Engineering SIMILAR Methodology Example

Introduction

Systems engineering is an interdisciplinary team method meant to create a successful system as described by INCOSE. The systems engineering process takes into account both the business and technical needs of all the clients or customers. The ultimate goal of Systems Engineering is to provide a quality product that meets the client or customers needs as INCOSE points out. Systems engineering is concerned with handling a problem that is complex. The systems engineering process assists a team working on a solution to avoid omissions and invalid assumptions, can assist them in managing changing issues, and efficiently produce a cost-effective and robust solution as described by INCOSE. Using a systems engineering approach to building products and solutions efficient use of project cost and timeframes are managed and controlled effectively. The systems engineering team is always aware of the project requirements, interfaces and issues along with what the consequences are of making a change to the systems engineering plan and how the change will impact the overall project. Research showed, according to INCOSE, that systems engineering can save from 10% to 20% of a project's budget. INCOSE also points out that half of all project failure is preventable by using systems engineering techniques. The purpose of this paper is to discuss a practical example of System Engineering.

The SIMILAR Methodology

To efficiently system engineer a product or function one needs to follow a methodology. This example will follow the SIMILAR systems engineering process as discussed by Jacobs. SIMILAR stand for Stating a problem, Investigation into the alternatives solutions to the problem. Then Modeling the system, Integrate the new system, Launching or installing a system, and Assess performance of what was installed. The final step is Re-evaluating what was installed to see what went right and wrong and fix issues that went wrong to make them better as described by Jacobs.

Project Overview: Groot

To help understand the systems engineering concepts of SIMILAR systems engineering process an example will be used. An organization has Information Technology group. Within the Information Technology team there are many groups. One of them is the database services (DS) team which is responsible for installing, designing and administering the databases for the organization. The team needs to identify the requirements for the DS metrics collection, monitoring and alerting framework.

The objective of the project is to identify how the Database Services metrics collection, monitoring system and alerting framework for all of organizations database management systems. The databases include MySQL, Oracle, Microsoft SQL Server and PostgreSQL. The project was named Groot after the tree cartoon character in the Guardians of the Galaxy movie.

Understand the Problem

The first step in the SIMILAR process is understanding the problem to be resolved or solved. One can document or describe the expected benefit of the system and how it will be used as INCOSE points out. While understanding the problem one should identify and meet with the stakeholder to understand what the boundaries of the systems engineering project are. The problem must address what must be completed not how the work will be completed as Jacobs discusses. To understand the problem, typically meeting are organized to gather input from end users, owners, and stakeholders. An acceptable system will satisfy all the requirements resulting from the problem statement. One issue that occurs while defining requirements on a project is scope creep. Scope creep happens when requested changes occur in the project without reconciling them against the problem statement and requirements. They are added to the project without doing reconciliation and then the project schedules become longer than planned.

To understand the problem in the Groot project, the DS team started by creating an inventory of current database servers and categorized the database into a business unit domain, application name, and the environment. The requirement is to organize a dashboard or single pane of glass (SPOG), management console or unified console for the databases in the organization. Groot is to provide the ability to display data for trend, analysis and capacity planning graphically. Groot provides the DS customers and team member's access to metric and monitoring and alerting for databases'. The Groot alerting facility will communicate with the companies paging system which is PagerDuty so that the DS person on call will be contacted when thresholds are exceeded. Groot will be an Open Source solution, so no yearly maintenance fees will be needed and will mimic the current functionality of the monitoring and alerting system in place.

Identify Alternatives Model the System

The next or second step in the systems engineering process is to investigate alternative solutions as INCOSE describes. The team needs to identify, model and evaluate any ideas compared to the one that currently exists. Once identifying the path forward with the solution, the team produces the rationale for not choosing the alternatives in case the current solution runs into issues or risks. The final solution as Jacobs includes the product and the process used to produce. The techniques to produce the product may change after simulation or prototypes are produced and can be a parallel or iterative process.

For the Groot project investigations into metric, monitoring and alerting tools that perform monitoring of more than one database was completed. The open source products found suitable were elastic search and Prometheus and Grafana. Both collect data and can provide a graphical interface. In this case the team decided to use Prometheus and Grafana. Prometheus collects the metrics and produces alerts. Grafana is the graphical interface for displaying the data.

Develop/Integrate

During systems engineering, as Jacobs points out the system, process and people are cohesive to enable them to interact with each other. The interfaces among subsystems need to be designed. The subsystems are to be defined along natural boundaries. Subsystems should be defined to lessen the quantity of data to be exchanged among the subsystems. Subsystems designed correctly will send finished products to other subsystems. The feedback loops surrounding individual subsystems are easier to achieve than feedback loops around interconnected subsystems as INCOSE discusses. The process of co-evolving systems also needs to be integrated. The importance of integration is a system built and operated using well-organized procedures.

The development and integration of Groot will be done on three servers. Two servers for Prometheus. One server for Grafana. To start the development and integration will occur in the test environment. A Prometheus exporter is installed on each database server. The Prometheus server periodically pulls data from the Prometheus exporter or client on each database server to collect the metrics. Thresholds set on the Prometheus server will spawn alerts to PagerDuty if the threshold of the metric crosses a specific value as identified by the DS team. Installation steps and integration testing is performed in the test environment until the application is stable and the requirements of the project have been completed. Then documentation, training and support is created and provided to prepare for the installation.

System Installation

Rolling out the system means putting the solution into production by use of the users. This can include the installation plan, acceptance test, support procedures and escalation steps, rollout plans and operational support, administration and maintenance steps as Jacobs points out. If a rollout is across many locations or countries, the rollout can become a complicated plan.

The Groot system requires installation in the production environment. No outage is needed to roll out the tools. The installation in the production environment is completed, support and escalation processes are in place. Once rolled out, a back of the Prometheus metrics database is set-up to run each night for recovery purposes.

Assess Performance

Once the rollout occurs, one must assess the performance. A metric is a data point used to understand the satisfaction, productivity of the product or service that has been rolled out. Metrics are collected over the use of the product or service as Jacobs points out. The performance measures are used to diminish the risk during design and manufacturing. Metrics are used to assist in managing a company's processes. Collecting the measurement is the key. If one is unable to capture measurements, one cannot control it. If one cannot control it then it cannot be improved.

The performance of the Groot tool is used to monitor the database management systems graphically but also to be notified when a threshold has been reached so a DS person may resolve the issue as soon as possible. The product will be seen to be performing if the DS team is able to see the metrics graphically for patters arising and receiving alerts before a database system is down or looks to be struggling in some way.

Re-evaluate

A fundamental tool for system engineering is the re-evaluation. Re-evaluation, as described by Jacobs, is usually a continuous process with some parallel loops. To re-evaluate what is going through the system engineering process one needs to observe outputs and use the information to make changes to the systems inputs, product or process. The SIMILAR methodology outlines how systems engineering process shows the distributed nature of the reevaluation activity in the feedback loop as Jacobs points out.

The Groot metrics collection, monitoring, and alerting system may need to be re-evaluated on a regular basis for metrics that need to be added or alerts that would be helpful in making a DS team member aware of issues arising before the issue cause harm to the database system and makes it unstable or brings it down.

Conclusion

The paper outlined a systems engineering method called SIMILAR which stands for State, Investigate, Model, Integrate, Launch, Assess and Re-evaluate as Jacobs points out. Groot, a metrics collection product for the Information Technology DS team, was used as an example to assist in understanding the steps of SIMILAR. Using this process assists the project team in lowering the cost of the project by stating the problem, thinking through the steps that will be taking, and identifying an alternative to the current solution. Once a solution is decided on, the next steps are development, testing, documentation, and acceptance of the product produced. With the product than ready for rollout, an installation plan creates and dates for installation are set, and the product is live. After running in production, the product performance is tracked and re-evaluated, and the customer feedback is collected. The paper used SIMILAR systems engineering process and the Groot project to provide real-world example of system engineering.

References

INCOSE. (2014). SE101 what is systems engineering? International Council on Systems Engineering. Retrieved from https://www.incose.org/docs/default-source/default-document-library/twg-se101-v11-2014-01-20.pdf

Jacobs, S. (2016). Engineering information security: The application of systems engineering concepts to achieve information assurance (2nd ed.).