Somewhat chatty EA thoughts for ChemEngg enterprises

1. On enterprise IT adoption in Chem engineering firms (by Kinshuk Adhikary)
Financial companies were the first ones to adopt IT on a full scale. It is heartening to note that
companies involved in Energy, EPC and Chemical engineering are exploring IT and software to increase
competitiveness and stay in business. Various blogs and forums indicate this trend.
As a former Chemical Engineer with a decade of EPC experience (and another decade of core software
applications experience), I am fortunate to have a unique dual view of the whole thing. I certainly can
hope that the below observations will have validity.
First, let us discuss a diagram : I often recall (with a feeling of horror) a diagram that I was once
shown by a Chief Software Architect. (in a $ 2-billion company that operated in 30 countries and had
diligently practiced IT for about 8-10 years). I am often forced to remember it, as part of my toolkit.
This huge diagram had 100 boxes and 500 line arrows criss-crossing. And the Chief Architect was in tears
– he had been asked to (a) make sense of the system, and (b) improve it, so that it came under better
management control.
Too little architecture, too late : Nimble competitors had been exploiting data analysis tools and
making hay, while this giant, literally sitting on a mountain of exploitable data, watched helplessly
because its sub-systems would not talk to each other. Good architecture was missing, and it was too late
to do anything about it.
Continuous climb : Financial companies did become early IT adopters, of COBOL based systems. The
machines and programs were quite good in silos – and most financial companies never moved further –
while their faster compatriots built “fully automated stock trading systems which do a million buy-sell
decisions in the first few seconds after the stock market opens”. Seems like it (IT) is a continuous climb,
the winners being often the cubs, not the lions.
The future is here, in the new generation : The mind-set changes needed for a sound IT adoption
flow from one and only one source – an urgent understanding that “a new generation is emerging, quite
different from the old”. When this understanding permeates every echelon of management, and the lives,
habits, mores of young and very young workers are considered – only then the direction becomes clear
and decisions become easy.
May sound philosophical but that is it, companies ignoring this often win the battle and lose the war. The
brave new generation have some attributes, like –
• tweets (140 chars) have replaced blogs > have replaced novels, i.e shorts spans, personalized
• the work-home boundary is paper thin, home-work (and video games) is done at office and office
work is done at home. The days of uninteresting applications seems numbered.
• gadgets are like their arms and legs, so every gadget has to be considered
• knowledge is an external repository, open, free. Only workflow and decisioning is human.
What works ? : Consider a very common application – timesheets. I have in my career implemented
god knows how many timesheet apps. Only one was well liked , well used,, and successful from a
management standpoint.
From the outside, this app was just a small icon that one could carry on desktop, mobile, blackberry –
clicking it would open up a single text box – user would enter a few loose lines of text about the task
done. That was all. The rest of the inferences the machine made by itself – rarely would it need to ask
“start time, end time” - all that baggage. It took quite an effort to build that, but it worked best of all
timesheets I have ever seen.
Here are two examples of modern applications that combine a sense of playfulness and seriousness , and
high technology – a TO-DO list at http://voo2do.com/, and a travel site at http://www.ixigo.com/
So what would Chemical engineering and EPC firms really need ? Same as others – minor diffs.
– ERP-like systems for financial, sales, CRM, HR, production, materials, and so on.
– Related local systems or modules hand-built at satellite and branch offices, talking to the main
– Analysis and decisioning tools, reports and dashboards for senior management
– Document management, knowledge bases, wikis, e-Learning apps, content creation tools
– Collaboration suites for various local sub-domains, common messaging platforms
– Custom tools for chemical engineering, process workflows, engineering workflows, drafting
– Project planning and estimation systems
– Task and review tracking systems, time trackers, preferable if integrated with the above five
– Mobile applications for on site personnel

2. How to avoid 100 boxes and 500 criss-crossing lines
• ERP : The jury is still out on ERP systems, COTS implementations. The best bet seems to be to
avoid extremes of ERP implementation. ERP systems tend to become monolithic, their individual
components cannot be thrown out and replaced. Because business scenarios change too swiftly,
very often the people maintaining such systems re-write the whole code once or twice over.
• Export-import : Any sub-system that cannot integrate with its neighbors and/or superior apps is
nothing better than a COBOL toy or an Excel macro. That implies that irrespective of how the
above list is finally implemented – (a) there must be an “export” option (b) there must be an
“import” option.
The life cycle of useful apps is almost Darwinian. Only those survive that manage to integrate
with their overall electronic environment, because their usefulness spreads into other systems.
• XML : The export-import i.e. “talking between systems”, should be in XML – since XML is the only
standard that all machines understand (or ought to at least, in 2009 A.D).
• DSL : The language can be XML, but the dialect (ML = markup language, DSL = domain specific
language) is crucial too. This babel problem only financial companies have overcome – a
Chemical engineering company cannot talk to another because there is no universal standard to
describe , say valves, reactors etc. Most companies define their own DSL internally – this is a
slow process but unavoidable. Eventually the best DSL in the market survives.
E-learning systems without an IMS or SCORM capability today cannot be imagined – the vast
mass of content creators follow these specifications and keep them alive. This is however not true
for 90% of the other enterprise tools and technologies, and best dialects are still awaited.
• Sacrosanct uniques, repositories : one database, one knowledge base, one rules repository,
one domain language. There cannot be two, or many. This is of course highly theoretical, but it is
important to keep in mind while designing the architecture. Imagine two Googles :-)
• Latest stuff : The last ten years have seen an explosion of business technologies and
terminologies – I have explained some of them in my blog here. There are also Gartner trends –
ignoring such trends, howsoever faulty they be, is risky.
• Paradigm shifts : occur every 3 years, anything older than 3 years – knowhow, college studies,
development tools – is automatically suspect. Things change beyond imagination. A tool like
IronSpeed (600$) or Drupal (free) can create an application in minutes for what used to take
months or even years to do. However, at the very fundament, at architectural levels, the changes
are not so dramatic.
• What is enterprise architecture ? An appreciation of this can help avoid many pitfalls. It is a
more abstract (and therefore durable) way of solving a problem. It has 3 levels – the pure
business problem, the software application problem, and the network and infrastructure problem.
• Most IT efforts in enterprises are intended for some fairly common high level endpoints :
• Management visibility, the CEOs dashboard, the company health meter, metrices
• User empowerment on a large scale, irrespective of distance boundaries
• Knowledge capture and storage outside of humans, for continuance reasons
• Decisioning rules, common storage and manipulation
• Forecasting and trends analysis
• Organizational skill growth, skill-competency and evalutions
• Intrusion factor : Most applications intrude, irritate users, involve learning curves, take more
time when they should be taking less, create information overload, generate tonnes of messages
etc. Good application building is incredibly difficult, and lazy developers with low levels of user
empathy or technical knowledge often create bad applications. In the end only a handful of
applications truly make a difference.
• User empathy : Most applications are designed by developers and for developers, and they lack
a certain quality of empathy. Typically, unless a piece of software has been (a) tested by millions
of users, and (b) undergone at least 3 full-scale re-versionings, it is usually error-prone and
generally a drag on efficiency.

