2019-07-30 Tuesday - Restoring EA Value

Note:
The thoughts in this posting have long simmered in my mind, but were brought to the fore of my thinking today, by this question posed on LinkedIn.

"Why is it that, whilst Google searches for #digitaltransformation have increased in the UK over the last 5 years, Google searches for #enterprisearchitecture have trended in the opposite direction? Has EA become un or under-appreciated? Or its value not understood?"

Photo by Riccardo Annandale on Unsplash

For organizations of a sufficient size, Enterprise Architecture (EA) is an essential part of the IT organization - to ensure that cross-cutting concerns are given the appropriate attention. Teams which are focused on line-of-business, project, or application level  - do not have the latitude (or, luxury) to look left-and-right, nor too far ahead. That's why you need an EA team.

There is great value that EA can bring to organizations - to aid the business in seeking to Accelerate, Innovate, and Elevate

But, sadly, some EA organizations still labor under the baneful delusion (to: credibility, value, engagement)  that their primary mission is to perform centralized governance - and to be a gate keeper against change.  In their mind, they see themselves as a sort of priesthood - holders of arcane knowledge - with a self-appointed sacred role as "Keepers of the One True Way".

In my experience - far too many EA ceremonies and initiatives turn out to be wasteful exercises - that produce marginal value, or none whatsoever. But, in many organizations - for an employee to point out such a thing would be certain career suicide. That's one of the great joys of being a consultant - when teams bring me in, I can help deliver the hard messages, the unvarnished truth, to help effect change with the leadership team...when such news might otherwise create problems for the careers of long-term employees.

Those problematic EA organizations have lost touch with the way that cloud architecture and software development has evolved, and the speed with which business needs to move - and have neglected to incorporate the principles of Agile into Enterprise Architecture as the foundation of their guiding principles.

To restore any sense of value-add, I would submit that Enterprise Architecture must be completely re-imagined.

The fundamental shift that needs to occur is to flip the orientation from reactive engagement (EA waiting to be engaged by the line-of-business on a per project basis) - to one of proactive engagement (EA being the initiator and leader of examination, investigation, research, and recommendations). And, importantly, EA must be empowered with the financial resources to initiate necessary projects.

If your EA initiatives are only funded on a line-of-business project basis - then, you are in a self-defeating cycle of EA failure mode - because you are just a passenger (and you are lucky to be even that) coming along for the ride, with no real power to anticipate and effect change.Which reminds me of a quote I saw posted last year (todo: find source and provide link):

"To be fair, I've seen a few EA teams over the years, that if they had spent their time cleaning the toilets .... they would have made a greater contribution to the organisation."

If an  EA organization were to pivot their mission focus - to providing the business with just three core outcomes/benefits - there is much good that would accrue from that.

In order of priority:

1) Speed. Focus the EA team's efforts on the analysis and re-architecture aspects needed to continually seek ways to accelerate the ability of the business to deliver new and better products/services/features - faster, with greater quality.

2) Efficiency. Focus the EA team's efforts on the analysis and re-architecture aspects needed to eliminate costs and waste - by focusing on the EA level of analysis to help the business streamline systems, interfaces, and processes (with judicious application of automation, and where appropriate - simplifying even the manual processes). This includes involving EA in examining and reviewing the actual DevOps performance of systems - to identify where-and-how waste and inefficiency is occurring - that may be a consequence of enterprise-spanning decisions/considerations.

3) Security. Focus the EA team's efforts on the analysis and re-architecture aspects to ensure that the security of the business is sound - and continually being improved (that includes facilities, network, infrastructure, systems, applications, components, third-party services, tools, data, interfaces, people, processes, and processing). 

When the results of this shift in mission focus are reflected in tangible results for the bottom line of the business, and customer acquisition/retention/satisfaction - then, EA will have a welcome seat at the table (instead of the often seen late-stage invitation to engage EA - as a mere formality, and after-thought).

Indeed, EA will be seen by the business as a true peer and ally - seen as a partner always demonstrating their awareness of the needs and priorities of the business - and deemed a valuable partner in the collaboration.

Over time, an organization's EA team will naturally elaborate beyond just these three - but having this intense focus during the "replanting" of the core EA mission - is necessary to achieve results.

If your EA organization is struggling to demonstrate its value/impact - let's talk - I can be an effective change agent to help you pivot.



2019-08-26:

I happened upon three recent YouTube videos (#1, #2, #3) by Tom Graves, #3 in particular includes a statement in the description - that immediately struck me as problematic - and illustrative of why I believe so many organizations have lost confidence in Enterprise Architecture as a practice - and why heavy-weight frameworks/methodologies such as TOGAF are quickly abandoned by EA teams:

"Enterprise-architecture principles and practice should apply in the same way everywhere, whatever the context or content, whatever the scope or scale"

Perhaps it is just an issue of semantics. But, I think "practice" should be replaced with "concerns". However, after watching video #3 again - I am convinced that Tom's word choice is quite intentional.

This was my reply to Tom's post on LinkedIn today:

"Tom, With all due respect...A minor semantic suggestion: replacing 'practice' with 'concerns' would seem to be more appropriate. Insisting on replicating the same practices, regardless of scale/scope - seems too rigid - and seems to ignore the practical realities of the available economics at different scale/scope."

"Insisting on the creation of all the diagrams/views/artifacts - that are mentioned in the video - regardless of scale/scope - is precisely the reason I think that many business stakeholders have lost faith/trust in EA as a practice - for the failure to adapt to the agile mindset. All of the concerns must be addressed - but insisting on rote repetition of the same practices, regardless of scale/scope, smells like cargo cult science."

2020-05-18:

Much of what is described in this article - is what you should NOT do.

2019-07-27 Saturday - Repeatable Architecture Processes

Photo by Suzanne D. Williams on Unsplash

In my consulting practice, there are several tools that I've created over the years to help clients move toward establishing repeatable architecture processes - and eventually moving toward an Agile (and Lean) Architecture approach.

For example:

1) Architecture Assessment Checklist - useful for quickly assessing an enterprise, application, or vendor product/service offering (often used in collaboration with a client's procurement team during their RFP process and preparing recommendations and vendor evaluation feedback to the leadership team).  Using this particular tool - primarily focused on evaluating technical aspects, this level of assessment analysis can often be completed over a period of 3-5 days.

2) Enterprise Architecture Assessment Template - A template for a deeper-dive assessment process - that is typically completed over a period of four (4) weeks - with the report usually consisting of 60-80 pages - that is intended to examine the following areas:

• Business Operations
• Product Management
• Enterprise Architecture
• Engineering
• Infrastructure
• Data Management
• DevOps
• Non-Functional Requirements
• Information Security

3) Enterprise Architecture Artifact Category Taxonomy - Currently in a working draft status, with 369 entries. I recently completed a major revision (v2) to its organization and structure. The next version (v3) will be another major revision and restructuring - and will be formally defined via OWL/RDF - to help facilitate some additional automated processing capabilities that I have in mind for the future.

4) Architecture Decision Record (ADR) Template - used to help facilitate the adoption of Agile Architecture practices - and help an organization move away from historically centralized governance of the majority of their architecture decisions - and minimizing the historically draconian "gating" function of more heavy-handed choke-point processes such as Architecture Review Boards (ARBs)

5) Solution Architecture Document (SAD) Template - An "illustrative, not exhaustive" exemplar - to provide a team or organization with a starting point of establishing a repeatable level of analysis in the preparation of a Solution Architecture - intended to provide guidance to team members that may be new (or, less experienced) - with respect to the concerns that are often missed. Always customized to suit the culture of the client - depending on their level of Enterprise Architecture Maturity, regulatory/compliance requirements, progression on their journey toward adoption of Agile Architecture practices, and on complexity and mission-critical nature of their systems and business operations.

The journey with a client is always a process of evolution - seeking to: "Accelerate. Innovate. Elevate".

2019-07-27 Saturday - Solution Architecture Document (SAD) Template

I've published an update to my Solution Architecture Document (SAD) Template - and have begun to incorporate elements of my Category Classification Taxonomy into the SAD.

Still very much a working draft - intended as a helpful starting point from which teams can further customize to suit their needs.

https://github.com/intltechventures/Consulting.Project.Tools/blob/master/templates/SAD.md

2019-07-24 Wednesday - Updated Artifact Classification Codes - A Taxonomy

A pretty significant update, restructuring, and clean-up

https://github.com/intltechventures/Consulting.Project.Tools/blob/master/taxonomies/ClassificationCodes.md

Still rough, and still a working draft - but  just approaching a level of usefulness as a starting point that a team could customize to their needs.

2019-07-20 Saturday - So, what is a 10x software engineer?

Photo by Nicolas Hoizey on Unsplash

There is an assumption embraced by many in the field of software engineering - that may take the form of one of two diametrically opposed positions:

• 10x software engineers exist.
• 10x software engineers are a myth.

I'm interested in the arguments put forth by both camps. However, in every field of endeavor, there are exceptional, world-class, elite performers. To deny that fact - would be foolish.

But first, let me explain something. The reason for writing this is actually two-fold:

 1) I'm interested in understanding WHY people hold either of these opinions.

2) if you think this is an important question - if you believe that you should be seeking out 10x software engineers in your hiring process -  permit me to to submit for your consideration - that you may be focusing on the wrong thing... (read this thread)

What you should be infinitely more concerned about - is rooting out the [-10x] software engineer from your organization.
Let me explain.

Drawn from over 30 years of observations while working in the industry - here are a few ideas of what might constitutes a [-10x] software engineer:

• Some lack the minimum requisite skills, aptitude, and technical knowledge.
• Some lack the interest/desire/motivation to make the necessary investment of time and effort to continue to maintain (and expand) their skills, knowledge, and professional development.
• Some are unaware of the minimal basics of good software development practices.
• Some are careless and inattentive.
• Some create more technical debt - than value-add
• Some focus on the easy ("window dressing") tasks first - delaying the hard work of eliminating technical risks/unknowns - putting the organization at significant risk of late discovery - and of incurring massive rework.
• Some are too enamored with driving their solution design recommendations based on resume-driven technology decisions (aka "Shiny New Thing" addiction, or a variation of "Let's Gamble Whether The Business Survives with this Unproven Technology").
• Some will willingly commit code to the source repository - that has not been tested. At all.
• Some will argue that version control is an unnecessary burden.
• Some will argue that writing documentation is an unnecessary burden.
• Some will argue that they don't have time to write automated test cases.
• Some lack an understanding of basic algorithms and data structures - and therefore are unqualified to make most nontrivial design decisions. 
• Some seem to take joy in creating an atmosphere of negativity and fomenting dissension.

Such individuals are capable of [-10x]  damage to an organization - they should have their network access revoked, and should be escorted from the building.

A client once engaged me in an architecture mentoring role - to help assess a very large engineering team (> 100) - to help diagnose why they were creating more technical debt - and more defects - in every Agile Sprint - than Stories delivered (by a not insignificant multiple).  My conclusion - after a significant amount of code inspections and code review discussions - was that quite a few of those software engineers were definitely in the [-10x] category.

As I explore my own thoughts on this topic - I will come back periodically and elaborate more in this posting, but I do have a few initial thoughts that may help illustrate where my views may diverge from what has previously been written by others.

If there are such things 10x software engineers - I think the distinction is really about the magnitude of the impact that a software engineer has beyond the scope of just their own work.
 

For your consideration - possible key indicators that someone might be a mythical 10x software engineer:

• A 10x software engineer demonstrates an active awareness and appreciation for the efficiency and productivity of their team - and their organization.
• A 10x software engineer isn't necessarily the engineer that codes 10x more, or 10x faster - but may be a more subtle and nuanced value proposition - in that the 10x person makes smarter choices - that result in code that is:
• more extensible; 
• easier to maintain; 
• easier to understand; 
• is well tested; 
• demonstrates elegance; 
• shows keen insight in the naming of things; and,
• exhibits higher scalability and performance tolerances.
• A 10x software engineer focuses on eliminating technical risks/unknowns first - so that late discovery is mitigated - and reduces the potential need for massive rework.
• A key indicator of a 10x software engineer is demonstrated by their relentless efforts to educate, elevate, and improve the abilities of other engineers in the organization.
• A key indicator of a 10x software engineer is their intense focus on automating the mundane - so that processes are automated, less error-prone, of higher quality, repeatable, and frees not just them - but their team/organization - to focus on more value-added work.
• A key indicator of a 10x software engineer is their ability to intuitively "see" (or, know) how a design will perform under various stress conditions - before writing a line of code.
• A key indicator of a 10x software engineer is their judicious application of this rule: "The fastest code is the code that you don't need to write".
• A key indicator of a 10x software engineer is in the ability to align their intuition, brilliance, creativity - with their efforts to create software - such that their design expands the capabilities of the organization in new dimensions - both in terms of business services offered, revenue generation, cost reduction, and enabling new business opportunities.  
• A 10x software engineer is humble and works to lift and elevate the capabilities (and attitudes) of their colleagues - and brings a tremendous positive energy to the work that they do - that permeates their environment.

I have more thoughts on this - but will do some deeper reading and reflection before returning to my key indicators list discussion above.

Fundamentally - I do believe - that there are individuals that exhibit better awareness, bring such a greater depth and breadth of experience, have a higher level of intuition, are more meticulous in their attention-to-detail, exhibit an extraordinary Duty-of-Care, deliver a higher quality in their work products, produce code with much better performance, who build software with better efficiency, and who make better design choices - and their contributions are so material and substantial - that they can have a positive 10x impact on an organization.

Thus, I agree that there are 10x software engineers - for I have seen firsthand the carnage and devastation that even a modicum of [-10x] software engineers can inflict on an organization - and I have been fortunate to have worked with several software engineers who were certainly worthy of the 10x designation - by virtue of the indicators noted above.

Perhaps 10x is a misnomer. Certainly no one performs at peak performance, all the time.

Perhaps a 10x is really more of a [1:10], or a [1:20], or a [1:100].

Background Reading:

Scholarly Research:

1984:

• Effects of individual characteristics, organizational factors and task characteristics on computer programmer productivity and job satisfaction, Information & Management Volume 7, Issue 4, August 1984, Pages 209-214
• "Several individual characteristics of computer programmers (self- esteem, level of experience, and mathematical aptitude); four organizational factors (perceived supervisory initiated structure, perceived supervisor consideration, perceived level of performance feedback, and perceived degree of participation in organizational decisions); and five task characteristics (skill variety, task variety, task significance, autonomy, and feedback) are related to computer programmer productivity and job satisfaction. Measurement was accomplished via questionnaires; least squares multiple regression was used to test the hypotheses."

2002:  

• An investigation into the effects of code coupling on team dynamics and productivity, Proceedings 26th Annual International Computer Software and Applications (August 2002)
• "During the past three decades a number of theories have been proposed to explain the idiosyncrasies of software development as a team activity. The paper compares and combines these theories into a coherent model of software development that links software coupling and dependency management with team productivity. As a practical test of this model, the paper then investigates, the effects of coupling in two large commercial systems. It achieves this by using the VCML Views visualisation technique, developed by the authors, to expose the system wide coupling found in the code and how this coupling develops during the lifetime of a project. It then compares the resultant VCML views with simple attributes of the two projects to derive a set of important conclusions. In particular, it finds that unmanaged coupling within the code is a good indicator of potential productivity bottlenecks; that the number of programmers on a project is not necessarily a good indicator of programmer productivity; and that the architecture of a software system can radically alter the number of programmers that can effectively work together on a system."

2006:

• Pair programming productivity: Novice–novice vs. expert–expert, International Journal of Human-Computer Studies Volume 64, Issue 9, September 2006, Pages 915-925
• "Agile Software Development methodologies have grown in popularity both among academic researchers and industrial practitioners. Among the various methodologies or practices proposed, pair programming, which is concerned with two programmers collaborating on design, coding and testing, has become a controversial focus of interest. Even though some success stories have been reported with the use of pair-programming in real software development environment, many people remain rather skeptical of the claims on pair-programming productivity. Previous studies in pair programming have only addressed the basic understanding of the productivity of pairs and they have not addressed the variation in productivity between pairs of varying skills and experience, such as between novice–novice and expert–expert. Statistical productivity measurements reported by different researchers also seem to lead to contradictory conclusions. Until now, the literature has not addressed how those results and experiments were related to each other. In this paper, we propose a controlled experiment called repeat-programming which can facilitate the understanding of relationships between human experience and programming productivity. Repeat-programming can be performed when controversial issues in non-traditional programming methodologies and development productivity need to be investigated into. To illustrate how the proposed empirical experiment can put arguable, divisive problems into perspective, we have examined the productivity in pair programming as a case study. With repeat-programming, we are able to (i) better understand why results of previous pair programming control experiments reached different conclusions as to the productivity of pair programming and (ii) most importantly, present a case in which novice–novice pairs against novice solos are much more productive than expert–expert pairs against expert solos."

 2007+: 

• Towards Applying Complexity Metrics to Measure Programmer Productivity in High Performance Computing, Catalina Danis, John Thomas, John Richards, Jonathan Brezin, Cal Swart, Christine Halverson, Rachel Bellamy, Peter MalkinIBM, TJ Watson Research Center

 2012: 

• MEASURING PRODUCTIVITY OF SOFTWARE DEVELOPMENT TEAMS, Serbian Journal of Management 7 (1) (2012) 65 - 75
• "This paper gives an exhaustive literature review of the techniques and models available to measure the productivity of software development teams. Definition of productivity, measuring individual programmer’s productivity, and measuring software development team productivity are discussed. Based on the literature review it was found that software productivity measurement can be done using SLOC (Source Lines of Code), function points, use case points, object points, and feature points. Secondary research findings indicate that the team size, response time, task complexity, team climate and team cohesion have an impact on software development team productivity. List of factors affecting the software development team productivity are studied and reviewed."

• Measuring Productivity of Software Development Teams Serbian Journal of Management, Vol. 7, Issue. 1, pp. 65-75, 2012

 2014:

• Software developers' perceptions of productivity, FSE 2014 Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering Pages 19-29
• "The better the software development community becomes at creating software, the more software the world seems to demand. Although there is a large body of research about measuring and investigating productivity from an organizational point of view, there is a paucity of research about how software developers, those at the front-line of software construction, think about, assess and try to improve their productivity. To investigate software developers' perceptions of software development productivity, we conducted two studies: a survey with 379 professional software developers to help elicit themes and an observational study with 11 professional software developers to investigate emergent themes in more detail. In both studies, we found that developers perceive their days as productive when they complete many or big tasks without significant interruptions or context switches. Yet, the observational data we collected shows our participants performed significant task and activity switching while still feeling productive. We analyze such apparent contradictions in our findings and use the analysis to propose ways to better support software developers in a retrospection and improvement of their productivity through the development of new tools and the sharing of best practices."

2016: 

