Should Enterprise Applications be evolving to Socialized Enterprise?

Posted on June 17, 2016April 25, 2017 by peterlawrence

Henry Ford had one-size-fits-all, and he wanted to own the entire supply chain. The world has been turned on its head to where every user wants to personalize everything, including their workspace. How does this new world order fit with process manufacturing applications?

Not so long ago, process manufacturing applications (real-time databases (RTDB), manufacturing execution systems (MES), manufacturing operational management systems (MOM), enterprise resource planning systems (ERP)) were being developed by an enterprise’s own IT department. The first systems to be truly productized in the 1990’s were the real-time databases, with thanks to OSI, and the enterprise resource planning, with thanks to SAP.

At that time, in-house computing consisted mainly of big-iron mainframes supporting financial, HR, and similar corporate systems. Networks were limited to supporting remote terminal access. Mini-computers (a ridiculous label given today’s sizes, but they were truly transformational in their day) such as DEC’s PDP series were the best choice for departmental computing initiatives since corporate IT were not that interested in real-time data, recipe management, blend planning, and all the other detailed work necessary to operate a process plant. The mini-computer technology was a great choice for many reasons: they could be purchased under-the-radar of IT; they were local devices so had no dependencies on the immature networks; and they were close to the individuals that understood the actual business problems they were used to solve.

Either the success of these departmental applications, the concern that corporate IT had regarding the increasing expenditure on these departmental initiatives, or increasing legislative or governance requirements meant that these applications were being pulled under the control of corporate IT. This was not entirely a bad thing because it could be argued that the focus should be on operating the plant, not creating and operating applications and associated infrastructure. However local ownership had its advantages as well: users would feel a sense of ownership and hence quality of the information; if there were missing applications they could be quickly created with Excel spreadsheets or Access databases, even though this contributes to spreadsheet-hell; locally-created applications could be quickly adapted to changing user requirements. In summary, this was a period when users had a considerable amount of influence over their computing environment. However this influence has gradually declined over the last 20 years.

At the same time as we have seen a decline in the ability an enterprise application user has over the kind of and configuration of applications, we have seen the reverse trend in a user’s personal computing environment. Users can configure their own portals using iGoogle; they can set up their own meeting groups with FaceBook; they can browse for information using Bing and Google; and they can assess, locate, and install new applications by browsing app stores.

The challenge facing enterprise IT is to provide that framework so that end-users can create their own environment via a configurable portal, and even their own applications via configurable information, displays, analysis, applications, and work-flows. However LinkedIn, FaceBook, and Google have far more developer resources than enterprise IT can dream of. So instead of trying to emulate these social applications, why not embrace them to provide the capabilities the enterprise end-users need. As well as relieving enterprise IT of the development cost burden, it immediately provides access to those utilities (gadgets for iGoogle, web-parts for SharePoint) with which a user can fashion their own experience.

Component	Old Model: Enterprise IT		→	New Model: Socialized Enterprise
Component	Sourcing	Role		Sourcing	Role	Example
Platform	Corporate IT architects	Define and implement the platform upon which corporate applications will run.		Cloud-sourcing	Cloud-based PaaS platform reducing/eliminating the need for local platforms.	Use Google App Engine
Framework	Corporate IT	Define development standards for in-house developed or purchased applications.		Developer-sourcing	Definition of Cloud-based Frameworks (data, workflow, BI, portals, etc) and SaaS designed for end-user configuration.	Cordys or RunMyProcess cloud-hosted
Applications	Corporate Developers or Application vendors	Buy/Build applications that met user-requirements as determined by requirements analysis.		User-sourcing	User-configured applications that adapt to the changing business needs without involving corporate resources: agile.	User composes iGoogle with gadgets from the marketplace.
Utilities	Users	Locate utilities (Excel, mini-apps etc) that fill in the functionality gaps and can be deployed ‘under-the-radar’.		Crowd-sourcing	User-acquired utilities from the open-market but which conform to the cloud-framework.	iGoogle gadgets that solve specific user problems

Perhaps we are just turning the clock back to when the user within the process manufacturing plant had considerable control over their computing environment.

Solving or simply displacing problems: Application HAZOPS?

