Evolving infrastructure takes time

There are many truisms you learn after working a while, such as the reality of meetings https://twitter.com/MichaelCarusi/status/1149162281294581761 (although I hear some people perennially relish meetings in order to not feel 'lonely' at work). There are other facts, such as 'nothing significant can be done quickly', especially in evolving a technology. I don't believe it's just a matter of the 99% rule https://en.wikipedia.org/wiki/Ninety-ninety_rule#cite_note-Bentley1985-1. Instead, it entails a process of successively building something and learning from usage and feedback. This takes time. Also, it needs to be done in an open, transparent fashion with the stakeholders so that the 'tech transfer' doesn't have a valley of death between R&D and deployment. Maybe this latter sentiment is an instance of my musings from years ago http://vzimmer.blogspot.com/2013/12/invention-and-innovation.html?

A couple of 'recent' examples of this arc of evolution includes the dynamics of the "Min Platform", which really started out as an element of the Min-Tree, or "Minimal Tree" effort described in
slide 16 of https://github.com/vincentjzimmer/Documents/blob/master/OSTS-2015.pdf from 2015. Namely, move the EDKII code base from being a Hummer to a Yugo. I learned thereafter that a Yugo might not be the best example of a smaller end-state analogy.

Regarding moving toward the Yugo, construction had its first milestone in March 2016 via a 'code first' approach, as described in
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Open_Source_IA_Firmware_Platform_Design_Guide_in_EFI_Developer_Kit_II.pdf. This 2016 work, in turn, expanded and added server class systems
https://github.com/tianocore/edk2-platforms/blob/devel-MinPlatform/Platform/Intel/MinPlatformPkg/Docs/A_Tour_Beyond_BIOS_Open_Source_IA_Firmware_Platform_Design_Guide_in_EFI_Developer_Kit_II%20-%20V2.pdf two years later in March of 2018. Now many of the elements of this work appear in the May 2019 Min Platform Architecture https://edk2-docs.gitbooks.io/edk-ii-minimum-platform-specification/.

Going back to the overall goal of a Min-Tree, the idea was to segregate silicon critical initialization code into the Intel Firmware Support Package (FSP) http://www.intel.com/fsp (described more below), minimize the platform code, and then right-size the generic 'core' code, such as the https://github.com/tianocore/edk2/tree/master/MdeModulePkg. Efforts to the latter end can be found at https://github.com/jyao1/edk2/tree/ReOrg/Mde where the packages needed to build a minimal platform's core can be derived. Another use case is an "Intel FSP SDK" where the minimal code to 'create' an Intel FSP https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Creating_the_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_%28FSP2.0%29.pdf could be derived, enabling a future where more of the FSP elements could be shared. Other advantages of 'less code' include cognitive complexity, fewer attack surfaces (and time for 1st and 3rd party code reviews), easier maintenance, easier integration, and potentially easier updates/servicing (more on that later).

Although the Min-Core mention above has yet to be up streamed, many of the packages in https://github.com/tianocore/edk2 have been deleted in the last few months or migrated into https://github.com/tianocore/edk2-platforms. Projects like https://github.com/u-boot/u-boot/tree/master/lib/efi_loader also provide a minimized UEFI core, in addition to Rust based virtual firmwares https://github.com/jyao1/rust-hypervisor-firmware. UBoot and the hypervisor VMM only provide enough compatibility for the OS but avoid providing any PI capability. https://github.com/yabits/uefi provides both UEFI and elements of DXE PI, such as dispatching drivers from FV's https://github.com/yabits/uefi/blob/master/core/dispatch.c. Going forward https://github.com/intel/modernfw offers a venue to explore some of these directions in smaller profile cores and language-based security https://github.com/intel/ModernFW/issues/4.