• What Predicts Software Developers’ Productivity? 
• "Organizations have a variety of options to help their software developers become their most productive selves, frommodifying office layouts, to investing in better tools, to cleaning up the source code. But which options will have the biggest impact?Drawing from the literature in software engineering and industrial/organizational psychology to identify factors that correlate withproductivity, we designed a survey that asked 622 developers across 3 companies about these productivity factors and about self-ratedproductivity. Our results suggest that the factors that most strongly correlate with self-rated productivity were non-technical factors,such as job enthusiasm, peer support for new ideas, and receiving useful feedback about job performance. Compared to otherknowledge workers, our results also suggest that software developers’ self-rated productivity is more strongly related to task varietyand ability to work remotely."

 2017:

• Empirical evaluation of the effects of experience on code quality and programmer productivity: an exploratory study, Empirical Software Engineering October 2017, Volume 22, Issue 5, pp 2457–2542
• "Years of experience are a poor predictor of programmer performance. Academic background and specialized knowledge of task-related aspects appear to be rather good predictors."

• Pashkevich, Natallia and Haftor, Darek M., (2017). "SOFTWARE PROGRAMMER PRODUCTIVITY: A COMPLEMENTARY-BASED RESEARCH MODE". In Proceedings of the 25th European Conference on Information Systems (ECIS), Guimarães, Portugal, June 5-10, 2017 (pp. 2755-2766). ISBN 978-0-9915567-0-0 Research-in-Progress Papers. 
• "The identification of the factors that condition a software programmer’s productivity remains a key challenge for both scholars and practitioners. While a number of studies have focused on the impact of one or a few particular factors, the way these factors jointly condition programmer productivity is still unknown. This paper presents a conceptual model aimed at a comprehensive understanding of the factors that complement each other to govern the productivity of a software programmer. The model is based on complementarity theory and its systems approach and addresses an individual worker’s productivity, which accounts for cognitive, technological, and organizational characteristics. The analyzed factors are organized into a system of complementarities, offering two propositions that specify the conditions of a programmer’s productivity. The model’s key contribution lies in its unique configuration of two systems of complementarities, which have the potential to add to the literature on the productivity of software programmers. The proposed model can be employed as a guidance for the design of empirical investigations of the conditions of individual software programmers’ productivity as well as information worker productivity in general."

• Chapter-4, Cooperative Software Development Andrew J. Ko with contributions from Benjamin Xie
• "After teaching software engineering for many years, I've been frustrated by the lack of a simple, concise, and practical introduction to the human aspects of software engineering for students interested in becoming software engineers."
• "In response, I've distilled my lectures from the past decade into these brief writings. They don't represent everything we know about software engineering (in particular, I don't discuss the deep technical contributions from the field), but the chapters do synthesize the broad evidence we have about how teams have to work together to succeed."

• Human-Centered Methods to Boost Productivity, Rethinking Productivity in Software Engineering pp 147-157, Brad A. MyersAndrew J. KoThomas D. LaTozaYoungSeok Yoon, (2019)

Misc. Articles, Blog posts:

This thread is illustrative of someone who has incredibly wrong ideas about 10x - and whose reasoning borders on cargo cult science...what he describes is prima donna behavior, at best...

• https://twitter.com/skirani/status/1149302828420067328

This thread (a response to the one above) is a much more sane exposition...

• https://twitter.com/onealexharms/status/1150180506056744961

Other articles founds...

• https://vas3k.com/notes/10x/
• https://www.ybrikman.com/writing/2013/09/29/the-10x-developer-is-not-myth/
• https://blog.usejournal.com/the-mythical-10x-programmer-e759a4ba2f0
• https://dev.to/ashrafalam/10x-programmers-myth-or-reality--4ge5
• https://thenewstack.io/10x-programmer-just-jerk/
• https://hackernoon.com/the-10x-programmer-is-a-myth-7f9074afc038
• https://dev.to/emmawedekind/101-tips-for-being-a-great-programmer-human-36nl
• https://www.andrews.edu/~vyhmeisr/papers/progprod.html
• https://www.construx.com/blog/the-origins-of-10x-how-valid-is-the-underlying-research/ 
• https://www.construx.com/blog/productivity-variations-among-software-developers-and-teams-the-origin-of-10x/

Possible 10x Programmer Exemplars:


Exhibit #1: Fabrice Bellard:

• https://en.wikipedia.org/wiki/Fabrice_Bellard

Exhibit #2: George Hotz




For the final answer to this question, Patrick Shyu's dry wit is excellent.

"Stack 10 keyboards" 

"Solve the problem forever and for everybody!"

One of the comments on Patrick's video wrote this brilliant gem:

"A 1x-er fixes a program. A 10x-er deletes the program."

 

2021-10-29 Friday

Forrest Brazaal: "10x developer" is meaningless without solving for X...

https://cloudirregular.substack.com/p/developer-equations

 