Posted on June 16, 2016November 15, 2017 by peterlawrence

Displacing problems: do information technology ‘solutions’ create more problems than they solve. Do information technology ‘solutions’ simply displace problems to another group? HAZOPS have been used to systematically assess risks in processes and operations. Why not ‘HAZOP’ the supposed information technology solutions we propose?

The information technology track record in process manufacturing

We and I speak for software and information technologists, have not always had a good record of solving the problems of the process manufacturing industry, instead we solve our own technical problems. Take for example the history of time series data management over the last 30 years:

You had a problem of instrument data, and we solved it with historians, but you came back and told us we were not listening because …
You had a problem with data visibility, and we solved it with portals, but you came back and told us we were not listening because …
You had a problem with analyzing what was going on, and we solved it with analysis servers, but you came back and told us we were not listening because …
You had a problem with deploying analysis, and we now solve it with plant models, but you come back and tell us we are not listening because …
You had a problem with following through on the results, and we now solve it with work-flow, but you come back and tell us we are not listening because …
You do not have an IT department nor the in-house skills to deploy such technology, perhaps we will solve that by moving in-house applications into the ‘cloud’, but what will you come back with to tell us we were not listening?

Perhaps the future problems will be that you do not really have the in-house skills to deploy applications in such a way as to gain their benefit. Thus we must think about solutions that are self-deployable, with built-in best practices. Apple iPad would not be very successful if along with the iPad you had to buy 2 days of consulting time to understand how to use the applications!

Another problem, if it can be called that, is that you will be employing GenY and GenX who are used to iPhone, Twitter, Facebook and other social applications. How will they respond to our applications that sometimes resemble work-overs of 1980’s mainframe applications?

The pace of change of the architecture, scope, and complexity of process manufacturing application solutions is far from slowing down. So if this thesis is correct, we might expect even bigger problems to be created by these supposed solutions. We need a strategy for anticipating those problems before they occur.

Avoiding future problems: Problem Displacement Assessment

So how do we avoid these mistakes in the future? This seems like an impossible goal, but in the event of a process incident there will be many who say that it should have been anticipated. And to respond to this the process industry has long used HAZOPS during the design or adaptation of critical processes and operations. A hazard and operability study (HAZOP) is a structured and systematic examination of a planned or existing process or operation in order to identify and evaluate problems that may represent risks to personnel or equipment, or prevent efficient operation. Why not apply the same structured examination directed towards the problems that we will create when we solve another problem. HAZOP pivots around examining Deviations from each intention, feasible Causes and likely Consequences. We can map deviations, causes and consequences to the impact of our ‘solutions’ as shown below:

HAZOP		Problem Displacement Assessment
HAZOP	Example	PRODIS	Example 1	Example 2
Asset	Heat exchanger	Application	Excel Unit production report	Database model-driven reporting system
Intention	To heat 2.3 kg/s of 96% sulfuric acid from 20°C to 80 °C.	Intention	To provide report of balance of feed and productions, together with production qualities (achieved using Excel with links to the data sources)	To provide report of balance of feed and productions, together with production qualities (achieved using a database model to deduce the feeds and products streams and associated data sources)
Deviation	MORE: 20°C to 100 °C.	Deviation	INACCURACY: regular imbalance of feed vs. products	INACCURACY: regular imbalance of feed vs. products
Causes	Reduced flow …	Causes	Excel macro mismatches actual material flows Inaccurate mass flow measurements Missing measurements …	Model mismatches actual material flows Inaccurate mass flow measurements Missing measurements …
Consequences	Dangerously overheated sulfuric acid.	Consequences	Inability to understand the source of the errors, the confidence in the reports diminishes until it falls out of use.	Requires new skills of DBA/analyst who can understand the underlying data structures needed to debug the problem. Since these skills are not available the confidence in the reports diminishes until it falls out of use.

So that is the proposal: whenever a new application is deployed or a significant adaptation is to be made to an existing application, let us undertake a systematic Problem Displacement Assessment using the same methodology as HAZOPS:

For each application,
- For each intended behavior of that application,
  - For each possible deviation from the intended behavior,
    - Identify what might be the causes of the deviation,
      - Identify the consequences of the deviation.