Julius Gamanyi -

- Wardley Maps — an Illustration from Gerstner’s book —Part 2
  
  Posted at 22:02 by Julius Gamanyi, on June 18, 2019
  The second loop around the Strategy Cycle is in chapters 8-10 of Lou Gerstner’s book, “Who Says Elephants can’t Dance,” in which he summarises his plan in the following sentence:
  
  “I turned my attention to three areas that, if not fundamentally changed, would disable any hope of a strategy built around integration: organization, brand image, and compensation.”
  Gerstner Jr., Louis V. (p. 83).
  
  I’ve found that to map out the above quote (probably for another blog post), I needed to understand IBM’s history a little, its success with its subsequent effects on IBM’s market position and on IBM itself, and lastly, the factors that led to Gerstner’s changes being not only necessary, but as “stones” (if I may borrow from Simon Wardley’s talk titles) that he (Gerstner) needed in “Crossing the River by feeling the stones” as he looped around the Strategy Cycle several times.
  
  I asked myself several times why I had to know this or why I felt it important. After all, it’s ended up being long enough that I’ve had to separate it out into its own post. Well, it dawned on me that knowing about it would form the “Landscape” that Gerstner would be considering. And “Landscape” is (if I can insert a reminder here) the second important part of the Strategy Cycle. Afterwards comes “Climate,” “Doctrine,” “Leadership.”
  
  A disclaimer applies: these maps are are my interpretations, which might be right, or wrong, or in between, but nonetheless useful.
  So Caveat Emptor ¯\_(ツ)_/¯
  
  Digressions – slightly useful to some
  
  First, I often recommend (when asked) to practice mapping from articles (example) , books, tweets (example), talks, even “vision” or “future” statements from organisations (example).
  
  In addition to these being in a more evolved state of Evolution (Cognitive Hierarchy post), they already contain the material that we need to “only” express. I apply Alexander Bain‘s principle of learning composition in writing to Wardley Mapping (see square brackets):
  
  The Composition of Themes involves the burden of finding matter as well as language; . . . For an English [mapping] exercise, the matter should in some way or other be supplied, and the pupil disciplined in giving it expression [mapping it out].
  Alexander Bain’s “English Composition and Rhetoric”. Page vii in the Preface.
  
  Through this, we build this up as a habit, which is manifested when we have to map but are constrained regarding time. Speaking of forming habits, A. B. Simpson writes:
  
  Every habit grows out of a succession of little acts. No habit comes full-grown into your life; it grows like the roots of a tree. . .The stenographer takes down words as fast as they are spoken. At first it is clumsy and slow work; but at length it becomes a habit, and now the stenographer does not have to stop and think how to make the characters; they come as naturally as words come to the lips.
  Simpson, A. B.. “The Christ Life.” Location 517. Kindle Edition.
  
  Wouldn’t it be great if mapping with its symbols, stages of evolution and their characteristics, the sources of capital, doctrine, climatic patterns, gameplay would come naturally to us as words come to lips. The downside is what Ian Walker coined as the “Wardley Curse” 😂
  
  Secondly is how long it should take to do these maps. That also depends on your context/situation. Sometimes we use “maps” as a term to mean the Value Vhain + Evolution, which represents only in the “Landscape” part of the Strategy Cycle. Other time we use the same term to mean the entire Strategy Cycle.
  
  Even if we limited the term to mean the Value Chain + Evolution, the time it would take to draw a map of a tweet is likely to be smaller than that of multinational organisation or a nation state.
  
  Ideally, the time required would be proportional to the scope and goal in mind.
  
  Building on previous post
  
  Before I continue, I’d like to point out one missing pieces from the previous post – pieces that I only found out through Holger and the attendees of the Wardley Mapping Meetup in Köln.
  
  Dealing with Inertia
  
  Some maps of the previous post contain inertia barriers but I didn’t go into how he dealt with them. The “Messaging” component helped overcome some inertia, but to my mind, the biggest help to overcome came from the “Moral Imperative” and the emergency context. Because IBM was seen as a national treasure that had to be rescued, many employees willingly gave up their jobs, others volunteered to come out of their retirement to help, still others worked much harder. One gets a glimpse of this not only through the “Dedication” page, but also from sentences sprinkled throughout the book.
  
  Maps that are bridges on what’s to come
  
  To recap the previous article, as the underlying components are becoming more certain, Gerstner prepares to make another loop around the Strategy Cycle – shown in the map below: that the new “purpose,” “scope,” and “moral imperative” build on the corresponding components. The maps in this section link the previous article with what’s to come, to the next loop around the Strategy Cycle.
  
  The map below is for completeness only. After the explanation is the next two sentences, I’ll dispense with the horizontal dotted arrow lines. Now, because the new map (#3) is built upon (#2) underlying components that are still evolving (remember that these initiatives took about 8 to 10 years), I’m using the dotted red arrow (#1) in the map to represent this. Naturally it makes the map appear a bit cluttered.
  
  Removing the previous components simplifies the map below – see below – and adds the knowledge and practices that Gerstner obtained from his previous experiences at McKinsey.
  
  Background to Gerstner’s second loop – the S/360
  
  Besides what Gerstner had done “to stop the bleeding,” making other loops required knowing what was essential at IBM. He tells us:
  
  Despite the fact that IBM, then and now [circa. 1993], was regarded as a complex company with thousands of products, I’d argue that, until the mid-1980s, IBM was a one-product company—a mainframe company—with an array of multibillion-dollar businesses attached to that single franchise.
  Gerstner Jr., Louis V. (pp. 116-117)
  
  Which is why I followed along, and hope that you will too.
  
  S/360 – its Background
  
  What follows is an attempt to show this on Wardley Maps while taking account of the historical background, which chapter 12 furnishes us with. I’ll also take selected paragraphs from Wikipedia to help with these maps.
  
  The map shows what I imagine to be the Pre-S/360 phase – most components at in the “Custom” phase. Gerstner writes:
  
  Before System/360, IBM was just one of several companies that made and sold computers. Each company’s computers were based on proprietary technology. They didn’t work with any other computers, even from the same company, and each computer system had its own peripheral devices like printers and tape drives. This meant that if customers outgrew a computer or wanted the advantages of some new technology, they had to discard all of their hardware and software investments and start over
  Gerstner Jr., Louis V. (pp. 115)
  
  I interpreted that to mean that most components are going to be in the “Custom” phase of evolution.
  
  From the article in Wikipedia, the S/360 hardware was made from integrated circuits.
  
  The next three maps show components that were being built ontop of S/360. First was the Operating System, then Middleware.
  
  Then the Middleware technologies are listed below.
  
  Applications and Peripherals are now (circa. After 1965) being built on top of the new S/360.
  
  The components “Application” and “Peripherals” are being built on top of what the S/360 made possible. Gerstner continues,
  
  Software developed for one processor would run on any System/360 processor. All peripheral devices—printers, tape drives, punch-card readers—would work with any processor in the family. For customers, System/360 would be a godsend. For IBM’s competitors, it would be a knockout blow
  Gerstner Jr., Louis V. (pp. 115)
  
  I’ll come back to the competition later.
  
  What’s noteworthy in the map below is the dying out of the previous Value Chain (shown in Gray) and the creation of new value chains that became the base for IBM’s dominance for two to three decades (circa. 1965 – 1985).
  
  Because of the new S/360, there was the building up of new capabilities and the Co-evolution of Practices, such as the Sales force having to change. Gerstner reminds us:
  
  System/360 required a very knowledgeable, consultative sales force that could help customers transform important business processes like accounting, payroll, and inventory management. Traditional order takers couldn’t do this job.
  Gerstner Jr., Louis V. (p. 116)
  
  To show this, I’ll make the S/360 into a submap
  
  Giving us
  
  Then the new areas of growth (circa. after 1965) are occurring. Details of the 3 new Submaps (Services, Post-S/360 Applications, and Middleware) are on Page 154 of the book.
  
  S/360 – its Success
  
  Building on the S/360 led to IBM’s dominance. I’ve taken ideas from the pdf, “The Future is predictable” together with Simon Wardley’s posts. For this, I’ll add more Users to the Map, and also Porter’s 5 forces.
  
  With tweaks (that are specific to IBM and enclosed in square brackets), these sentences from Simon Wardley’s post (after Figure 247 in Chapter 19) are applicable.
  
  From the map, we start with the industry [IBM] itself. It has a need for investors (i.e. shareholders) which involves a bidirectional flow of capital e.g. investment from the shareholders and return on investment to the shareholders. I’ve simply marked this as a “$” to represent a financial flow in both directions. . . . In order to pay for the return on investment (whether dividends or share buybacks) [IBM] needs to do something that makes a profit. This involves [providing Computing] to Customers.
  Simon Wardley; “Wadley Maps” on Medium, Chapter 19, Figure 247
  
  Represent competition with Porter
  
  To represent the competitive landscape, I’ll use Michael Porter’s 5 Forces.
  
  Recap on Porter’s 5 Forces on a Wardley Map
  
  Simon Wardley applies Porter’s 5 forces in Chapter 17 (section titled “On Porter” and Figure 222) onto a Map. The whole section is worth reading. I’ll quote the relevant parts here & also use the same figure:
  
  For those unfamiliar with Porter’s five forces, these are rivalry within the industry, threats of new entrants, threats of substitution and the bargaining power of suppliers vs consumers. In this section we’re going to examine these five forces through the lens of the peace, war and wonder cycle (see chapter 9).
  Simon Wardley; “Wadleymaps” series on Medium, Chapter 17
  
  In the time of Wonder:
  
  In the time of wonder, it is a battle to become established. The field is not yet developed and there are no “new entrants” as there are no established figures to be “new entrants” against. Everything is new, uncertain and uncharted. It is the wild west, ‘ere be dragons and the home of split infinitives. The consumers hold the power and it is they who decide whether this industry will succeed or not despite their initial inability to know whether they need it.
  Simon Wardley; “Wadleymaps” series on Medium, Chapter 17
  
  In the time of Peace:
  
  In the time of peace, there is a constant tug of war between supplier and consumer power over the products produced. The developing giants are normally well protected from new entrants in a game of relative competition. The exception is the occasional threat of substitution. It is this substitution by a different product which tends to be the dominant factor.
  Simon Wardley; “Wadleymaps” series on Medium, Chapter 17
  
  In the time of War:
  
  In the time of war, new entrants providing a more industrialised form of the act threaten the existing giants that are stuck behind inertia barriers. It becomes a fight for survival for these giants and they are often poorly equipped. It is not a case of a product becoming substituted by another product but instead an entire industry being changed to more industrialised forms. It is often assumed that the shift towards utility provision means centralisation but this is not the case
  
  Since we’re talking about IBM during the period of 1960s to early 1990s, I don’t expect to have components in the time of “War.” You can read more about these forces from Simon Wardley, and the forces themselves are well explained by Porter himself (see HBR article from 1979).
  
  S/360 – with Porter’s 5 Forces
  
  Let’s apply Porter’s forces to our map. How would it look like ?
  
  A few basic notes: Firstly, every double-circle represents a Barrier to Entry. Secondly, since the existing components were submaps, enclosing them within the symbols representing Porter’s forces was more convenient than attaching the forces to the components themselves. Finally, all these components have an arrow pointing left, meaning that the suppliers, in this case, IBM had a lot of bargaining power, which is characterised by Porter as:
  
  he power of each important supplier … depends on a number of characteristics of its market situation and on the relative importance of its sales … to the industry compared with its overall business.
  Michael Porter in https://hbr.org/1979/03/how-competitive-forces-shape-strategy
  
  (1) and (2) The Services and Sales components can best be seen in Gerstner’s description:
  
  Even the sales force had to change. System/360 required a very knowledgeable, consultative sales force that could help customers transform important business processes like accounting, payroll, and inventory management. Traditional order takers couldn’t do this job. The company had to create a product service and maintenance capability and a customer-training and educational arm
  Gerstner Jr., Louis V. (p. 116)
  
  Hence the reason I’m representing these barriers as K/F/S — i.e., “Knowledge” that the Sales forces requires; “Financial” barrier required to train up such a workforce and setup the Services capability; lastly “Social” because that’s the backbone of Sales and Services (in my optinion). On the other hand, since the “Services” component is “new,” it would be fighting to be established. My inference is that because it’s setup from the company that provides the underlying component, it’s perceived as more credible in the eyes of Customers.
  
  (3) The component, “Post S/360 Application,” was important but not that high a barrier to entry. Because of which, suppliers could be substituted. This in turn increased the Customers’ bargaining power.
  
  (4) and (5) were differentiators and therefore barriers too. Gerstner writes:
  
  How did we end up in 1990 with the world’s largest software business? Because there would be no usable System/360 without an operating system, or a database, or a transaction processing system, or software tools and programming languages
  Gerstner Jr., Louis V. (p. 116)
  
  These crucial components (1), (2), (4), and (5) don’t have arrows pointing right, which means that the Customers’ bargaining power was limited. The S/360 and most of the components built on top of it were not undifferentiated to such an extent that Customers could always find alternative suppliers. Furthermore, Customers also loved what the S/360 made possible: more powerful, reliable, and less costly machines that allow for interoperable software applications. The result was that
  
  IBM’s share of the computing market skyrocketed. Competitors reeled; many disappeared. The company’s revenues grew at a compound growth rate of 14 percent from 1965 to 1985. Gross profit margins were amazing—consistently around 60 percent. Market share exceeded an astounding 30 percent, which eventually invited antitrust scrutiny.
  Gerstner Jr., Louis V. (p. 117)
  
  More representations on our Wardley Maps
  
  We’ll add more components to our maps.
  
  Effects of Doctrine on Success and vice-versa
  
  IBM’s leadership position in the marketplace, and even leading up to it, had created a a certain kind of culture/belief system/doctrine that was embodied by its visionary founder, Thomas J. Watson, Sr. Speaking of Watson, Gerstner writes:
  
  Watson’s experience as a self-made man engendered a culture of respect, hard work, and ethical behavior. IBM was the leader in diversity for decades, well before governments even spoke of the need to seek equality in employment, advancement, and compensation. A sense of integrity, of responsibility, flows through the veins of IBM in a way I’ve never seen in any other company. IBM people are committed—committed to their company, and committed to what their company does. . . He [Watson, Sr.] summarized them in what he termed the Basic Beliefs: Excellence in everything we do. Superior customer service. Respect for the individual.
  Gerstner Jr., Louis V. (pp 183-184)
  
  Gerstner remarkably adds:
  
  Institutionalizing these beliefs wasn’t just a matter of displaying signs in every office (although they were everywhere). The Beliefs were reflected in the compensation and benefits systems, in the management schools, in employee educational and training programs, in marketing, and in customer support. It was the doctrine of the company—and very few companies have extended a doctrine so pervasively
  Gerstner Jr., Louis V. (p. 184)
  
  These quotes are from Part 3 of the book (from chapter 20 to 23). Attempting to map out how he dealt with culture (as defined, and used, by Gerstner) is out of scope for these series that I’m doing. Those interested can read those enlightening chapters.
  
  Adding these to the map would look like below: the first map shows what’s to be made into a submap:
  
  After making the value chain into a submap, we can add more components that build on it.
  
  Position in the marketplace the basis of Compensation
  
  Building on the submap, we see that the market for computing is growing, and IBM has the largest chunk (1), thanks for its offerings (number #2). These are made possible through the employees (number #3) who are compensated (point #4) according to some compensation model. Because being compensated for your work/labour is universally accepted, it’s in the Stage 4 of Evolution.
  
  As for the map below, it highlights components that affect Doctrine, i.e., the company’s position in the marketplace and its employees.
  
  Which gives us the table below:
  
  Factors leading to an org structure
  
  Because of its position in the marketplace, IBM ended up serving many types of Customers. As it served more customers, so did it increased its marketshare.
  
  The map below adds another factor that led to the “Product Divisions” – which was to cope with the rate of technological change and the corresponding threats and opportunities.
  
  Conclusion
  
  Like I said at the beginning of this post, I didn’t expect the background to be this long. Morever, there are a few things I’d wanted to add but I’m restricted by time and probably your attention 😉 – things such as the effect on Doctrine that came from being in such a dominant market position for decades; or the effect on Doctrine that crept in through the antitust suit that lasted for abou 13 years; or the partial blindness to the competition; etc.
  
  For those interested in Culture, I’d recommend his observations in chapters 20 to 22, on its establishment, how it degrades, how it can be changed, and the sheer difficulty of maintaining it. Then compare his approach with those from today’s well-known companies.
  
  As for those interested in Strategy, I’d recommend chapters 23 to 25 where he discusses what Strategy is not (e.g. vision statements), what it is, and it’s importance.
  
  Ofcourse, I never would’ve been able to make any sense of it without Wardley Maps – both the work and the people. There’s always more to learn, and I’m looking forward to it. Notwithstanding, we have a decent base.
  
  As for writing these posts, my current bottleneck is drawing these map. But Sertillanges’ remark keeps nudging me on:
  
  The reward of a work is to have produced it; the reward of effort is to have grown by it.
  Antonin Sertillanges, “The Intellectual Life”
  Share this:
  Click to share on Twitter (Opens in new window)
  Click to share on LinkedIn (Opens in new window)
  Click to email this to a friend (Opens in new window)
  Like this:
  Like Loading...
  Posted in Wardley Maps | 0 Comments | Tagged IBM, Lou Gerstner, Simon Wardley, Wardley Mapping, Wardley Maps
- Adapting to PARA using GitLab
  
  Posted at 21:20 by Julius Gamanyi, on May 30, 2019
  It’s almost 2 months since I started walking through Tiago Forte‘s series on P.A.R.A Method (Projects. Areas. Resources. Archives) and implementing it. I’ve got Ben Mosior and Tasshin Fogleman to thank for the connection.
  
  I loved these series, especially the fifth one, the Project List Mindsweep, because it broad enough to cover both home and professional life, and fine enough to manage “actionable systems” (Todo lists) and non-actionable systems (where we store reference information), as read in:
  
  the Project List was the lynchpin of not only P.A.R.A. and your broader PKM (personal knowledge management) system, but to your entire working life. . . your Project List is transmitting information between your actionable and non-actionable systems
  Tiago Forte’s Project List Mindsweep
  
  Pain points from Friction
  
  The article and the corresponding Evernote templates were a great help. Yet, when it came to the practice, I found myself overwhelmed: there are at least 2 Evernote notes to keep open: the article itself and a copy of the template – this is where I’ll list the project titles, and if necessary, the descriptions. I followed the article, step by step, while updating the template. For each step in the article, I had to copy the project title into the relevant section in the Template, and then modify the project title a little bit, either to write the desired outcome or to review them. I couldn’t sustain that repetition after 3 projects.
  
  Turning to Excel Spreadsheets
  
  This prompted me to find a different way of dealing with these. I naturally turned to Excel, which was sufficient to start with. Each worksheet corresponded to a “trigger.”
  
  Excel worksheets corresponding to each trigger mentioned in the Part 5 of PARA
  
  In the worksheet, each project with its title and description was a row; and each step, a column. Following the steps for all my projects became easier. But I have project ideas almost every week (when I’m commuting, in discussions with others, etc). Project ideas also come when doing the weekly/monthly reviews. Adding these to the Excel Spreadsheet was not appealing because Excel, working poorly on mobile, means I need to have a laptop to update it.
  
  I ended up looking for a way to visualise all the projects, the steps described for Project Lists, and the P.A.R.A workflow (esp. the weekly and monthly review). Trying a visual board like Trello/Jira/GitLab seemed like the next step to me.
  
  My 2 main requirements were to be able to have multiple boards and able to create a card/issue by sending an email. Why email? Take a look at One-Touch to Inbox Zero.
  
  GitLab Setup
  
  Since I already had a GitLab account, I chose to use that one instead of the other tools. GitLab offers multiple boards at the project level, group level.
  The bronze level subscription ($4/month) gives you multiple boards on one project. This is the one I’ve started with. For silver subscriptions, multiple boards are also available at the group level. I’ve encountered 2 limitations with GitLab:
  - I can’t duplicate items – it’s copy and paste (at least for now).
  - A board’s description is not formatted and ends up as one long line. Nevertheless, it’s still useful to have.
  Description of a board in GitLab remains unformatted
  
  I’ve configured my GitLab to allow me to do this. In the GitLab project, “jg-para,” I’ve setup boards to match the Workflow.
  I took my brain dump Project List, combined all worksheets into one, with two columns (title, description), saved it as csv file and imported them all into GitLab.
  
  In my day-to-day work, when I think of idea that could be a project, or from any of the “triggers,” I send an email to the relevant project in GitLab and an issue is created. Much the same way that emailing our Evernote account’s email address creates a corresponding note in Evernote.
  
  Now I know that all project ideas are in one place. Later, maybe during one of the review cycles, I’ll still be able to follow the steps in that article to deal with these project ideas.
  
  Because each GitLab “issue” represents a potential PARA “project”, after an issue goes ino the “Executable” board, it gets its own Notebook in Evernote. Before using GitLab, I used to create an Evernote notebook for potential projects. After the steps of “Organise” and “Reflect,” I’d delete the project notebooks that are no longer relevant.
  
  This setup has made the PARA steps, workflows, and my projects visible. In turn, I no longer feel so overwhelmed.
  
  Of course, none of this would be possible without these series on PARA.
  
  Animated GIF as Summary
  
  Summarised in a visual gif :
  Share this:
  Click to share on Twitter (Opens in new window)
  Click to share on LinkedIn (Opens in new window)
  Click to email this to a friend (Opens in new window)
  Like this:
  Like Loading...
  Posted in PARA, Productivity | 0 Comments | Tagged GitLab, PARA, Productivity, Tiago Forte
- Wardley Maps in drawio
  
  Posted at 23:14 by Julius Gamanyi, on March 25, 2019
  I recently came across dr awio, and I’ve been using it to make Wardley Maps. In addition to the online version, there’s also a desktop version that you can download and use.
  
  It doesn’t require me to sign up for an account; it integrates well with common cloud storage options (dropbox, google drive, onedrive). As a result, I find myself using it more than I thought, especially when it comes to layers.
  
  To see what I mean, I’ve placed the maps from the previous article on AWS S3 to try out. The output/export of drawio was a single html file that can also be saved locally and opened in the browser.
  
  Interact with the map – using buttons
  
  To interact with the Wardley Map mentioned above, you can use the buttons present or select which layers you’d like to see. The disadvantage of using the buttons is that pressing them out of sequence messes up what’s displayed.
  
  Shows icon to make image occupy whole screen.
  
  Use the “fullscreen” option to view the map. This abstracts away browser-specific behaviours.
  
  The click through the buttons at the top in this sequence:
  - 1, 2, 3, then on 3 again (to make the selection disapper)
  - 4a, 4b
  - 5a, then click “back to map”
  - 6, then click “back to map”
  - 7, 8
  Gif version
  
  Animated version (with button clicks) of all Wardley Maps contained in previous article, i.e., https://juliusgamanyi.com/2018/12/28/wardley-maps-an-illustration-from-gerstners-book/
  
  Interact with the map – using layers
  
  To select the layers, hover your mouse over the map’s page to reach the icon for layers. There, you’ll see several checkboxes that can be selected.
  
  Shows layers contained within the diagram that, in order to be shown, have to be selected
  
  Gif Version:
  
  Animated (gif) version (using checkboxes to select specific layers) of all Wardley Maps contained in previous article.
  
  Using drawio online with icons/symbols for Wardley Maps
  
  If you’d like to try out drawio online for drawing Wardley Maps, I’ve created drawio specific template, or a set of icons, that should save us time. These are are saved online and made available through a URL [1] because draw-io online gives us the option of specifying URLs from which to load icons/symbols – see step 3 in the image below. For a quick try, see section titled “P.S. Update on 09-April 2019“
  
  URL is
  https://s3.eu-central-1.amazonaws.com /wardleymaps.prototypes.001.gerstner/Misc/WardleyMap-Icon-Library
  
  Steps to add icons/symbols of Wardley Maps to drawio online
  
  GIF Version
  
  Gif version showing steps to add icons/symbols of Wardley Maps to drawio online
  
  Using drawio desktop with icons/symbols for Wardley Maps
  
  If you prefer the desktop version of drawio, I saved the same icons on Dropbox ( https://www.dropbox.com/s/d1s4ua0rmnvdduw/WardleyMap-Icon-Library?dl=0 ) and GitHub (
  https://github.com/juliusgb/wardley-map-icons/tree/master/drawio )
  
  In drawio, first click on File, then “Open Library,” and select where you saved the file.
  
  Gif Version
  
  Animated (gif) steps to add Wardley Map icons/symbols to the desktop version of drawio.
  
  Adding to the collection of icons/symbols
  
  If you’re interested in adding to these icons, there’s a GitHub repository where I keep them. You can also modify your local copy and send it to me.
  
  Further reading and other tools
  
  With respect to tools, Chris Daniel started us off with atlas2. Then Ben Mosoir summarises what’s being used, adding some reflection on tooling in general.
  
  P.S. Update on 09-April 2019
  
  I’m still discovering what drawio enables. E.g., with this link [1], the stencils are now linked to the corresponding github repo, meaning that you’ll always get the latest version of the stencils.
  After updating the repo, I don’t need to copy them to s3 and dropbox. Whereas you, by getting the stencils from github (if you’re using the desktop version), always have the latest version. Win-win for all. wohoo!! 😎
  
  URL [1] – https://www.draw.io/?splash=0&clibs=Uhttps%3A%2F%2Fraw.githubusercontent.com%2Fjuliusgb%2Fwardley-map-icons%2Fmaster%2Fdrawio%2FWardleyMap-Icon-Library
  Posted in drawio, Tools, Wardley Maps | 0 Comments | Tagged drawio, Wardley Map Icons, Wardley Map Symbols, Wardley Mapping, Wardley Maps
- Wardley Maps — an Illustration from Gerstner’s book
  
  Posted at 09:49 by Julius Gamanyi, on December 28, 2018
  I’ll be mapping a few important chapters of Lou Gerstner’s book, Who Says Elephants can’t Dance (amazon affiliate link) [1], as illustrating Wardley Mappings. Not that Gerstner draws maps for us but his descriptions and narratives embody much strategic thinking that I couldn’t help recall Wardley’s Strategy Cycle, which led to an attempt at visualising them using Wardley Maps.
  
  Justifying my application
  
  But, before we explore the maps from Gerstner’s book, I’d like to explain why I think it’s the best that I’ve come across that illustrates Wardley Mapping, looping through the Strategy Cycle within a business context.
  
  When I say “the best,” I mean it in the sphere of what I’ve come across and read. This sphere is naturally quite narrow.
  
  Of all the materials out there, a subset have been published or made public. Of these, I’ve read a small portion. Of those that I’ve read, I see two that are relevant to Wardley Maps. I’ve restricted myself to books. Articles are too short for this purpose. On the other hand, I could wade through documents, such as annual reports of publicly traded companies – this I occasionally do – but these make for dull reading, let alone function to impress the mind with vivid illustrations.
  
  First are the series of books by Peter Krass. These consist of a collection of articles from the leading business men and women of the time, articles arranged around varied themes within the broader categories of Business, Management, Leadership, Entrepreneurship, and Investment. I mention these series because, in them are many articles contributed by several contemporaries of Gerstner — such as Bill Gates (Microsoft), Larry Ellison (Oracle), Andy Gove (Intel) — contemporaries that he speaks of.
  
  Secondly, there’s Richard Tedlow’s book, Denial: Why Business Leaders Fail to Look Facts in the Face—and What to Do About It (amazon affiliate link). The Wikipedia entry summarises it as:
  
  The book has two parts. The first portion highlights companies that have struggled to solve matters within their respective businesses while the second part features firms that successfully overcame obstacles.
  
  From my perspective, the scope of what they did and didn’t do is too narrow when compared to Gerstner’s book in the following sense: with Gerstner, he described to us the context (the market, customers, competitors, employees, culture, leadership) followed by his actions whereas in “Denial,” it’s Tedlow (the author) who tells us the context and then explains the actions or inaction of the business leaders at that time. This gives the impression (at least to me), that the companies spoken of didn’t know (or didn’t make explicit) the context (at least the critical parts relevant to them) in which they operated, i.e., didn’t know their landscape. Of those that did, their landscape and corresponding value chains described were small – made up of a few components – in comparison to Gerstner. If you don’t know the landscape, how can you apply doctrine, climatic patterns, and gameplay on an industry/market level ?
  
  Regarding learning to map, the task is two-fold: to find materials ample enough to cover all the elements of Strategy (in business), and on the other hand, to express them on one or several Wardley Maps. Relevant books and articles furnish us with materials. What’s left, for us learners, is to map them. Laying aside how true they are and to what degree, these materials become common ground to those learning. Imagine a book club, with the added twist that the selected book is mapped, and the subsequent discussions revolve around the maps produced.
  
  Gerstner’s book/memoir furnishes me with such materials with a large enough scope – that of a big, mutlinational corporation – and an acknowledge of the role luck plays in succeeding.
  
  Assumed knowledge and how I’ll quote
  
  Before I proceed to the parts of the Strategy Cycle, I hope you’ve already read Gerstner’s book. Otherwise, I might spoil it for you. I’ll take it apart (figuratively speaking) and place chapters/sections where I think they’d fit on the Wardley Map and the Doctrine cheatsheet without much regard to their sequential order in the book. This is a poor man’s version of Boyd’s “analysis” and “synthesis,” which he taught through a mental exercise that ends up with snowmobiles. I’m hoping this ends up as useful regardless of being small in degree.
  
  Secondly, to keep the article as short as possible, I’ll assume that you’re already familiar to some extent with Simon Wardley, Wardley Maps, and the corresponding terms and symbols (see Figure 60 and 61 in Chapter 6)
  
  Thirdly, to use Gerstner’s words to illustrate Wardley Maps would require quoting from him extensively. E.g., to illustrate the point of “removing bias and duplication” within the “Development” category of Doctrine, I’d show the current state with the appropriate quote (in RED), followed by the decisions reached and actions taken, and finally how this point looked like afterwards (in ORANGE). Limiting myself to only those descriptions of the current state, he says this about “duplication” on page 42:
  
  I returned home with a healthy appreciation of what I had been warned to expect: powerful geographic fiefdoms with duplicate infrastructure in each country. (Of the 90,000 EMEA employees, 23,000 were in support functions!)
  
  Then again on page 64 (note he uses “division” instead of “geography” – the difference is huge especially in the context of a global company):
  
  Today (circa 2001) IBM has one Chief Information Officer. Back then we had, by actual count, 128 people with CIO in their titles—all of them managing their own local systems architectures and funding home-grown applications. . . The result was the business equivalent of the railroad systems of the nineteenth century—different tracks, different gauges, different specifications for the rolling stock. If we had a financial issue that required the cooperation of several business units to resolve, we had no common way of talking about it because we were maintaining 266 different general ledger systems. At one time our HR systems were so rigid that you actually had to be fired by one division to be employed by another.
  
  There are 15 more page numbers (in different parts of the book) that correspond to the different points of Wardley’s Doctrine to show us the situation at the time (what I’m referring to as the “current state”). And that’s just the first part – the current state. There are many other passages on the decisions and actions he took, and what the corresponding result was. To reproduce all that here would definitely overstep the “fair use” policy of copyright in books. Unless one of you know him and can ask permission form him – after all, it’s for educational purposes 🙂
  
  Therefore, I’ll state the page numbers in the relevant sections, which should help you find your way. As seen above, his descriptions are excellent. I know it’s cumbersome to read an article on the one hand, and on the other, to look up pages in another book. Nevertheless, I’d still recommend it. Who knows, you might find even more that I’ve probably missed. I’ll restrict myself to quoting where it matters to make an impression on the mind.
  
  Looping around the Strategy Cycle
  
  I’m referring to Wardley’s Strategy Cycle below:
  
  Simon Wardley’s Strategy Cycle –
  CC BY-SA 4.0
  
  In this book are, what seems to me, several loops around it:
  - The first loop consists of chapters 3 to 7.
  - The second loop consists of chapters 8 to 10.
  - Another is in Part II of the book.
  - Yet another is Part III of the book.
  Other parts of the book contain more iterations around the Strategy Cycle. For this article, I’ll start with the first loop.
  
  First map and corresponding Doctrine
  
  The map below shows the current state of IBM – recall it’s in the mid-1990s. I’ve kept it simple. I’ve placed the map of Wardley Maps on top of, or next to, what I’d represent as IBM’s map.
  
  Figure 1 – Map of business landscape
  
  Because of this overlay, Point 1 in Figure 2 below shows what has an effect on Doctrine, that is, the internal and external processes on Doctrine, and the most important of all, the messaging – whether it’s something important to the CEO, senior leadership, and to the company. If restricted to the CEO, this shows itself in the what he says, the decisions he makes, and the actions he takes.
  
  An example of this is when Gerstner, having decided to stop milking the Mainframe, re-invests in it in order to lower its prices – good for the Customer; risky for the company in improving cashflow and remaining profitable.
  
  Figure 2 – Influences on Doctrine and historical play
  
  I’ve added the component of “Messaging and Communication” because of Gerstner’s estimation of it during transformational efforts, namely:
  
  The sine qua non of any successful corporate transformation is public acknowledgment of the existence of a crisis. If employees do not believe a crisis exists, they will not make the sacrifices that are necessary to change. Nobody likes change. Whether you are a senior executive or an entry-level employee, change represents uncertainty and, potentially, pain. (p. 77)
  
  The importance of this “Messaging and Communication” component is felt today in other companies. Consider the effect that Jeff Bezos’ letters has had on Doctrine at Amazon. Or the effect from Warren Buffett’s annual letters for Berkshire Hathaway.
  
  Point 2 in Figure 2 above is supposed to show what happened to cause the company to lose market share and money. This made most of the components have the characteristics and properties found in the “Custom” phase.
  
  Point 3 is to show that a lot of uncertainty surrounded the major three components but not “Moral Imperative.” This uncertainty made these components risks. There was no guarantee, as Gerstner explains, that the company would succeed in stopping the bleeding, let alone be profitable. Nevertheless, the “Moral Imperative” was felt keenly and strongly – in the board members, in Gerstner, in the senior leadership team, and in many of the employees.
  
  Doctrine
  
  I’m taking liberties with where I put Doctrine. When I see it in the “Genesis” and “Custom” phases, I interpret it to mean that the Cheatsheet will contain lots of red. As we move through the stages of Evolution, it becomes orange, then green. As I mentioned earlier, I’ve added the page numbers in the relevant boxes, which should help you find your way.
  
  Table 1 – current Doctrine
  
  Add Decisions and Actions to the map
  
  The map below shows Gerstner’s decisions and the affected components. This corresponds to the “Decide and Act” part of the Strategy Cycle.
  
  Besides the two decisions that he made early on — keeping the company together instead of splitting it and repositioning the mainframe — Gerstner introduces three initiatives that are shown in the map below.
  
  Figure 3 – Initiatives, Inertia, and points of change
  
  Keep in mind that I’ve oversimplified the components “External facing” and “internal facing.” What I quoted at the beginning of this article is one of the things that Gerstner says about them.
  
  He further added, that:
  
  Reengineering is difficult, boring, and painful. One of my senior executives at the time said: “Reengineering is like starting a fire on your head and putting it out with a hammer.” (p.64)
  
  Table 2 – Initiatives Summarised
  
  Areas of Doctrine affected by Initiatives
  
  These initiatives affected these areas of Doctrine. I’ve kept them colour-coded with the parts of the map.
  
  Table 3 – Initiatives affecting Doctrine
  
  Initiatives change the map
  
  These initiative, running in parallel, took many years to complete. Nevertheless, even after one year, there was much improvement. Gerstner summarises some of them (see pp. 65-66):
  
  By addressing some of the obvious excesses, he had already cut $2.8 billion from our expenses that year alone. Beyond the obvious, however, the overall task was enormous and daunting.
  
  The map below shows how the components have moved. One point to note is that the dotted red arrows start from where a component was before the initiatives started.
  
  Figure 4 – a changing landscape
  
  He goes on to tell us:
  
  From 1994 to 1998, the total savings from these reengineering projects was $9.5 billion. Since the reengineering work began, we’ve achieved more than $14 billion in overall savings.
  
  Since he doesn’t mention the time period, I’m assuming a time period of approximately 8 years — from 1993 to 2001 — to improve the area of Doctrine of “Optimise Flow” (in category “Operation”)
  
  Hardware development was reduced from four years to an average of sixteen months—and for some products, it’s far faster. We improved on-time product delivery rates from 30 percent in 1995 to 95 percent in 2001; reduced inventory carrying costs by $80 million, write-offs by $600 million, delivery costs by $270 million; and avoided materials costs of close to $15 billion.
  
  Doctrine is also changing
  
  Some areas of Doctrine are no longer “red” but “amber.” They’re not “green” because the Doctrine component is not yet in the Utility phase and there are also more iterations to come around the Strategy Cycle.
  
  Table 4 – Improved Doctrine through Initiatives
  
  Preparations for the second loop
  
  We’re now in a position to start looping around the Strategy Cycle a second time. Describing it all might be too much for this single article. If you, dear reader, have read thus far, I’ll leave you with the starting point of the next iteration in the map below, where the node “previous Wardley Map” encapsulates the aforementioned maps.
  
  Figure 5 – How starting the second loop would look like
  
  Conclusion
  
  I’ll admit that reading this book several times in order to follow the threads of each point of doctrine, pattern, and gameplay has been weary at times. For the repetitious readings, like the repeated use of sharp knife, often blunts the impact of these impressions on my mind.
  
  On the other hand, by the same repetitious process, I engrave again on my mind those traces that are bound to easily fade.
  
  References and useful links
  
  [1] – Page numbers are based on the edition, “HarperCollins e-books. Kindle Edition”. Complete title is “Who Says Elephants Can’t Dance?: Leading a Great Enterprise Through Dramatic Change” by Gerstner Jr., Louis V.
  
  There’s an online course that teaches Wardley Maps – https://learn.leadingedgeforum.com/p/wardley-mapping/?product_id=277424
  Posted in Strategy, Wardley Maps | 1 Comment | Tagged IBM, Lou Gerstner, Simon Wardley, Strategy, Wardley Mapping, Wardley Maps
- The Journey Continues
  
  Posted at 19:50 by Julius Gamanyi, on November 12, 2018
  I’ve just moved to this website.
  - The posts for 2018 I first wrote on Medium. I’ve imported them here too.
  - As for the more older posts, these are generic enough for me to have moved them from our internal company blog.
  I decided recently to attempt publishing one post every month – one month would be a post here and for the next month, a post for our internal company blog.
  
  Whether I’ll keep it up remains to be seen.
  
  Like this:
  Like Loading...
  Posted in Uncategorized | 0 Comments
- Wardley Map — Cognitive Hierarchy
  
  Posted at 01:52 by Julius Gamanyi, on September 15, 2018
  What I’ve found helpful in maintaining my ardor as I get to grips with complex topics has been a Wardley Map of a “Cognitive Hierarchy,” a hierarchy I came across a while ago[1]. Even though it’s explained in the context of war, I’ve found it useful when also applied to my studies. Perhaps it might do the same to yours.
  
  Many subjects that I’d like to get into require time from me to understand, even if I limit myself to Hamerton’s definition of “soundness,” [2] which is below:
  
  The best time-savers are the love of soundness in all we learn or do, and a cheerful acceptance of inevitable limitations. There is a certain point of proficiency at which an acquisition begins to be of use, and unless we have the time and resolution necessary to reach that point, our labor is as completely thrown away as that of mechanic who began to make an engine but never finished it. . . .
  
  On labour versus the accomplishment:
  
  Now the time spent on these unsound accomplishments has been in great measure wasted, not quite absolutely wasted, since the mere labor of trying to learn has been a discipline for the mind, but wasted so far as the accomplishments themselves are concerned. . . .
  
  Defining “soundness” and its examples
  
  I should define each kind of knowledge as an organic whole and soundness as the complete possession of all the essential parts. For example, soundness in violin-playing consists in being able to play the notes in all the positions, in tune, and with a pure intonation, whatever may be the degree of rapidity indicated by the musical composer. . . .
  
  A man may be a sound botanist without knowing a very great number of plants, and the elements of sound botanical knowledge may be printed in a portable volume. . . .
  
  Suppose, for example, that the student said to himself “I desire to know the flora of the valley I live in,” and then set to work systematically to make a herbarium illustrating that flora, it is probable that his labor would be more thorough, his temper more watchful and hopeful, than if he set himself to the boundless task of the illimitable flora of the world. . . .
  
  Lastly, it is a deplorable waste of time to leave fortresses untaken in our rear. Whatever has to be mastered ought to be mastered so thoroughly that we shall not have to come back to it when we ought to be carrying the war far into the enemy’s country. But to study on this sound principle, we require not to be hurried. And this is why, to a sincere student, all external pressure, whether of examiners, or poverty, or business engagements, which causes him to leave work behind him which was not done as it ought to have been done, is so grievously, so intolerably vexatious.
  
  Since some of these topics are not necessarily related to my job, it means spending some of my spare time on them. Suppose that to acquire soundness in topic ‘X’ requires 40 hours; if I have 2 hours per day that are free from interruptions, I would need 20 days (almost 3 weeks) for such an acquisition. This also assumes that I’m pursuing only that one topic. I leave it you to imagine what happens when tackling other topics at the same time, varying them to break the monotony. After the initial enthusiasm wanes, is endurance called for, so as to maintain the consistency of working on it daily; or like John Foster once called it, “this indefatigable patience of exertion.”[5]
  
  For that, having an assurance that it’s worth it for me is encouraging. This is where having maps that I can frequently review maintains my ardour. They also help me decide whether to pursue a particular subject, and, most importantly, to what extent. After all, “the time given to the study of one thing is withdrawn from the study of another, and the hours of the day are limited alike for all of us.”
  
  What would the map of an individual (in this case, me) look like ? Some aspects are applicable to groups/teams, but I wanted to keep the scope as narrow as possible. Because it’s for an individual, most components are in the “Custom” phase, e.g., the person has to perform analysis; it’s not something that can be delegated/outsourced.
  
  1. The first user need is to understand a topic, especially, as it relates to either help in arriving at a decision (perhaps “to decide” should be the top-level user need) or to see patterns or to anticipate the consequences of others’ (or my) actions. To decide, to see patterns, to anticipate consequences — all these are applicable in many contexts — at work, at home, and in the community. If a topic does not help me with these, I often lay it aside. I’m excluding those that are for amusement — but even with these, it’s almost an impossibility for them not touch those three points.
  
  2. Having selected, and committed to, such a topic, there’s the need to apply “judgement,” which is not only knowing that something is but why it is so. Based on one’s experience, expertise, and intuition, one also develops principles (or the inner workings) that can explain what’s going on. Yet without such experience or intuition, so do they need be built up. One cannot apply the judgement he/she does not posses. Therefore, there’s the need for the next component: if I practise applying these cognitive functions to the processed data, I’ll be able to construct a mental model/picture of the current situation/environment and be able to make decisions that anticipate what others might do, owing to the principles/laws/patterns that have caused the situation in the first place.
  
  3. Once we have various processed data that have been evaluated (either by oneself or by others), there’s the need to apply those “cognitive functions,” to harmonise them. If applied to studies, “comparing text with text,” as Sertillanges encourages us, “making the different sources of information complete, illustrating one with the other, and draw[ing] up your own article.” As he concludes, he reassures us, “It is an excellent gymnastic, which will give your mind flexibility, vigor, precision, breadth, hatred of sophistry and of inexactitude, and at the same time insure you a progressively increasing store of notions that will be clear, deep, consecutive, always linked up with their first principles and forming by their interadaptation a sound synthesis. ” [3] Such links to first principles lend themselves to drawing Wardley Maps 🙂
  
  That’s where the difficulty manifests itself — where does one begin, and end, with the many resources (print, video, audio, etc) on a topic ? Which of them to gather? How many of them can one get through, knowing that each differs in style, breadth, depth ? How to bring them to terms, to find and state their propositions, their arguments, and their solutions, if any ? Mortimer Adler and Charles Van Doren [4] help us here. This calls, once more, for that “indefatigable patience of exertion.”
  
  There’s also that feeling that John Foster [5] so aptly describes:
  
  Is it, then, in the first place, that a man can instantly place himself among the subjects of knowledge, and begin to take possession, without the cost of any tedious forms of introduction? No; he must consume in all a number of years in the acquisition of mere signs; in the irksome study of terms, languages, and dry elementary arrangements. Is it, that having thus fairly arrived within the boundary of the ample and diversified scene, he is certain to take a direction toward the richest part of it, and with the best guides? He may happen to be led by some casual circumstance, or to be attracted by some delusive appearance, to a department where his mind will exhaust its strength in endless toils, to reap nothing but a few vain and pernicious dogmas. He may be as if Adam, when “the world was all before him where to choose,” had been deserted by “Providence his guide,” and beguiled to wonder into what is now Siberia.
  
  Or if a man in quest of knowledge should have directed his view to a more valuable class of subjects, he may waste a great deal of labour and time, and be often tempted to renounce his purpose in disgust, through an unfortunate selection of instructors and guides.
  
  Hence the reason to be severe with those who profess to instruct; and the necessity of critically reviewing each work, such that the criticism serves as a signpost to encourage other travellers to the helpful, or as a warning sign advising them not to approach. This is where Simon Wardley’s “Tomb of Tomes” would come in handy 🙂
  
  4. For that sifting to occur, these have to evaluated based on some criteria — e.g., their importance, relevance, and reliability. But then, the question becomes “important” to whom ? What’s important to me may not be important to you. Moreover, even if I limit this check to myself, what’s important to me now may not be what’s important to me a few months/years’ time. Because I have to apply these criteria frequently, I’ve left this activity in the “Custom” phase.
  
  5. At this point, only one book is under consideration. For it to have been produced required someone to apply the processing functions to raw data.
  
  What limits do I see in such a map have ? Firstly, this map is for a cognitive hierarchy. It’s generic. It’s not specific to any subject nor to any industry/company/team. In order to apply it to something specific, e.g., to learn about AWS or Azure or Bash shell scripting, you’d need to map your industry/company/team to see where such knowledge sits in the phases of evolution. This, in turn, determines how much to invest and what the expected return is. Next is to overlay one map on the other. If the lower components of the chain are seen as commodities in their respective markets/industries, then you can focus on steps 1 and 2 only.
  
  Secondly, this map doesn’t show any higher-order activities that result from, and build on, more commodotised components.
  
  How does such map help me? Firstly, because of the constraint of time, I’d prefer to only perform activities in step 1 and 2. But, lacking those, I have no choice but to continue descending the value chain. For topics that can be traced back to a few excellent books, I skip (or rather, defer) tackling the many books — the second pipeline — and focus on the books that expressed the initial idea. Sometimes, I find it necessary to descend lower, and apply the processing functions to the author’s raw data, if appropriate/applicable. This is one reason I read, with keen interest, the bibliography or references sections of books and article. And why, I, too, include them in what I write.
  
  Secondly, I’ve noticed that the further down the chain I go, the more time I’ll need to ascend up again. I may be on step 5 for months (according to the 2hr per day guideline), making some progress, but still at the bottom of the chain. Looking at the user need repeatedly refreshes, renews my vision of the goal and sustains me in my pursuit.
  
  This, I’ve found to be a pleasant side-effect.
  
  References
  
  [1] – pp. 20–23 of “Naval Doctrine Publication (NDP) 6”
  
  [2] – pp. 93-96 of “The Intellectual Life” by Philip Gilbert Hamerton. (Affiliate link)
  
  [3] – p. 113 of “The Intellectual Life: Its Spirit, Conditions, Methods” by A.G. Sertillanges, translated from the french by Mary Ryan, 1987 edition, reprinted in 1998. (Affiliate link)
  
  [4] – pp. 114–136 of “How to read a Book” by Mortimer J. Adler and Charles Van Doren
  
  [5] – p. 118 of “The Improvement of Time” by John Foster, edited by J. E. Ryland (1863) — Google Book
  Share this:
  Click to share on Twitter (Opens in new window)
  Click to share on LinkedIn (Opens in new window)
  Click to email this to a friend (Opens in new window)
  Like this:
  Like Loading...
  Posted in Wardley Maps | 0 Comments | Tagged Cognitive Hierarchy, Study, Wardley Mapping, Wardley Maps
- Learning to Map — Cloud IDEs— Developer Workspaces — fast time to first line of code
  
  Posted at 17:59 by Julius Gamanyi, on March 16, 2018
  Just as it’s now the norm for applications and systems to run on public cloud infrastructure and platforms, perhaps so too should be the norm for Integrated Development Environments (IDEs) and the corresponding configuration — those tools that help us write software applications — to reduce the yak-shaving.
  
  I recently got a new Samsung phone and didn’t have to reinstall all my apps. I signed in, was asked to confirm my previous handset, and all my apps with their settings were automatically retrieved and setup. Previously, the process involved remembering all the apps and their settings (especially security and privacy settings), downloading them, changing their settings, opening each one of them to check, and then using the app.
  
  Is such a convenient “user experience” too much to ask for a developer’s workspace ? Do we still need to setup our developer environment/workspace again and again each time we change laptops or change teams or projects? Is there a way to have, what Ryan Boyd, in the context of creating a sandbox for Neo4J graph database, so aptly phrased, “fast time to first line of code”?
  
  To explore this, I’ll use a Wardley Map — something I’m learning from Simon Wardley and the community. Because a map, once created and discussed among relevant people, helps one gain awareness of one’s current environment (situation awareness), which gives direction to actions that lead to serving users’ needs effectively and efficiently.
  
  A word on terminology: writing software requires more than an IDE. Besides downloading it, one also needs to configure it, to obtain the project/program files to work on, and other settings/configurations that make it possible to run the program under development. I’ll refer to all these components as a “developer/development workspace”, just as Codenvy uses the term. It differs, naturally, from what the term means in the context of an Eclipse IDE or in the context of “Amazon WorkSpaces.”
  
  Users, User Needs, and User Journeys
  
  Users and their needs, being the anchor of a Wardley Map, will be my starting point. Who uses IDEs and what do IDEs help them achieve? So far, I can think of 5 categories of users and the corresponding “transactions they’re likely to have with the program/application” (by application, I mean any piece of code that’s made available — from simple programs to learn from, such as those in books, to big applications.
  
  The categories are:
  - Category A — the developer(s) writing the application and making it available;
  - Category B — those who might contribute to it, i.e., help fix open issues on it or extend it;
  - Category C — those who’d like to play around, experiment, with it;
  - Category D — those who’d like to use the application but have no interest in looking at the code — I’ll not go into much detail as far these are concerned. However, this is, in most cases, why the application is built in the first place;
  - Category E — those who, having found that it solves a problem partially, want to incorporate it into their own application as a 3rd party library dependency.
  We have a few needs for different users, whose needs I’ve grouped into “primary” and “secondary” in Table 1 below.
  
  Table 1: Users and their needs
  
  Users’ needs and their relations
  
  The “secondary” needs are the ones I’ll be focusing on. Figure 1, drawn with the Atlas Wardley Mapping Tool, that shows the relationships between the “secondary” needs.
  
  Figure 1: Users, their needs, and the relation between the needs
  
  A few notes on this map:
  - The different users, depending on what they’re working on, can be found in either of the 4 stages of evolution. I put them in “Product” because it’s the most likely.
  - Depending on the idea, or programming language, “Programming an Idea” can take place in either of the 4 phases of evolution. Ideally, I’d represent this as a pipeline.
  - A convention for naming needs that’s worked for me so far is to add the past tense suffix if they are required by other components. E.g., from the Programmer’s perspective, the need is to “program an idea;” but when this need is required by “Play/Experiment,” I read it as: “Play/Experiment” needs “Programmed Idea.”
  Scope
  
  I’ll focus on these 3 users: “Programmer”, “Contributor”, and “Experimenter”, and on the 3 needs: “Program(med) Idea,” “Enable(d) Contributions,” and “Play/Experiment” because they have to setup their developer workspace for the program. One of the underlying components these three need is “Developer Workspaces.” Figure 2 shows this.
  
  Figure 2: Developer Workspace and underlying components — https://creately.com/diagram/ja9kc5il/1VaV4MAPWkf48eMdpoJ2IR3yGCw%3D
  
  Starting from the top of Figure 2, all three users need to have a workspace. All three, in order to fulfill their needs, have to prepare their own workspace. Hence, why I’m placing the component slightly after the custom phase.
  
  In a non-job context (e.g., at home), a developer sets up his own local development workspace. I, like many others, do this several times: every time I have to replace my laptop, or when trying to build and run different projects on my laptop.
  - Depending on how complex these projects are, so do the setup instructions. As a developer, excited to get, build, and run the code, I would read as accurately as possible, follow each step thoroughly, sometimes all steps work the first time (always an unexpected but delightful surprise), most times not (maybe a specific setting is required on the operating system, etc), which leads to attempts to undo every change in order to start afresh on a clean canvass, until it works.
  - To give up one project and start on another means undoing all the previous changes, but the effort is sometimes not worth it. And so they stay; configuration for project upon project keeps piling up.
  - For a new project, the setup process is similar. After a few projects and repetitions, a simpler way is always welcomed.
  From the project’s perspective (supplier/provider), any users interested in running the project’s application code will also go through the same process, unless it’s been somewhat automated/created for them (e.g., as a Virtual Machine). From the user’s (demand) perspective, for each different project our developer/experimenter/contributor, is interested in, they’ll have to go through this again and again because each project is likely to be on a different technology stack that relies on different underlying components and versions.
  
  For users, this on-boarding experience is slooow. Doing it for different projects turns the initial delight to tediousness. But then, after several repetitions, we’ve become so used to it to be numb.
  
  On the job, the process is similar but the scope is much wider. Depending on the technical hats I wear (developer, team lead, technology architect), I’m both a user and a provider/supplier.
  - As a developer, I use what’s available on the project — if it’s automated, great. Otherwise, do it manually & automate it over time.
  - As one responsible for a team, one component I’m responsible for is the on-boarding experience of new team members — to make it fast and smooth — in terms of tools, access, etc. The worst case is for every new team member to go through the process already described above.
  - As a technology architect [one definition about the scope of their differing responsibilties is defined on the company website], joining a project, one of the activities is to, if not already done, take care of (describe, specify, define upgrade path of some components, build) the developers’ workspace in the context of build, deploy, release, and operational processes (including tools and the underlying infrastructure) beginning with the project files in source control, onto a developer’s machine, all the way to different development, test, staging, and ultimately production environments.
  If I could somehow provide that workspace so that other developers didn’t need to install anything but use existing components (e.g., their browser), then on-boarding would be much faster; and keeping the components standardised, up to date, secure, would simplify this step of the developers’ workflow.
  
  Fast time to first line of code
  
  This is what Eclipse CHE, and its SaaS version — Codenvy (which RedHat acquired in May 2017) — makes possible. Figure 3 shows a simplified value chain.
  
  Figure 3: simplified value chain — https://creately.com/diagram/jetrhpl6/BqnKkGuSGcIbnZY6BXQpnfsPVD4%3D
  
  To start working on a project, I now need to have a browser or a desktop to start working on a project’s codebase. The URL to the workspace is provided by the project (the provider/supplier provides).
  
  This sentence from Simon Wardley is applicable here:
  
  “You might find that you’re forced to treat the operating system as more of a product than a commodity because some essential business application [in our case, the build tools and runtime environments] is tightly coupled to the operating system. By understanding and breaking this link, such as forcing the application into a browser, you can often treat a wide number of other components as a commodity.”
  
  As far as I know (and I’m happy to be corrected), other “Cloud IDEs” — Microsoft’s VSCode, AWS’ Cloud9 (which AWS acquired in July 2016)— don’t deal with this problem of developer workspaces. But they do solve the problem of working on the desktop and the browser.
  
  So, as User A (developer/programmer), having created a workspace for a project and made it available via a URL, the other users, User B (contributor) and User C (experimenter), can have a very “fast time to first line of code,” which removes the friction of their meeting their primary needs (job to be done, leisure, or learning).
  Share this:
  Click to share on Twitter (Opens in new window)
  Click to share on LinkedIn (Opens in new window)
  Click to email this to a friend (Opens in new window)
  Like this:
  Like Loading...
  Posted in Java, Wardley Maps | 0 Comments | Tagged Cloud Services, Codenvy, Eclipse Che, IDE, Wardley Maps
- At the LJC openjdk hackday
  
  Posted at 16:01 by Julius Gamanyi, on May 18, 2014
  One way to relax, after a major project release, or as near to it as to allow a deep breath, is to spend some time with others setting up, testing, and working on something at a Hackday. “What?” I hear someone exclaim, “you’ve just built software for a release; it’s exhausted you; and now you still want to work on software, though of another kind, and you find that relaxing? Come now, surely, you jest!”
  
  Before responding to this, here’s an outline of this post:
  - The openjdk hackday and what it consisted of. The hackday happens once every month.
  - How to understand, or at least navigate, a complex codebase; and how this applies to complicated legacy codebases.
  - What’s involved in building and testing the openjdk; and thoughts on keeping up with the different versions of Java.
  Like I said, it’s one of the ways to relax. Secondly, not all activities exhaust you in the same way nor to the same degree: he who has spent the week in Spreadsheets might find it relaxing to work in PowerPoint; he who works indoors might relax outdoors, and vice-versa; he whose mind has been wrestling with Prose, in its rhythmic irregularities, soothes himself in rhythmic Poetry. In all these examples, and in many others that occur to you, effort is expended yet the activities vary; each exercises different mental faculties, and breaks off that weariness of the monotonous exertion of the same faculties. Hence the recommendation to so arrange our activities that, being neither idle nor worn out, we find a certain rest in them.
  
  Before going to the Hackday, I read the instructions, followed numerous links: one link to get the software I needed, then attracted by another, and then another, and there I stayed tangled in the web. One effect was that feeling of being overwhelmed by the information I came across, and the proficiency that would be expected, and my impatience to start contributing; I had forgotten that we all have to start somewhere. Even on the day, I was hesitant: to go or not to go. But, having committed, I went. I also realised that it’s better to download all the reading materials and the required software in case there’s no Wi-Fi.
  
  Overlooking one part of London
  
  At the hackday were several people, all with different experiences, all with varying degrees of proficiency; yet, all eager to learn, willing to be taught, and willing to teach. To this, you can add, as an auxiliary, the venue. The hackday was at the Salesforce office, the 26th floor of new The Heron building.
  
  After having breakfast, talking with the other attendees, connecting to the Wi-Fi, the host gathers us, explains the ground rules, outlines the main ideas on the agenda, and opens it up to the attendees to suggest more ideas that they’d like to work on. Most of us attending had a preference of what to work on: some wanted to work on openjdk, some on Scala, others on Play, some on Go, some on Clojure.
  
  Brainstorming over food
  
  The agenda had two pre-planned items:
  - Getting started on, and improving the openjdk. The openjdk is a Reference Implementation (RI) of the Java programming Language since version 7.
  - Working on betterrev – a wrapper, written in Play, for the JDK build system. More details are here
  The floor was then opened to the attendees to speak on what they would like to work on, and also what they’re working on.
  - One of the attendees (Norbert Radyk ) was working on a Scala wrapper for the Apache Commons POI library (a Java API for Microsoft Documents). Those who had come for Scala had something to work on; Norbert had helpers; and I think that explaining his project to strangers and seeing them productive was a good preparation for his talk at the London Scala User Group (video)
  - Another was working on Hugo, a static blog generator written in Go. I was interested, but I couldn’t be in two places at the same time: I’d like to do away with setting up WordPress and a database, and return to using Emacs orgmode for my notes.
  Finding your group – Pairing
  
  Now that we know who’s working on what, it becomes easy to find the group we’d like to work with. Having found the openjdk group, each of us explained where we were on the learning curve: some were having issues with the virtual machines, some with getting around Linux, some with understanding the relationships between the main JDK components. Some were further ahead – they had attended other sessions previously. We coalesced around Mani, around each other, asked for help, received help, and began experimenting. Having the prepackaged virtual machines helped much.
  
  We followed two documents of instructions to get started:
  - The beginner’s guide – google-doc-1.
  - The intermediate guide – google-doc-2
  One the attendees had already downloaded the 2 virtual machines that were created for developing openjdk. The links to the virtual machines are kept up-to-date in the beginner’s guide. I was working on the virtual machine that had the jdk sources in Eclipse, not the one that uses IntelliJ for its IDE. Retrieving the sources of jdk9 and building it consumed most of virtual machines space on the hard disk. Because of this, I skipped the section on building jdk9 and focused on those instructions which apply to jdk8 – I had to make the most of the day. Expanding the size of the virtual machine’s hard disk was something I could do later.
  
  Level 1 directory hierarchy
  
  Two questions occurred to me: the first is how do you grasp the different components that make up the JDK, and how quickly can you do that? How are they structured? What’s the biggest component? One way to see the structure of the jdk components is to the UNIX tree command. The one below shows the tree structure of the first level hierarchy of the openjdk.
  
  But it’s much easier to visualise these components, their size and complexity using SonarQube. Most tools that are used to build and test the jdk predate Maven, Hudson/Jenkins, and SonarQube. Hence the reason why some jdk components will not appear in SonarQube’s reports.
  
  For a codebase that we’re new to, using these tools is a quick way of understanding their structure and complexity. On any new project, I always ask for documentation of the application. Not getting it, or finding it non-existent, I would mentally add a percentage to the estimate I had in mind. Now with tools like SonarQube, if allowed to use them, would reduce the time to build up knowledge of an application.
  
  The second was: the virtual machine we were working on had three versions of Java; we were installing a fourth – so, how are these different versions used in build and testing a new version?
  
  Using several jdk versions, and keeping up
  
  What I found interesting was how the different versions of Java are needed to build and test new versions. At one of the LJC sessions on the new version of the JMS API, much was said about how it uses the new features of Java 6 and 7, and I never understood why it was so or why it had to be. Why should new versions of the Java language necessitate a re-write, or at least the perception of one, of the components that make up the Java EE platform? Doesn’t this seem like a waste of time and effort?
  
  Seeing how new versions of the Java language are built answered this question that has been lingering within me. You currently have Java 7; how would you build Java 8? Isn’t it by using Java 7:
  - Using Java 7, write the new feature that you need for Java 8 – (I’m using Java as the umbrella term for both the jdk and the jre).
  - Test that Java 7 compiles your new Java 8 feature. Also ensure that the test you’ve written passes in Java 7.
  - Write a program to use the new Java 8 feature. Compile and run it using Java 8. Ensure that the test you’ve written in Java 8 for your program passes.
  - Now you can go back to Java 7, and mark your new feature as complete.
  This process is also what the jdk test suite (jtreg) allows us to test. There are more complex tests but that’s for another time.
  
  Extend this process to Java EE: it stands to reason that as new versions of the Java language are being created, the relevant components in Java EE will also need to be written using the features of the new Java version.
  
  What, then, does this mean for us who work with the different versions of both Java the language and Java EE? Can’t I just learn one version thoroughly and not trouble myself with these “new” features? The answer, as always, depends on what our work entails, and on what we can ignore, or pass by, without being culpable of incompetence in our work. I like how Cobbett uses the word ignorance, restricting it to the relation between all knowledge and that proportion of it that we’re expected to know:
  
  Ignorance consists in a want [lack] of knowledge of those things which your calling or state of life naturally supposes you to understand. A ploughman is not an ignorant man because he does not know how to read; if he knows how to plough. [1]
  
  Hammerton goes further. He shows how we’re qualified for our calling, or profession, partly by our knowledge and partly by our ignorance since “everything we learn affects the whole character of the mind.” I would re-phrase him thus: we call a small proportion of knowledge ignorance; whereas we call, as science, a larger proportion of it.“ This larger quantity,” he continues, “is recommended as an unquestionable good, but the goodness of it is entirely dependent on the mental product that we want. [2]
  
  Moreover, I think we’ll also save time, even in learning these new features if we know what problems these versions and platforms are attempting to solve. I think we know, or are learning, about them; and we should frequently bring them to mind again as new versions and technologies being released and weigh them. Consider Java EE – one central problem it attempts to solve is distributed computing: how do I, as a computer, communicate with another computer existing on some other network to get some work done? If that computer uses Java objects, how do I talk to it? Java EE provides Remote Method Invocations(RMI) or EJBs. What if that computer doesn’t use Java? If it uses HTTP, try Web Services over HTTP. But that requires me to wait for a response before I can continue with my work. I don’t want to wait; I have other things I could be doing while the other computer is processing my request. Ok, use Messaging which is in Java EE. As these initial solutions were improved, newer versions come out. At the same time, other problems were becoming apparent and were looked at, such as, how do we make it easier for the developers to use what we’re providing? how do we ensure consistency between those implementing these services?
  
  Knowing the problem, and recognising it as a problem, gives us a standard which allows us to consider the extent to which the solution addresses the problem, to compare the different solutions, and to determine how just and solid are the arguments in their favour. Then, perhaps an order of these solutions is established in our minds, ordered by how they address the problem – either addressing part of the problem or addressing the whole problem. That standard also becomes the criteria we use to classify these solutions. And each subsequent version or new technology can find its place in our mental catalogue. How do we go about learning about these problems and solutions?
  - Reading blogs – how many would you need to read, notwithstanding the weak reasoning in some, or the repeated and diluted information in others?
  - How about writing sample programs – how many would you have to write to determine the correct behaviour for all scenarios? How would you know all the scenarios that are likely to occur?
  - Reading about the different frameworks, and probably their source code – how many to go through?
  - What about StackOverflow? How about mailing lists? Or even books?
  Of course, each has its place. But for a comprehensive view which, like a map of a city, shows you the major towns, their relation to each other, in terms of distance and size, and leaves you free to decide how to get from one town to the other, there’s no better place to start than by reading the Specifications – those of the Java language itself and those of Java EE, the Java Specification Requests (JSR). What I quoted from Hammerton still applies: “the goodness of it is entirely dependent on the mental product that we want.” The best expression on comprehensive views that I could find was Cardinal Newman’s:
  
  . . . we cannot gain real knowledge on a level ; we must generalize, we must reduce to method, we must have a grasp of principles, and group and shape our acquisitions by means of them. It matters not whether our field of operation be wide or limited ; in every case, to command it, is to mount above it. Who has not felt the irritation of mind and impatience created by a deep, rich country, visited for the first time, with winding lanes, and high hedges, and green steeps, and tangled woods, and every thing smiling indeed, but in a maze? The same feeling comes upon us in a strange city, when we have no map of its streets. Hence you hear of practised travellers, when they first come into a place, mounting some high hill or church tower, by way of reconnoitring its neighbourhood. In like manner, you must be above your knowledge, not under it, or it will oppress you ; and the more you have of it, the greater will be the load. . . Instances abound; there are authors who are as pointless as they are inexhaustible in their literary resources. They measure knowledge by bulk, without symmetry, without design. [3]
  
  Here are some high hills from which to reconnoitre the Java EE neighbourhood: JEE 5 (JSR-244) ; JEE 6 (JSR-316); JEE 7 (JSR-342). Page 6 of each of those JSRs has a diagram showing what the new version contributes to the old one, and the context of the subsequent JSRs; just as the Executive Summary of Annual Reports describes the business and the environment in which it operates.
  
  References
  1. William Cobbett, (1829), Advice to Young Men, and (Incidentally) to Young Women, in the Middle and Higher Ranks of Life, p. 119. Online pdf.
  2. Philip Gilbert Hammerton, (1873), The Intellectual Life, p. 52
  3. John Henry Cardinal Newman, (1886), The Idea of a University, 6th ed., pp. 139-140. Online PDF.
  Share this:
  Click to share on Twitter (Opens in new window)
  Click to share on LinkedIn (Opens in new window)
  Click to email this to a friend (Opens in new window)
  Like this:
  Like Loading...
  Posted in Java, OpenJDK | 0 Comments | Tagged hackday, Java, ljc, london-java-community, openjdk
- Long articles – how come?
  
  Posted at 21:41 by Julius Gamanyi, on February 5, 2014
  At times, what we write ends up being longer than we thought, and we’re naturally uneasy that the length of it will dissuade our fellow readers from proceeding. In my previous entries is one sentence that I had started in order to justify the length of that article: that while considering the reader’s time and attention, it was in proportion to the subject-matter. But, in hastening to describe the event to you, I left the thought there incomplete. Now, adding a little to that thought here, is what this entry is about.
  
  When we come across long articles, one of our initial reactions is reaching for that common, though inaccurate, saying, that “a picture is worth a thousand words,” placing it next to the article, and wondering whether it imperceptibly escaped the writer, while we ourselves are subjected to thousands of words when (or so we think), for the same purpose, a couple of pictures would have been just as adequate.
  
  All of which could be true; yet, keeping articles short is often not possible, at least of those that I’ve tried to write. These have been on events whose content I thought worthwhile to transcribe. I am fully conscious of how we all are pressed for time, and how difficult it is to retain anyone’s attention for a long time; and how, even in those moments of relaxation or idleness, we prefer almost any thing that doesn’t tax our attention for long. But we do make time, and compel our attention, for those things we consider worthwhile.
  
  It’s out of this concern, at least in part, that for those blog entries describing the events, I determined to make one or two statements to explain why the length is in proportion to the content. I may be going to more events, which means that, for subsequent blog entries, I’ll probably be repeating those statements. So, applying the DRY (Don’t Repeat Yourself) principle, I thought it convenient to have such an explanation in one place which I can refer to.
  
  As for that common saying, “A picture is worth a thousand words,” wherever it’s appropriately applied, I would add “that describe it.” Consider this: here is a picture; is it worth any thousand words? Would it be worth the first thousand words in a dictionary? What about the last thousand words? I’m accounting for only the number of words, not the “picture,” or the “words” used, or the standard of “worthiness” appealed to.
  
  Now, at these events, there are more things to describe than I have the inclination, and the ability to do so strikingly: there are those one-on-one conversations you have with others who are attending, either during the breaks or over drinks; there are those numerous hints from the expressions of people’s faces, their varying modulation of voice, and their actions which gradually rise from expressing nervousness to confidence; all of which would occupy a curious observer because of the probable lessons they contain.
  
  Furthermore, on stage, all these are somewhat magnified. There, we see the earnestness of the speakers, which diverts us from the familiarity of the day’s routine; and which fixes our attention, at least for a while, on our temporary instructors and on their subject-matter. Stranger still, even those plain announcements take a transient hold on us.
  
  To describe all these would take much more than a thousand words. So far, I, like some others, have limited these summaries to those talks that we’ve been to, and take it for granted that the contents of those talks are able, by themselves, to sustain your interest while reading about them in more than a thousand words.
  
  As always, I’m happy to be corrected.
  
  For others going to events, and writing summaries, I can’t wait to read them, however long they turn out to be.
  Share this:
  Click to share on Twitter (Opens in new window)
  Click to share on LinkedIn (Opens in new window)
  Click to email this to a friend (Opens in new window)
  Like this:
  Like Loading...
  Posted in Writing | 2 Comments | Tagged article, long-form, Writing
- JBoss Enterprise Forum, and the red hat goody
  
  Posted at 09:56 by Julius Gamanyi, on February 22, 2013
  A summary of this month’s JBoss Forum on Integration consisting of:
  - a description of the venue, speakers, and audience;
  - short summaries on what each speaker spoke about.
  This short overview I have taken from my notes supported by my memory. I’ve verified the information that’s open to the public. Yet, inaccuracies and errors, if any, are my own.
  
  At the entrance to the Stationer’s Hall
  
  Yes, I couldn’t resist Red Hat’s red hat. I received one at the JBoss Enterprise Forum where Integration was the focus. This was on Thursday, 7th February 2013 at the Stationer’s Hall; a hall, well preserved from the 14th Century, and rich in history.
  
  Though the hall’s history was a conversation starter, Integration was the theme. Red Hat had chosen its speakers well – addressing both the business and technical aspects of Red Hat and Integration. These were:
  - Werner Knoblich, VP and General Manager of Red Hat EMEA;
  - James Strachan, Senior Consultant, Software Engineering, Red Hat; (He created the Groovy programming language)
  - Rob Davies, Technical Directory for Fuse Engineering, Red Hat; (One of the authors of the book, “ActiveMQ in Action”)
  - Steve Gaines, Head of Middleware, Red Hat UK and Ireland.
  The audience was varied; varied in where they work – some in private companies, in institutions of education, in public sector organisations, some as industry analysts; varied in what they do, in their interests, concerns, and outlook; out of which Steve Gaines addressed three important ones bringing all the rest in harmony, as the different musical notes, when suitably combined, form a harmonious sound.
  
  The start of the day was an indication that Red Hat had arranged the sessions optimally – they started with breakfast 🙂
  
  Then onto the business overview, followed by the theoretical concepts of Integration and Messaging. After this was a short coffee break. Then James Strachan demonstrated Integration using Apache Camel with Fuse IDE. Next was Steve’s short and well-arranged talk, which led into the Question and Answer (Q & A) session.
  
  Werner explained three important things:
  - That Open Source was not Red Hat’s business model. Rather, it was the way that Red Hat developed software;
  - Red Hat’s acquisition of FuseSource (link) gives Red Hat a stepping stone (and a place) into Enterprise Integration, which is to become part of their product suite centred around Integration.
  - Red Hat’s acquisition of Polymita (link) means that Red Hat is moving into the BPM (Business Process Management).
  In this way, Red Hat covers two areas: the front end with BPM; the middle end with FuseSource, and back end with the JBoss Application Server.
  
  After the sessions with James and Rob, two questions required fuller explanations from the speakers, namely:
  1. In JBoss, what is the recommended way to do Messaging to enable Integration without using standalone Messaging Providers?
  2. What’s the relation between FuseSource Apache ActiveMQ and Apache Camel?
  As to the first question, the background is this: in the JBoss Application Server (AS) 4, there was a JBossMQ component which you could use for messaging. Then in JBoss AS 5, 6, and 7, JBoss has a messaging component, which uses HornetQ internally. And now that JBoss has acquired FuseSource, which comes with its own FuseMQ, there’s more choice. What JBoss would like to do is to have one way to do messaging in the future, and that’s by using FuseMQ.
  
  What then is FuseMQ and how is related to FuseSource? FuseMQ is a product developed by FuseSource. Building on top of ActiveMQ, FuseSource has made FuseMQ to address few important requirements of enterprise messaging, such as Clustering and High Availability.
  Another requirement which FuseSource seeks to satisfy is that of providing patches and upgrades as soon as possible, if it’s part of your agreement (Service Level Agreement – SLA) with them. Suppose that during production, you found a FuseMQ (or ActiveMQ) bug which affects your application, submitted it, and according to its severity and SLA, required a patch in 48 hours, then FuseSource can provide the patch. If the same bug was submitted to the Apache Software Foundation (ASF), ASF would need at least 72 hours to vote to include the bug fix in the next release.
  
  From the Apache HTTP Server documentation, we have these statements which apply to the ASF projects:
  
  In fact, each Apache Software Foundation project has its own PMC (Project Management Committee), to determine committers, project direction and overall management. . . .
  The project is a meritocracy — the more work you have done, the more you will be allowed to do. The group founders set the original rules, but they can be changed by vote of the active PMC members. There is a group of people who have logins on our server and access to the source code repositories. Everyone has read-only access to the repositories. Changes to the code are proposed on the mailing list and usually voted on by active members — three +1 (‘yes’ votes) and no -1 (‘no’ votes, or vetoes) are needed to commit a code change during a release cycle; docs are usually committed first and then changed as needed, with conflicts resolved by majority vote. . . .
  Anyone on the mailing list can vote on a particular issue, but only those made by active members or people who are known to be experts on that part of the server [application] are counted towards the requirements for committing. Vetoes must be accompanied by a convincing technical justification.
  
  Since some of those who develop ActiveMQ, i.e., committers, work for FuseSource and FuseMQ is a fork of ActiveMQ, FuseSource is not as restrained, and is therefore free to provide patches when you need them. Later on, these patches are merged into the main ActiveMQ branch, after the usual ASF voting system.
  
  The relation and process described above exists between, and is applicable to, Apache Camel and the FuseSource’s Mediation Router.
  
  Steve Gaines was the final speaker. Using four case studies as examples, he described the three requirements of three enterprises that ActiveMQ was able to satisfy. Naturally, the numbers (or metrics) are still exciting to see.
  - Performance: For this example, their client, through ActiveMQ, was able to handle 32,000 transaction per second. I don’t remember if, in this case, transactions mean the same thing as messages. But since the context is Messaging and Integration, I’ll assume so for now.
  Nevertheless, the default implementation of ActiveMQ can handle 6000 messages per second, assuming that the rate you produce messages is at least the same rate that the receiver will consume them. Imagine producing 6000 message per second but the receiver consuming 10 messages per second. And of course, before discerning this, you raise a defect with ActiveMQ 🙂
  - Global Scalability: For this client (SpecSavers), the challenge was threefold: rolling out Messaging to 1900 global retail stores, managing the installations, and affording to pay for the product to use in that many stores. The installation and service costs of ActiveMQ made it attractive to SpecSavers.
  - Proven Enterprise Quality of Service (QoS): this client (CERN) cared about running the operational grid for the Hadron Collider. The goal here was to distribute 100, 000 messages in more than 140 facilities in 20 countries.
  You’ve got to admit, that’s an impressive list of what JBoss and ActiveMQ were able to accomplish.
  
  red hat in the office
  
  During the demo and Q & A sessions, James Strachan, using the Fuse IDE, showed us how easy it is to use Apache Camel to integrate several systems. In addition, with Camel, you’re middleware logic is separate from your business logic; and this makes testing integration simple. Because most of the Camel classes have corresponding JMX MBeans, Fuse IDE takes advantage of that to make it easy to visualise as messages pass through Camel and are routed to different destinations.
  
  I enjoyed this forum; and it wasn’t all because of the red hat.
  Share this:
  Click to share on Twitter (Opens in new window)
  Click to share on LinkedIn (Opens in new window)
  Click to email this to a friend (Opens in new window)
  Like this:
  Like Loading...
  Posted in Java, JBoss, Open Source | 0 Comments | Tagged activemq, fusesource, jboss, redhat
- Recent Posts
  - Wardley Maps — an Illustration from Gerstner’s book —Part 2 June 18, 2019
  - Adapting to PARA using GitLab May 30, 2019
  - Wardley Maps in drawio March 25, 2019
  - Wardley Maps — an Illustration from Gerstner’s book December 28, 2018
  - The Journey Continues November 12, 2018
- Browse by Categories
  Browse by Categories
- Archives
  Archives
- Except where otherwise noted, this work is licensed under a Creative Commons Attribution 4.0 International License.

%d bloggers like this: