tag:blogger.com,1999:blog-89033875930050467242024-03-14T04:13:56.866-04:00A Businessman's ViewDiscussions on topics diverse, sure to entertain even the most seasoned professionals. Witty banter gives new life into everyday subjects.Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comBlogger124125tag:blogger.com,1999:blog-8903387593005046724.post-58256382470298207502021-01-05T13:33:00.002-05:002021-01-05T14:56:37.116-05:00So What is this IPaaS Stuff, Anyway?<p><a href="http://larrysalomon.blogspot.com/2020/10/is-nolow-code-key-to-it-nirvana.html" target="_blank"> In my last post</a>, I discussed how no-code/low-code platforms fulfill rapid development of business applications - addressing the needs of the Citizen Developer (a <a href="https://www.gartner.com/en/information-technology/glossary/citizen-developer" target="_blank">Gartner term</a> first used around 2009). I also commented on how this specific objective limits their ability to provide true integration capabilities, which require the flexibility to adapt to the myriad variations of infrastructure. This is a concern because companies often have acquired legacy systems via M&A activity while simultaneously investing in new technology solutions, resulting in a mishmash of systems with multiple ways of accessing them.</p><p>In this post, I'd like to examine how the needs of the latter group are met by describing some key capabilities that are "must-haves" for any company looking to execute on a digital transformation strategy. In order to do this, let's define who the target user base is for such a technology platform.</p><p><i><b>Disclaimer:</b> I work for MuleSoft (a division of Salesforce), which <a href="https://anypoint.mulesoft.com/" target="_blank">sells an IPaaS solution</a>.</i></p><p>Application Development Organizations (ADOs) are tasked with writing applications, sure, but the primary purpose of this activity is to either increase the business' ability to generate revenue by creating differentiating features or to decrease costs by reducing operational expenses through the use of automation (or both). Ultimately, these activities will result in a customer experience (CX) that is better than before, and studies have demonstrated that a CX which is better than your competitors will have a positive impact on top line revenue.</p><p></p><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEji9SYg7zvSi-6OYXEORpWb6cEZKzCeRI8N9ZD7Bmag5RaELytrNCLOdbMxCVHJ2xFKhYJj5QDz9Bc6dRDEPR2zfiA8OxpEVCdvhujB7QNbfLgJm6DS1ApryMFFyvTISA2dnI6dD6LldGlq/s1280/System-Integration-1.jpg" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="940" data-original-width="1280" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEji9SYg7zvSi-6OYXEORpWb6cEZKzCeRI8N9ZD7Bmag5RaELytrNCLOdbMxCVHJ2xFKhYJj5QDz9Bc6dRDEPR2zfiA8OxpEVCdvhujB7QNbfLgJm6DS1ApryMFFyvTISA2dnI6dD6LldGlq/s320/System-Integration-1.jpg" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">If you squint, it looks like a race car.</td></tr></tbody></table>However, if we go back to the context of the problem - that there are a mixture of new and legacy systems in use at any mid- or large-sized company - we can already appreciate the challenge of completing this goal of creating new applications to improve the CX. Specifically, the need to <a href="http://larrysalomon.blogspot.com/2020/08/data-is-new-oil.html" target="_blank">access data</a> in legacy systems can be challenging at best especially given proprietary protocols and data formats. <p></p><p>For example, if you ask a room of 100 developers how to access SAP to get data about a product you will get a small percentage of people with the knowledge, skills and experience about BAPI protocols and iDoc data formats raising their hands. This means that the process of creating applications that incorporate SAP will require these few individuals to support the rest of the application teams, in essence making them a resource constraint that ultimately becomes a bottleneck for the rest of the application development pipeline.</p><p>IPaaS platforms should alleviate this problem. Having said this, here is my list of capabilities that any integration platform must have in order for you to be successful at adopting it for the reasons stated above.</p><p><b>Integration with a variety of non-trivial systems.</b> It should be no surprise that the primary capability of any integration platform is the ability to...well...integrate with multiple systems, especially the non-trivial ones like ERP, HRIS, financial systems, etc. However, because every company's installation of these systems will differ from their peers, this integration capability has to be more than "one and done," i.e. it should support the common use case while also providing the flexibility for these out of the box integrations to be adapted to a company-specific configuration.</p><p><b>Self-documenting processes.</b> During my 20 years as an application developer, I often <strike>wrote</strike> saw code bases where there was either little-to-no documentation (usually in the form of comments interspersed in the code) or the documentation was originally added but, over the months/years that followed, the code evolved without keeping the documentation in sync. This meant that anyone else who had to perform updates to the code base who were not already intimately familiar with its function often times expended a Herculean amount of effort just trying to understand what was happening before they could begin to make changes, and even then there was a higher risk of breaking something due to some unforeseen consequences.</p><p><b>Ease of consumption. </b>If we write processes that incorporate multiple, difficult to use systems like ERP but we ourselves are also difficult to use then have we accomplished anything? Going back to my BAPI/iDoc example, above, all we've accomplished is propagating the need to have a small number of subject matter experts that become a resource bottleneck for the rest of the organization. The integration platform must make it easy for others to use what we've written.</p><p><b>Governance. </b>This goes without saying, but Information Security should never be a second-class citizen. If I, as a developer, am writing an API that accesses critical systems then there should be a way to control who can access the API I ultimately publish. This means that multiple authentication/authorization methods should be supported, whether it's OIDC, OAuth2, SAML, etc.</p><p>These are the primary capabilities. But why stop there? There are other things that should be considered as well, which I will lump into the category of Non-Functional Requirements.</p><p><b>Infrastructure management.</b> In a two part blog entry (<a href="http://larrysalomon.blogspot.com/2015/09/provisioning-for-what-purpose-part-1.html" target="_blank">part 1</a> and <a href="http://larrysalomon.blogspot.com/2015/11/provisioning-for-purpose-part-2.html" target="_blank">part 2</a>) that I wrote in 2015, I described how infrastructure isn't provisioned for the sake of having it lying around. Instead, infrastructure is provisioned for the purposes of running applications or, as we are discussing, hosting APIs that integrate multiple systems together. In the last 10+ years, Cloud Service Providers (CSPs) like AWS, Azure, GCP, etc. have increases in their adoption rates, so now companies are taking a cloud-first approach in order to eliminate the effort of having to install, configure, maintain and administer infrastructure in a data center. This could be extended further - CSPs have web-based interfaces to make management easier, but why do it at all? Shouldn't the IPaaS platform be able to manage the underlying infrastructure for the APIs that it will host?</p><p><b>Monitoring and Scalability. </b>Continuing the previous point, if the APIs are deployed in infrastructure managed by the IPaaS platform, should you be required to have separate monitoring solutions to manage them? What about scalability? The Delphic saying "know thyself" has direct applicability here - if the IPaaS platform is in the best position to understand what's happening within itself it should also be the one to provide monitoring, alerting, and the ability to scale up or down the computational resources required to run the APIs that it hosts.</p><p><b>Discoverability and reuse.</b> This is easily argued as more of a process related capability than a solution capability. After you've taken the time to build an integration into a system of record, the ideal result would be that someone else can leverage the investment you've already made for their benefit. Encouraging the concept of reuse can result in significant acceleration in the ability for an organization to deliver on their commitments to build and deploy applications that align with strategic initiatives. However, reuse is only achieved when it's easy to discover what has been created already - this is accomplished by including a repository where assets can not only be stored but also are tightly coupled with the rest of the "integration building" process such that previously built integrations can be easily downloaded and incorporated into subsequent projects with minimal or no manual effort.</p><p>To summarize, we've examined how no-code/low-code platforms differ from IPaaS platforms because of the differing needs they are addressing. We've further explored some of the capabilities that should be required by you before you adopt any IPaaS platform regardless of vendor. And then we looked at non-functional requirements to reduce the burden on your operations staff. </p><p>Any questions or comments are welcome.</p>Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-4158858322192407042020-10-28T14:34:00.012-04:002020-10-28T16:19:47.412-04:00Is No/Low-Code the Key to IT Nirvana?<p><br /> Unless you've had your head in the sand for the past year or so, you've seen the phrases <i>low-code</i> and <i>no-code</i> bandied about quite frequently everywhere you look. You've probably wondered if this is something new that's here to stay or just a "flash in the pan." Although the terms have been in the fore of the IT trade publications recently, Low Code Development Platforms (LCDP) (and the corresponding No Code Development Platforms) have been in existence since 2011. Their roots can be traced to the 90's with 4th generation programming languages and GUI-assisted programming paradigms, e.g. IBM VisualAge for Basic, which was discontinued in 1998.</p><p></p>For those of you who aren't familiar with either, the premise is that these platforms allow someone to quickly build applications using a WYSIWYG interface and a "click and configure" paradigm to <table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-bottom: 1em; margin-left: 1em; margin-top: 1em;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj53aHln2x-mkAcvXf7M1KgogPu3BJxT3XSmWMVWy0lTKdpKccvSKKw_szDNmQybNNJEFry1TFWbyJ6n1RRFB31V5SKG8qLqCVGuezpCyU9tgkql-ZMkWJ3VuG7a6c2IEN_70q4oCdbf0AC/s2048/Coding.jpeg" style="clear: right; margin: 1em auto;"><img border="0" data-original-height="1360" data-original-width="2048" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj53aHln2x-mkAcvXf7M1KgogPu3BJxT3XSmWMVWy0lTKdpKccvSKKw_szDNmQybNNJEFry1TFWbyJ6n1RRFB31V5SKG8qLqCVGuezpCyU9tgkql-ZMkWJ3VuG7a6c2IEN_70q4oCdbf0AC/s320/Coding.jpeg" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Isn't this the source code to Roblox?<br /></td></tr></tbody></table><br />rapidly build full applications with little or no coding required. You use something akin to a playing card that represents an action or integration which you string together to build a sequentially ordered process that mimics a business process that you need executed.<p></p><p>The resulting applications also benefit from the capabilities of the platform. For example, security best practices that protect the application and its users from the top 10 OWASP attacks could be something that is applied automatically (if the platform's runtime supports this, of course).</p><h3 style="text-align: left;">Is that all there is?</h3><p>To quote Peggy Lee, "is that all there is"...to a successful IT integration strategy? And why is IT integration even a part of this conversation?</p><p>Let's answer the last question first. Simply put, any company that is more than a few years old will have done things like acquired another company with different technology solutions, purchased now-defunct technology platforms, or simply did not upgrade older versions of major COTS solutions such as ERP, CRM, and others. Along the way, these companies have also continued to invest in current technologies in order to keep the business humming along.</p><p>This is significant because IT sprawl has always been a problem. But given the claim I made in my last entry, <a href="http://larrysalomon.blogspot.com/2020/08/data-is-new-oil.html" target="_blank">Data is the New Oil</a>, the real value in a company is not in its IT systems but in the data they contain, as this data ultimately describes the business, its customers, and everything in between.<br /></p><p>Therefore, integration is the real challenge in business, since this allows a business to leverage all of its data, and this isn't a new problem either. <a href="https://en.wikipedia.org/wiki/Enterprise_application_integration" target="_blank">Enterprise Application Integration</a> strategies and <a href="https://en.wikipedia.org/wiki/Service-oriented_architecture" target="_blank">Service Oriented Architectures</a>, popular concepts in the 1990's and 2000's, attempted to overcome this challenge but failed horribly. Instead, a new operating model needed to be developed, one which made integration less painful and allowed the business to unlock the value in their data.</p><h3 style="text-align: left;">This is real, folks</h3><p>Analyst firm <a href="https://www.marketsandmarkets.com/Market-Reports/api-management-market-178266736.html" rel="nofollow">Markets and Markets</a> "expects the global Application Programming Interface (API) management market size to grow from USD 1.2 billion in 2018 to USD 5.1 billion by 2023, at a Compound Annual Growth Rate (CAGR) of 32.9% during the forecast period. The major growth drivers of the market include growing demand for API-led connectivity, and need for public and private APIs to accelerate digital transformation."</p><p>Since integration is critical to a business' success (as evidenced by the size of the market and the expected monstrous 32.9% CAGR), we have to look at where no-code/low-code platforms - I'll abbreviate this to NCLC - fit in the context of integration in order to answer the Peggy Lee question. </p><p>Is integration even possible with NCLC platforms? If so, is it effective? </p><p>The answer, unsurprisingly, is "it depends." Because you, as the producer of assets using an NCLC platform, have little to no control over the facilities that platform provides to integrate into your systems, you are at their mercy when it comes to integration. Sure, all of the leading vendors in this space will provide access to common systems like email and others, but when you step out of the commodity systems space and into the premium application market (e.g. ERP) then the integration capabilities of these platforms have to be examined more thoroughly.</p><p>What happens, then, if the platform doesn't account for the way you have your SAP environment configured? Tough luck. Your CRM system has custom objects that you need access to? Maybe you'll get lucky. Can you unlock the value in your data via an integration strategy that's built on "tough luck" and "maybe you'll get lucky?" Probably not.</p><h3 style="text-align: left;">Sugar and spice, and everything nice</h3><p>What's really needed is the flexibility to code if you need to. <a href="https://en.wikipedia.org/wiki/Cloud-based_integration" target="_blank">Integration Platform as a Service</a> (IPaaS, which the link refers to as <i>cloud based integration</i>; this is incorrect since on-premise solutions can be included as well) provides that flexibility while also giving some of the benefits of NCLC. Solutions like MuleSoft's Anypoint platform, Dell Boomi, Jitterbit, Workato and others provide this flexibility in varying amounts to allow you to quickly develop the integrations necessary to achieve true IT nirvana while not (necessarily) requiring coding skills to produce meaningful results.</p><p>This is not to say that NCLC platforms have no benefit - they absolutely do. But their benefit lies in a different direction that addresses ease of production rather than ease of integration.</p><p>In summary, although NCLC platforms have a <a href="https://kissflow.com/rad/no-code/no-code-overview/" target="_blank">variety of benefits</a> the true objectives of a business must be clear: are they to be quick and easy, or flexible and adaptable? In my next blog entry, we'll examine some of the required capabilities of any integration platform to allow you truly meet your strategic goals.</p>Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-25330467552427506192020-08-25T15:32:00.005-04:002020-08-26T11:18:51.318-04:00Data is the New Oil<p>It was everywhere in the news on Monday, August 24: <a href="https://www.reuters.com/article/us-djia-changes/salesforce-to-replace-exxon-in-dow-jones-industrial-average-index-next-week-idUSKBN25K2HP" target="_blank">Salesforce was replacing Exxon on the Dow Jones Industrial Average</a>. (To be completely accurate, Salesforce, Amgen and Honeywell are replacing Exxon, Pfizer and Raytheon.)</p>
<p>"Wait," my wife said. "Isn't the Dow Jones Industrial Average meant for companies that produce physical products?"</p>
<p></p><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj3qwmX3EevSnQG9piTMj2xkKInVu51dreitx4Ph3aXJL0R_fyAb7jaB_sT__nLKldITNzQa8F_hB_zjw-a42u4HhoHRqDxjqaVzal5tVbbzgV8pbvx_L6FISWXBJ1XFY2BU5vTqDGSVkyG/s600/Data.png" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="400" data-original-width="600" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj3qwmX3EevSnQG9piTMj2xkKInVu51dreitx4Ph3aXJL0R_fyAb7jaB_sT__nLKldITNzQa8F_hB_zjw-a42u4HhoHRqDxjqaVzal5tVbbzgV8pbvx_L6FISWXBJ1XFY2BU5vTqDGSVkyG/w320-h213/Data.png" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">"I think I have a typo in my Excel formula..."<br /></td></tr></tbody></table>That's a great observation, I thought, especially considering that Exxon has been a part of the DJIA in some form since 1928 and Salesforce has "only" been around since 1999 and produces software exclusively. Ignoring the word "Industrial," however, the DJIA has been the most recognizable, the most frequently reported, and the most easily "understood" (using that term loosely) measure of America's economic health. And since Salesforce, which is the industry leader in Customer Relationship Management (CRM) and related solutions for 14 years (<a href="https://www.salesforce.com/company/news-press/stories/2020/8/salesforce-gartner-sales/" target="_blank">according to Gartner</a>), is as close as you can get to longevity married with financial success, it shouldn't be surprising that this becomes part of our country's economic litmus test.
<p>So how did Salesforce establish itself as a bastion of economic growth? For that matter, how is Facebook valued at over $750B (as of the writing of this blog post) when it doesn't produce anything tangible (ignoring, for the moment, its acquisition of Oculus in 2014)? How is AirBnb worth over $385B when it doesn't own a single property? How is Uber valued at over $80B when it doesn't own a single car?</p>
<p>In a word: <b>data</b>.</p>
<p>In 2015, <a href="https://www.capgemini.com/wp-content/uploads/2017/07/big_fast_data_the_rise_of_insight-driven_business-report.pdf" target="_blank">Cap Gemini conducted a study</a> that talked about the then-current impact of data on businesses. In it, they surfaced some interesting observations:</p>
<p></p><ol style="text-align: left;"><li>64% of respondents said that big data is changing traditional business boundaries and enabling non-traditional providers to move into their industry;</li><li>65% of respondents see big data as a key enabler of their organization’s effectiveness / competitiveness; and</li><li>63% consider that the monetization of data could eventually become as valuable to their organizations as their existing products and services.</li></ol><p></p>
<p>The last point is the most telling of them all, especially since this report is now 5 years old. I have full confidence that, if you asked these same companies again these questions, those numbers would be higher now. In fact, in 2017 <a href="https://www.gartner.com/en/newsroom/press-releases/2017-02-08-gartner-says-within-five-years-organizations-will-be-valued-on-their-information-portfolios" target="_blank">Gartner predicted that by 2022 companies will be valued based on their information portfolios.</a></p>
<p>To summarize those three data points, "data is the atomic unit of value" in business today. The disparity between a company's valuation and its tangible assets can easily be attributed to the fact that GAAP does not allow intangible assets to be put on a Balance Sheet (though, to be fair, the revenue generated by the use of that data should show up on the Cash Flow and Income Statements).</p>
<p>Back to the original point: Salesforce has always been a company that believes in data, but until 2018 that interest has only extended as far as the boundaries of its own data about you and your customers. In 2018, however, the company acquired MuleSoft, which specializes in unlocking the value of your data regardless of where that data resides.</p>
<p>MuleSoft's philosophy has always been that the constraints around data access is what prevents companies from realizing their full economic potential because these constraints slow down the delivery of new products and services, meaning that a business' ability to generate greater amounts of revenue through existing or new streams is hampered as a result. Furthermore, the traditional approach of tightly coupled, point-to-point integrations between applications and the systems that house business-critical data substantially reduces business agility, meaning that companies are slow to adapt and more rapidly incur technical debt as a result.</p>
<p>Companies have tried to respond with the creation of a Chief Data Officer post, and the need for this role has certainly increased over the past few years - in June 2018, <a href="https://www.visualcapitalist.com/the-rise-of-the-chief-data-officer-cdo/" target="_blank">Visual Capitalist published an infographic</a> that stated in 2019 over 90% of global companies would have a Chief Data Officer - but is this really having an impact? Unfortunately, many companies use their CDO to regulate access to data by employees instead of using it to generate value and, conversely, few companies have a true data-oriented strategy in spite of the fact that the Facebooks of the world have demonstrated in no uncertain terms the value of developing one.</p><p>The net-net of this rambling is, simply stated, that your data is more valuable than you probably realize. Getting easy access to that data is the first step in the journey to unlocking that value, but once you've taken that step you will quickly find yourself wanting to run like the wind.</p>Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-50325401710020414712020-05-15T10:28:00.001-04:002020-05-18T09:55:55.789-04:00The Engine is UnrealIf you're not a gaming enthusiast or you've been living under a rock this week, you may have missed the Technology Demonstration of <b>Unreal Engine 5</b> (UE5) on a PS5 preview system. It's an incredible piece of work packaged in a fully playable demo that showcases the advancements that UE5 has made over the years.<br />
<br />
A bit of history: back when Quake was the epitome of first person shooter (FPS) games a company out of Cary, NC called Epic MegaGames (now just <b>Epic Games</b>) developed this original, futuristic FPS game called Unreal that ran on an original graphics engine simply dubbed The Unreal Engine. I was a huge Quake fan at the time, and when Unreal was released everyone at the office that were also gamers rushed to see who could finish the game first. Along the way, we were all awed at how amazing the scenery looked in spite of our relatively low-level graphics cards.<br />
<br />
(I won the contest, by the way. It went down via a phone call to my boss on a Saturday:<br />
<br />
<i>Me [leaving message]: Steve, I have good news and bad news...</i><br />
<i><br /></i>
<i>...the good news is that you're not that far from the end of the game.</i><br />
<i><br /></i>
<i>...the bad news is...well, you figure it out.</i><br />
<br />
He called me an asshole on Monday when we returned to work. Heh.)<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibP9MIxNqkLXa9ZWTuj2NnD5P-Zn6I0bFGyWElT_5UsFnZ9rpfqMEcnMcXH-UKpT4JfZwaX2XuW2IAQ1K6oqjD88H65O7ljsstCSKNAVjuj3OL8rLuXXFhTmxIFmMl2XUh8HVvPDjWz2FW/s1600/UE5-1.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="900" data-original-width="1600" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibP9MIxNqkLXa9ZWTuj2NnD5P-Zn6I0bFGyWElT_5UsFnZ9rpfqMEcnMcXH-UKpT4JfZwaX2XuW2IAQ1K6oqjD88H65O7ljsstCSKNAVjuj3OL8rLuXXFhTmxIFmMl2XUh8HVvPDjWz2FW/s320/UE5-1.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Opening scene from the UE5 playable demo</td></tr>
</tbody></table>
Fast forward to this week. The Unreal Engine, which powers games like <b>Fortnite</b>, <b>Gears of War</b> and others, is now on its fifth iteration. To put that in perspective, the original engine was released in 1995. It's taken 25 years to evolve 5 times. The video is simply stunning, but not completely unexpectedly there are plenty of people complaining that it is "only" running in 1080p and "only" running at 30 Frames Per Second (another definition for FPS; context matters of course).<br />
<br />
These people are missing the point - let me explain.<br />
<h2>
It Isn't the Resolution, Stupid...</h2>
When NVIDEA was about to release the RTX series of GPU cards, everyone drooled over their demo in August 2018 that used the then-unreleased Battlefield 5 game to showcase how <b>ray-tracing</b> rendered scenes in a very realistic manner along with A/B comparisons to highlight how much better it is vs. the traditional technique of rendering lighting that's on screen only (called screenspace reflection), i.e. it wouldn't show reflections of light that wasn't in the viewport of the player. Ray-tracing, however, is an incredibly computationally intense process, meaning that it was impossible to expect that level of quality to happen in a software only package.<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEinuWKQPoKX1L-dJTERPKHTznFVzu5O7vHMA7hLUA-dst29BbdWbEYz1CS8LQ3ymhpbYeWEcUgW1b5LVryTfjusGaew8xMFr_8ygkjWBYq_Zf9YehIo8Zo5A-i7RpmzL5vdNU2T71A_Mnpj/s1600/UE5-2.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="900" data-original-width="1600" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEinuWKQPoKX1L-dJTERPKHTznFVzu5O7vHMA7hLUA-dst29BbdWbEYz1CS8LQ3ymhpbYeWEcUgW1b5LVryTfjusGaew8xMFr_8ygkjWBYq_Zf9YehIo8Zo5A-i7RpmzL5vdNU2T71A_Mnpj/s320/UE5-2.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">How's <i>that</i> for dynamic lighting and shading?</td></tr>
</tbody></table>
Now, UE5 storms into the room screaming "hold my beer!" as you can see in the video captures (a.k.a. <i>vidcaps</i>) that I've included here. If you can see the realism in these scenes, you are also thinking "it must be hardware based ray-tracing!" but you'd be wrong. This is rendered completely in software.<br />
<br />
The point I'm trying to make is that UE5 demonstrated in less than 2 years since the RTX card was released in October 2018 that hardware is no longer necessary to get ray-tracing-quality rendering.<br />
<h2>
...But Nothing Happens in a Vacuum</h2>
That doesn't mean that specialized hardware isn't needed. If you watch the UE5 demonstration video (embedded at the bottom), you'll hear Epic Games' <a href="https://twitter.com/BrianKaris" target="_blank">Brian Karis</a> (Technical Director of Graphics) talk about how the engine is able to import the cinematic versions of Quixel Megascan assets using 8K textures that can be as small as an individual pixel, which also requires pixel accurate dynamic shading resulting in over 1 billion (yes, with a "b") triangles in each frame of the demo that are crunched, in real time and in a lossless fashion, to 20 million triangles that are actually rendered.<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVrXA3DvD4eccpAByr35gzzrCx78BBp3F42HTi1ujzTt92Cw-e-0pUFsGVdrOlno7JYwHfabMEsbLmADXbfvk0QOH-imbvb72ooz6brXz_A6tvzpRT7zByGuJkxWqEIcwD6oQQObJSlEvB/s1600/UE5-3.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="900" data-original-width="1600" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVrXA3DvD4eccpAByr35gzzrCx78BBp3F42HTi1ujzTt92Cw-e-0pUFsGVdrOlno7JYwHfabMEsbLmADXbfvk0QOH-imbvb72ooz6brXz_A6tvzpRT7zByGuJkxWqEIcwD6oQQObJSlEvB/s320/UE5-3.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">This is what 20 million triangles looks like</td></tr>
</tbody></table>
That's a lot of triangles, Karen.<br />
<br />
Obviously, every single asset, whether Quixel Megascan, Niagara Effects, etc. isn't kept in memory for the entirety of the game / demo, but instead are loaded at runtime. The massive size of these data structures collectively means that both SATA and even current generation NVMe drives won't have the juice to supply data to UE5 at the rate in which it is consumed.<br />
<br />
So Sony developed a brand new storage architecture for the PS5 to make this all a reality. I won't go into details (mainly because I don't know them heh) but, to put this into perspective, whereas the PS4 took 20 seconds to load 1G of data the new storage architecture allows the PS5 to load 5G of data <i>in one second</i> for a massive 100x increase in performance.<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjGHzc5MqK45kDfc9q2u5BJ4yQSa9AK1oG9i4nkd7wR6H2GZccmstRmuYawd8nuJDN_8bopB9BvNgHkG3Ay2XjrGeuV6p5Xc39Snhevn5s5g7rTZeijG0pQVTP3AOIADQI8JFurLKzJWCka/s1600/UE5-4.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="900" data-original-width="1600" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjGHzc5MqK45kDfc9q2u5BJ4yQSa9AK1oG9i4nkd7wR6H2GZccmstRmuYawd8nuJDN_8bopB9BvNgHkG3Ay2XjrGeuV6p5Xc39Snhevn5s5g7rTZeijG0pQVTP3AOIADQI8JFurLKzJWCka/s320/UE5-4.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">This statue alone is comprised of 34 million triangles</td></tr>
</tbody></table>
The reason why I bring this up is that it's impossible to imagine a world where Sony doesn't license this architecture to disk drive manufacturers meaning that it'll eventually end up in your gaming laptop a few years down the road. Considering how storage is one of the two biggest bottlenecks in general purpose computing (the other being network speeds), the implications of having this in my laptop are enormous.<br />
<h2>
The Impact on Film-making</h2>
This is an area that many people probably don't realize is already happening. UE4 (the previous generation) was used by top-tier effects companies such as <b>Digital Domain</b>, <b>ILM</b>, <b>Lucasfilm </b>and <b>Weta Digital</b> to render complex scenes on large projection screens allowing the actors to be filmed directly in the original shot rather than require green screens to be used.<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwhlvYG4MJA-bh7FmKdw4TSaeYSRdm7xoPhyYZ-2Uj8JE0WXP8AsubGVOMZym54yhltyMP5Mmrjb5xmtAV2A0_1iK3jSiBLhql5tg1sfUXn_0jhTIZrhKEowxwEv3ywY9G2NEImlEDy0s2/s1600/UE5-6.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="900" data-original-width="1600" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwhlvYG4MJA-bh7FmKdw4TSaeYSRdm7xoPhyYZ-2Uj8JE0WXP8AsubGVOMZym54yhltyMP5Mmrjb5xmtAV2A0_1iK3jSiBLhql5tg1sfUXn_0jhTIZrhKEowxwEv3ywY9G2NEImlEDy0s2/s320/UE5-6.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Over 500 of those statues are in this scene for a total of <br />
over 16 billion triangles just for the statues</td></tr>
</tbody></table>
However, the production pipeline for this process wasn't for the faint of heart nor was it cheap due to the limitations of the platform. Now that UE5 can render cinematic quality scenes in software only, it isn't too far fetched to imagine that the use of frequency of CGI in smaller budget films will increase and the complexity of scenery will increase as well. This is great news for indie production houses who want to dip their toes into film genres that were previously out of reach due to budgeting constraints.<br />
<h2>
Summary</h2>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbNmIorloNn6ey0Vdf12tqZLNXLVbOMuCHvu7hA578IOijpNwABGsUKuw5huEpnQCEjn9U7nQDm_TXlIxxxwJgOQimKc1zojP4_tJZNanxVv39Kf-BZxE2X-7demxGpr7bEkUGj9i6Z031/s1600/UE5-5.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="900" data-original-width="1600" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbNmIorloNn6ey0Vdf12tqZLNXLVbOMuCHvu7hA578IOijpNwABGsUKuw5huEpnQCEjn9U7nQDm_TXlIxxxwJgOQimKc1zojP4_tJZNanxVv39Kf-BZxE2X-7demxGpr7bEkUGj9i6Z031/s320/UE5-5.png" width="320" /></a></div>
All-in-all the pending release of the UE5, coupled with the architectural advancements of the PS5 storage system, is great news for everyone whether we benefit from it directly (via gaming) or indirectly (via new storage devices or better quality cinematography). You simply need to look beyond what the demonstration showed to see the bigger picture, pun most definitely intended.
<br />
<br />
Check it out in the demonstration video, below.<br />
<br />
<div align="center">
<iframe allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen="" frameborder="0" height="315" src="https://www.youtube.com/embed/qC5KtatMcUw" width="560"></iframe></div>
Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-61252693909497152502020-04-24T10:54:00.000-04:002020-04-24T10:54:27.886-04:00Job Searching ThoughtsI promised on LinkedIn that I would document my process of finding a new job, which took me four months and was complicated significantly by the global COVID-19 pandemic. This is that blog entry.<div>
<br /></div>
<div>
<b><span style="font-size: large;">The Context</span></b></div>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi6nilTgr36Ztn03iuOFQJEtDyKli0UCgRS8RzRrDzzvMe5SgJmszAnqCkavfK7CG0ztcbQGKPeMnq11UgZ5_dPQU92J3aMvw9smeGAa3sdbDCnkMDkEYrrjNqLjDylpWBgOv5KsS3WwSSA/s1600/Stress.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="613" data-original-width="960" height="203" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi6nilTgr36Ztn03iuOFQJEtDyKli0UCgRS8RzRrDzzvMe5SgJmszAnqCkavfK7CG0ztcbQGKPeMnq11UgZ5_dPQU92J3aMvw9smeGAa3sdbDCnkMDkEYrrjNqLjDylpWBgOv5KsS3WwSSA/s320/Stress.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">"I want to rip my hair out! Oh, wait..."</td></tr>
</tbody></table>
<div>
In mid-December, I received a phone call from my manager at the time. The call, if I summarize it in a humorous light, went something like this: "you got a nice end-of-year commission check, yes? Great because you don't have a job after the end of this month. Merry Christmas."</div>
<div>
<br /></div>
<div>
<b><span style="font-size: large;">The Strategy</span></b></div>
<div>
I was given two weeks before my position was eliminated, and I was told that if I could find another position elsewhere within the company I would remain employed there. "Great!" I thought. "I'll just reach out to the numerous people in senior positions to get transferred to another group." Unfortunately, it wasn't this easy - either there was no headcount available or it was in a different region of the country with no way to transfer the open headcount to the East Coast, where I am based. And because I am unable to relocate due to family concerns, that was not an option.</div>
<div>
<br /></div>
<div>
As a result, I started reaching out on LinkedIn at the very end of December.</div>
<div>
<br /></div>
<div>
<b><span style="font-size: large;">LinkedIn, a Network for Professionals</span></b></div>
<div>
I've been blessed to have, over the years, established a vast network of over eighty CxO and C-1 individuals. These are people I have worked with throughout my career who have ascended through the ranks into positions of power and influence. I figured that one of them <i>had</i> to have an open position in their organization that I could fill.</div>
<div>
<br /></div>
<div>
Some background on me: I'm a "big picture thinker." I excel at engaging senior executives like this to not only listen to their strategic initiatives but to also ascertain whether there are holes in those plans and/or whether there are ways to improve an already good idea and unlock more value for their organization. I'm typically part of the sales team for large accounts like the big pharmaceuticals, insurance companies and global banks. It seemed natural to me, therefore, that I could easily slide into a Business Value Consultant or similar type of role.</div>
<div>
<br /></div>
<div>
I started contacting CEOs that I know. And then CROs, CMOs, CIOs and CTOs. And then mid-level managers. And finally individual contributors.</div>
<div>
<br /></div>
<div>
In the end, a drummer that I had just met two weeks prior - yes, you read that correctly - who is an IT recruiter professionally told me that he knows a corporate recruiter at my current employer. He offered to reach out to them to see where it may go and, ultimately, it was this random conversation that led to a job offer.</div>
<div>
<br /></div>
<div>
<b><span style="font-size: large;">Thoughts on my Job Search</span></b></div>
<div>
Along the way, I applied some things I had learned throughout the years, hustled quite a bit, and got lucky a few times. Here are the things I learned along the way.</div>
<div>
<br /></div>
<div>
<b>Build a pipeline of job searches. </b>In any enterprise sales position, quota carrying people know that they need a pipeline that represents the potential to make 3x, 4x or even 5x their number. The reason for this is that most of those opportunities will fail, with the remainder allowing them to reach their quota. A similar concept applies here - at any given time during the 4 months that I was searching, I had 3-5 simultaneous interactions with different companies - never more and never less.</div>
<div>
<br /></div>
<div>
<b>Don't flood your pipeline. </b>Having said that, I could have had 10 times that number if I had wanted to do so. But I knew that I would need time to prepare for each phone call, research the backgrounds of each company and the individuals with whom I was speaking, etc. Finally, I knew that if I were able to somehow manage to translate every connection to an opportunity at the same time, most or even all of them would fail, meaning I would have nothing in the pipeline for the next several weeks while I tried to uncover additional jobs for which I could apply. The expression "slow and steady wins the race" applies here, and while the temptation is there to try to do as <i>much</i> as possible as <i>quickly </i>as possible so that you can hopefully minimize your unemployment time, it makes more sense to start with the highest quality opportunities first and, if those fail, start looking for new high quality opportunities as you simultaneously inject the next set of ready-to-go opportunities into your pipeline.</div>
<div>
<br /></div>
<div>
<b>Document everything. </b>This isn't the first time I've been unemployed. Back in the 90's I went through this process while living in the State of NY, and back then the unemployment office expected you to bring in documentation proving that you were actively looking for work. When this started I expected something similar for the State of NJ and, as a result, I immediately kept a log of every interaction at every company that I had - each one dated - as well as a list of every job posting on LinkedIn for which I submitted myself for consideration. As time went on, however, this document served as a way for me to keep straight all of the companies I was actively engaged with (opportunities that were "qualified out" were moved to another section at the end of the document); what the next steps were; and the previous activities at that company. This was immensely valuable for me to prepare for the next phone call that I was to have with each company, since many of the jobs were similar in nature and it would have been easy to confuse one company for another if I attempted to do this from memory alone.</div>
<div>
<br /></div>
<div>
<b>Be proactive with your network. </b>You have undoubtedly encountered a lot of other quality companies throughout your career. Do you know if any of your former peers are working at those companies now? It's easy to check! If you find someone with whom you had a good relationship previously, send them an IM on LinkedIn to a) let them know your situation, b) find out what shape the company is in, and c) see if they know of any open positions that are <i>not</i> published in the Careers section of that company's website. (Yes, that happens more often than you think.)</div>
<div>
<br /></div>
<div>
<b>CxOs are just like everyone else. </b>It's tempting to think that a CEO can just snap their fingers or wave a magic wand to create a job for you. Hell, I knew that wasn't the case and yet I <i>still</i> tried to make this a reality. Unless they have a position that reports directly to them, they are just like everyone else, i.e. they are able and often willing to introduce you to the hiring manager but that's all that they will do. The only advantage you really have by knowing someone in their position is that they are well-connected in their company and so any introduction they offer to make will be successful, unlike other situations where you'll reach out to hiring managers directly who won't even respond to your outreach efforts.</div>
<div>
<br /></div>
<div>
<b>And, yet, CxOs are not just like everyone else. </b>In spite of the previous paragraph, the value of a set of references (when you apply to companies other than their own) or endorsements that includes CEOs and people in similar positions cannot be understated. For example, my initial interaction on LinkedIn was a general purpose posting about my situation. A CMO based in the U.K. that I know shared this post on his timeline, and it received far more views than my original post did. A number of people who viewed the shared post resulted introduced me to senior people at their companies.</div>
<div>
<br /></div>
<div>
<b>Don't get discouraged. </b>I realize this is much easier said than done. In early March, I had completed the interview process with a great company and after coming home from the final interview (on a Tuesday) I told my wife I expected an offer to come by Friday. On Wednesday, the Board met and decided to put all hiring on hold until the COVID-19 pandemic played itself out. While this is an extreme example given the global pandemic, similar things can happen to you during your job search. It's easy to despair, but if you have a healthy queue of opportunities to insert into your pipeline stay positive and continue the cadence you already have established.</div>
<div>
<br /></div>
<div>
<b>Don't get offended when people don't reply. </b>There will be a lot of situations where you'll reach out to people that you know and won't receive a reply. Or you'll have a friend who "knows someone" tell you that they want you to reach out to them but won't receive a reply. Etc. Is it acceptable behavior when people do this? No. Should you get upset because of it? No. Use the energy instead of focus on the next opportunity in your pipeline. </div>
<div>
<br /></div>
<div>
<b>Finally, don't discount anything. </b>As I mentioned, it was a drummer that I met just two weeks prior to him telling me that he was an IT recruiter that ultimately resulted in me finding my next adventure. In sales there is an expression that says "Always Be Closing" (or "ABC"). You never know how you'll be introduced to your next employer so always take the time to speak to people about your situation <i>and</i> (more importantly) what you're hoping to achieve at the end of this. Note that there is a fine line between doing this and simply whining about how unjust life is so be sensitive to this. </div>
<div>
<br /></div>
<div>
If you're currently unemployed I hope that these thoughts help you in even the smallest of ways so that you can change your situation more quickly.</div>
Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-44437385406919816632019-09-07T13:49:00.000-04:002019-09-07T20:03:43.189-04:00Value Selling? Challenger Selling? Bah!Every so often, it seems, there is a new "Johnny come lately" on the sales scene as far as methodologies, means of engagement, etc. is concerned. Whether it's <b>BANT</b>, <b>MEDIC </b>(or any its variants), <b>Value Selling</b>, <b>Challenger Selling</b>, etc. there always seems to be a new book that promises to make you more effective in your selling activities. Here's and idea, however, that doesn't seem to get a lot of press coverage, in all likelihood because it's fairly obvious: <b>just solve the problem</b>.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_bKfAcYXrJyVsAq-NXMHWNJdoB36NsYzPjfxXF-a33zVE9VU_hEmyLQBY-wqQBELV5LYKoGaNdu2mszfZfI_xr7CvH2x7CiCL5k3gFWG92Zw0nRoiMSCapejdYMv55jzToSRpdfnfnwrE/s1600/Cube.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="592" data-original-width="592" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_bKfAcYXrJyVsAq-NXMHWNJdoB36NsYzPjfxXF-a33zVE9VU_hEmyLQBY-wqQBELV5LYKoGaNdu2mszfZfI_xr7CvH2x7CiCL5k3gFWG92Zw0nRoiMSCapejdYMv55jzToSRpdfnfnwrE/s200/Cube.png" width="200" /></a></div>
Let me explain.<br />
<br />
With the exception of the CIO, CTO and CDO, most IT professionals aren't looking to anticipate future needs or prevent issues that will occur because they can start to develop a solution now. Instead, they are reactive, seeing problems develop and then realizing that solutions are needed.<br />
<br />
See if these stories sound familiar.<br />
<br />
- The <b>PMO</b> is having trouble managing releases from the application development teams because compliance-related activities like developing support plans aren't done by the application owner yet these deficiencies aren't uncovered until the application has had a Severity 1 issue in production six months after it was released.<br />
<br />
- The <b>Security Operations</b> team discovers that anyone using the proper version of their VPN solution can get access to the corporate network regardless of authorization due to a misconfiguration or their VPN infrastructure.<br />
<br />
- <b>Infrastructure Monitoring </b>has a monitoring solution, which has been in use for years, that was bought by a large software company who decided to discontinue support for it two years ago. Only now have the applications being monitored outgrown its capabilities, meaning that it finally has to be replaced.<br />
<br />
In all of these examples (which are all based on recent situations in real companies), the solutions to the problems weren't pursued until the problems became large enough that they could no longer be ignored and solutions were absolutely necessary. If you were the head of the PMO, the CISO, or the Head of Infrastructure Operations in those examples, do you need someone to challenge the way you think? What about someone to show you the value of their solution to your business?<br />
<br />
When I was in IT, my answer would have been, "I don't need any of that - just fix my damn problem." Yet this seems to be the biggest challenge to all sales professionals that I've seen - they overthink things and, as a result, they spend far too much time trying to impress their customer with all of the bells and whistles of their solutions. They should instead be showing their customers how they can stop keeping the lights on and go back to creating value for their company through innovation.Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-26156821621636837662019-04-08T14:41:00.002-04:002020-03-12T13:40:03.897-04:00Choose WiselyI'm a big fan of <a href="https://na.leagueoflegends.com/en/" target="_blank">League of Legends</a> (affectionately known as "LoL"). There's a saying that man can live on potato chips and toilet paper alone - I could live on playing LoL, and toilet paper would be optional. LoL is a game in the MOBA genre, which is an acronym for Multiplayer Online Battle Arena. In this particular MOBA game, you select a character to play based on their abilities, your knowledge of their play-style, and your opponent. Additionally, you can customize some of their stats to, for example, deal more damage or to regenerate your health more quickly so that you (hopefully) don't die if your opponent "goes all in."<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHgBomH3_jf2NvposQx2N__xUQiIiC282wBeI3Qzsu_9q_BCHoLE-UdjOLL2HgkNhN-8cFu9THIjmxXaWbI3ZulktlU4UmaNoY61fc0OIccxVeHcBMWvhMcElDXrb0J16e0QUlFKCOSmFc/s1600/LoL+Gameplay.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="438" data-original-width="800" height="109" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHgBomH3_jf2NvposQx2N__xUQiIiC282wBeI3Qzsu_9q_BCHoLE-UdjOLL2HgkNhN-8cFu9THIjmxXaWbI3ZulktlU4UmaNoY61fc0OIccxVeHcBMWvhMcElDXrb0J16e0QUlFKCOSmFc/s200/LoL+Gameplay.jpg" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">League of Legends gameplay</td></tr>
</tbody></table>
I'm a morning person so on the weekends when I wake up (before anyone else in the family), I like to make my cup of coffee, turn on Twitch, and <a href="https://www.twitch.tv/solorenektononly" target="_blank">watch my favorite morning LoL streamer</a>, SoloRenektonOnly. (You owe me for any new subscribers, Mike.) On one such occasion, SRO/Mike was talking about the customization process and said that people often ask him if one stat boost is better than another. His response was quite profound - he said (paraphrased), "everything is an opportunity cost. Don't think about what you get for taking this stat boost but instead think of the other stat boosts you could have gotten instead and consider whether the one you're choosing is better than the others for the game you're playing." I would add to that and say that, after the match is finished, you determine whether your choice was the correct one to make.<br />
<br />
In other words, apply the <b>Deming Cycle</b>.<br />
<br />
The <a href="https://en.wikipedia.org/wiki/PDCA" target="_blank">Deming Cycle</a> is often referred to the PDCA cycle (which stands for "plan, do, check, act" [and then repeat]). Created by W. Edwards Deming, it was used in quality control but quickly found its application in other areas, such as ITIL and Six Sigma due to its inherent feedback loop which enabled something called <b><a href="https://wiki.en.it-processmaps.com/index.php/ITIL_CSI_-_Continual_Service_Improvement" target="_blank">Continual Service Improvement</a></b>, i.e. the "check" from the last iteration is taken into consideration for the next iteration (the "act"). This concept is applicable in other areas too, whether we are talking LoL, planning your weekly dinner menu for the kids (if they don't like your broccoli casserole this week then don't make it next week heh), etc.<br />
<br />
If you were to summarize PDCA without using the words that make up its definition, it would probably sound something like this: choices are not things to be made in isolation. There is no "see what I can do now?" in life. Instead, everything should be viewed through the lens of "see what I chose not to do because I made this decision?" This is especially important in corporate strategy. There are finite amounts of resources (staff, money, time) and so choosing to go in one direction means you are unable to go in another direction, at least at the velocity you would if time and resources were infinite.<br />
<br />
So how do you create a list of initiatives you could start as a company? To answer that, you'd need some sort of metric that provides an equal basis for comparison. While ROI is the typical metric used, each project will take a different amount of time to complete, cost different amounts of capital, and provide different amounts of benefit. This lack of consistency is why financially savvy people tend to gravitate to one of two financial metrics: NPV and IRR.<br />
<br />
<b><a href="https://www.investopedia.com/terms/n/npv.asp" target="_blank">NPV</a></b>, or <b>Net Present Value</b>, is the value of a project to be completed at some point in the future in today's currency. In other words, it takes into consideration how much the capital that you would spend on the project could return if invested elsewhere. It relies on the concept of <b><a href="https://www.investopedia.com/terms/d/dcf.asp" target="_blank">Discounted Cash Flows</a></b> (<b>DCF</b>) that reduce the benefit by a fixed percentage (the <a href="https://www.investopedia.com/terms/d/discountrate.asp" target="_blank">Discount Rate</a>) every year until the project is completed.<br />
<br />
As you can imagine, NPV is useful for examining a single project, but when comparing multiple projects it's still an apples-to-oranges comparison since there is no single consistent frame of reference for making the comparison. This is where <b><a href="https://www.investopedia.com/terms/i/irr.asp" target="_blank">IRR</a></b>, or the <b>Internal Rate of Return</b>, comes in. I'm going to catch a lot of flak from the financial people for saying that IRR is a risk-adjusted view of the value of a project expressed in terms of a percentage. (In reality, the actual definition of IRR is that it's the discount rate that would need to be applied so that NPV equals 0; higher numbers indicate that the project is a better quality investment.)<br />
<br />
In other words, you can calculate the IRR for any project and you'll always get numbers on the same scale (percentages). This is useful for comparing multiple projects, since the one with the highest IRR will be, <i>all else remaining equal</i>, the one with this highest value from a quality of investment perspective.<br />
<br />
I italicized "all else remaining equal" for a reason, however: there are aspects to any project that cannot be accounted for in any financial model. Unsurprisingly, the biggest ones are the cultural impact that any large initiative will have, the rate of adoption, and the amount of pushback you get from both senior leadership and the general masses. Not unlike the challenges that you hear about with DevOps, this innumerable but tangible characteristic of any project can doom any initiative before it gets a real chance to be successful.<br />
<br />
"Wait, Larry," you say. "You just basically said that we should compare multiple projects using a fixed-reference, financially based model to choose the one that's the best, but then you said that the assessment may be completely invalidated by things that are immeasurable?" Much like the comment by SRO/Mike, any decisions you wish to make cannot simply be done by looking at the raw value of that decision but much be considered in the broader context of what else would happen if you make that decision.<br />
<br />
Therefore, the development of any effective corporate strategy should not only be prioritized in terms of the potential raw impact to the business but instead should take into consideration the associated risk of each item on that list. While this won't be a formulaic approach to creating a fool-proof strategy, it will certainly increase the chances of success by simply highlighting the potentially negative aspects so that you are fully aware of the risks and can proactively develop contingency plans for mitigating any negative impact that may occur.Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-57251543964984728662019-02-25T12:20:00.001-05:002019-02-27T10:34:50.879-05:00Don't Push the Fish!Yes, I realize that's probably the strangest title for a business-related blog post that you've ever read (or that I've ever written). You'll see the relevance by the end of this article - I promise.<br />
<br />
During my years as a Computer Science undergrad at Clemson University (go Tigers!), I was taking a class on algorithms when the following statement (paraphrased) was made: a well-designed algorithm will always trump computing power (assuming, of course, there isn't a huge difference between the CPU speed on the former versus the latter). This means that you could have a slower CPU but with a better algorithm it would always outperform the faster CPU when various benchmarks were run on both processors. In business, a similar concept exists: you can have the best technology, but it's the company with the best "everything else" that will always win.<br />
<br />
What is the "everything else," you ask? Taking a page from the Organizational Change Management (OCM) playbook, we see that there are typically five stages to any company that's doing well, listed in order of execution.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQ0z5GMKtQN_3rgaRUyi2GdLXUbd5dtOTM9BDkTXbieby7_qiQDJNnYZ2DiIbw7dU-Mo8T2fDtouvomijledQB1Mf1bZg8jcs8makb1dwPTwVyorQqhAfRWxefxxExhetiz2K6ct42AyxA/s1600/Process.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="495" data-original-width="814" height="194" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjQ0z5GMKtQN_3rgaRUyi2GdLXUbd5dtOTM9BDkTXbieby7_qiQDJNnYZ2DiIbw7dU-Mo8T2fDtouvomijledQB1Mf1bZg8jcs8makb1dwPTwVyorQqhAfRWxefxxExhetiz2K6ct42AyxA/s320/Process.png" width="320" /></a></div>
<b>Strategy</b>. This defines the overall corporate goals. This is not a mission statement, which I've always found useless since they are often filled with "feel good" terms that really have no real weight behind them. And it isn't filled with unqualified statements like "become the leader in our industry" either. This is one or more quantifiable items that describe the desired end state for the entire company.<br />
<br />
<b>Structure</b>. Based on the strategic goals, the business will have to be structured in such a way that you can focus on those goals with little distraction. The "one general manager, one toy" rule comes to mind, i.e. be able to be the best at your toy. Don't lose focus by taking on other responsibilities that have little or no bearing on your toy.<br />
<br />
<b>People</b>. Either hire the best people to lead the business segments or spend the time and money to invest in your top employees so that they are able to do the same.<br />
<br />
<b>Process</b>. How are you going to achieve your segment's goals? If every segment is a business unto itself, what's the operational model look like? How are your day-to-day responsibilities being fulfilled? What about exception handling, i.e. how do you handle out of band events that can have a material impact to your segment's bottom line?<br />
<br />
<b>Technology</b>. Finally, what technical capabilities (note that I did <i>not</i> say "what technology solutions") will you need to achieve your goals?<br />
<br />
The pitfall that I've seen several organizations fall into is that they execute the first three in the correct order but the last two will be reversed. In essence, they buy solutions based on whatever the latest trends are that they find in the trade publications and then they try to reverse engineer their processes around the features and functionality in the solutions that they purchase. This is wrong, however, because it results in gaps that need to be filled via manually executed processes or other such shenanigans.<br />
<br />
As a child, did you ever help your parents do a large jigsaw puzzle (1,000 or more pieces)? If so, you probably found an interior piece that <i>looked</i> like it fit in a particular spot but it didn't really even though you spent a few minutes trying to close that millimeter gap at the bottom edge. Your parent eventually had to dissuade you of further attempts before finding the correct piece to place there. Buying technology without having the process well defined is similar to this. It looks like it'll work, but there are always gaps that prevent things from executing as smoothly as they should.<br />
<br />
Now we come to the title of the blog. I'm a huge fan of the show <a href="https://www.history.com/shows/forged-in-fire">Forged in Fire</a> (on the History Channel), which isn't surprising to anyone who knows me since I'm also a huge fan of the fantasy/adventure genre of fiction (Lord of the Rings, Wheel of Time, Riftwar Saga, etc.). Last year, a new series debuted after this show called <a href="https://www.history.com/shows/forged-in-fire-knife-or-death">Knife or Death</a>, which was a timed "obstacle course" (loosely used term there) where contestants could bring their edged weapon of choice in an attempt to hack-and-slash through a variety of things in the quickest time possible.<br />
<br />
At one point in the course they get to "sudden death," which is where they have one attempt to completely cut through 3 items, one at a time. One of those items is a large fish, hanging from the ceiling via a rope attached to its tail. The correct way to cut through the fish is to slice through its spine at a slightly downward angle so that the blade prevents the fish from moving away, but invariably 90% of the contestants try to slide through the side of the fish, which only pushes the fish away from the blade. This is similar to the process-vs-technology point I was making above: you can attempt to figure out the process after you've acquired the technology, but you're simply pushing the fish, i.e. you may make some progress toward your goals but ultimately it's a failing proposition because you aren't approaching the problem correctly.<br />
<br />
To put it another way, buying technology first is akin to the tail wagging the dog. Figure out first what the best method is to reach the end state that you desire and then find the best means to execute afterward. You may end up buying solutions where you use only 50% of the capabilities, but if that means your business is able to execute like a finely tuned watch then the investment is still worth every penny you spend.Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-62831322137219204162018-09-21T12:32:00.000-04:002019-02-25T11:50:41.390-05:00Your Dad's DevOps is DeadAgile. Test Driven Development. DevOps. All of these terms represent phases that the application development community, as a whole, have gone through for various reasons. Whatever the reason, however, they all miss the mark. Yes, I just said that.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhY-GZhV9NkNXztRNIzteopjFyEuoViptOAmz7aZkhKgODJ_riBYptCMPsOnGmtHS4y3q81I5507mie6o2rs90ndwrUxE-Aj7es7zX9vh_8Mcb9MPdlHfkUKsE0prIPe5dncSHxz_uy0cs-/s1600/testing.jpeg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="1067" data-original-width="1600" height="133" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhY-GZhV9NkNXztRNIzteopjFyEuoViptOAmz7aZkhKgODJ_riBYptCMPsOnGmtHS4y3q81I5507mie6o2rs90ndwrUxE-Aj7es7zX9vh_8Mcb9MPdlHfkUKsE0prIPe5dncSHxz_uy0cs-/s200/testing.jpeg" width="200" /></a></div>
Several years ago, I conducted a webinar entitled <b>Agile is Dead</b>. The title wasn't only incendiary to those who attended; I even heard from the agile project management solution's product team who decried my title as an attempt to force them into irrelevancy.<br />
<br />
"Never mind that," I told them. "Listen to what the content is all about." What was the content then, and why am I bringing it up now?<br />
<br />
Back then, I argued that Test Driven Development was a fallacy because the one thing that was immutable was the release date. Forcing developers to spend time developing test cases to be solved and that leaves developers less time to write the code that satisfies the test cases that they developed. It was a relevant point then, but it's even more relevant now.<br />
<br />
Remember: there are a bevy of companies that do the same thing as your company. Many of them are smaller, more nimble (by definition) companies. And so giving your customers any excuse to go to them is a bad idea since, after all, your customers simply want to accomplish their own goals, e.g. by a new knick-knack that they feel they need.<br />
<br />
Don't believe me? Ask Amazon, <a href="https://www.fastcompany.com/1825005/how-one-second-could-cost-amazon-16-billion-sales">which calculated in 2012 that it would lose $1.6B (that's billion) in revenue because of a <i>1 second</i> delay</a> in their shopping cart processing code. 1 second would cost them 10 digits of revenue. And that's not just theoretical either - the news is littered with similar examples where a poor customer experience resulted in a huge impact on revenue.<br />
<br />
Going back to my original point: DevOps is dead. In fact, I'd argue that it was never alive in the sense that it was the driving force behind business decisions. Instead, it was the result of the recognition that the consumer landscape has irrevocably changed and, if companies aren't more mindful of the perceived value of the end result, their customers will leave.<br />
<br />
Consider for a moment that statement. A poor customer experience will result in a drop in revenue.<br />
<br />
In March 2017, a <a href="https://customergauge.com/blog/monetized-net-promoter-tying-revenue-to-nps">study was conducted by Customer Gauge</a> to determine the impact of <a href="https://en.wikipedia.org/wiki/Net_Promoter">Net Promoter Score</a> (NPS) on revenue. What they determined was that a 10 point increase in NPS corresponded to a 3.2% increase in revenue. And while they didn't look at the converse of that conclusion (i.e. how much revenue is lost due to a 10 point drop in NPS), it's reasonable to conclude that there will be a drop of similar magnitude.<br />
<br />
What does this all mean? It means that you should stop focusing on whether development and operations can come together, hold hands, and sing kumbaya. Instead, there should be a recognition that <i>all</i> parts of your company need to work together to ensure an exemplary customer experience. There is no development or operations. There is only the brand of your company and the effect that each individual has on that brand's value.Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-83460634470486469402018-02-27T13:32:00.003-05:002018-02-27T13:32:56.001-05:00It's all about Problem Management<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjEP-kGZsG3mOBwH64KXvxhsSVu9ksYFdSibKxmx4V2nmdMbrtM2kphlyI1e0GxR6_1fdnXCj2IFwcf-AQ8oYLePIcZDf0j3jZAeZbE8iCbjcVt9zkWYZl-DFM0NUok66ebB8D4R7GM0kR/s1600/Magnifying-Money.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="150" data-original-width="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjEP-kGZsG3mOBwH64KXvxhsSVu9ksYFdSibKxmx4V2nmdMbrtM2kphlyI1e0GxR6_1fdnXCj2IFwcf-AQ8oYLePIcZDf0j3jZAeZbE8iCbjcVt9zkWYZl-DFM0NUok66ebB8D4R7GM0kR/s1600/Magnifying-Money.png" /></a></div>
It occurred to me, recently, that all of the articles I've tweeted from Flipboard while drinking my morning coffee fall into one of two categories.<br />
<br />
<b>A new product or service is unveiled.</b> This could be by a new company who is trying to make a name for itself, but just as often it's from an existing company that is trying to elevate itself to either stay ahead of the competition or take a threat head-on to avoid being pushed aside.<br />
<br />
<b>An existing product or service had a failure of some sort that was discovered and/or revealed.</b> Frequently, these are security breaches but can also be a failure in the sense that customer satisfaction was significantly impacted, the brand was damaged, etc.<br />
<br />
When a company fails to consider their purpose from the prospect of their customers then failures occur. For example, Equifax failed to secure their environment which allow them to be the victim of one of the largest (reported) security breaches in history. However, on a bigger scale, they seemed to forget that customers (every citizen in the United States) rely on them to provide a credit score so that they can purchase things like houses, cars, etc. In order to do that, <a href="https://en.wikipedia.org/wiki/Personally_identifiable_information">Personally Identifiable Information</a> (PII) is required, which requires that the PII is properly secured to prevent misuse by thieves.<br />
<br />
The point that I'm trying to make with this long introduction is that organizations are the most effective when they realize that they exist to solve problems and then audit every decision through the magnifying glass of "will this help us solve the problem?" Doing so will also solve the desire for revenue because problem solving is the proverbial "better mousetrap" that will have the world beating a path to your door.<br />
<br />
My question is this: what's the problem that is being solved with Agile development and, more generally, DevOps? To answer that, let's examine how companies generate bottom line revenue. Limiting this to operational cash flow, this happens through the following three activities:<br />
<br />
<b>Increase top line revenue.</b> This occurs when greater numbers of one's product or service are sold; new products or services are developed and sold; or some combination of the two.<br />
<br />
<b>Reduce expenses.</b> Top line revenue generation has a cost associated with it, whether it's the cost of salaries of your sales team; the cost of new product development; the cost of infrastructure required to run the business; etc.<br />
<br />
<b>Mitigate risk.</b> The impact of this is a bit harder to quantify because most companies don't keep metrics on the impact of a production outage, for example. Anything that impacts the ability of the company to deliver the products or services is a risk to the company because not only is there an opportunity cost associated with it, there are also impacts to the Net Promoter Score and ultimately the brand. These affect future sales, which then affect top line revenue as described above.<br />
<br />
Looking at each of these from a DevOps perspective but starting with the problem statement, we get the following:<br />
<br />
<b>Problem: </b>we aren't releasing new features quickly enough. These either increase the desirability of our product, resulting in increase sales or allow our sales reps to more effectively do their job so that they can sell more in the same amount of time. This is an <i>increase top line revenue</i> play.<br />
<br />
<b>Problem: </b>in order to release new features more quickly, we increased the amount of infrastructure and people used in the process of developing and deploying those features at the cadence that we want. This is a <i>reduce expenses</i> play.<br />
<br />
<b>Problem: </b>we've added more infrastructure and people, which has allowed us to increase the release frequency, but due to the lack of full automation of our processes our <a href="https://en.wikipedia.org/wiki/Defects_per_million_opportunities">Defects Per Million Opportunities</a> have substantially increased too. As a result, we have more errors that occur due to failed change and release process executions, which costs us both revenue and erodes our customer base. This is a <i>mitigate risk</i> play.<br />
<br />
Keeping these problems up front instead of allowing them to get lost as solutions start to be discussed will allow you to select the best solutions for each type of problem. One of the biggest areas where I've seen this is with respect to automation, which is a key component of any DevOps strategy. During a discussion I had recently, someone commented that no company has an "automation center of excellence" to which I replied that "automation" by itself is a concept and not a specific discipline <i>per se</i> around which you can establish a center of excellence. So why, then, do companies think that any automation will work when a specific type of automation is needed?<br />
<br />
For example, many companies are flocking to point solutions (e.g. Jenkins, Chef, Ansible, etc.) to solve their need for Continuous Delivery. They are quick to ignore the fact that these point solutions solve one specific and narrowly-focused part of the CICD problem, but instead of trying to expand the scope of their search they try to force the solution to do more than what it is intended to do.<br />
<br />
Am I suggesting that these point solutions have no place in CICD? Hardly. But the correct solution for the problem needs to be chosen for the solution to actually have its intended effect. Otherwise, you may eventually solve one problem (e.g. increase top line revenue) while creating another (e.g. increasing the cost associated with doing so due to the higher TCO of the selected solution).Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-33331248817589631852017-08-07T11:03:00.000-04:002017-08-13T09:54:45.322-04:00What's in a Name?Over the years, I've written on the topic of application release on several occasions (<a href="http://larrysalomon.blogspot.com/2015/03/is-docker-end-of-traditional.html">here</a> and <a href="http://larrysalomon.blogspot.com/2015/11/provisioning-for-purpose-part-2.html">here</a>, for example). The topic itself is generally straightforward in that automating your application release process provides several benefits:<br />
<ul>
<li><b>Increased reliability</b> insofar that the deployment process is being managed by software, meaning that "friendly fire incidents" are less likely to occur</li>
<li><b>Increased release velocity</b> as the time to deploy the application in a single environment is reduced, sometimes substantially</li>
<li><b>Increased release cadence</b> as more frequent releases are now possible given the previous two points</li>
</ul>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgl5v_ftJ_4ub_gv8ofO3pJ1o0E4aEOBFWmLIUP75uZwCr75RTeNJFd1gun1QK8YGbNn8FcVZZefWl_GU5CCw_DvOFNoFD2hhWIcXdo3JLVlCtZcOV0Kk0vRW4Yrjfu_pxhIa6Xxf8faveg/s1600/hello-1502386_1280.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="872" data-original-width="1280" height="136" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgl5v_ftJ_4ub_gv8ofO3pJ1o0E4aEOBFWmLIUP75uZwCr75RTeNJFd1gun1QK8YGbNn8FcVZZefWl_GU5CCw_DvOFNoFD2hhWIcXdo3JLVlCtZcOV0Kk0vRW4Yrjfu_pxhIa6Xxf8faveg/s200/hello-1502386_1280.png" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Is ARA always about applications?</td></tr>
</tbody></table>
Not only this, but automating your CICD pipeline is a key enabler for DevOps, as it is one of the five tenets of that school of thought. (The others, if you aren't aware, are cultural change; efficient processes that are void of wasteful, time and resource consuming steps; measurement of the effectiveness of your processes; and sharing the information in a feedback loop for continual service improvement.)<br />
<br />
Lately, I've seen a few examples of alternate ways to apply the concept of <b>application release automation</b> (ARA) to effect process improvements:<br />
<br />
<b>Database DevOps.</b> This is a term I'm using to describe software solutions that automate the development and release of database objects. Companies like <a href="http://www.datical.com/">Datical</a> and <a href="http://www.dbmaestro.com/">DBMaestro</a> recognize that, although databases are an essential component of any traditional 3-tier application, they are also able to stand alone in their own right due to the complex nature of the DBMS ecosystem.<br />
<br />
<b>Back-office Release Automation.</b> ERP and CRM solutions frequently offer the ability for organizations to customize the functionality of those systems to meet the unique requirements of that organization. Well-known solutions such as SAP and Siebel are immediate examples of such back office solutions where custom module development has a process analogous to traditional software development.<br />
<br />
But the most interesting area (to me, at least) where this is being applied is in non-traditional application release. By this I mean applications that aren't comprised of binary executables or even scripts. Instead, these are objects of other solutions like <b>Informatica </b>where they are developed and tested like any application and also have a life-cycle of environments that they traverse during their journey to a production deployment.<br />
<br />
I realize that one could make the argument that these are just an extension of Database DevOps or Back-office Release Automation. However, there are only elements of those other two categories while the majority of this use case is unique.<br />
<br />
Consider the Informatica example. Informatica has its own workflow objects that access databases and can execute shell scripts as part of their "execution." All of these components are artifacts in the Informatica application, even though that term is a misnomer since Informatica is the application and not the workflow objects that it executes to perform standard ETL types of activities.<br />
<br />
Yet, ARA can have a positive impact here because:<br />
<ul>
<li><b>The general release process is the same.</b> You copy artifacts to the target machines; deploy them by importing the Informatica objects into the repository; and you effect changes to the database that the Informatica workflows access.</li>
<li><b>The non-automated process has the same challenges.</b> Manual deployments have several potential points of failure; manual approvals via email slow down the release velocity; and releases are often managed by spreadsheet or some other manually maintained ledger.</li>
</ul>
The point that I'm trying to make is that ARA doesn't have to be about applications that you write in some standard programming language like Java or C#. Instead, this should be viewed through the lens of the challenges faced by an organization and the net benefits that can be realized using an automation solution such as <a href="https://automic.com/application-release-automation">CA-Automic's ARA</a>.<br />
<br />Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-87527822821378165132017-06-14T10:22:00.000-04:002017-06-15T21:55:44.433-04:00Only the Finished Product MattersFor many years, people have lamented the ever increasing use of automation in the workplace. In the 80's it was on the assembly line, and people complained that the impact on the blue collar labor force would have a detrimental and even a material impact on the economy. Since the late 90's, this discussion has shifted to the white collar labor force, especially as it relates to IT Automation, and the resulting amount of noise has increased exponentially in the last 10 years.<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWYpQQFLIP-oYt7yUVEjrxmqWIHhESgB-mkKkiFGSjOu1jR8lUBahr_H2meaE82mfcJ_vT_6ictqzLdrJq5LXqRC6Gj5cUUzwu-IRyH_Dwv5Duy7DQRI9hDqXcMWWitfp0xYZDLG98H5m-/s1600/robot.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="540" data-original-width="540" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWYpQQFLIP-oYt7yUVEjrxmqWIHhESgB-mkKkiFGSjOu1jR8lUBahr_H2meaE82mfcJ_vT_6ictqzLdrJq5LXqRC6Gj5cUUzwu-IRyH_Dwv5Duy7DQRI9hDqXcMWWitfp0xYZDLG98H5m-/s200/robot.png" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">"The robots are coming!"</td></tr>
</tbody></table>
What, specifically, is the complaint? "Replacing people with robots" (as we've often heard it characterized) eliminates the need for the people in the first place. They lose their jobs, which is bad for both moral and economic reasons. Often, FUD (Fear, Uncertainty and Doubt) is incorporated into the message along with "#skynet" as people say that we will only be one step away from computers taking over the world and eliminating humankind a la Terminator.<br />
<br />
Ok, maybe it's not quite as bad as the last statement, but I have seen inklings of that in the various comments whenever this topic is discussed.<br />
<br />
From a purely business perspective, however, it's a much easier discussion since business is driven by money. Ignoring the "money is the root of all evil" commentary, business simply want to bring in more money than they are spending, and they want the distance between those two numbers to increase over time.<br />
<br />
As I've written before in <b>The Executive Relationship (</b><a href="http://larrysalomon.blogspot.com/2012/03/executive-relationship-part-1-of-3.html">parts 1</a>, <a href="http://larrysalomon.blogspot.com/2012/03/executive-relationship-part-2-of-3.html">part 2</a> and <a href="http://larrysalomon.blogspot.com/2012/04/executive-relationship-part-3-of-3.html">part 3</a>), one of the ways companies achieve this is to streamline existing processes (also a core tenant in <b>Lean </b>and <b>DevOps</b>) by removing unnecessary waste built into these processes over the years. But when you consider this from the perspective of <a href="https://en.wikipedia.org/wiki/Value_stream_mapping">Value Stream Mapping</a> (also a part of <b>Lean </b>and <b>DevOps</b>), one of the ways to streamline an existing process is not to eliminate useless activities but also to simply speed up steps to be executed to complete the process as a whole. This is where IT Automation comes into play.<br />
<br />
My personal definition of <b>IT Automation</b> (a.k.a. IT Process Automation, ITPA, Runbook Automation) is the following:<br />
<br />
<i>IT Automation is the process of executing tasks with minimal human intervention to achieve a well defined result.</i><br />
<br />
The advantages of incorporating IT Automation are numerous:<br />
<ul>
<li>It executes much more quickly even when done sequentially</li>
<li>It can execute tasks in parallel</li>
<li>It provides consistent and repeatable results</li>
<li>It won’t mistype a command line parameter causing problems</li>
<li>Because run books defined in an automation system are self-documenting, the need for people with specialized knowledge is significantly reduced or eliminated</li>
</ul>
<br />
<div>
<b>But I would argue that even these items are not what matters most.</b> What matters most is the end result, because that is what your customers want. If I go into a fast food place and order a "number 3, medium, with a diet soda" I don't care if people or robots fulfill my order. All I care about is getting the food I requested so that I can satisfy the need that resulted in the order (i.e. hunger). And if I feel like I cannot get what I want from this location in a timely manner with a level of quality that I expect then I'll go to another location that can meet those requirements.</div>
<div>
<br /></div>
<div>
This concept extends across all industries, meaning that your end users don't care about how things get done - they just want results. Don't believe me? Consider for a moment the multiple corporate scandals that are happening at Uber that have recently resulted in <a href="https://techcrunch.com/2017/06/13/no-acting-ceo-at-uber-no-problem/">co-founder and CEO Travis Kalanick being ousted</a>...I mean taking an unspecific leave of absence. In case you are unaware, Uber has taken a lot of heat for having a poisonous work environment where sexism runs rampant, the drivers are underpaid or are cheated of their ability to participate in higher rates changed by the company, etc.</div>
<div>
<br /></div>
<div>
Yet Uber still has a market capitalization of <b>USD$69B</b>. That's <b>B</b> as in <b>Billion</b>. For a company that owns no vehicles of its own, that number is mind boggling. Is it justified? That's a discussion for another blog entry. But this much is clear: the company itself is doing quite well when you measure success from the perspective of how many people are using Uber to get from point A to point B.</div>
<div>
<br /></div>
<div>
In other words, riders don't care about the significant challenges the company has at the moment. They simply need to get to their son's baseball game, their daughter's dance recital, their customer meeting. They only care about results and whether the company can deliver the results in a way that meets their expectations.</div>
<div>
<br /></div>
<div>
As long as this is what is ultimately driving our economy (Results as a Service), companies are going to do whatever is necessary to improve their ability to deliver the results including incorporating IT Automation to whatever degree is needed. And if your company hasn't adopted this "do whatever is necessary" attitude by looking at IT Automation as a means for increasing the quality of the goods and services it delivers then it needs to wake up and smell the roses quickly before getting left behind by its peers.</div>
<br />Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-50025839075675838152017-05-12T11:21:00.000-04:002017-05-15T16:54:06.386-04:00Where Were You When...Where were you when<br />
<br />
...Hank Aaron hit his 715th home run?<br />
<br />
...Steve Jobs introduced the first iPhone?<br />
<br />
...Felix Baumgartner jumped from 39km in space and parachuted to Earth while televising it?<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEii4Oc8DH6DsLIJu0S2zCFBcdKkkqmQX2mJKQP-Swp0Z8Esq27Zrylzfk3djdMUHiImqnu7K8CeXOOpzW351pQsQQ6uMn9buMLTYOco5Iv2pjxM4Y4WWq9DDdAD09dNdMme1x0nrZZiHabt/s1600/soda-cans.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="132" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEii4Oc8DH6DsLIJu0S2zCFBcdKkkqmQX2mJKQP-Swp0Z8Esq27Zrylzfk3djdMUHiImqnu7K8CeXOOpzW351pQsQQ6uMn9buMLTYOco5Iv2pjxM4Y4WWq9DDdAD09dNdMme1x0nrZZiHabt/s200/soda-cans.jpg" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Mmm...soda!</td></tr>
</tbody></table>
My wife and I have had this long-standing debate about whether drinks with Aspartame should be consumed. She says no, but I say yes because I don't want the added sugar since I'm overweight as it is. (Nevermind the options of not consuming the drink in the first place because then I'd drink beer instead and that's no better for my waistline.) So once while consuming one of my favorite beverages - San Pellegrino Limonata - I read the list of ingredients to see which type of sweetener was present. It was sugar. I lost.<br />
<br />
"Remember when there was this huge backlash about High Fructose Corn Syrup?" I asked her, in hopes of avoiding discussing the fact that I was drinking something with sugar in it. At that point, we both acknowledged that during that backlash companies reacted in one of two ways:<br />
<ol>
<li>They fought back and tried to convince the general public that High Fructose Corn Syrup was just like sugar, didn't result in elevated risk for obesity, diabetes, etc. We all saw the advertising campaign from the corn growers that highlighted this.</li>
<br />
<li>They modified their recipes to use cane sugar, Agave nectar, or something else.</li>
</ol>
When talking to executives at my customers, I've often rallied behind the statement by Gartner in 2014 that companies either think like a technology company or lose their "first mover advantage." (I like to paraphrase that as "constantly innovate or rapidly become irrelevant.") For companies looking to avoid being this equivalent of the Titanic DevOps seems like a viable pivot, and yet this has become the veritable albatross around the neck of many CxOs who want to adopt DevOps but completely fail to do so. <br />
<br />
What gives? One of the tenets of DevOps is the <b>CALMS </b>initialism.<br />
<br />
<b>C</b>ulture<br />
<b>A</b>utomation<br />
<b>L</b>ean (process engineering, that is, not the avoidance of sugary beverages)<br />
<b>M</b>easurement<br />
<b>S</b>haring<br />
<br />
None of these items are things that happen overnight, especially cultural support for the evolution to a DevOps mindset. The biggest problem with the latter is the inability for organizations to overcome the way of thinking that encouraged IT silos, the "it's not my job" mentality, etc.<br />
<br />
Think High Fructose Corn Syrup.<br />
<br />
When the backlash against that happened, companies that were able to change the way they created their products enjoyed a huge (my guess, not backed up with empirical data of course) bump in top line revenue because this issue was "top of mind" for many consumers who were consumed with creating a more healthy lifestyle. For the companies that stuck with the old ingredient, they certainly didn't "rapidly become irrelevant," but I can assure you that even to this day I still check the ingredients list and avoid products with High Fructose Corn Syrup in it whenever possible.<br />
<br />
DevOps is a journey to be sure. But the journey will pay dividends for years to come, and so it is an investment that is worth every penny of sweat capital that you will invest.Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-21677272754047480332017-04-18T10:01:00.000-04:002017-04-18T10:01:37.075-04:00Use the Right Tool for the Job<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiXUrzHdZUb4qzXCFHhchvdGBzAev-8OSbBdmyQBXy9OOxeNzcfcGrabdjlJAXrSEF1Hokg7snksMmzW3ZMo_oxp4POfgqsLssJny3u4Y9uxTUW7Oic1Y8ihrffekm0BADoqzPXFlq4PDN8/s1600/Spatter.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiXUrzHdZUb4qzXCFHhchvdGBzAev-8OSbBdmyQBXy9OOxeNzcfcGrabdjlJAXrSEF1Hokg7snksMmzW3ZMo_oxp4POfgqsLssJny3u4Y9uxTUW7Oic1Y8ihrffekm0BADoqzPXFlq4PDN8/s200/Spatter.jpg" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Image copyright (c) by James Aiken</td></tr>
</tbody></table>
My wife and I have a fun dynamic: she approaches situations with surgical precision, while I tend to be more of an imprecise paintbrush like you would imagine was used in the painting you see here. One day, she chastised me one day for cutting something with a butter knife and insisted that I should be using a paring knife instead. I argued that it wasn't needed.<br />
<br />
Who was right?<br />
<br />
As you can imagine, I was intentionally vague with the description of the situation above so that I could illustrate that an understanding of the context is required to answer it properly. In this particular situation, I already had the knife out from making my daughter a sandwich for her lunchbox and had switched to cutting strawberries. So, technically, she was correct, but I was also able to properly execute my task with the tool at hand, literally.<br />
<br />
This loosey-goosey approach to executing a process works in some situations, but in others it should be avoided at all costs. Would a MacGyver approach work with DevOps? Could you slap together a bunch of unrelated tools in such a way that the proverbial "bubblegum + aluminum foil" result allows you to have an enterprise class CICD solution? The answer is "probably not." Yet I have found numerous organizations that attempt to shoehorn single purpose solutions like Jenkins or Chef into the role of CICD orchestrator, only to wonder what went wrong when the level of effort ends up being immense and/or yields something that either doesn't meet their expectations or isn't able to grow with them as an organization.<br />
<br />
As with the example about cutting strawberries, context is needed here. Many commonly used DevOps solutions are single-minded in their purpose: Jenkins was built to be a continuous integration tool; Chef was built to be a provisioning / configuration management tool; etc. And just like you wouldn't use bubblegum and aluminum foil to build a jet engine, you shouldn't use solutions to do things they weren't intended to do. This includes situations where the company that produces such a solution releases a subsequent bolt-on in hopes of expanding the scope of use to include use cases that should not be considered in the first place. (I'm looking at you, Chef.)<br /><br />With continuous delivery, specifically, you need to realize that any orchestration solution needs to be able to address the following six verbs:<br />
<br />
<b>Who </b>should have access to various applications and processes that are part of an organizational portfolio? Roll-based access control should allow you to limit who has access to what so that developers on one team can't modify applications being built by other teams, or deploy an application into operational environments to which they don't normally have access.<br />
<br />
<b>What </b>artifacts should be included as part of the application deployment process? Are all artifact types supported by the solution?<br />
<br />
<b>Where </b>is the application to be deployed? Does the solution allow you to deploy across multiple environments while automatically adapting the workflow to account for environment-specific configuration differences?<br />
<br />
<b>When </b>do deployments occur? Can it be on-demand? Scheduled via a release calendar? Queued up so that a different function can decide when the queue should be processed?<br />
<br />
<b>Why </b>are you using an enterprise class orchestration solution? Are you still doing enterprise releases twice a year or are you looking to increase the frequency of deployments to be once a week or more frequently than that? And...<br />
<br />
<b>How </b>does an application get deployed? How is the process defined? How are integrations with surrounding parts of the ecosystem (e.g. ITSM solutions, etc.) accomplished?<br />
<br />
Applying this litmus test to the commonly used solutions like Jenkins, Bamboo, etc. will show you that these solutions often excel in one or possibly two of these areas, but rarely will you find something that addresses all six in a way that allows your organization to benefit without adding risk to the operational side of the business.<br />
<br />
The onus is on you to understand the <i>raison d'être </i>of your toolset so that you can also understand why changes may be needed. If you are looking to expand your capabilities so that you can deliver business functionality to your end users in an expedited fashion while also putting structure around the process so that there is no risk added as a result of the increase in velocity, then you need to stick <a href="https://offers.automic.com/preview-the-possible">to evaluating orchestration solutions that were built for this purpose from the beginning</a>. This will give you the confidence to move forward with the implementation of your CICD strategy.Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-27179225479677372312017-03-14T11:08:00.002-04:002017-03-14T11:14:01.917-04:00Application Development Done RightIn a previous article, entitled <a href="http://larrysalomon.blogspot.com/2017/01/devops-as-ultimate-panacea.html">DevOps as the Ultimate Panacea?</a>, I described how developing code without thinking about the current needs of the end user as well as the future needs once they've become accustomed to using your application ends up not only frustrating them but also can result in customer churn and ultimately lower revenues. In this article, I'd like to describe something simple that I came across today that shows a definite degree of effort to do quite the opposite.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrmQ1xRXvlDhigFE3-92O0Sfxpq3n5IbTVuFo9iCPusPBa8Mdr98KcTIbiH3RVFwHWwjeXEM4W8L5tiHlIGmgaQGAyLva0JclEbTFLpXa4wATMZ9wGIOJusvkbmV1U_j6xIqcoJAf1-lLr/s1600/food.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrmQ1xRXvlDhigFE3-92O0Sfxpq3n5IbTVuFo9iCPusPBa8Mdr98KcTIbiH3RVFwHWwjeXEM4W8L5tiHlIGmgaQGAyLva0JclEbTFLpXa4wATMZ9wGIOJusvkbmV1U_j6xIqcoJAf1-lLr/s200/food.png" width="200" /></a></div>
Recently, we had a severe snowstorm, one with blizzard-like conditions, which is unheard of in central New Jersey. Being responsible adults, my wife and I went to the grocery store to stock up on essentials (read: chips, chocolate, etc.) in case we get stuck at home.<br />
<br />
As we were ringing up our order, the cashier mentioned to us that the store has a mobile application. Since both of us are in technology oriented professions, we were skeptical about the need for a grocery store mobile application. But then the cashier told us two things that immediately caught our ear:<br />
<br />
<ol>
<li>The application will allow us to search for a specific item and, if the location where we shop carries the item, it will also tell us in what aisle and where in that aisle the item will be located.</li>
<br />
<li>We can associate digital coupons with the application so that we don't have to worry about collecting those strips of paper that spew out whenever we scan our loyalty card at other grocery chains, much less keep them organized, etc. All we need to do is scan a single QR code at the register; the appropriate coupons are consumed and the savings automatically applied to our bill.</li>
</ol>
<br />
These two features are enough for us to justify the 25 minute drive to this particular chain, which is something we've only done once every two months at best in the past. This is in spite of the fact that there are two major chains (without digital capabilities like the two items mentioned above) currently within 5 minutes of our house currently.<br />
<br />
Although it's possible for these capabilities to have simply "sprung from the head of Zeus," it's more likely that the software development methodology facilitated this wonderful end result. Implementing methodologies such as <a href="https://en.wikipedia.org/wiki/Test-driven_development">Test Driven Development</a> and <a href="https://en.wikipedia.org/wiki/Behavior-driven_development">Behavior Driven Development</a> provide a constant feedback loop to give the developers a chance to see user behaviors in near real time in order to make changes as needed.<br />
<br />
Of course, this feedback loop is useless without a mechanism to deploy new builds of applications fast enough to keep up with the rate of change in the development of the applications in question. This is where release automation comes into play. A fully implemented, <a href="https://automic.com/products/application-release-automation">fully automated CICD process</a> is essential for ensuring that companies can develop at the "speed of change" so that <a href="http://larrysalomon.blogspot.com/2017/03/its-easier-to-fail-at-devops-than-it-is.html">they aren't overtaken by their competition</a>.<br />
<br />
<hr />
<br />
While our grocery bill won't do much to add to the bottom line of this particular grocery chain, if you multiply the effect it's had on us by the number of people like us who are hearing about this for the first time, you can see how this could have an impact over time. And this is possible only because someone took the time to consider the shopping experience; how it could be improved in a very real way for their customers; and then provided the necessary structure internally to give the development teams the ability to fully realize their vision.Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-74538065660950521752017-03-06T13:27:00.000-05:002017-03-06T13:33:43.349-05:00It's Easier to Fail at DevOps than it is to Succeed<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiEmNW5CXaf_LFXVqg0aWUcCl6YC2_z-rlaoYTvN151Ye_YI0Q94RSn0Js20W9d1Qc4JC2yUehH-l0f0zlFasBldXr_S-JjYtNLh5EOlrwXZfQdePp2P7UvoeB5bVrbZTF80CiA4N_W0iw0/s1600/Under-Construction.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiEmNW5CXaf_LFXVqg0aWUcCl6YC2_z-rlaoYTvN151Ye_YI0Q94RSn0Js20W9d1Qc4JC2yUehH-l0f0zlFasBldXr_S-JjYtNLh5EOlrwXZfQdePp2P7UvoeB5bVrbZTF80CiA4N_W0iw0/s200/Under-Construction.png" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Slippery when wet</td></tr>
</tbody></table>
Since the term DevOps was coined in Belgium back in 2009, it is impossible to avoid the term whether in discussions with colleagues or in professional trade magazines. And during the years while this movement has gained momentum, <a href="https://www.google.com/search?q=components+of+any+successful+devops+strategy">many things have been written</a> to describe what elements of a DevOps strategy are required for it to be successful. <br />
<br />
Yet in spite of this, there is an interesting data point worth noting: not many organizations feel there is a need for DevOps. In a Gartner report entitled <b>DevOps Adoption Survey Results</b> (published in September 2015), <b>40%</b> of respondents said they had no plans to implement DevOps and <b>31%</b> of respondents said they hadn't implemented it but planned to start in the 12 months after the survey was conducted. <br />
<br />
That left only <b>29%</b> who had implemented DevOps in a pilot project or in production systems, which isn't a lot.<br />
<br />
"Maybe it's because there truly isn't a need for DevOps," you say. While that may have been true if DevOps were around in the beginning of last decade, the consumerization of IT and other types of "instant gratification" technology advances would dictate otherwise. In fact, in a 2014 presentation entitled <b>CEO Resolutions for 2014 — Time to Act on Digital Business</b>, Gartner analyst Mark Raskino told a group of CxOs in various industries that (paraphrased) they need to either constantly innovate, or they will rapidly become irrelevant. All it takes is one stumble to be overtaken by their competitors who recognize the need to think like a technology company whether or not they are one.<br />
<br />
Let's drill down a bit. Even though DevOps means far more than application release processes, Agile development methodologies have changed the landscape of software development such that the promote and release functions are now often the bottleneck. It is here that automation can have the biggest impact, yet many organizations haven't addressed this to its fullest extent. In a report by IDG Research entitled <b>Market Pulse Research: The State of DevOps</b> (published in August 2013), <b>36%</b> of respondents said that their release processes were completely manual and <b>53%</b> said they were only partially automated. The kicker is that they all recognized that automated application release is a key enabler to the successful implementation of a DevOps strategy.<br />
<br />
What is the real problem here? It would seem that many organizations are looking for ways to successful achieve the nirvana of DevOps when they should instead focus on how to avoid failure. They are charging forward without protecting the flanks, and as a result they are getting hamstrung.<br />
<br />
What are some of the reasons why DevOps can fail to take hold? While there is hardly the same quantity on the pitfalls to avoid as there is on what it takes to be successful, <a href="https://www.cognizant.com/whitepapers/patterns-for-success-lessons-learned-when-adopting-enterprise-devops-codex2393.pdf">Cognizant published a great whitepaper</a> containing six key things to watch out for when embarking on your DevOps journey. These items are on pages 2 and 3, and are a "must read" even if you're already immersed in implementing DevOps at your organization. Another great <a href="http://www.computerweekly.com/feature/Overcoming-the-business-and-technology-barriers-to-DevOps-adoption">article published in Computer Weekly</a> discusses the business and technology challenges when implementing DevOps. From the article, "for enterprises entrenched in the old way of software development, <a href="http://searchcloudapplications.techtarget.com/feature/Experts-say-DevOps-and-cloud-made-for-each-other">adopting a DevOps style</a> of working isn't going to be easy for CIOs without buy-in from the whole IT department."<br />
<br />
I could not agree more. Focusing on the goal is fine, but for something that requires such a huge shift in the way multiple departments work it needs to be recognized that there are many more ways to fail than there are to succeed.Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-30323425399013906702017-01-13T15:06:00.001-05:002017-01-13T15:06:51.859-05:00DevOps as the Ultimate Panacea?<i>Truth without love is cruel, and love without truth is foolish. - Sam Leung</i><br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj3atJ2WCsr9Og5JVneUhVHPUcxz8D_9fSR1oaCr5OH1bgroPInMKDE9A3EcIvpBDZZzVoCxXp5WvPQKMpDCgELCp2x2kDlTQLboxV1V-r3sC7xpfbUmJAHaD22jvKD-I5I91j_p5Pk4u7Q/s1600/devops-panacea.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj3atJ2WCsr9Og5JVneUhVHPUcxz8D_9fSR1oaCr5OH1bgroPInMKDE9A3EcIvpBDZZzVoCxXp5WvPQKMpDCgELCp2x2kDlTQLboxV1V-r3sC7xpfbUmJAHaD22jvKD-I5I91j_p5Pk4u7Q/s200/devops-panacea.png" width="200" /></a>Those of you who follow me on Twitter (@foolomon) know that I tweet industry news relating to DevOps and other topics (such as Information Security, IoT, etc.). Based on the sheer number of articles that I come across but do <i>not</i> tweet about, you would be justified in believing that DevOps is still the darling child when it comes to marrying application-based functionality with the business value it should be aligned with.<br />
<br />
"What if I told you," Morpheus might ask, "that DevOps is not the panacea you think it is?"<br />
<br />
"What, what?" you exclaim. "I thought DevOps is the be-all, end-all of application development! 'Continuous delivery' is the way to go, man!" Bear with me while I explain myself.<br />
<br />
Recently, I read an <a href="http://www.forbes.com/sites/georgebradt/2017/01/02/how-to-become-the-must-hire-candidate-in-a-job-interview/#4774648d3bb3" target="_blank">article in Forbes</a> that said something quite profound: "people don’t want to buy a quarter-inch drill bit; they want a quarter-inch hole." DevOps is the drill bit in this analogy; it is the means by which the hole is created, which is represented by the application being deployed to production. The point that I'm trying to make is that, like ITIL was in the 90's, people are putting too much emphasis on DevOps while forgetting that the ultimate goal is to develop an application that does what the users want.<br />
<br />
In other words, don't forget to do your homework before writing a single line of code for the upcoming sprint. Otherwise, you'll end up with an application that does everything imaginable except inspiring your users to actually use the application. <br />
<br />
As an example, consider my favorite navigation application, Waze. Realize that I use this exclusively for my GPS needs while driving in spite of the fact that I have Google Maps, and the base iOS map application on my phone. However, there are a few things about this application that annoy me to no end, most notably the fact that it will send me through every side street imaginable if that results in an arrival that is 15 seconds faster than it would have been if I stayed on major streets and/or highways.<br />
<br />
What they failed to imagine is that each time a driver has to make a turn, the drive becomes a bit more irritating especially when you're already on a perfectly good road heading in the same general direction. Multiple this by 10 turns during a 20 minute drive and you can understand the frustration that people can feel using the application during their drives. Worse, excessive turns makes it much more difficult to remember the route they took, meaning that they have a perpetual dependency on using the application whenever they drive.<br />
<br />
When you frustrate your users they start looking for alternatives. For me, that alternative is spending time on Google Maps to familiarize myself with routes to common destinations so that I no longer need to use Waze. For others, it may be to use a different application entirely in spite of the fact that they may arrive a few minutes later than they would have using Waze. Etc.<br />
<br />
"So what?" you ask. "You're talking about a free application for my phone." True, but consider the business analog: applications are meant to provide a standardized way of accomplishing a specific task. The moment someone feels the need to deviate from that by not using your application you increase the risk of a lower quality or potentially incorrect result. This can adversely impact your organization's productivity as corrective measures must be taken on a case-by-case basis as well as affect the bottom line because of lost revenue, higher operational costs, etc.<br />
<br />
In short, DevOps is a tactical play in that it guides the execution of an application development strategy. What it will not do is determine what those applications should be doing, and it is this activity that is the raison d'être for application development in the first place. Do your homework to make sure you are solving the problem and not simply providing a solution, and you will enjoy success as those applications have a positive impact on your organization's productivity and financial well-being.Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-36465138122126580612016-10-17T12:29:00.000-04:002016-10-17T12:29:37.509-04:00#FailOpsMany years ago, <a href="https://uk.linkedin.com/in/vishnepolsky" target="_blank">Oleg Vishnepolsky</a> and I worked together at IBM's T. J. Watson
Research Center on the OS/2 1.1 port of the TCP/IP protocol stack. Recently, I had a conversation with Oleg, who is currently the CTO at The Daily Mail Online, about DevOps and how it seems companies miss the whole point of what DevOps promotes. <br />
<br />
During our conversation (via email), it came out that he was of the opinion that DevOps is not a successful paradigm to follow and asked me for my thoughts on the matter. I decided (with his permission) to publish the conversation because it seems that a lot of people are of a similar mind when it comes to DevOps (just as there were similar attitudes when the OGC released ITIL in the late 1980's), and while I do agree that many companies are not seeing the benefits of DevOps that it is supposed to bring to an organization, I don't believe that the problem is with the paradigm. Hopefully, my answers to Oleg will not only clarify why DevOps is important but will also underscore why care must be taken to ensure that it is embraced correctly in order to fully realize the potential benefits that it can bring to your organization.<br />
<br />
<hr />
<br />
<i>Oleg, <br /><br />Here's my take on your blog entry, which I just read: DevOps is truly nothing new, like ITIL was nothing new either. Both were simply a formal means of describing things that were occurring for many years already upon their release. What ITIL and, to a lesser extent, DevOps does is describe the best practices that are needed to increase the chances of success. You note this "best practices" connection in your article, but I don't think you fully appreciate the value in doing so. <br /><br />The biggest "problem" here (and I use that term loosely) is that you seem to have little experience working with organizations where the "software development pipeline" is so poorly implemented that it causes more problems than the extra value that Agile is supposed to bring to the organization. (I jokingly call this "frAgile".) I have, however, run into these types of organizations on a high enough frequency that it is scary. <br /><br />One thing that is clear about DevOps, which was similar in the days when ITIL was initially released in 1988 by the OGC: it is not meant to be a "you must do it this way" process. Instead it is meant to describe ways that application development and operations can work together. The biggest benefit of this is by highlighting what many people like you and me with the appropriate level of experience already know: development is all about writing code while rarely giving the appropriate amount of consideration to quality, while operations is all about ensuring stability in the production environments, meaning they aren't too happy about software releases because that means constant change, which is counter to the concept of ensuring stability. <br /><br />This is a critical point because although application development organizations are frequently measured by the number of defects, true, getting applications out the door on time trumps everything including software quality. I can recall one such time during my days in application development when development was halted for an entire month so that we (a team of 40+ developers) could all do testing (like a staff aug for the QA group). That sounds great until you realize that we only tested for and fixed severity 1 and 2 defects and ignored severity 3 and 4, which dwarfed the former categories of defects in terms of quantity by an order of magnitude. <br /><br />So DevOps screams at developers that operations wants stability so they need to make quality a priority. At the same time, it screams at operations that developers are trying to release things quickly to get new business functionality in the hands of the end users. That last point cannot be understated. In March 2014, Gartner told a group of CIOs the following: "CEOs must focus on leading their organizations to think like and become more like ‘tech’ companies, because within a few years, digital business capabilities will dominate every industry. Urgent action is needed because first-mover advantage is common in digital business, and fast followers must be very fast." <br /><br />To put that more succinctly, "<b>constantly innovate or rapidly become irrelevant</b>." <br /><br />So DevOps is not only a buzzword but it is, in a very real sense, a "must have" since without this coordation between the two organizations, a company will lack the velocity to do exactly what Mark Raskino at Gartner said in that quote, above. Consider this for a few moments: in May 2011, Amazon was noted as releasing something to production every 12 seconds. One of my customers, Bet365, releases to production every 4 minutes. And when I was at a previous employer, one of our large financial services customers in EMEA had 60,000 production releases every month. This need to scale to massive throughput from development to production is here now, and so the coordination proscribed by the DevOps movement is needed now as well. </i><br />
<i><br />I hope this helps. <br /><br />Kind regards, <br />Larry</i><br />
<br />
<hr />
<br />
<i>Thank you. What i see happening though in the industry is that devops is taken as a mandate to let developers loose on production environment.</i><br />
<i><br /></i>
<i>Oleg</i><br />
<br />
<hr />
<br />
<i>Oleg,</i><br />
<i><br /></i>
<i>Well, that's kinda what I meant by "poorly implemented." That's similar to when people thought (and, unfortunately, frequently still think) that Agile means "release more quickly." In the latter, the part they miss is "release more quickly <b>without incurring more operational risk</b>." (To wit, the official mantra of Agile is to "fail fast" but that ultimately has the goal of allowing an organization to release more quickly with less risk because bugs are identified earlier in the SDLC and fixed there when the amount of effort to remediate is significantly less.) </i><br />
<br />
<i>Organizations that take the word "DevOps" and use that as a shield to justify poor decisions related to operational impact are headed for failure. But that's not the fault of the DevOps movement and is instead the fault of the leadership at the company that allows this to happen.</i><br />
<i><br /></i>
<i>Kind regards,</i><br />
<i>Larry</i><br />
<br />
<hr />
<br />
Your comments on this subject are highly encouraged because it's important to have thoughtful discussions about this and how you and your company can reap the greatest benefit from having fully <i>and correctly</i> embraced the DevOps mindset.Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-82162789998131345532016-09-08T09:43:00.002-04:002016-09-08T09:43:33.865-04:00Agility Has Its LimitsAutomation and orchestration have given us free two-day shipping via Amazon Prime; next day shipping via the major postal companies; delivery via Uber or drone; and so on. These are all concepts that we are either intimately familiar with as consumers of these services or at least are cognizant of them because of news reports, TV commercials or YouTube videos.<br />
<br />
<b>Convenience and Digital Transformation</b><br />
<br />
The value of convenience cannot be overstated. However, there will always be times when these methods of delivery will not be enough. For example, a freak snow blizzard in my area wasn't a big deal for me since I have snow removal equipment. But as I drove past kids sledding in the field at the end of the street I wanted to buy a sled for my children also. Next day shipping wouldn't have satisfied my need to have this <i>now</i>. Of course, Uber or drones could have delivered such an item theoretically. But unless you live in NYC or a similarly sized metropolitan area <i>and</i> the goods purchased were something that either service would deliver then you're still forced to get in your car and drive to the nearest Walmart.<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9nPP2ldKl_YiYUv32wlyRjbnHqMZWRZwY4WroK5qad3XjAiHWMKFX118vElc5RdJvyTy1-H0prKI26ezIHESXNEkhBGOPfwPA3PYcFD0RmR99hTeP5RGft9iRDdIzwloi1ZGdF9R3kfQ5/s1600/Coin-Stacks.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="158" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9nPP2ldKl_YiYUv32wlyRjbnHqMZWRZwY4WroK5qad3XjAiHWMKFX118vElc5RdJvyTy1-H0prKI26ezIHESXNEkhBGOPfwPA3PYcFD0RmR99hTeP5RGft9iRDdIzwloi1ZGdF9R3kfQ5/s200/Coin-Stacks.jpg" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Measuring your way to revenue</td></tr>
</tbody></table>
It is during times like these that we must keep in the proper perspective the benefit that agility from a technology perspective gives a company. For online shopping, the ability to deliver new functionality on an as-needed basis is critical to staying ahead of the competition. For example, Amazon has a production deployment once every 25 seconds on average. For the brick and mortar companies, however, the need for agility is somewhat different since the quality of the end user experience isn't dictated by how good the Point of Sale software looks. The focus in this situation is in the quality of the in store inventory, the cleanliness of the store, the helpfulness of the staff, etc.<br />
<br />
Regardless of what defines "a quality experience" for a business, it can be measured. And if it can be measured, then the measurements can be gathered and analyzed. And if the measurements can be gathered and analyzed, then there is a need for the gathering and analysis. This need exists whether you are a brick and mortar business, an online business, or a hybrid of the two. The results can be stunning.<br />
<ul>
<li>Take <b>Netflix</b>, for example. Netflix does real time analysis of their customers' viewing habits to suggest new movies they may want to watch. <a href="https://github.com/Netflix/genie/wiki/FAQ" target="_blank">This starts with an ETL process</a> that gathers the data and normalizes it into a format that is more easily digestible by the balance of the algorithmic analysis engine that results in recommendations.</li>
<br />
<li>Or consider <b>LinkedIn</b>. LinkedIn does real time analysis of their users' network to suggest people that they may know based on degrees of separation. <a href="http://www.slideshare.net/automic/how-linkedin-uses-automic-for-big-data-processes" target="_blank">This starts with several ETL processes</a> that run on Hadoop, Teradata, and other data sources to enable this functionality to work.</li>
<br />
<li>Finally, look at <b>AMC Theatres</b>. AMC does real time analysis of ticket and concession sales to automate their social media feeds. This starts with an ETL process on Hadoop to gather, normalize, and process information to post updates to various social media sites with no user intervention.</li>
</ul>
<b>Digital Growth </b><br />
<br />
Anything that defines "a quality experience" for a business is quantifiable and should be measured. Why not? After all, this need exists whether you are a brick and mortar business, an online business, or a hybrid of the two like AMC. The process of measuring, gathering, analyzing and reporting unearths what is and is not working so success can be capitalized on in real time.<br /><br />As you can see from the examples above, the results can be stunning. But the quantity of data that these companies generate means none of this would be possible without data automation, which is geared specifically at real-time execution of jobs to gather and then process large amounts of data in real-time.<br />
<br />
<b>Orchestration Backbone</b><br />
<br />
There are a number of platforms to process large amounts of data (Hadoop, Hortonworks, and Cloudera, to name a few). However, the orchestration to coordinate the activities around gathering and reporting, is critical. Without it, you would be stuck with the task of building a custom set of solutions to do these two very important activities. It is this orchestration that distinguishes a large data processing platform like Hadoop from a data automation platform that enables you to effect a change in your company based on what the data contains.<br /><br />The other thing all the above examples have in common? They all chose <a href="http://www.automic.com/" target="_blank">Automic</a> to provide the orchestration capabilities to allow them to transform their businesses into something that responds in real time to the needs of their customers and users.<br /><br />As <b>Vijay Aruswamy</b>, Big Data Operations at LinkedIn, put it, “We're using Automic to automate data transformation on Hadoop, Teradata, User Input and External sources of information. It supports our data driven products like ‘People You May Know’ or ‘Jobs You May Be Interested In’.”<br /><br />Automation, when properly harnessed, means the difference between being able to continuously innovate and rapidly becoming irrelevant. And though large scale adoption of automation is not an endeavor to be undertaken on a whim, examples of data automation like those listed above show the outstanding benefits that come as a result of this investment that you make for your company’s future.Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-23021166578122295452016-03-09T10:27:00.001-05:002016-03-10T08:31:41.874-05:00Digital Darwinism<i>"In 2014, CEOs must focus on leading their organizations to think like and become more like ‘tech’ companies, because within a few years, digital business capabilities will dominate every industry. Urgent action is needed because first-mover advantage is common in digital business, and fast followers must be very fast."</i>- Gartner, "CEO Resolutions for 2014 - Time to Act on Digital Business," published in March 2014.<br />
<br />
A more succinct way to state the above is "continuously evolve or rapidly become irrelevant."<br />
<br />
You have to look no further to see the effects of gross negligence to adapt than the U.S. Post Office. Last year, I got divorced, sold the house, and moved to a new location. My ex-wife moved to a different location. And although we both created mail forwarding requests, she kept getting mail that was addressed for me. She moved over 4 months ago, and even today she is still getting my mail when it is mailed to my former address.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiOy9SrJy7wCEUOL42h9G-kjOsmUCdqoh07TOvNEDhCywfhgI40BwHRCCuoRd4Mv1pUbEoOJ5v40MTgoDK8G3_l9IrXNNvwDvNOqCK9udVXIL63zRTpcILawn7vfABnwKTMq1NQ76seyCct/s1600/Continuously-Evolve.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiOy9SrJy7wCEUOL42h9G-kjOsmUCdqoh07TOvNEDhCywfhgI40BwHRCCuoRd4Mv1pUbEoOJ5v40MTgoDK8G3_l9IrXNNvwDvNOqCK9udVXIL63zRTpcILawn7vfABnwKTMq1NQ76seyCct/s1600/Continuously-Evolve.jpg" /></a></div>
When I asked the USPS about it, I was told this: only the first initial of the first name and the last name are used by the USPS for processing mail forwarding at a specific address. Since my ex-wife has the same first initial as I do, that explained why she was receiving my mail (and that of my deceased father, who also shares this characteristic). I was in shock then, and it still leaves me shaking my head when I consider that statement because there is no need to restrict the amount of data that is used when considering whether or not a name on an envelope matches an entry in a database.<br />
<br />
To describe a specific alternative, the concept of <a href="http://www.ibm.com/support/knowledgecenter/SS8JHU_2.1.1/com.ibm.programmingedm.doc/edmwh019.htm" target="_blank">fuzzy searches</a> have been around since my days at IBM in the 1980's. The linked article describes how it is used, but the underlying idea is to remove all vowels, replace certain digraphs with functional equivalents, replace duplicate consonants with singular instances, and replace certain consonants with their functional equivalents. For example, "Larry Salomon" may become "Lry Slmn"; "CEOs must focus on leading" may become "C mst fks n ldng"; etc.<br />
<br />
Combine this with a conversion to uppercase / lowercase, and then apply an MD5 hashing algorithm (a 16-byte value) to the result to get a (relatively) unique fingerprint for the name. Couple this with the ridiculously <a href="http://www.mkomo.com/cost-per-gigabyte-update" target="_blank">cheap cost of disk storage per gigabyte</a> and you have the ability to support whatever mail forwarding needs could possibly exist.<br />
<br />
To put this in perspective, as of 2013 there were 7.125 billion people living in the world. Not excluding a single person, even infants, if there were a single mail forwarding request for every one of those people, the storage requirements would be: 7,125,000,000 x 16 bytes per hash / (1024 x 1024 x 1024 bytes per terabyte) = 106 terabytes of storage. Contrast this with Facebook, which (as of 2012) <a href="https://gigaom.com/2012/08/22/facebook-is-collecting-your-data-500-terabytes-a-day/" target="_blank">collects 500 terabytes of data</a> on its users <i>per day</i>. And while no single cause can fully explain the <a href="http://www.prc.gov/press-releases/prc-releases-its-analysis-usps-financial-health-report-highlights-continuing-losses" target="_blank">dire financial straits</a> of the USPS, symptoms like this do not inspire confidence that the leadership has any clue how to meet the ever evolving needs of its customers.<br />
<br />
"Adapt or die." Live by this mantra, and you will continue to stay ahead of your competition.Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-62770993219593031092015-12-10T12:42:00.000-05:002016-01-18T12:45:10.393-05:00Stagnation Leads to Death<i>"Pró-gress must pro-gréss" - Unknown</i><br />
<br />
Nowhere more than in the world of technology is the notion of velocity and acceleration more evident in terms of its ability to contribute to the success of a business. It is imperative for companies to evolve if they intend on staying in business. In fact, Gartner said in 2014:<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhH4kpF9eEoVXHiJIeIFQauAWBzCWyrh2-eFvAXBcbNSPvxWwrIs0LwMqvKtYd3NYUpDLcoQMVNd7GP4fO5QNFNhJLv3AwIWLMz6hICMpYE-TJlVQ8ObsPYOnfhs-GasFicugqz3XvGVpo6/s1600/Weakest-Link.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhH4kpF9eEoVXHiJIeIFQauAWBzCWyrh2-eFvAXBcbNSPvxWwrIs0LwMqvKtYd3NYUpDLcoQMVNd7GP4fO5QNFNhJLv3AwIWLMz6hICMpYE-TJlVQ8ObsPYOnfhs-GasFicugqz3XvGVpo6/s200/Weakest-Link.png" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">What is your weakest link?</td></tr>
</tbody></table>
<i>"In 2014, CEOs must focus on leading their organizations to think like and become more like 'tech' companies, because within a few years, digital business capabilities will dominate every industry. Urgent action is needed because first-mover advantage is common in digital business, and fast followers must be very fast."</i> (<b>CEO Resolutions for 2014 - Time to Act on Digital Business</b>, <a href="https://www.gartner.com/doc/2676616/ceo-resolutions-time-act-digital" target="_blank">published by Gartner</a><a href="https://www.gartner.com/doc/2676616/ceo-resolutions-time-act-digital" target="_blank"> in March 2014</a>.)<br />
<br />
Contrast this with the Fortune 500. Established in 1955, it chronicled the evolution of the top 500 global companies. But in spite of the implied size of the companies on this list, less than 20% of those companies are still in existence. And although attribution to events such as M&A must be given, it is reasonable to assume that the majority of those companies are no longer around due to their own inability to adapt to the drumbeat of change in the marketplace.<br />
<br />
Is this the inevitable fate of most companies? I would argue that it isn't. What is needed to avoid this is the ability to recognize the need to evolve. As a great example of this, the vast majority of industry pundits were ready the shepherd the decline and ultimately the demise of the mainframe after the Y2K efforts had concluded. Not only has the mainframe survived, though, its use has increased since that time. (See the <b>2014 Mainframe Study </b><a href="http://www.bmc.com/blogs/mainframe-trends-results-2014-mainframe-survey/" target="_blank">published by BMC in January 2015</a>.)<br />
<br />
If the oldest computing platform can continue to evolve then this begs the question: why haven't all legacy, general purpose computing applications also done the same? A great example of this is workload automation. Originally designed to be simply a job scheduling system, its purpose then was to simply coordinate the execution of tasks, or jobs, that were developed by other IT operations or application development teams. The problem that has developed, however, is that the number of systems with which workload processes may possibly interact with have increased exponentially over the years. And so organizations are faced with Sophie's choice: either continue to retain staff that have specialized knowledge on systems that are now considered ancient or implement a costly modernization effort to remove those systems with more modern equivalents that, assuming such replacements exist, have a lower burden from a staffing perspective on an organization.<br />
<br />
Even if such modernization potential exists, companies are frequently loathe to undertake them due to the heightened amount of operational risk they incur during the initiative's overt phases and immediately after until time has proven such modernization to have been successful due to the absence of production errors. While data relating to this is scarce at best, we can see such reluctance exhibited within the realm of IT's newest darling, DevOps. In 2013, <a href="https://www.ca.com/us/register/forms/collateral/market-pulse-research-the-state-of-devops.aspx" target="_blank">IDG published a survey</a> describing how 45% of its respondents said that application release automation was a key enabler for DevOps, yet only 11% had implemented such automation. Considering that <a href="https://en.wikipedia.org/wiki/DevOps" target="_blank">DevOps was born in 2008</a> the rate of adoption has been pitiful to say the least.<br />
<br />
All is not lost, however. Even though some workload automation systems are still antiquated in terms of capabilities, they are only antiquated in the sense that they have peers who have evolved over time. Integration with existing infrastructure, monitoring capabilities, and the addition of operationally focused capabilities (like <a href="http://automic.com/sap-system-copy" target="_blank">SAP system copy</a> or <a href="http://automic.com/business-analytics-big-data" target="_blank">processing of big data warehouses</a>) exist in solutions produced by companies exhibiting thought leadership.<br />
<br />
In summary, there is no need to settle for less. While the tendency exists for company to mark time with their existing operational systems footprint, there is typically no requirement to do so. If your systems are not providing the capabilities you need in a way that allows you to optimize your run-rate then perhaps you should be looking elsewhere for systems that do meet those requirements.Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-83626387499354213512015-11-03T13:50:00.000-05:002016-03-09T09:41:34.303-05:00Provisioning For What Purpose? (Part 2)<a href="http://larrysalomon.blogspot.com/2015/09/provisioning-for-what-purpose-part-1.html" target="_blank">In part 1</a>, we discussed how provisioning is part of the overall process of releasing an application, and how application release is a specific case of process automation. In this part, we are going to look at the general capabilities of an automation platform with the overall view of applying those capabilities to application release, service orchestration / provisioning, and workload / job scheduling.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3fqjQ5pStlNLoGO-A8EdLcjcozb5I-NdqgD48GcKW33-5cZvl1dC3EpUktc3-wUGIhoGKDVNDKr79m6D8akCdtTbGb2iItw3xonthyHKeziJwjLjPwo2zH4HZr_cPZMISGt9oOhBrTW8o/s1600/Signs.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="184" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3fqjQ5pStlNLoGO-A8EdLcjcozb5I-NdqgD48GcKW33-5cZvl1dC3EpUktc3-wUGIhoGKDVNDKr79m6D8akCdtTbGb2iItw3xonthyHKeziJwjLjPwo2zH4HZr_cPZMISGt9oOhBrTW8o/s200/Signs.jpg" width="200" /></a>The earliest use of automation can be traced back to IT Operations where Run Books were used heavily to "begin, stop, supervise and debug the system(s)" (<a href="https://en.wikipedia.org/wiki/Runbook" target="_blank">from Wikipedia</a>) in the Network Operation Center (NOC). Run Books were initially index cards containing a set of instructions to accomplish a certain task; these were then listed on 8.5" x 11" paper; and ultimately moved to huge three ring binders due to the complexity of the underlying systems with which the operator interacted.<br />
<br />
At some point, companies such as Opsware, RealOps, and Opalis recognized that well defined, mature processes were simply a set of repeatable steps with simple branch logic built-in. They built products that were then sold to HP (in 2007), BMC (in 2007), and Microsoft (in 2009), respectively, to allow Run Book Scripts to be defined in a computerized form and then initiated via an operator console and, later, via integration with ITSM solutions.<br />
<br />
From a capabilities standpoint, all automation (Run Book Automation [RBA] now often referred to as <b>Process Automation</b>, <b>Workload Automation</b>, or <b>Release Automation</b>) requires similar capabilities. These are listed below:<br />
<br />
<b>Support for a broad number of platforms. </b>Distributed systems
are widely used, of course, but the mainframe also didn't die as many
"industry experts" predicted it would in the last decade. Combined with
the many Unix variants and even lesser known platforms like IBM's
iSeries, all of these operating systems have enough market share that
they cannot be ignored and should be supported.<br />
<br />
<b>Built-in integration with the surrounding ecosystem. </b>While being able to enter commands manually via some script window is no worse than writing BASH or WSH scripts, having built-in support for commonly used IT infrastructure (e.g. monitoring systems, typical system metrics such as CPU usage or free disk space available, web / application / database servers, etc.) allows the workflow designer to simply enter a few values in a data form and the underlying system takes care of translating the action to the underlying commands.<br />
<br />
<b>Parse and react. </b>Taking the output of executed commands or their result codes and either extracting values to be used in subsequent steps or branching based on those values is critical.<b> </b><br />
<br />
<b>Complex scheduling. </b>Email systems like Outlook standardized the use of calendars for scheduling meetings or tasks to be completed. The use of scheduling in an automation platform, however, needs to be much more capable since automated IT processes are often run according to very complex scheduling rules.<br />
<br />
Integration capabilities cannot be emphasized enough. To illustrate the former, the need to query free disk space (for example)
exists no matter what the ecosystem is so using high level, abstract
commands frees the author from having to explicitly add support for new
platforms as they are adopted by their IT department. Instead, they can simply drag and drop a step called "query disk space" into their workflow and do not have to worry if the workflow will be running on Windows, Unix, OS/400, etc.<br />
<br />
Similarly, the ability to support very complex scheduling rules is also a "must-have." For example, end of month financial reporting may need to run on the
last business day of each month (which varies in length) unless it is a
holiday, in which case it would run on the next business day after
that. Rules like this cannot easily be expressed using "Monday,
Tuesday, ..." or "Every <i>n </i>weeks" types of criteria that end users are typically familiar with.<br />
<br />
Other core capabilities that are not automation specific are multi-tenancy, Role Based Access Control (RBAC), High Availability (HA), and auditing features. These will not be discussed here due to their use in several other types of IT Operations systems with which you are ultimately familiar.<br />
<br />
All of these capabilities do not belong in one type of automation system or another. Instead, they belong in a core platform that can be utilized by several types of solutions to meet various business needs. Whether it is something general (e.g.job scheduling or application release) or something specific (e.g. processing large Hadoop datasets or copying your SAP system from one instance to another), having a feature rich automation-centric foundation ensures that all of your operations systems will not only meet your current needs but will also grow as your needs do.<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-48523398842934123562015-09-22T20:32:00.000-04:002016-03-09T09:41:34.299-05:00Provisioning For What Purpose? (Part 1)In the early part of the last decade, I ran a global education program at a mid-sized company called Softwatch. In this role, my responsibilities required that I provide education to our partners around the world. One such occasion had me traveling to Paris to teach a class with 20 students from various parts of Europe, and so my partner <a href="https://www.linkedin.com/pub/matthew-grob-cphims-fhimss/4/262/936" target="_blank">Matt Grob</a> and I flew out on Saturday to spend the weekend creating a complete education lab from scratch.<br />
<br />
Granted, it's not incredibly taxing when you're building a lab in Paris of all places. The process, which was fairly straightforward, took us both days and then we had the nights to explore the Champs-Élysées, La Concorde, etc. not to mention eat and drink amazing culinary delights.<br />
<br />
However, I digress. The point I am trying to make is that it took us an entire weekend to build 20 computers in an identical manner. It cost the company several hundred dollars to provide accommodations (hotel and meals) that would have been unnecessary if it were 2012 instead of 2002.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjqzxcVsF3kxV1PlXYsfphwoE9952SRJPL_SkqwhrpnzL9oahFtA_QlHT5nC4KBEv0CBIoZRnLR2I4Jlk0KFlGiuTLyQcLq7PXtyAsQ0F8tqKaJrQB7DZV1SRzCyRhnKLkTlmFLE1avmhee/s1600/Wheels.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjqzxcVsF3kxV1PlXYsfphwoE9952SRJPL_SkqwhrpnzL9oahFtA_QlHT5nC4KBEv0CBIoZRnLR2I4Jlk0KFlGiuTLyQcLq7PXtyAsQ0F8tqKaJrQB7DZV1SRzCyRhnKLkTlmFLE1avmhee/s1600/Wheels.jpg" /></a></div>
But it must be said that provisioning, for provisioning's sake, is never done - there is always a purpose. This task is performed to provide an environment that can run applications. Maybe the applications are COTS (Commercial, Off The Shelf) or internally developed, but applications are the <i>raison d'être</i>. Even in my story, we were building the machines so that my company's software could also be installed and run by the students during the class.<br />
<br />
Provisioning, then, should be considered part of application release.<br />
<br />
Many companies have missed the boat: BMC's <b>BladeLogic</b> and CA's <b>Automation Suite for Clouds</b> are provisioning with no purpose. They require other solutions to consume the produced machine, real or virtual, so that it may be incorporated into a bigger picture. But customers no longer want building blocks - they want turn-key solutions - so these formerly bedrock solutions are now passé. This is evidenced by the fact that both of these solutions are now buried deep within the websites of their respective owners. I suspect similarly deep locations will be found on the websites of other vendors in this space.<br />
<br />
Looking at the bigger picture, however, we see that provisioning is simply a sequence of steps to be followed: <br />
<ol>
<li>Install the OS</li>
<li>Install the application server, DBMS, or ESB</li>
<li>Configure the application server, DBMS, or ESB</li>
<li>Connect it to the rest of the infrastructure</li>
<li>Deploy the application components on the box. </li>
</ol>
The above steps define a process to be automated.<br />
<br />
Automation is automation, regardless of how it's being used. And all automation, regardless of its design, requires core capabilities that have withstood the test of time in terms of stability and scalability.<br />
<br />
In part 2 we will look at some of these core capabilities that should be required features of any automation platform.Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-61558524324353369772015-06-22T21:39:00.000-04:002015-07-01T12:31:01.181-04:00Application Defects are a Real ProblemThis past weekend was my high school's 30th year reunion get together in my hometown in Beaufort, SC, which is home to Parris Island and the awesome Marine Corps Air Station across town. My companion purchased the tickets for us both using reward miles on her airline of choice via that airline's website. She is a frequent flier on that airline for professional reasons so her profile contained her rewards program number and her TSA pre-check number. I, on the other hand, don't fly on this particular airline much so I don't belong to their rewards program. In fact, I don't fly often at all, since my job typically keeps me in the greater NYC metro area where I can drive everywhere that I need to go so I never filed for a TSA pre-check number either.<br />
<br />
Imagine my dismay, then, when browsing our boarding passes revealed that my boarding pass said "TSA pre" on it. "That's odd," we thought, and were sure that some other system would flag that as a mistake. That didn't happen, though, and I was allowed to waltz through the high speed line without taking my shoes or belt off and walk through the much more lenient metal detector rather than the full body scanner.<br />
<br />
Still, we chalked it up to a fluke. After all, my companion printed the boarding passes at home. We wouldn't have that luxury for the return trip and would be required to use the kiosk at the ticketing counter, and we were sure that this wouldn't happen again. It did, however, and once again I was able to make it through security with the greatest of ease.<br />
<br />
I can't say with 100% certainty what the cause is, but it is most likely an application defect that resides somewhere in the backend systems of either the airline or Sabre (which is the largest Global Distribution Systems provider for air bookings in North America, according to Wikipedia). Regardless, you can understand why this is a real problem since any person with malicious intent could exploit this easily with very harmful results.<br />
<br />
We've all read various research reports on the impact of application defects, but here are a few numbers for you:<br />
<br />
<ul>
<li>29% of an application developer's time is spent in some part of the problem resolution process, whether that is root cause determination or remediation of the actual defect.<sup>[1]</sup></li>
<br />
<li>6.7 days elapse from the time a defect is first observed until it is fixed<sup>[1]</sup></li>
<br />
<li>The annual impact of application defects on the U.S. economy is $60 billion.<sup>[2]</sup></li>
<br />
<li>It costs 30 times as much to fix a defect if it is detected in production.<sup>[2]</sup></li>
</ul>
<br />
<span style="font-size: x-small;"><sup>[1]</sup> Forrester Research</span><br />
<span style="font-size: x-small;"><sup>[2]</sup> NIST</span><br />
<br />
These numbers, while interesting, really hit home when you consider that organizations are already under intense pressure to release new features and functionality more quickly than ever before. This is compounded by the fact that many organizations have still not fully made the transition from Waterfall to an Agile SDLC methodology, so the process of releasing these new features is still quite cumbersome. When a lot of time is spent remediating application defects, that means less time is being spent developing code or performing more unit tests.<br />
<br />
What can be done? One of the obvious solutions is to switch to an Agile SDLC methodology. Other viable solutions that address significant parts of the problem are:<br />
<br />
<b>Virtualize the backend systems.</b> Using a solution like CA Service Virtualization or a similar solution from IBM or HP, you can isolate live code so that defects uncovered during testing are more quickly found. Furthermore, virtual services developed by such solutions eliminate the need to have access to downstream systems all of the time, allowing developers to work in parallel, resulting in savings of 30% or more time from inception to release.<br />
<br />
<b>Accelerate testing.</b> This means more than just developing test scripts that can be automated. Automatic generation of test scripts - "automating the automation" - as well as the synthetic generation of test data that eliminates the multi-week wait time between regression suite runs that are required to allow the DBAs to pull a new copy of the production data and mask it so that regulatory standards are met. CA Continuous Application Insight, CA Data Finder, BMC AppSight, and IBM Optum provide various capabilities in these areas.<br />
<br />
<b>Get insight into your application.</b> Applications are complex, and long gone are the days when people understood what happens after you issue a request to a downstream component or another application with which you integrate. Being able to see the various components being invoked along with the data used in each invocation is invaluable to a developer, especially if the tester can generate a document containing this information when the defect is first observed.<br />
<br />
Contrast that with the effort to reset the environment, re-execute the test case, get the defect to happen for the exact same reason, all while documenting everything that they were doing. Forrester once reported that 25% of all defects are rejected as irreproducible and that nearly half of their respondents said they spend over an hour cumulative per defect documenting what happened. CA Continuous Application Insight, CA APM, and BMC AppSight (and others, undoubtedly) provide various capabilities in this area.<br />
<br />
The point is that application defects will always exist. But there really aren't legitimate reasons why something as simple as the defect that I personally encountered have to exist. And when the stakes are as high as they are when you have a plane full of passengers, it is the responsibility of every organization to ensure that the applications they produce are of the highest quality.Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.comtag:blogger.com,1999:blog-8903387593005046724.post-52650210247589540212015-03-26T11:11:00.000-04:002015-03-29T22:11:27.733-04:00Is Docker the End of Traditional Application Release Management?Ever since its release in 2013, Docker has quickly catapulted into the enviable position of being the darling of every (operations manager's) eye. If you've been vacationing on Mars since then or simply haven't been staying on top of the news releases such as the one that has heralded Microsoft's intention to support Docker on Windows (a <span data-dobid="hdw"><i>cause célèbre</i> for sure since Docker is originally a Linux specific platform), here is what you've missed.</span><br />
<span data-dobid="hdw"><br /></span>
<span data-dobid="hdw">Docker is a partitioning capability within the address space of an operating environment. By allowing the partition to use the host OS directly even though that OS resides outside of the partition (known as a <i>container</i>), the start up time is substantially reduced as is the resource requirements for the management of the container. (I hope my z/OS readers find this concept to be somewhat familiar.) </span><br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgvX4hH5MuXUb13QTYA4B1d87IItKjQfyfgrghm4PNpBP_6VQs4cGRYYu5AnJuXwP_VAn0fU02oRrSS_i-j6tJdeP4O0g9ASgGA9aAASlkqjihKFhxYCmcYmoT4zsAhOzGElaXNtHn1PAgr/s1600/VMs.png" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img alt="" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgvX4hH5MuXUb13QTYA4B1d87IItKjQfyfgrghm4PNpBP_6VQs4cGRYYu5AnJuXwP_VAn0fU02oRrSS_i-j6tJdeP4O0g9ASgGA9aAASlkqjihKFhxYCmcYmoT4zsAhOzGElaXNtHn1PAgr/s1600/VMs.png" title="From https://www.docker.com/whatisdocker/" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Typical Virtual Machine layout<br />
(from www.docker.com)</td></tr>
</tbody></table>
<span data-dobid="hdw"><b>Financial people</b> love this because the cost of acquiring licenses for the operating environment can be substantially reduced since, theoretically, every component that is not part of the application itself can reside outside of the container. This means only one Windows license needs to be procured versus one per VM, which is traditionally the <i>modus operandi</i>.</span><br />
<span data-dobid="hdw"><br /></span>
<b><span data-dobid="hdw">The concept is simple, but how does it work?</span></b><br />
<br />
<span data-dobid="hdw">Essentially, a special file (called a <i>dockerfile</i>) contains one or more instructions on how a container is to be created. The dockerfile is used as part of a (presumably) automated process to generate the container on the file system, which can contain as little as a single application and its associated binaries. This container (a subdirectory in the file system) is transferred to the target environment as any set of files would be and is started there using the docker run time, which can be invoked via command line interface or an API (typically REST based but there are other implementations). </span><br />
<br />
<span data-dobid="hdw"><b>System Administrators</b> love this because containers are easy to deploy (XCOPY anyone?) and maintain (REST interfaces can be easily integrated into any modern Infrastructure Management platform).</span><br />
<span data-dobid="hdw"><br /></span>
<span data-dobid="hdw">So that's it, isn't it? End of story? We can now throw away all of our Application Release Management platforms like <b>IBM's UrbanCode Deploy</b>, <b>BMC's Varalogix</b>, or <b>CA Technologies' Release Automation</b>, right? </span><br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWglU74hsU6pXIbDK7cAOVqyGdhPnnVq23p13Qtl5-4ZuDzf8a6Eg_rTcDZqpyaF2tjtdF8OP3DBAgJzxlRKCEk89PIBQvUw9l9xY5Ok5sKJeBs3WCd959IzbWoP8UyuEvC7HTlJ3gEGz6/s1600/Docker.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img alt="" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWglU74hsU6pXIbDK7cAOVqyGdhPnnVq23p13Qtl5-4ZuDzf8a6Eg_rTcDZqpyaF2tjtdF8OP3DBAgJzxlRKCEk89PIBQvUw9l9xY5Ok5sKJeBs3WCd959IzbWoP8UyuEvC7HTlJ3gEGz6/s1600/Docker.png" title="From https://www.docker.com/whatisdocker/" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Typical Docker layout<br />
(from www.docker.com)</td></tr>
</tbody></table>
<span data-dobid="hdw">"Not so fast, pardner." This concept falls down </span><span data-dobid="hdw">when people eye it as a substitute for true application release management. More specifically, we can describe the latter using five of the six question words that everyone learned in high school English:</span><br />
<span data-dobid="hdw"><br /></span>
<span data-dobid="hdw"><b>Who.</b> It should not be allowable for anyone in an organization to deploy an application to an environment. In fact, even for those who should be allowed to do so, there are frequently others who have to approve the deployment decision. </span><br />
<span data-dobid="hdw"><br /></span>
<span data-dobid="hdw"><b>What.</b> For organizations that truly embrace the concept of business agility, deploying a complete application every time is unacceptable. Artifacts deemed as low risk (e.g. content updates) may be deployed immediately while higher risk artifacts will be queued up to be released after much testing and other validation. Docker falls into this category but has limitations, which will be touched on below.</span><br />
<span data-dobid="hdw"><br /></span>
<span data-dobid="hdw"><b>Where.</b> The target environment of a deployment is frequently different from every other possible target environment that an application will touch during its journey from development to production. These differences are typically addressed by making changes to the configuration of the application after it has been deployed.</span><br />
<span data-dobid="hdw"><br /></span>
<span data-dobid="hdw"><b>When.</b> Release windows are not a new concept. Even in non-production environments, a case for establishing a release window could be made since environments are often shared among multiple teams within the same function or even across functions (i.e. testing and development may use the same environment).</span><br />
<span data-dobid="hdw"><br /></span>
<span data-dobid="hdw"><b>How.</b> Probably the most problematic to fully integrate into an organization's operational capabilities, the process of deploying an application is far more than simply understanding how to install and configure it. Integration with ITSM applications to ensure that change requests have been entered and are in the correct state, approval gates have been successfully completed, etc. have to be incorporated into the process of deployment so that the state of the operating environment is always well understood.</span><br />
<br />
Of the five question words above, Docker only addresses one of them and not in the most effective manner possible. Consider the scenario of a well known bank based in Europe. They currently have in excess of a thousand production releases <i>every month</i>. This was accomplished by recognizing that not all production releases are high risk. In the example under <b>What</b> it was noted that certain types of artifacts had minimal impact. As a result, the release of those artifact types could be expedited, which helped ensure that this bank's customer facing assets were always meeting the needs of their clientele.<br />
<br />
If they were using Docker, however, the entire application would need to be rebuilt regardless of the types of artifacts that were actually approved for production release. The risk that unapproved binaries could be released into production is simply unacceptable for most companies. And this is only for one of the five items, above - Docker does nothing to address the other four.<br />
<br />
To summarize, Docker is an exciting and (relatively) new technology that should be viewed as simply another mechanism that exists within the greater whole of application release. But it should not be viewed as a replacement for a well defined methodology that not only includes the "what," but also includes "who," "where," "when," and "how".Larry Salomon Jr.http://www.blogger.com/profile/07451799480626936601noreply@blogger.com