Again, to build a full platform, you need platform + core + FSP in this model. A nice embodiment of bringing all three together is described in the Apollo Lake https://firmware.intel.com/sites/default/files/uefi_firmware_enabling_guide_for_the_intel_atom_processor_e3900_series.pdf. Another high level view of bringing all of these components together can be found in figure 6-19 of https://www.apress.com/us/book/9781484200711.

Speaking of ModernFW and FSP's, I'm pretty excited by some of the examples of alternate boots, such as https://github.com/intel/ModernFW/issues/10 and https://github.com/rprangar/ModernFW/tree/SBL_DNV_POC built upon https://github.com/slimbootloader/slimbootloader. The latter is again an arc of evolution from primarily coreboot based solutions to coreboot and Slim Bootloader. Leveraging the FSP's across these different 'consumers' demonstrates the scalability of the technology. Since Slim Boot Loader and coreboot take 'payloads', which can include UEFI https://github.com/tianocore/edk2/tree/master/UefiPayloadPkg or Linux or....does that mean the X64 UEFI variant is a "CSM64", as a dual to the CSM16 https://github.com/tianocore/tianocore.github.io/wiki/Compatibility-Support-Module (just kidding)?

Telescoping into the Intel FSP, its development followed a similar arc, with some of the direction intent described in https://firmware.intel.com/sites/default/files/SF14_STTS001_Intel%28R%29_FSP.pdf. The scaling of FSP commenced with codifying existing FSP practices as the 1.0 specification commencing in April 2014 https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec.pdf and then point evolutions in 1.1 https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v1-1.pdf and 1.1a https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v1-1a.pdf in April/November 2015. The 1.0 was really capturing the then-current practices and separating out the generic, class-like API's from the SOC specific "Integration Guide" dictum's. The 1.1/1.1a changes were derived from learning's with different flash layouts and roots of trust designs. These were still monolith FSP's. The 2.0 https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v2.pdf evolution in May 2016 was based upon SOC boot flow with non-memory mapped flash, think 'boot from eMMC/NAND/UFS', thus creating the FSP-T, M and S modules that could comprehend these boot flows. The Apollo Lake usage described above was one of the driving factors for this change.

Why the FSP2.1 evolution? In May of this year the FSP 2.1 https://cdrdv2.intel.com/v1/dl/getContent/611786 specification was released. It was created in response to the overhead of creating 'wrappers' to invoke the FSP 2.0 from a native EDKII firmware. These wrappers are defined in the 'consuming FSP' document https://firmware.intel.com/sites/default/files/A_Tour_Beyond_BIOS_Using_the_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_%28FSP2.0%29.pdf. The design of 2.1 maintains FSP 2.0 interface compatibility via "API Mode" usage and extends the design to include "Dispatch Mode." The latter entails guidance of how to use the FSP 2.1 binary as a well-formed UEFI PI Firmware Volume that includes a PEI core https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Core/Pei, thus allowing for dropping the binary directly into a firmware device layout containing other FV's with PEI, DXE, and UEFI https://uefi.org/specifications images. This 2.1 change was based upon learning's in scaling FSP 2.0 in the last 3 years.

And in the spirit of evolving code with specifications, there are FSP 2.1 binaries available at https://github.com/IntelFsp/FSP/tree/master/AmberLakeFspBinPkg and platform code demonstrating "dispatch mode" at https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/KabylakeOpenBoardPkg. This in contrast to the Apollo Lake "FSP 2.0" example mentioned earlier.

In addition, there are more opportunities for streamlining platform construction with art like MinPlatform's, thinner core code, ModernFW, and Intel FSP's. These include optimizing servicing the platform. Work is available on microcode and monolithic firmware updates via https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Capsule_Update_and_Recovery_in_EDK_II.pdf and its code embodiment https://github.com/tianocore/edk2/tree/master/SignedCapsulePkg. Moving forward  the separate elements are being made serviceable via the Firmware Management Protocol https://github.com/tianocore/edk2/tree/master/FmpDevicePkg, and it makes sense to enable separate servicing of components like Intel FSP's https://github.com/jyao1/edk2/tree/FspCapsule and other elements of the system based upon provenance. This will potentially help remove some of the friction in delivering on requirements like https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-193.pdf.

And speaking of security, there are nice call outs at https://twitter.com/IntelOpenSource/status/1148638118867849217 and https://firmwaresecurity.com/2019/07/01/new-uefi-tianocore-documents/ for some of the updates to guidance on securing the firmware and having a shareable threat model with the community. This is especially important as we treat issues submitted via https://github.com/tianocore/tianocore.github.io/wiki/Reporting-Security-Issues. As described earlier, minimal* (core, platform, etc) ease in the assurance analysis given there is less complexity, but such analysis still requires some base erudition upon which to lead the design and code assessments.

I'll close with a bit or irony and humor. I mention above the use of safer languages like Rust, in addition to extolling the virtues of open,

but there really is no silver bullet. Similarly, I mentioned smaller, simpler and less complex, but the product still needs to be useful

And on those parting thoughts I'll close this blog.

Cheers

Post-Intel Developer Forum 2014

I would like to thank Tim Lewis for mentioning this blog at http://uefi.blogspot.com/2014/09/new-bios-related-blogs.html. I have dual-posted this item to https://uefidk.com/blog/edkii-fsp-and-other-topics, too, as an experiment. The later community has some interesting code projects and write-up's I reference below.

I spent a few days last week in San Francisco at the Intel Developer Forum (IDF).  My hotel was right off Union Square, thus allowing me to witness of cross-section of San Francisco each morning.

All of the sessions were at the Moscone Convention Center.

My presentation at https://intel.activeevents.com/sf14/connect/sessionDetail.ww?SESSION_ID=1265 now has the material posted https://intel.activeevents.com/sf14/connect/fileDownload/session/08F28DCA2DB2EA88418F93B309D82DE4/SF14_STTS001_102f.pdf.

The audio variant of the material should be posted in a couple of weeks. My talk immediately preceded and also mentioned the session of UBMS https://intel.activeevents.com/sf14/connect/sessionDetail.ww?SESSION_ID=1266 led by Brian Richardson and Mark Doran.

As always, the most exciting part of the event entailed discussion with customers and collaborators both within and outside of Intel. My session was at 9:30am on Thursday and I took a short trip down memory lane, remarking on the two presentations I made in 2003, the first of which entailed how to build out platforms using the Intel (R) Framework specifications http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-specifications-general-technology.html along with Bob Hart from Insyde and Mike Kinney from Intel, which became the foundation for chapter 7 of the Beyond BIOS books http://www.amazon.com/Beyond-Bios-Implementing-Extensible-Interface/dp/0974364908 and http://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295.

My talk picked up off Brian and Mark's talk from last year https://intel.activeevents.com/sf13/connect/fileDownload/session/DB60155205A8DF5837DA22D0FF90E3A3/SF13_STTS001_100.pdf and built out the progress during the intervening twelve months. I was happy to have Giri Mudusuru and Jiewen Yao from the PC Client Group (PCCG) and my Software and Services Group (SSG) help with questions and answers at the end, too, in addition to serving as co-authors on some of the white papers mentioned later in this blog.

Beyond the FSP-on-EDK2, which is a hybrid of source plus binary, the session also treated on alternate enabling models, including pure open source. Since the session only ran for one hour, with 50 minutes of presentation and 10 minutes of Q&A, we wanted to provide both the attendees and the broader ecosystem an opportunity to 'go deeper' on the subjects treated. As such, beyond the above-listed presentation material, we also note some addition material on slide 27.

The two papers we posted ahead of the talk includes the FSP-on-EDK2 aspect in http://www.uefidk.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Using_the_Intel_Firmware_Support_Package_with_the_EFI_Developer_Kit_II_0.pdf for the initial portion of the third agenda item, and http://www.uefidk.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Implementing_the_TinyQuark_Design.pdf for the second portion of fourth agenda item, respectively. The idea behind the white papers is to 'add words between the Power Point pictures', or elaborate on some of the design intent behind these two engineering efforts.

Another reveal at the talk is the upcoming book from Apress Embedded Firmware Solutions. The alpha posted online http://www.apress.com/9781484200711 already treats the coreboot plus FSP topic, with the final book due early next year. Again, this type of material production aligns with the intent of providing more behind-the-scenes detail and intent of these efforts. Presentations are great to set the tone and direction, and open source repositories must exist in the 'reduction to practice' phase, but having the written word in between the evangelism and the bits helps close the loop for the development community, in my opinion.

Some of the material left of the cutting room floor, in the interest both of time and scope of the presentation, included the recent UEFI payload for coreboot built with EDKII http://www.uefidk.com/develop#accordions_develop-page-9. This was going to follow foil 16 of the presentation were the concept of a 'payload' is introduced, but the inclusion seemed to veer astray of the EDKII/coreboot + FSP tenor of this section.

Here are a couple of the redacted foils that show the flexibility of these open source firmware communities, EDKII, FSP, and coreboot.

and

In the first diagram above you can see that the payload is composed of modules out of EDKII built into a firmware volume. This is the spatial view. We didn't want to mix GPL-based coreboot and EDKII sources, so the only import from the coreboot community was the coreboot memory declarations, or CBMEM, which were also defined in coreboot's libpayload, a BSD-friendly licensed set of sources. The second diagram above shows the flow of the UEFI payload with the coreboot platform 

The ultimate theme of the presentation, though, was to offer customers choice. The imagery used to reinforce this point included the quotation "All Roads Lead to Rome" http://en.wiktionary.org/wiki/all_roads_lead_to_Rome with 'Rome' in this case representing the customer using Intel(R) products and the 'Roads' describing the various enabling options.

Beyond IDF and its technical sessions, though, there was a rare Sergey Brin sighting http://www.theverge.com/2014/9/10/6133589/this-photo-of-sergey-brin-doing-yoga-at-IDF-is-not-strange, although my picture is a bit blurrier

And IDF also featured live music Weds night, namely Weezer http://www.weezer.com/

which was pretty interesting.

While at IDF I also had a chance to work directly with Jiewen, and overseas colleague. We typically interact over email or phone given his home site in the Shanghai, PRC, area and mine in the Seattle, WA, US area. One of the common questions we receive about UEFI Secure Boot UEFI Secure Boot entails Authenticated Variables. This was a topic treated lightly in the implementation document, so Jiewen and I created http://www.uefidk.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Implementing_UEFI_Authenticated_Variables_in_SMM_with_EDKII.pdf to specifically address the SMM-protected variant of this driver posted on http://www.tianocore.og.

On any of these presentations, white papers, and even this blog posting, I look forward to community feedback.

2/15/2015 update - the book cited at the end of the IDF presentation is now for sale http://www.apress.com/9781484200711

Trends and openness

The balmy days of summer have made me reflect upon the past. And colleagues leaving of late make me more thoughtful. This is sort of a twist on the earlier career development talk, but with advice on how to pivot and react to the world. Of course the discourse includes a long-winded blog format that also treats on various aspects of life in tech and the human condition.

To begin, I work at a remote site (aka 'Siberia' of West Coast), so a long period of time can pass between seeing most colleagues. Even in the age of video conferencing, few parties use that class of tool, and I keep my camera covered with a yellow sticky note for other reasons.... In fact, I can work with some colleagues for years and only communicate on the phone or e-mail. When I finally do meet one of those long-distance collaborators in person, I often want to blurt out "you sounded much taller/shorter/fatter/older.... on the phone." But there really isn't an appropriate response. At one point I had mistakenly thought a collaborator was the Office Space stapler guy while remotely collaborating, and when we did finally meet, I sat stunned for the first ten minutes when I realized that I had mistaken this gentleman for an erstwhile cryptographer. The stapler guy image and the tan, fit person sitting across from me in the conference room didn't quite align.

On the other side of the coin, I do see certain people aperiodically over the course of the years, say at internal conferences or face-to-face mission meetings. In the early days of my tenure we would beat our chests and opine about all-night coding sessions, weight lifting, and other antics of youth, all with shiny, fresh cherubic faces.

Fast forward 10-15 years, and I note the weariness on faces w/ lines reflecting hours of ennui in meetings, bodies thicker around the middle from those days of eating lunch while on con-calls + fast-food while working late + more meetings + poor eyesight from poring over code and docs....  There is an occasional spark in an eye recounting the past, but mostly there are discussions that entail children and who is promoted or working at company XYZ.

But the advantage of wisdom includes having a network of collaborators and a more senior role to effect change. And that position is important, because the one thing that is constant over this span of time is change, especially in the technology industry. And when it comes to disruptive trends and change in our industry, I like to think of these trends as the four horseman of the apocalypse. When a disruptive trend is afoot, you can be in one of the three places: in front of the trend (and get trampled), behind the horses (and do clean-up duty), or riding one of the horses. Given my simplified view of things, you can imagine my predilection, namely riding one of the horses and being that agent of change.

As part of riding that course and driving change, one of the trends I observe has been the movement to open ecosystems, open source, including the move from PC/AT style BIOS to firmware environments like UEFI and its edk2 based development on tianocore.org. The salient portion of system software work, whether operating systems like Linux or edk2, includes openness and ecosystems. That's where open source can help.  Marc Andreesen rightly noted that software is eating the world http://online.wsj.com/news/articles/SB10001424053111903480904576512250915629460, and now open source software is eating software http://readwrite.com/2013/12/12/open-source-innovation#awesm=~oIwdZdqu0YdTo8.

This tend of open source source helps inform innovation paths, too.  Whether the discussion includes the minimal features to exemplify a capability, such as a micro-hypervisor using hardware virtualization https://github.com/udosteinberg/NOVA, or showing how a full UEFI edk2 implementation on Quark (1MByte image) can scale down to a 64-kbyte solution with "TinyQuark" http://firmware.intel.com/sites/default/files/Intel_Galileo_TinyQuark_64K.zip for https://firmware.intel.com/projects/get-started-intel-galileo-development-board. Why zips for the latter and not checked into an upstream open source IA firmware ecosystem? That's a discussion for another day. These small examples prove an innovation direction ahead of broad product execution that may embrace some of the design precepts demonstrated therein.

Another example of openness and innovation is network boot. Recall my description of IPV6 network booting at http://vzimmer.blogspot.com/2013/10/configuring-ipv6-network-boot.html. I'm a big fan of pre-OS networking https://www.researchgate.net/publication/258834396_A_Quick_History_of_UEFI_Networking and I chair that subteam, along with security, in the UEFI forum.

Since that discussion the options at http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml have been expanded by my friend at HP Samer El-Haj-Mahmoud http://www.uefi.org/sites/default/files/resources/UEFI_Summit_July_2013_UEFI2.4_Networking.pdf. The essence of these new options is to allow the UEFI machine to express that it has the ability to boot using a TCP-based, or connection-oriented protocol like HTTP, versus today's TFTP-based PXE wire protocol. This allows for more robust and scalable deployments without the need for retries and timeouts that afflict the UDP-based TFTP deployments.

Processor Architecture Types

Registration Procedure(s)

Expert Review

Expert(s)

Vincent Zimmer

Reference

[RFC5970]

Available Formats

CSV

