The KIT ─ Knowledge & Information Technology
No. 250 - 16 October 2019
Was this forwarded to you?
In This Issue
IBM's Blockchain-Based Supply Chain Service
How to Engineer Software
OMG Meet-and-Greet in Silicon Valley.
Visibility of Data Science in Oil & Gas
Seen Recently
Claude Baudoin

Consulting Services
  • IT Strategy
  • Enterprise Architecture Roadmap
  • Business Process Modeling & Analysis
  • Enterprise Software Selection
  • IT Innovation Briefings
  • IT Due Diligence
  • Executive IT Seminars
  • Cloud Computing
  • Security Maturity
  • Software Process
  • Knowledge Strategy
  • Technical Communities
  • Knowledge Capture
  • Taxonomy development
  • Enterprise Social Media
Contact Us:
cébé IT and Knowledge Management
www.cebe-itkm.com
info@cebe-itkm.com
+1 415 870 ITKM
Twitter: @cbaudoin
Archive:
Previous KIT Issues
Forward this issue to colleagues and friends: use the "forward email" link below at left, rather than "Forward" in your email software, to preserve your privacy, give the recipient more options (their own unsubscribe link, etc.) and to give us better click-through data. Thanks!
IBM's Blockchain-Based Supply Chain Service
A few days ago, IBM launched the Sterling Supply Chain Suite. This is a Hyperledger-based system, accessible through a set of open APIs, that allows participants in a supply chain (manufacturers, distributors, retailers) to trace their products as they move from point to point in the chain -- both in terms of custody and, if enabled by IoT sensors, geolocation. IBM's recent acquisition of Red Hat was instrumental in providing the technology behind this new offering.
How to Engineer Software: A Model-Based Approach
Our colleague Steve Tockey, who has been involved in the practice and teaching of software engineering for 30+ years, wrote a book that promises to be a fundamental contribution to the discipline. Here is the fundamental message:

Software can be engineered. Software should be engineered. But true engineering -- in the sense of civil engineering, chemical engineering, mechanical engineering, aeronautical engineering, industrial engineering, etc. -- of software requires more than just claiming "software engineer" as a job title. This book:
  • Defines what software engineering should really mean and shows how and why software needs to be developed this way
  • Presents the true nature of code -- what lines of code actually mean-and draws out vital implications from that
  • Explains how the common difficulties experienced on mainstream software projects are avoided when this approach is applied
The approach in this book derives from work started in 1987 and has been used on a variety of software projects including real-time/embedded, scientific & engineering, and business data processing. All of these projects met or favorably exceeded stakeholder expectations for schedule, cost, content, software quality and long-term maintenance.

You may also want to check the companion website for the book.
Reminder: OMG Meet-and-Greet in Silicon Valley
The Object Management group is hosting a happy-hour "meet and greet," graciously hosted by Real Time Innovation (RTI) in Sunnyvale, Calif., on October 24. Click here for more details and registration.
SPE Elevates Visibility of Data Science
The impact and rapid evolution of IT-related disciplines means that communities and associations need to adapt their classification of areas of interest in order to stay relevant to their membership. The Society of Petroleum Engineers (SPE) is a case in point. They recently decided to split their somewhat confusing "Management and Information" discipline into two: "Management" and "Data Science and Engineering Analytics" (DSEA). This makes a lot of sense, since the technologists are not always interested in management and vice versa -- although, of course, they should talk to each other!

Now, since those reorganizations are bound to be needed every few years, content management systems, member profiles and subgroup memberships, web sites, etc., should be designed to be adaptable. SPE is also a good example of the consequences of rigid systems, as the announcement of the discipline split ends with this ominous warning: "You will start seeing changes related to this decision gradually. However, it will require changing almost all the systems and platforms we use to run our programs and services and will take some time. We appreciate your patience." Designers, take note: categories based on industries, disciplines, markets, etc., should be "soft" and easily changed without having to require weeks of months of work.
Seen Recently...
"Note to those building internal cloud platforms for your company. If the public cloud was as cumbersome to use as your cloud platform, nobody would use the public cloud. So think about usability as much as you think about security & compliance."
-- Mike Kavis, author of Architecting the Cloud
"In this new era of utility computing powered by the cloud, the architect's role is even more critical."
-- Ravi Mayuram, senior VP of Engineering and CTO at Couchbase