3. Primer for software developers (when talking to chemical engineers) :
– developers ought to understand that Chemical Engineers esp. have a very good understanding of
key terms like – process, feedback, control, instrumentation, trees, branchings, joins, structures
i.e. things that the IT applications world is only now beginning to play with.
– as an user group, they understand “changes in inputs and corresponding changes in output, with
a black box in between”. This makes it easy to convey IT concepts
– most of the chemical engineers work is a taskflow or a chain or a process – and sometimes just
configuring an issue-tracking-review system to their custom vocabulary is all that is needed
– they DO NOT understand databases, relational pieces of data, and they think Google and
wikipedia are “databases”. Most users also think that the screen is the database.
– they think Excels spreadsheets are meant for engineering calculations, and the concepts of forms,
http internet, persistence, data acid-ity and transactions – are not their forte.
– the chemical engineers world is all about - a mass of lines and pipes and instruments and
vessels, a finite set of attributes around each. Often the internal formulae of small calculations
are immaterial, what matters is that they all work together and deliver a big set of data. This is
easier to say than to do, because units of measurement differ drastically between those
calculators, moreover the sequence of calculations and recursion convergence is important.
– the big set of data generated by chemical engineers is primarily needed for cost estimations,
project progress evaluation, and further engineering
Primer for chemical engineers when talking to software developers:
– engineers in general need to be aware that things have changed since FORTRAN. (sadly, my own
wife who is also a Chemical engineer, still thinks that “software” mean “calculations”).
– software is all about “preserving the state of an universe of data, after due transformations”.
– data is numbers, or very small pieces of text – not what you get from Google or wikipedia. What
you get from Google and wikipedia are “documents”, or links to documents. Documents have the
following things – they have versions, they have structure, and they may contain data.
– excel sheets with macros are fine for working alone at home and producing a report or a chart,
but not for collaborative preserved working. Such collaboration can be done if one single copy
exists and can be shared over the web, but the moment you create and save a new copy, you are
breaking some fundamental rules about the sanctity of data
– in todays world, only web based systems, or those which draw data from a single repository
(database) are relevant. Multiple copies of anything are evil.
– do NOT get dazzled by any software – treat it like pencils or staplers, tools to be used for a
bigger purpose. Most software is faulty and bad, including the ones that send people to the
moon. The increase of errors versus complexity is a mathematical certainity, something like
Heisenberg'sprinciple.
– all engineers can understand software, and most software is easy to adopt when you treat it with
contempt and understand how incredibly dumb they are at the back of it. Most do this - accept
data (from you), put data into properly organized cabinets and racks, and fetch it to show, with
some minor changes in between. Ditto for facebook, tweeter, everything, everything.
– emails longer than 140 chars are a time waste, even dangerous for formal enterprise
communication or record keeping. They cannot ring a bell, alert you, like chats do, and moreover
emails are headless. Anything that is not classified into categories and under control of some
higher set of rules is useless, it is only when communication messages live within another
system do they become useful.

4. A day in the life, in a highly automated workplace
(Actually, I haven't yet seen a non-software company doing the things below. Most knowledge work
today centers around the production of good quality documents, which is what a software company also
does, so it should be relevant).
The fundamental and smallest unit, around which the entire system revolves, is an atomic “task”.
• Worker (everybody is one) logs in to system. Does NOT open the email Inbox. Instead, a tasklist
dashboard opens up, showing pending tasks, urgent messages, news feeds etc.
• Worker sorts, searches, categorizes tasks, completes (closes) them one by one. The task
document itself is saved in a document versioning repository as the latest version.
• The task is marked for review. A peer, or superior – reviews the task, if necessary pulling the
document from the repository. Final complete if Ok, else re-sends for re-work with comments.
• Spurious looking things are eliminated from the task list with an empowered click. All anomalies,
results, activities, emitted by the task management system are peer or superior reviewed.
• Completion of a bunch of tasks is a trigger to update a project plan in say MS-Projects. Managers
have the task of being on top of this task flow, allocating, re-prioritizing, and in extreme cases,
doing a task themselves. Effectiveness is all about the graininess of the task, the resources
supplied to the worker to do it.
• Project managers in particular have to understand the individual task completions against a
backdrop of the complete project (a million tasks?) - and tighten the slack if exists.
• Meantime, all tasks having been completed, the worker plays some pool or some silent video
game, or does some reading and “open contributing” over some forum. Or checks personal
emails or does some on line shopping or vacation planning, all while sitting in the office.
• A meeting is called, so everyone opens the chat IM window.
• A meeting is called, so everyone calls a conference number in goToMeetings.
• A physical meeting is called, but the system shows all conference rooms are booked. So everyone
including the CEO file to the pantry.
• Knowledge managers scour the universe for knowledge, keep the KB clean, and supply
knowledge to the needy.
• Senior managers and top management only focus on key things – key accounts, key
relationships, key deals, key events, key fire-fights.
• They are able to do this because they have progressively compressed dashboard charts and
graphs. For example, the top testing manager knows only “3553 bugs today, target 3210
tomorrow”.
• External facing folks (sales people, vendor handling personnel) actually have cabins (!!) and even
ancient looking telephones.
• No one fills time sheets because the basic unit of work is the “task”.
• Etc. etc.