Type	Architecture Name	Reference
0x00 0x00	x86 BIOS	[RFC5970][RFC4578]
0x00 0x01	NEC/PC98 (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x02	Itanium	[RFC5970][RFC4578]
0x00 0x03	DEC Alpha (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x04	Arc x86 (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x05	Intel Lean Client (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x06	x86 UEFI	[RFC5970][RFC4578]
0x00 0x07	x64 UEFI	[RFC5970][RFC4578]
0x00 0x08	EFI Xscale (DEPRECATED)	[RFC5970][RFC4578]
0x00 0x09	EBC	[RFC5970][RFC4578]
0x00 0x0a	ARM 32-bit UEFI	[RFC5970]
0x00 0x0b	ARM 64-bit UEFI	[RFC5970]
0x00 0x0c	PowerPC Open Firmware	[Thomas_Huth]
0x00 0x0d	PowerPC ePAPR	[Thomas_Huth]
0x00 0x0e	POWER OPAL v3	[Jeremy_Kerr]
0x00 0x0f	x86 uefi boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x10	x64 uefi boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x11	ebc boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x12	arm 32 boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x13	arm 64 boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x14	pc/at bios boot from http	[Samer_El-Haj-Mahmoud]
0x00 0x15-0xff 0xff	Unassigned

These tags as part of the wire protocol for DHCP, along with the URI device path node from the UEFI 2.4 specification, errata B, allow for negotiating this download and informing the network boot program from where it was loaded, respectively. Good stuff. And I look forward to booting UEFI on the Skynet.

Openness and ecosystems also allow for bringing people along in the journey. I was shocked and pleased when one of my overseas colleagues mentioned how to escape from the 'Cathedral', namely a reference to Eric Raymond's book http://www.catb.org/esr/writings/cathedral-bazaar/ on the same. The meme infects technologists regardless of experience or culture, as exemplified by our Friedman'esque Flat World http://www.amazon.com/The-World-Is-Flat-Twenty-first/dp/0374292884.

And you have to innovate. I cannot recall the number of conversations I've had over the years which evolve roughly as follows (I'm the 'technologist' here):

[technologist] 'You can do this feature with open technology.'

[incumbent] 'Don't do that, you'll compete w/ my value proposition.'

Which is sometimes met by 

[incumbent's marketing] 'It's easy to pass someone by when they are standing still.'

Exactly.

Regarding this exchange, the technologist doesn't want to break the cathedral's feature since both parties often work for the same company. But the technologist does observe these business facts to his colleagues, namely that the bazaar has the potential to power this disruption. Given that potential, why not disrupt yourself? I use the analogy of driving down I-5 to Portland. I can mind the fuel gauge and re-fuel when necessary. This entails diligence in observing the physical reality of an automobile. Or I can ignore reality and run out of gas in the middle of the interstate. The fuel constraint is like the competitive technology, you should only ignore at your own peril and 'control' the phenomena as best you can.

In the thick disruption and openness, being open also helps solve the outside-in problem. Sometimes a technologist in the cathedral wants to drive something that the other priests in the cathedral are loathe to support. So the 'outside-in' strategy can include getting customers (i.e,. the 'outside') excited and pulling the internal team (i.e., the 'inside') to respond. This is the less-kind version of  http://knowledge.wharton.upenn.edu/article/outside-in-strategy-for-the-c-suite-put-your-customers-ahead-of-your-capabilities/ since recalcitrant priests may be caught flat-footed to respond to the customer request once the outside-in push accelerates. But by enjoining the outside with open source ecosystems, there is a ready substrate to help the cathedral meet the incoming business request. Essentially the bazaar is the join point and shared infrastructure to evolve technology between partners, such as common open source code into which the cathedral can accrete its features.

The other fact I have realized over time is that everyone has their own cognitive frame and history. This is where the humanities http://blogs.scientificamerican.com/cross-check/2013/06/20/why-study-humanities-what-i-tell-engineering-freshmen/ still have a place in engineering. The arts teach 'how' to think and embrace change. Whether its the questioning of all premises in the spirit of Socrates, realizing the arbitrary language games of many conversations via Wittgenstein, or treating the world with skepticism that is resolved via Popper-like proofs and refutations. Take these words with a grain of salt, of course, as my bachelors degree is in electrical engineering and my masters in computer science. Thus you're reading the advocacy of an autodidact in the humanities, not a lettered representative therein.

And sometimes you just need time to be alone with your thoughts.

And you have to leave your ego at the door. The best advice I received on this point came from Andrew Fish, who once confided in me his secret, namely when you are in the thick of a debate and you realize that you are in the wrong, do the 'flip', or embrace the interlocutor's position. There is no shame in evolving your position in light of additional data. The flip should be done with due care and consideration lest you become a relativist or perceived as wishy-washy, but you must observe the truth when you see it. Part of leaving your ego at the door also includes taking criticism and feedback. You will often be incorrect, or not everyone will love you or your ideas, especially if you are on the wave front of a disruption. And the more you disrupt, the more ire you might draw from your peers and the incumbents.  And following Rumsfeld, "Learn to say `I don't know.' If used when appropriate, it will be used often."

And you must also always tell the truth. My best advice in this vein comes from Mike Richmond: "Never lie, but don't always tell everything." Telling the truth and being genuine eases the burden of having different stories for different parties and having to compartmentalize yourself. You will ultimately succeed on being transparent and delivering value, not on dissimulation and currying favor.

Another piece of advice includes finding the true root cause of an issue. It's quite easy to 'blame' other people, or the ad hominem attack, since the targets are nearly inexhaustible, with the last number I heard pinning the figure at a world population of over seven billion people in 2013. This class of attack sows enmity and reduces your credibility since a barbed tongue replaces truth.  But the technique goes pretty far, especially within companies. Only when existential realities like external market forces or internal resources enter the fray does this technique lose its potency.

Also, I observe that technologists who were most successful in the last disruption have difficulties in adapting to the next trend. I analogize this to the armies in the wake of World War I (WWI). In that conflict, trench warfare prevailed and the best defense devised for future conflicts by the French was the Maginot Line, or an armored variant of a trench covering their border. When World War II occurred, airplanes flew over the line. The quote that is often related to this historical event includes: "generals always fight the last war, especially if they have won it."

In the technology industry, you can imagine the parallels to the Maginot Line. Specifically, the technologist who drove the last disruption may be loathe or unable to address the next one. To me, you should always acts as the challenger, or a recent colleague graduate, with something to prove. The technology industry doesn't respect tenure. It instead demands results. And as Heraclitus said (now we're going pre-Socratic), "you can never step in the same place of a river twice." In the river of technology, that has never been more true than today.

But spotting trends is tough. I recall the exuberance of Gilder's Telecosm.  This hasn't aged as well as Grove's or Christensen's books, I fear. It turns out that the fiber of the Telecosm became the conduit for the web and data traffic that drove the new businesses, such as Google.

And having a network doesn't just include your co-workers. Your network should span other industries and companies - see advice on same at http://www.forbes.com/sites/ricksmith/2014/07/02/5-career-mistakes-you-will-regret-in-10-years/. I still remember my first trek to the Intel Developer Forum where I presented in 2003. The then-CTO of Sun Greg Papadopoulos said in his keynote "All of the smartest people don't necessarily work for your company." Your company does have the smartest people who are both dialed into the road map, strategy and capabilities of that enterprise, though, so I believe the advantage still goes to the company - necessary for success, but typically not sufficient (i.e., the 'if' but no the 'iff'). To close the sufficiency argument (and get to 'iff'), alternate views and help of others, especially in open ecosystems I've described in this posting, are key. As evidence of same, just throughout these recent blog entries you'll find reference to colleagues both within and outside of my company from whom I have had the honor to learn and collaborate over the years.

So you might not always guess right, but by enjoining the community with openness, listening, and reacting to the customer and acclimate market needs, you'll do fine. The tactics might include a pivot, flip, or re-plan, and through all of those actions remain genuine, honest, and work hard.

Speaking of working hard, time to get back into the melee and cease by blog graffiti on the wall of the internet.