Guiding and Aligning Investments in IT, OT, and Physical Systems with Enterprise Architecture


Introduction

Organizations, such as manufacturers, energy producers, and transportation companies, that operate complex and extensive physical (rather than information technology) systems that are core to their business, often use different engineering disciplines to guide and align investments in different domains.  Often, IT systems investments are guided by enterprise architecture groups, while design and operation of physical systems such as factories, mines, wells, pipelines, and transportation networks are guided by systems engineering (SE) groups, or more specialized engineering groups such as mining or petroleum engineers.   Increasingly, though, IT and physical systems must work together to monitor and control complex or geographically distributed systems to meet operate safely, meet customer commitments, and comply with regulations.  Therefore, enterprise architects and systems engineers must work together.  This article first clarifies and analyzes some important terms, and then demonstrates how enterprise architecture can be used to guide and align systems investments.

Definitions and Analysis

The Gartner Group defines IT as follows:

 “IT” is the common term for the entire spectrum of technologies for information processing, including software, hardware, communications technologies, and related services. In general, IT does not include embedded technologies that do not generate data for enterprise use.

Gartner defines Operational Technology as follows:

Operational technology (OT) is hardware and software that detects or causes a change, through the direct monitoring and/or control of industrial equipment, assets, processes, and events.

Note that that OT that generates data for enterprise use can be considered a part of IT.  This article uses the term “connected OT” to refer to this type of OT.

Gartner defines Enterprise Architecture as follows:

Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve targeted business outcomes that capitalize on relevant business disruptions.

Here is how the International Council on Systems Engineering (INCOSE) defines systems engineering:

Systems Engineering is a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods.

INCOSE defines model-based systems engineering (MBSE) as:

The formalized application of modeling to support system requirements, design, analysis, [and] verification. and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases…MBSE is expected to replace the document-centric approach that has been practiced by systems engineers in the past…

There is certainly some overlap between the definitions of EA and systems engineering.  If we consider an entire organization, with all its assets, as a sociotechnical system (for our purposes, a system involving people, processes, information, and any type of technology), one could use systems engineering principles to produce a signature-ready proposal to modify the system in response to a disruptive change.  To muddy the waters further, enterprise architects typically model baseline, transitional and target states of sociotechnical systems as part of preparing their proposals to management.

On the other hand, there is a clear difference in emphasis in the two definitions.   EA is fundamentally about guiding the response of organizations to disruptive change.  An EA recommendation may certainly include systems investments, and those recommendations may be based on systems engineering activities and may even include recommendations for further systems engineering activities.   But an EA recommendation may also include changes in policy, culture, workforce composition, or almost any other type of change.  Even though EA teams are often housed in IT organizations, their reach OFTEN extends to nearly everything it takes for businesses to manage disruptive change.  The following scenario depicts the historical and current involvement of an EA team in helping a fictitious organization adapt to disruptive change.

Scenario

Acme Transportation (Acme) operates a major North American railroad. Acme has implemented positive train control (PTC) for safety and regulatory compliance, as well as precision scheduled railroading (PSR) for improved asset utilization, reliability, and financial performance.  Acme has also built several logistics centers, each of which is centered around a pre-existing intermodal yard with space that it leases to customers for distribution centers, repair, and light manufacturing facilities. 

For the PTC implementation, Acme enterprise architects worked with worked with PTC systems and signaling engineers to model the PTC implementation and its impacts on the rest of the enterprise and anticipate the uses of the vast trove of position and speed information collected through PTC. Since then, analytic applications and ad hoc queries using this data have given Acme greater insight into railroad operations and set the stage for the move to PSR.

Acme enterprise architects contributed to PSR by describing new, precisely-timed services that the railroad could offer to certain customer segments, identifying which customers and services could be adversely impacted by PSR, and identifying the required changes to business processes and systems.

Acme enterprise architects contributed to the Logistics Centers by detailing the changes in organizations, business processes, and business systems required to establish them and operate them profitably.

With PSR and its Logistics Centers, Acme can now transfer standard shipping containers between precision-scheduled trains and Logistics Center customer premises very quickly and enable precisely-timed container transfers in its intermodal yards.   Also, with the information it collects through PTC and other monitoring systems, it can now tell customers precisely where their containers and other goods are located at any time.  Acme has grown its business by taking on additional customers whose needs align with their precision-scheduled routes and therefore benefit from railroad capacity freed up by PSR.

However, PSR has brought other challenges to Acme.  A single incident, such as equipment failure or an adverse track condition anywhere in its rail system can have far-reaching effects and cause Acme to delay many scheduled pickups or deliveries.  Several seemingly minor incidents have snowballed recently and have required Acme to pay penalties to customers as specified in its service contracts.  Its sales team has also heard that a few of its large customers are considering reducing their reliance on Acme.   Acme executives have therefore asked their EA team to propose a solution to this challenge.

The Acme EA team interviewed a broad range of stakeholders, including Acme employees in engineering, operations, sales, customer service, and finance, as well as a few representatives from customers impacted by the delayed pickups and deliveries.  The EA team worked with industry consultants to learn how other railroads were facing the challenges of PSR, and with experts in Acme’s physical systems to understand adverse incidents and their causes.  They incorporated all this knowledge into a holistic model that was reviewed by all stakeholders and accepted as a consensus baseline.  The EA team then developed and ranked a series of options to meet the operational challenges of PSR by collaborating with the same stakeholders and consultants.  Finally, they developed a signature-ready recommendation to management.     

The recommendation centered around the establishment of an Incident Response Team (IRT) charged with identifying and mitigating all incidents that could affect customer commitments.  To enable the IRT, the recommendation included the development of an Incident Management System (IMS) to report on such incidents, assess their systemic impacts, and prioritize them for remediation based on customer impact.  The recommendation stated that the IMS should rely on the following data sources: 

  1. Rolling stock and track health.  Acme locomotives increasingly use connected OT to report their health automatically, and trackside cameras and heat sensors report the health of freight cars. Sensors on tracks increasingly report excessive track motion as train pass over them and other adverse conditions.  The EA recommendation included the acceleration of connected OT adoption for this purpose and the development of an Equipment Health data warehouse for all collected information.
  2. Container position and car location.  Acme also increasingly uses connected OT to tell whether a container is on a trailer chassis in one of its intermodal yards, or on a particular rail car. Acme can also locate each of its rail cars, whether they are part of a moving train or waiting in a yard or siding.   All this information is available in an Equipment Position event stream.  The EA recommendation included the acceleration of connected OT adoption for this purpose and the development of an Equipment and Shipment Location and Movement data warehouse for all collected information.
  3. Train schedules.  These are maintained in an existing Scheduling database.  The EA team recommended the development of an API to allow the IMS to access up-to-date scheduling information.    
  4. Customer Commitments.  The EA team recommended adoption of a standard, human- and machine-readable customer contract section for these commitments, and their extraction and storage in a new Customer Commitment database.
  5. Manually Reported Incidents.  An existing Incident Reporting System and database tracks incidents affecting safety and reliability as reported by railroad personnel.   The EA team recommended development of an API to enable IMS access to incident data.
  6. Transportation Network Model. A model of Acme’s transportation network, including its connections to key customers and partners supports incident impact analysis.  It is maintained in the Transportation Network database.  The EA team recommended that Acme’s systems engineers add more information about the network to this database, and enhance its API to meet the data access needs of the IMS.

The recommendation also stipulated that the IMS would perform the following functions:

  1. Data Aggregation.  Data must be collected from all the data sources listed above.
  2. Data Analysis.  Data must be analyzed to determine the likely business impact of each incident, to link related incidents together, and to prioritize incidents for remediation.  
  3. Case Management.  Salient incidents, and groups of related incidents, must be assigned to cases, which must be assigned to IRT members known as case managers.  Once assigned, cases must be updated with relevant new information from all data sources.
  4. Presentation.  The status of the most significant cases must be presented on a master dashboard, which must enable drilldown into individual cases.   Also, each case manager must have a continuously updated dashboard reflecting the cases assigned to them. In addition, authorized individuals must be able to subscribe to incident alerts that are sent to registered and secured mobile phones.

Besides the new team and system, the EA recommendation also contained the following elements:

  1. Incident Handling Processes, including standardization of the terms used to describe incidents, and improvement of the processes for sharing details of incidents captured in the existing Incident Reporting System.
  2. Change Management, including new mandatory e-learning programs on the revised incident handling process and on the potential system-wide impact of local incidents.
  3. Roadmap.   A quarter-by-quarter comprehensive plan for implementing the recommendation, including all changes to organizations, processes, facilities, and technology.
  4. Cost-Benefit Analysis.  A detailed examination of the financial impacts of the plan, including the overall ROI.  This analysis was prepared with a financial analyst assigned to work with the EA team.

Conclusion

EA and systems engineering are complementary and overlapping disciplines.  But EA is uniquely focused on responding holistically to business disruptions with actionable management recommendations.  These disruptions may be external or internal, stemming, for example, from competitors, regulators, economic or political conditions or new management, customers, partnerships, strategies, or technologies.  To respond holistically to such changes, enterprise architects must therefore be generalists, with an understanding of their organization’s businesses and the IT, OT, and physical systems they operate.  As the scenario above illustrates, they must also cultivate strong relationships with key systems experts.

With sufficient knowledge and relationships, skilled EA teams can provide the necessary context for successful systems engineering by developing compelling investment recommendations, providing baseline, transition, and target enterprise models as a foundation for MBSE, and ensuring that system engineering initiatives are properly aligned with other investments across the enterprise.  

Authored by Iver Band, EA Principals Senior Instructor and ArchiMate Expert