Forrest Brazeal, cloudirregular.substack.com

2019-07-19 Friday - Polyverse.io (Polymorphic OS)

I am always keen to keep an eye out for new innovative approaches to improving the security of the enterprise.

Through my connection with Pete Jarvis, I recently learned about Polyverse.io

• https://polyverse.io/how-it-works/

• https://polyverse.io/weakness-report/ 

• https://blog.polyverse.io/ 

• https://blog.polyverse.io/so-what-does-polymorphic-linux-fix-bb68c809cf14
• "More than two-thirds of the vulnerabilities disclosed in 2017 were exploitable by memory-based cyberattacks. Polyverse mitigates all of them."

The company has assembled an impressive team:

• Alex Gounares, CEO:
• Former CTO AOL, CTO Microsoft Online
• Bill Gates Technology Advisor (TA) for four years 
• Archis Gore,  CTO:
• Winner of code for Bill Gates contest in India (150K+ applicants)
• Ran site reliability and security for Amazon.com globally
• Chris Hanaoka   Chief/VP of Engineering:
• Ran Azure Cloud Infrastructure at Microsoft 1M+ servers
• VP Engineering Yahoo
• VP Engineering Ask.com
• Steven Potter, VP Global Sales: 
• $12B+ in government and commercial contracts awarded over his 20 year career
• Army Invention of the year
• Navy SEAL
• Pete Jarvis, VP Business: 
• Nortel Networks Presidents award for innovation for CentrexIP, 
• Ran Microsoft UPnP Forum, 
• Named contributor to WS-Security, WS-Eventing, WS-Discovery.

"Security is complicated, and companies often don't have the personnel or resources to protect themselves. Polyverse enables 'No Click Security', that protects you before, during, and after a fileless attack. It takes five steps to install and protect yourself. https://polyverse.io/polymorphic-linux-installation-guide/ and enables expansion of Splunk, Elastic and MicroFocus  ArcSight threat detection capabilities."

"What: Polyverse overcomes hacking by hiding operating systems in plain sight: where you have a million threats to one operating system, Polyverse provides millions of operating systems to one threat. We support public cloud, private data center deployments, and Arm, Intel architectures for embedded deployments."

"How: Polyverse inverts the problem, we take the OS and recompile it so each OS instance is unique at a memory and stack level. Polyverse's goal is to change the economics of attack in support of the defense. How so? Today, an attacker can invest 10 million in the creation of an exploit that takes control of an operating system. The attacker then recoups the investment across millions of devices, further once detected they will sell the exploit to others. Polyverse stops the first operating system investment being applied to the next. This breaks the economic model of attack. Polyverse consumes the resources of the attacker and stops them from recouping their time, and money across [N] devices."

"The Result: The attack is detected, thwarted and the attacker goes elsewhere."

"Status: Today, Polyverse works with the US Government, DLT, Microsoft, Amazon Web Services, MicroFocus, RedHat, Ubuntu, Alpine, and others to stop fileless attacks in the wild. Polyverse most notably does not change the source code of the operating system in any way, only the compiled binary operating system image layout. This approach drastically reduces the attack surface for the attacker, yet requires no changes to developer or user behavior."

"Detect, Defend, Deter: Here is a video overview of a simulated zero day stack attack on an OS, without and with Polyverse. In the case of with Polyverse the attack triggers a segmentation fault. Thus, we can deploy 10 instances – 6 standard, and 4 Polyverse instances and monitor the systems with Elastic, Splunk or Micro Focus ArcSight. If the four Polyverse instances seg fault, and the six standard do not we infer that a zero day exploit has been applied and notify the administrator."

https://vimeo.com/259728601

"Polyverse can be used to enhance your site detection capabilities in collaboration with Elastic, Splunk and MicroFocus to signal attack, and defend and deter attackers."

 Partnerships / Certifications:

• Docker Member
• Open Container Initiative Member
• Red Hat Technology Partner
• VMware Partner Ready for VMware Cloud on AWS
• Open Invention Network Member

Pete shared some noteworthy penetration testing results from a real-world public security hackathon:

• "None of the teams could to gain access to Polyverse VM's."
• "Most people/teams would spend 20-30 minutes attempting to gain access, got frustrated and then moved on to the other VM's without Polyverse."
• "Conclusion: The attacker saw a better door lock, and moved on to an easier target."
• "Zero Polyverse customers have been remotely exploited by fileless attacks "

Another interesting bit:

Polyverse runs "the largest build farm for Linux in the world on AWS. (200K build jobs at any given time, 1M+ jobs at peak, 10 Complete Linux Distributions rebuilt twice a day for every machine.)"

For those interested in more information, please contact Pete Jarvis, VP of Business, Polyverse:

• https://www.linkedin.com/in/pkjarvis/
• pete@polyverse.io

These YouTube videos may also be of interest:

2019-07-18 Thursday - Quantum Physicist Prof Michelle Simmons - Breakthrough

Quantum leap from Australian research promises super-fast computing power

https://www.theguardian.com/technology/2019/jul/19/quantum-leap-australian-researchers-could-lead-to-much-greater-computing-power

• "they have been able to achieve the first two-qubit gate between atom qubits in silicon, allowing them to communicate with each other at a 200 times faster rate than previously achieved at 0.8 nanoseconds."

• "In choosing silicon, Simmons said the research team had demonstrated that their atomic-scale circuitry has the lowest electrical noise of any system yet devised to connect to a semiconductor qubit."

2019-07-16 Tuesday - Thoughts on a recent CIO article

CIO Article: What is Architecture?

https://www.cio.com/article/3404327/what-is-architecture.html

First, let me say - I find much that I agree with - in the views expressed by the author.

However, I find the author's statements to be a bit incongruent in one respect - in that he acknowledges the value of creating architecture views/artifacts for particular users; to answer specific questions; the relevance of specific stakeholders; fit-for-purpose depictions, etc...

...to only then leap to a conclusion, which - as phrased - is not really supported by the preceding statements:

..."there are only two reasons to create any architecture artifact: to explain an engineering design to a non-engineer, or to mitigate technical risk."

Here, something seems inherently "out-of-tune"...

Photo by Matthew T Rader on Unsplash

Taken at face value - this article, if embraced by non-IT executives - does a great disservice to  minimize the value of enterprise architecture efforts.

I would submit that there may be other valid scenarios worthy of your consideration - for justifying the creation of architecture artifacts - that would otherwise be excluded by such a simple test.

These are just a few examples that quickly come to mind:

• To provide a mechanism for evolving (and aligning) the thinking of a proposed architecture - that can be communicated with technical and non-technical staff (e.g. for communication; for managing expectations, for iterative agile architecture evolution; for architecture ideation; for soliciting input - not necessarily to address a technical risk) - which requires both precise technical depictions, and often must necessarily include higher-level abstractions for consumption by non-technical / business stakeholders.

• To communicate and coordinate architecture details with integration partners (whether internally, for communication with distributed teams across a corporation - or, with external third-party partners).

• To support RFP processes - to provide sufficient detail for fixed-price quotes to be negotiated 

• To support recurring periodic analysis for Application Portfolio Management (APM) Rationalization opportunities

• To support Value Chain Analysis - and opportunities for rationalization and optimization.

• To support Lean Process Improvement optimization. 

• To support roadmap planning.  

• To document an Architecture Decision Record (ADR), re: Agile Architecture

•  To document the trade-off analysis when there are competing alternatives.  This creates a point-in-time perspective - but also is an invaluable tool in teaching business stakeholders, engineers - and in developing junior architects - by serving as an educating mechanism for the concerns that should be considered - how they are weighed - and how to balance competing concerns in making a final decision.  This also serves as a  "glue" function for improving communication & collaboration with the various stakeholder groups - and supports vetting that architecture has correctly heard (and understood) the key business priorities - and is not basing architecture decisions purely on the merit of technical considerations.

•  To support communication and transition planning between AS-IS and TO-BE

• To support Dependency Impact Analysis - to accelerate the ability of the organization to quickly & accurately determine where the modification or replacement of a given system (or component) may have upstream or downstream impact. [Ardoq is one example of an architecture tool that can be of significant help in such an endeavor.]

• To provide a meaningful way to organize and capture "tribal knowledge" that might otherwise walk out the door, as staff turnover inevitably occurs. 

• To clearly articulate the boundaries of responsibility between systems; and between automated vs. manual processes;

• To support reviews by Security, Audit,  and Compliance/Governance processes - that are mandated by regulatory (or practical) considerations

Where I fundamentally find myself in disagreement with the author,  may best be surmised as follows:

• Architecture isn't just about technical risk mitigation, or just explaining the engineering design to a non-engineer.
• Architecture is a holistic exercise that must include not only the engineering and technical aspects  of design - but must also consider and reflect the business goals and objectives - and an understanding of the technical/non-technical forces and constraints that may inform, constrain, and guide any solution design considered.
• The architect's role in documenting a system must include an understanding (and representation) - of how value is created for the business - and by documenting the AS-IS, and via transition plan - move the conversation to focus on the TO-BE, driven by a business-valued focus on reducing costs, increasing FLOW - to reduce time-to-market for new products and services, and increasing operational efficiency.
• Architecture is also about telling a story: To answer the important question of  "Why?"- as well as "Who", "What', "How", and "Where" (and sometimes, we may need to weigh in on "When" - such as in the sequencing of dependencies, to mitigate technical risks).
• At the heart of the matter, architecture is about value-creation and value-protection for the business. Thus, an architect may rightly justify expending effort in creating and maintaining artifacts for a variety of valid reasons.

2019-07-14 Sunday - New Consultation Call-Scheduling Service

*** Schedule a 1-hour Consultation ***

I've set-up an integrated calendar/scheduling service - to allow clients to schedule, and pay in advance, for one hour consultations - for those times when they may just need to get a quick answer/perspective from an expert.

Clients may also wish to leverage my expertise for brief consultations during a specific focus area of a design review, as part of a vendor discovery / technical evaluation call, to brainstorm architecture and technology roadmaps, or as a catalyst during an idea storming session to help generate a diverse set of alternative solution ideas.

I've also wanted to explore the possibility of offering these type of short consultations - as a way to provide career coaching and mentoring to fellow professionals in my industry. Think of me as an on-call "Personal River Guide" for the turbulent times that you may face in your career - from time-to-time.

The ability to have a confidential, trusted, adviser - who can offer an outsider's independent and objective perspective - can be invaluable - to executive leaders, managers, as well as staff.

While you may have had a mentor early in your career - as you've progressed and risen - it becomes more difficult, with every passing year - to find a peer (or, as is sometimes most needed - someone with more experience) that you can confidently turn to for confidential advice.

When you are under pressure to respond to the various sensitive situations that may arise during the course of a career - this consultation service can serve to help you navigate the turbulent waters.

Whether the challenge is some aspect of your own salary/compensation negotiations; preparing for a performance review; preparing for an important presentation/meeting; or seeking guidance on how to handle problems that can arise in politically-charged/sensitive relationships; or sketching out your personal professional development/improvement strategy to help you reach the next level - these are challenges that you need not face without a guide.

Photo by Rune Haugseng on Unsplash

2019-07-07 Sunday - Experimenting with RunKit

https://runkit.com/home

• "RunKit notebooks completely remove the friction of trying new ideas. With one click you'll have a sandboxed JavaScript environment where you can instantly switch node versions, use every npm module without having to wait to install it, and even visualize your results. No more configuration, just straight to coding."
• "Create an API without worrying about servers or configuration. Just export a endpoint function and your notebook automatically becomes an HTTPS endpoint, accessible from any app. Great for prototyping iOS and Android backends, or creating microservices."
• "RunKit makes it easy to let your users run the sample code in your blog posts and documentation right on your website."

console.log("Hello, I'm executing within the RunKit environment");

2019-07-04 Thursday - Visual Studio Code

Have you tried Microsoft's Visual Studio Code editor yet?  If not - you should.

https://code.visualstudio.com/

For a long time, I was a strong supporter of the Eclipse IDE - and yet - the pain of broken plugins, and the rate of the rot & decay increasing - with the number of plugins that are not maintained - with the accelerated pace of releases - has led me to finally abandon it as my primary code editing tool.

I've often fallen back to using Notepad++ - which is a good enough tool - for the majority of any quick code editing tasks.

But, I've long wanted a better tool - with a robust and vibrant marketplace of community contributed plugins.

While other of my peers have indicated their preference for Sublime Text - I have settled on the most excellent Visual Studio Code editor.

The June 2019 (version 1.36) release - yet again - impresses me with the continued pace of improvements - ease of use - and ease of configuration.

 Opening a Go file - it was a seamless experience of the UI detecting and initiating the install process - automatically - for the 11 related plugins that were suggested.

2019-07-04 Thursday - Book To Read: Living Documentation: Continuous Knowledge Sharing by Design

There is a never-ending tension between the perceived need for exhaustive documentation - and the cost/effort to produce/maintain it.

The level of need exists on a spectrum - and will vary depending on a number of requirement forces: Mortality Risks, Regulatory Compliance, Complexity of System Design and Integration, Accessibility to Source Code, Degree of Reliance/Integration with external/isolated Third-Party Systems, Degree of Dependencies between Manual vs. Automated Processes, etc.

There is no silver bullet - but I am constantly seeking out new ideas, techniques, strategies, and lessons-learned for optimizing this particularly challenging problem.

Cyrille Martraire has published a new book this year, "Living Documentation: Continuous Knowledge Sharing by Design" - which I plan to add to my reading stack in the near future. Looking forward to reading his insights and suggestions.

2019-07-02 Tuesday - TensorFlow-2.0.0-beta1 MINST Demo

On Monday night, I upgraded my TensorFlow from the 2.0.0-alpha to 2.0.0-beta1

• https://www.tensorflow.org/beta/

The documentation suggests:

"The best place to start is with the user-friendly Sequential API. Create models by plugging together building blocks. Run this “Hello World” example"

References:

• http://yann.lecun.com/exdb/mnist/

My "Lab.ML" Github Repository folder: examples/TensorFlow/MINST_Demo/

• https://github.com/intltechventures/Lab.ML/tree/master/examples/TensorFlow/MINST_Demo

...with sample output: