Coordination, the underused “C” word
I’d like to argue that a single frame can be used to view a lot of the issues that we think about. Specifically, I’m referring to coordination, which I think is a clearer way of characterizing much of what we commonly call communication or collaboration.
It’s easy to argue that computing, to an overwhelming extent, is really about communication. Most obviously:
- Data is constantly moving around — across wide area networks, across local networks, within individual boxes, or even within particular chips.
- Many major developments are almost purely about communication. The most important computing device today may be a telephone. The World Wide Web is essentially a publishing platform. Social media are huge. Etc.
Indeed, it’s reasonable to claim:
- When technology creates new information, it’s either analytics or just raw measurement.
- Everything else is just moving information around, and that’s communication.
A little less obvious is the much of this communication could be alternatively described as coordination. Some communication has pure consumer value, such as when we talk/email/Facebook/Snapchat/FaceTime with loved ones. But much of the rest is for the purpose of coordinating business or technical processes.
Among the technical categories that boil down to coordination are:
- Operating systems.
- Anything to do with distributed computing.
- Anything to do with system or cluster management.
- Anything that’s called “collaboration”.
That’s a lot of the value in “platform” IT right there.
Meanwhile, in pre-internet apps:
- Some of the early IT wins were in pure accounting and information management. But a lot of the rest were in various forms of coordination, such as logistics and inventory management.
- The glory days of enterprise apps really started with SAP’s emphasis on “business process'”. (“Business process reengineering” was also a major buzzword back in the day.)
This also all fits with the “route” part of my claim that “historically, application software has existed mainly to record and route information.”
And in the internet era:
- “Sharing economy” companies, led by Uber and Airbnb, have created a lot more shareholder value than the most successful pure IT startups of the era.
- Amazon, in e-commerce and cloud computing alike, has run some of the biggest coordination projects of all.
This all ties into one of the key underlying subjects to modern politics and economics, namely the future of work.
- Globalization is enabled by IT’s ability to coordinate far-flung enterprises.
- Large enterprises need fewer full-time employees when individual or smaller-enterprise contractors are easier to coordinate. (It’s been 30 years since I drew a paycheck from a company I didn’t own.)
- And of course, many white collar jobs are being entirely automated away, especially those that can be stereotyped as “paper shuffling”.
By now, I hope it’s clear that “coordination” covers a whole lot of IT. So why do I think using a term with such broad application adds any clarity? I’ve already given some examples above, in that:
- “Coordination” seems clearer than “communication” when characterizing the essence of distributed computing.
- “Coordination” seems clearer than “communication” if we’re discussing the functioning of large enterprises or of large-enterprise-substitutes.
Further — even when we focus on the analytic realm, the emphasis on “coordination” has value. A big part of analytic value comes in determining when to do something. Specifically that arises when:
- Analytics identifies a problem that just occurred, or is about to happen, allowing a timely fix.
- Business intelligence is using for monitoring, of impending problems or otherwise, as a guide to when action is needed.
- Logistics of any kind get optimized.
I’d also say that most recommendation/personalization fits into the “coordination” area, but that’s a bit more of a stretch; you’re welcome to disagree.
I do not claim that analytics’ value can be wholly captured by the “coordination” theme. Decisions about whether to do something major — or about what to do — are typically made by small numbers of people; they turn into major coordination exercises only after a project gets its green light. But such cases, while important, are pretty rare. For the most part, analytic results serve as inputs to business processes. And business processes, on the whole, typically have a lot to do with coordination.
Bottom line: Most of what’s valuable in IT relates to communication or coordination. Apparent counterexamples should be viewed with caution.
Related links
- Of course, some claims about coordination wind up being quite bogus. That’s the basis for my long-ago rants about dashboards and “balanced scorecards”.
- I’ve posted multiple times about analytic use cases, emphasizing areas such as “early warning” or optimization.
- I also sometimes specifically break down BI use cases.
- We should all be thinking about the future of work.
Comments
3 Responses to “Coordination, the underused “C” word”
Leave a Reply
I have concluded that the problem is that we do not manage data as a modular asset with a defined: architecture; interfaces; and standards.
I have a developed a solution for a modular data integration function, and will be publishing a paper on this very soon.
To give you a preview, the fundamental problem is that firstly most data integration is done through JOINing (as opposed to SEMI-JOIN) and secondly, data is managed in databases as opposed to portable data files. Both of these concepts are counter-intuitive to most data professionals.
To be continued…
Neil,
Well, you certainly saw one of my main unspoken points — modularity is a key way to address difficulties in coordination. But I doubt any one kind of refactoring is enough to solve “the” one and only modularity problem. 😉
Hi Curt,
While I agree that there are limits to modularization, I argue in my paper that a huge unforced error we continue to make is the “Fan Trap” problem introduced by normal JOINs (which I compare to lead). I spend much of the paper explaining: this problem; why the problem is holding us back; and how if we switch to from JOINs to “SEMI-JOINs” as the de facto operator for data integration that it then becomes possible to realize a modular data system.
The paper itself is here:
https://drive.google.com/open?id=0B6QIZPV6OQqgb2p4SVVUb1k1Rzg
I have since provided an example of how this modular approach could be applied to a Digital Marketing Agency to build a specific modular data system for common analytical scenarios:
http://hepburndata.blogspot.ca/2017/08/a-modular-data-system-for-digital.html
If you have any questions or concerns about this, feel free to e-mail me them and I would be happy to respond with another example.